- Dec 06, 2018
-
-
Richard Levitte authored
[skip ci] Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7786)
-
Richard Levitte authored
[skip ci] Reviewed-by:
-
Richard Levitte authored
[skip ci] Reviewed-by:
-
Richard Levitte authored
[skip ci] Reviewed-by:
-
Richard Levitte authored
[skip ci] Reviewed-by:
-
Richard Levitte authored
[skip ci] Reviewed-by:
-
Richard Levitte authored
[skip ci] Reviewed-by:
-
Richard Levitte authored
[skip ci] Reviewed-by:
-
Richard Levitte authored
[skip ci] Reviewed-by:
-
Richard Levitte authored
[skip ci] Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
This applies to the 'master' git branch and OpenSSL version 3.0.0 and up. Pre-3.0.0 versions retain the previous license. The boilerplate will change in increments after this change. Reviewed-by:
-
Richard Levitte authored
Make it just say "the License", which refers back to the standard boilerplate. Reviewed-by:
-
Richard Levitte authored
Previously, the API version limit was indicated with a numeric version number. This was "natural" in the pre-3.0.0 because the version was this simple number. With 3.0.0, the version is divided into three separate numbers, and it's only the major number that counts, but we still need to be able to support pre-3.0.0 version limits. Therefore, we allow OPENSSL_API_COMPAT to be defined with a pre-3.0.0 style numeric version number or with a simple major number, i.e. can be defined like this for any application: -D OPENSSL_API_COMPAT=0x10100000L -D OPENSSL_API_COMPAT=3 Since the pre-3.0.0 numerical version numbers are high, it's easy to distinguish between a simple major number and a pre-3.0.0 numerical version number and to thereby support both forms at the same time. Internally, we define the following macros depending on the value of OPENSSL_API_COMPAT: OPENSSL_API_0_9_8 OPENSSL_API_1_0_0 OPENSSL_API_1_1_0 OPENSSL_API_3 They indicate that functions marked for deprecation in the corresponding major release shall not be built if defined. Reviewed-by:Tim Hudson <tjh@openssl.org> Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
We're strictly use version numbers of the form MAJOR.MINOR.PATCH. Letter releases are things of days past. The most central change is that we now express the version number with three macros, one for each part of the version number: OPENSSL_VERSION_MAJOR OPENSSL_VERSION_MINOR OPENSSL_VERSION_PATCH We also provide two additional macros to express pre-release and build metadata information (also specified in semantic versioning): OPENSSL_VERSION_PRE_RELEASE OPENSSL_VERSION_BUILD_METADATA To get the library's idea of all those values, we introduce the following functions: unsigned int OPENSSL_version_major(void); unsigned int OPENSSL_version_minor(void); unsigned int OPENSSL_version_patch(void); const char *OPENSSL_version_pre_release(void); const char *OPENSSL_version_build_metadata(void); Additionally, for shared library versioning (which is out of scope in semantic versioning, but that we still need... -
Richard Levitte authored
This is in preparation for a switch to MAJOR.MINOR.PATCH versioning and calling the next major version 3.0.0. Reviewed-by:
-
Richard Levitte authored
This is in preparation for new versioning scheme, where the recommendation is to start deprecations at major version boundary. Reviewed-by:
-
- Dec 05, 2018
-
-
Matt Caswell authored
Fix some issues in tls13_hkdf_expand() which impact the above function for TLSv1.3. In particular test that we can use the maximum label length in TLSv1.3. Reviewed-by:
-
Matt Caswell authored
This reverts commit ec0c5f56 . SSL_export_keying_material() may use longer label lengths. Fixes #7712 Reviewed-by:
-
Andy Polyakov authored
Fixed-top interfaces tolerate zero-padded inputs and facilitate constant-time-ness. bn_div_fixed_top tolerates zero-padded dividend, but not divisor. It's argued that divisor's length is public even when value is secret. [extended tests] Reviewed-by:
Paul Dale <paul.dale@oracle.com> Reviewed-by:
-
Andy Polyakov authored
and add template for constant-time bn_div_3_words. Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
It's being replaced with constant-time alternative. Reviewed-by:
-
- Dec 04, 2018
-
-
Matt Caswell authored
Reviewed-by:
-
- Dec 03, 2018
-
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Check that s is less than the order before attempting to verify the signature as per RFC8032 5.1.7 Fixes #7693 Reviewed-by:
-
Richard Levitte authored
Expand the text on deprecation to be more descriptive and to refer back to openssl_user_macros(7). Incidently, this required a small change in util/find-doc-nits, to have it skip over any line that isn't part of a block (i.e. that hasn't been indented with at least one space. That makes it skip over deprecation text. Reviewed-by:
-
