-
Notifications
You must be signed in to change notification settings - Fork 4
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Based on the 3.0.8-1 wrap in Meson's WrapDB. Co-authored-by: Håvard Sørbø <[email protected]>
- Loading branch information
Showing
2,418 changed files
with
1,769,791 additions
and
104 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,19 @@ | ||
| Copyright (c) 2021 The Meson development team | ||
|
|
||
| Permission is hereby granted, free of charge, to any person obtaining a copy | ||
| of this software and associated documentation files (the "Software"), to deal | ||
| in the Software without restriction, including without limitation the rights | ||
| to use, copy, modify, merge, publish, distribute, sublicense, and/or sell | ||
| copies of the Software, and to permit persons to whom the Software is | ||
| furnished to do so, subject to the following conditions: | ||
|
|
||
| The above copyright notice and this permission notice shall be included in all | ||
| copies or substantial portions of the Software. | ||
|
|
||
| THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR | ||
| IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, | ||
| FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE | ||
| AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER | ||
| LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, | ||
| OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE | ||
| SOFTWARE. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,113 +1,28 @@ | ||
| What This Is | ||
| ============ | ||
| # OpenSSL for Meson | ||
|
|
||
| This is a fork of [OpenSSL](https://www.openssl.org) to enable QUIC. In addition | ||
| to the website, the official source distribution is at | ||
| <https://github.com/openssl/openssl>. The OpenSSL `README` can be found at | ||
| [README-OpenSSL.md](https://github.com/quictls/openssl/blob/openssl-3.0.12%2Bquic/README-OpenSSL.md) | ||
| ## How this works? | ||
| TL;DR: this wrap abuses OpenSSL build system within Node.js. | ||
|
|
||
| This fork adds APIs that can be used by QUIC implementations for connection | ||
| handshakes. Quoting the IETF Working group | ||
| [charter](https://datatracker.ietf.org/wg/quic/about/), QUIC is a "UDP-based, | ||
| stream-multiplexing, encrypted transport protocol." If you don't need QUIC, you | ||
| should use the official OpenSSL distributions. | ||
| Node.js has OpenSSL built-in with additional scripting around it to generate configs for GYP build system and thus bypass OpenSSL's native build system. | ||
|
|
||
| The APIs here are used by Microsoft's | ||
| [MsQuic](https://github.com/microsoft/msquic) and Google's | ||
| [Chromium QUIC](https://chromium.googlesource.com/chromium/src/+/master/net/quic/) | ||
| This wrap abuses that feature by replacing bundled OpenSSL with upstream version, patching mentioned mechanism to also generate a bunch of `meson.build` files for different platforms and uses top-level `meson.build` to wire everything together. | ||
|
|
||
| We are not in competition with OpenSSL project. We informed them of | ||
| our plans to fork the code before we went public. We do not speak for the | ||
| OpenSSL project, and can only point to a | ||
| [blog post](https://www.openssl.org/blog/blog/2020/02/17/QUIC-and-OpenSSL/) and | ||
| [openssl-project email](https://github.com/quictls/openssl/discussions/54) | ||
| that provides their view of QUIC support. | ||
| During installation unmodified Node.js tarball will be downloaded, its bundled OpenSSL will be replaced with upstream version and patched with `meson.build` files, enabling ability to build OpenSSL with Meson 🎉. | ||
|
|
||
| As stated in their blog post, the OpenSSL team is focused on their 3.0 release | ||
| (released 2021-09-07), and does not intend to add QUIC functionality to 1.1.x. | ||
| There is a community need for a QUIC-capable TLS library. This fork is intended | ||
| as stopgap solution to enable higher level frameworks and runtimes to use QUIC | ||
| with the proven and reliable TLS functionality from OpenSSL. This fork will be | ||
| maintained until OpenSSL officially provides reasonable support for QUIC | ||
| implementations. | ||
| ## How to update to newer release | ||
| First, you may need to install some packages: | ||
| ``` | ||
| sudo dnf install -y nasm perl-FindBin perl-IPC-Cmd perl-Text-Template | ||
| ``` | ||
|
|
||
| This fork can be considered a supported version of | ||
| [OpenSSL PR 8797](https://github.com/openssl/openssl/pull/8797). | ||
| We will endeavor to track OpenSSL releases within a day or so, and there is an | ||
| item below about how we'll follow their tagging. | ||
| Unless Node.js changes the mechanism we abuse above (unlikely, but possible, please check the diff between corresponding versions), `generator.sh` file can be used. | ||
|
|
||
| On to the questions and answers. | ||
| Just update OpenSSL version in wrap file, update Node.js version in `generator.sh` file to such that contains matching OpenSSL version bundled with it and run `generator.sh` from the root of the repository: | ||
| ``` | ||
| subprojects/packagefiles/openssl/generator.sh | ||
| ``` | ||
|
|
||
| What about branches? | ||
| -------------------- | ||
| Generated files in `generated-config` directory, after which you can try to build it. `create_release.py` will run it as part of the release process, so it doesn't need to be included in Git. | ||
|
|
||
| We don't want to conflict with OpenSSL branch names. Our current plan is to append | ||
| `+quic`. Release tags are likely to be the QUIC branch with `-releaseX` appended. | ||
| For example, the OpenSSL tag `openssl-3.0.0` would have a branch named | ||
| `openssl-3.0.0+quic` and a release tag of `openssl-3.0.0+quic-release1`. | ||
|
|
||
| How are you keeping current with OpenSSL? | ||
| ----------------------------------------- | ||
|
|
||
| (In other words, "What about rebasing?") | ||
|
|
||
| Our plan is to always rebase on top of an upstream release tag. In particular: | ||
|
|
||
| - The changes for QUIC will always be at the tip of the branch -- you will know what | ||
| is from the original OpenSSL and what is for QUIC. | ||
| - New versions are quickly created once upstream creates a new tag. | ||
| - The use of git commands (such as `cherry`) can be used to ensure that all changes | ||
| have moved forward with minimal or no changes. You will be able to see | ||
| "QUIC: Add X" on all branches and the commit itself will be nearly identical on | ||
| all branches, and any changes to that can be easily identified. | ||
|
|
||
| What about library names? | ||
| ------------------------- | ||
|
|
||
| Library names will be the same, but will use a different version number. The version | ||
| numbers for the current OpenSSL libraries are `1.1` (for the 1.1.0 and 1.1.1 branches) | ||
| and `3` (for the 3.0 branch). We will be prefixing `81` (ASCII for 'Q') to | ||
| the version numbers to generate a unique version number. | ||
|
|
||
| - `libcrypto.so.81.3` vs `libcrypto.so.3` | ||
| - `libcrypto.so.81.1.1` vs `libcrypto.so.1.1` | ||
| - `libssl.so.81.3` vs `libssl.so.3` | ||
| - `libssl.so.81.1.1` vs `libssl.so.1.1` | ||
|
|
||
| The SONAME of these libraries are all different, guaranteeing the correct library | ||
| will be used. | ||
|
|
||
| ...and the executable? | ||
| ---------------------- | ||
|
|
||
| We currently do not have any plans to change the name, mainly because we | ||
| haven't made any changes there. If you see a need, please open an issue. | ||
|
|
||
| The `openssl version` command will report that it is `+quic` enabled. | ||
|
|
||
| ...and FIPS? | ||
| ------------ | ||
|
|
||
| We are not doing anything with FIPS. This is actually good news: you should | ||
| be able to load the OpenSSL 3.0 FIPS module into an application built against | ||
| this fork and everything should Just Work™. | ||
|
|
||
| How can I contribute? | ||
| --------------------- | ||
|
|
||
| We want any code here to be acceptable to OpenSSL. This means that all contributors | ||
| must have signed the appropriate | ||
| [contributor license agreements](https://www.openssl.org/policies/cla.html). We | ||
| will not ask for copies of any paperwork, you just need to tell us that you've | ||
| done so (and we might verify with OpenSSL). We are only interested in making it | ||
| easier and better for at least the mentioned QUIC implementations to use a variant | ||
| of OpenSSL. If you have a pull request that changes the TLS protocol, or adds | ||
| assembly support for a new CPU, or otherwise is not specific to enabling QUIC, | ||
| please contribute that to OpenSSL. This fork is intended to be a clean extension | ||
| to OpenSSL, with the deltas being specific to QUIC. | ||
|
|
||
| Who are you? | ||
| ------------ | ||
|
|
||
| This is a collaborative effort between [Akamai](https://www.akamai.com) and | ||
| [Microsoft](https://www.microsoft.com). We welcome anyone to contribute! | ||
| ## Acknowledgement | ||
| This OpenSSL port wouldn't be possible without [Node.js project](https://github.com/nodejs/node) under [MIT license](https://github.com/nodejs/node/blob/master/LICENSE), whose OpenSSL build system was decomposed and heavily refactored. |
Oops, something went wrong.