-
Notifications
You must be signed in to change notification settings - Fork 226
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.
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
OpenSSL dependencies list #39
Comments
Is this some legacy thing that can't be changed to use a different AEAD? Preliminary ECDSA signing support was just added in ring 0.13.0-alpha4, and the |
Yes, it's to access data from existing Firefox Sync clients. |
I'm currently trying to integrate biscuit (for JWKs) in order to drop the However, I couldn't find an accessor for the |
Later on, we might expand ring's API to be more accomodating to non-standard forms and other forms of keys, but looking at the backlog, that probably won't happen soon. The current design of ring is that we don't provide the X and Y coordinates intentionally. Instead we provide the entire public key in a long-ago-standardized form. In the case of JOSE they made a mistake and decided to make their own new format for public keys. So far, I've told JWT libraries that they should internally convert the standard form that ring provides into the form they need by parsing the standard form themselves. In the case of ECC public keys, the first byte is "0x04", the X coordinate is the first half of what's left, and the Y coordinate is the second half of what's left. So, I would submit a PR to biscuit to do that. |
Should be |
The standard form of the public key is exactly the same for both. |
Thank you Vlad, I've updated the list: we need |
If you use the |
We still need OpenSSL as part of SQLcipher (for logins, places) and for sync15-adapter, though. All our consumers of the FxA crate realistically still pull in OpenSSL. |
Those can be dealt with too. |
Our last OpenSSL dependant are:
|
* experiments and enrollment status are all stored in the DB. Only fetches experiments in the constructor if there are none in the DB, which doesn't smell like the right thing long term - otherwise though, you must explicitly call `update_experiments()`. We should work out what behaviour makes sense for apps here. * Fully implements the `opt_out` etc methods. Any experiment can be opted in to and opted out of, with this stored in the DB. Calling `update_experiments()` will not change the opted-on/out status - there's a new 'reset_enrollment` function that does though. Note that opting out is fully supported, but the expectation is that this must only be used in a dev or test context. * When `update_experiments()` is called, enrollments for experiments which no longer exist are removed, and new experiments are evaluated for enrollment. We don't emit any events yet, but we could. We do log so you can see things happening. We don't support experiments being paused, nor start and end dates for experiments, etc. * It allows you to opt in/out/etc to non-existing experiments - but they will be removed when `update_experiments()` is called (ie, it's treated as though the experiment was removed. We could fix this, but meh. * No longer hits the server as the SDK interface is constructed. * Our command-line utility `experiment.rs` supports all of this - use --help.
I believe that to simplify and shrink our Rust libraries builds, we should move away from OpenSSL.
Instead, we should use the ring rust library which doesn't need to be linked against a static library.
However,
ring
is still incomplete and we are missing some important crypto primitives, so we should consider this issue more as a laundry list.rustls-tls
feature ofreqwest
.┆Issue is synchronized with this Jira Story
The text was updated successfully, but these errors were encountered: