RFC adding third party Ed25519, HPKE, and CBOR libs #208
Conversation
rfcs/additional_cypto_cbor_libs.md
Outdated
| An Ed25519 Python implementation: | ||
| https://github.com/pyca/ed25519/blob/main/ed25519.py |
There was a problem hiding this comment.
This appears to be CC0, which I know different companies have differing policies around, both in terms of usage and any potential contributions.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
wptserve needs to be able to decrypt and decode requests, and then encode and encrypt responses.
No description provided.