-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #7 from jschauma/main
add articles, fix a typo
- Loading branch information
Showing
1 changed file
with
3 additions
and
3 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 |
|---|---|---|
|
|
@@ -10,7 +10,7 @@ | |
| <body> | ||
| <h1 id="what-this-is">What This Is</h1> | ||
| <p>This is a fork of <a href="https://www.openssl.org">OpenSSL</a> to enable QUIC. In addition to the website, the official source distribution is at <a href="https://github.com/openssl/openssl" class="uri">https://github.com/openssl/openssl</a>. The OpenSSL <code>README</code> can be found at <a href="README-OpenSSL.md" class="uri">README-OpenSSL.md</a>.</p> | ||
| <p>This fork adds API that can be used by QUIC implementations for connection handshakes. Quoting the IETF Working group <a href="https://datatracker.ietf.org/wg/quic/about/">charter</a>, QUIC is a "UDP-based, stream-multiplexing, encrypted transport protocol." If you don't need QUIC, you should use the official OpenSSL distributions.</p> | ||
| <p>This fork adds an API that can be used by QUIC implementations for connection handshakes. Quoting the IETF Working group <a href="https://datatracker.ietf.org/wg/quic/about/">charter</a>, QUIC is a "UDP-based, stream-multiplexing, encrypted transport protocol." If you don't need QUIC, you should use the official OpenSSL distributions.</p> | ||
| <p>The API's here are used by Microsoft's <a href="https://github.com/microsoft/msquic">MsQuic</a>, and Google's <a href="https://chromium.googlesource.com/chromium/src/+/master/net/quic/">Chromium QUIC</a>, and others.</p> | ||
| <p>We are not in competition with OpenSSL project. | ||
| We informed them of our plans to fork the code before we went public. | ||
|
|
@@ -19,11 +19,11 @@ <h1 id="what-this-is">What This Is</h1> | |
| "https://www.mail-archive.com/[email protected]/msg02585.html">announced their plans</a> | ||
| to do their own QUIC implementation, now that the 3.0 release is done. | ||
| <p>There is a community need for a QUIC capable TLS library, for both the 3.0 and 1.1 streams. | ||
| 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.</p> | ||
| This fork is intended as a 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.</p> | ||
| <p>This fork can be considered a supported version of <a href="https://github.com/openssl/openssl/pull/8797">OpenSSL PR 8797</a>. 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.</p> | ||
| <p>On to the questions and answers.</p> | ||
| <h2 id="what-about-branches">What about branches?</h2> | ||
| <p>We don't want to conflict with OpenSSL branch names. Our plan is to append <code>+quic</code> to upstream tag names to create our branches. Release tags will be the upstream tag name with <code>-quic1</code> appended (where <code>1</code> will be the incrementing release number). For example, the OpenSSL tag <code>openssl-3.0.10</code> would have a branch named <code>openssl-3.0.10+quic</code> and a first release tag of <code>openssl-3.0.10-quic1</code>. Please note that this is <i>not</i> compatible with semantic versioning, as any version with a <code>-value</code> suffix is sorted before the version (i.e. <code>openssl-3.0.10-quic1</code> < <code>openssl-3.0.10</code>). Using a <code>+</code> can remediate thie, but some release tools don't like the <code>+</code>.</p> | ||
| <p>We don't want to conflict with OpenSSL branch names. Our plan is to append <code>+quic</code> to upstream tag names to create our branches. Release tags will be the upstream tag name with <code>-quic1</code> appended (where <code>1</code> will be the incrementing release number). For example, the OpenSSL tag <code>openssl-3.0.10</code> would have a branch named <code>openssl-3.0.10+quic</code> and a first release tag of <code>openssl-3.0.10-quic1</code>. Please note that this is <i>not</i> compatible with semantic versioning, as any version with a <code>-value</code> suffix is sorted before the version (i.e. <code>openssl-3.0.10-quic1</code> < <code>openssl-3.0.10</code>). Using a <code>+</code> can remediate this, but some release tools don't like the <code>+</code>.</p> | ||
| <h2 id="how-are-you-keeping-current-with-openssl">How are you keeping current with OpenSSL?</h2> | ||
| <p>(In other words, "What about rebasing?")</p> | ||
| <p>Our plan is to always rebase on top of an upstream release tag. In particular:</p> | ||
|
|
||