Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RFC adding third party Ed25519, HPKE, and CBOR libs #208

Open
wants to merge 8 commits into
base: master
Choose a base branch
from
Open

RFC adding third party Ed25519, HPKE, and CBOR libs #208

Changes from 2 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
edb3a4a
Create additional_cypto_cbor_libs.md
JensenPaul Aug 21, 2024
31edd1d
clarify note on transpiling
JensenPaul Aug 22, 2024
e78ffac
add usage details
JensenPaul Aug 22, 2024
cb6ff54
add example APIs
JensenPaul Aug 23, 2024
d236bb8
Update additional_cypto_cbor_libs.md
JensenPaul Aug 27, 2024
606ed05
Update additional_cypto_cbor_libs.md
JensenPaul Aug 28, 2024
4c0957d
use markdown link instead of footnotes
JensenPaul Aug 29, 2024
c3d0435
We also need Python HPKE & CBOR libraries
JensenPaul Oct 30, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 34 additions & 0 deletions rfcs/additional_cypto_cbor_libs.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
# RFC 208: additional crypto and CBOR libraries

## Summary

Several new web APIs require additional cryptography and CBOR libraries to
properly test. These libraries are to support cryptography and the CBOR
JensenPaul marked this conversation as resolved.
Show resolved Hide resolved
protocols not otherwise supported in JavaScript or Python, namely Ed25519,
HPKE, and CBOR. There are open source libraries commonly available that
implement these protocols and have compatible licenses. This RFC proposes
adding such libraries to the tools/ directory so that web-platform-tests may
exercise and verify proper compatible implementations of these new web APIs.

## Details

We're proposing adding these libraries (or some very similar ones) to the
tools/ directory:
JensenPaul marked this conversation as resolved.
Show resolved Hide resolved

An Ed25519 Python implementation:
https://github.com/pyca/ed25519/blob/main/ed25519.py
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This appears to be CC0, which I know different companies have differing policies around, both in terms of usage and any potential contributions.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CC0 is broadly considered to be the legal equivalent to the colloquial definition of "public domain", so I don't expect that to be an issue, although perhaps @alex could weigh in.

Creative Commons (non-zero) is generally what triggers more paranoia across different companies. However, I am not sure what the policy is for Web Platform Tests.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have absolutely no context here, but:

That repo is a pure-Python, but somewhat optimized, implementation of ed25519. It was implemented by taking djb's original ed25519 Python code and optimizing it. djb's original implementation is listed as being licensed "in the public domain": https://ed25519.cr.yp.to/software.html. However, "public domain" is not a concept that exists in all jurisdictions, thus we licensed our modifications under the most permissive license that should work everywhere. For all practical purposes, I do believe anyone should be encumbered by this license.

All of that said, for 99.999% of use cases, you should get your ed25519 from pyca/cryptography, which is dual BSD-3-Clause/Apache-2 licensed. It will be much faster, etc. The only reason to use ed25519.py is if you have a use-case that absolutely requires it be pure python. Bootstrapping the python packaging ecosystem is the only real use case I'm aware of.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the use case here, wptserve, is in fact pure-Python, so ed25519.py is in fact a reasonable match for our needs.

CC0 licensing also sounds very permissive, and it looks like web-platform-tests already contains some CC0 licensed code: https://github.com/web-platform-tests/wpt/blob/master/images/wpt-pr-bot-logo/wpt-pr-bot-logo-darkblue.svg?short_path=d6712fa#L4

I think we've resolved all concerns here and so I'm going to resolve this thread. Feel free to unresolve this comment if this does pose a problem.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fact that wptserve is pure python doesn't really mean it needs to have only pure python dependencies. As the maintainer of ed25519.py, I think it'd be a mistake to use it unless you have immovable constraints like pip does.

But at any rate, you've got the licensing history, do as you please.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've certainly tried to avoid compiled dependencies — especially those that have more requirements to build above and beyond what CPython requires to build.

It's certainly the case that we care about being able to run WPT tests (and thus the server) on relatively unusual architectures/OSes (an obvious example is that some of the WebKit ports are still maintaining Linux/arm32 support, for which no cryptography wheels are available — and there's been reluctance to add all the dependencies to build cryptography into the image used — but also there are more extreme cases such as macOS on Apple Silicon prior to its public announcement); any time where we add a compiled dependency it potentially adds a whole load of "you need to install X, Y, and Z before you can install the Python dependencies".

Thus, in general, unless there's a very compelling reason, we've had a strong bias for pure-Python dependencies.


An HPKE JavaScript implementation:
https://github.com/dajiaji/hpke-js
JensenPaul marked this conversation as resolved.
Show resolved Hide resolved

A CBOR JavaScript implementation:
https://github.com/paroga/cbor-js/blob/master/cbor.js
JensenPaul marked this conversation as resolved.
Show resolved Hide resolved

## Risks

Users of these libraries may need to update them from time to time if new
functionality or fixes are required. This is likely not a big risk.

The HPKE library proposed may require inclusion of some other dependent
libraries and uses deno to build into a single JavaScript file. Perhaps
it's simplest to commit the single transpiled JavaScript file.
JensenPaul marked this conversation as resolved.
Show resolved Hide resolved