- Dec 06, 2018
-
-
Richard Levitte authored
[skip ci] Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7792)
-
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
[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): OPENSSL_SHLIB_VERSION We also provide a macro that contains the release date. This is not part of the version number, but is extra information that we want to be able to display: OPENSSL_RELEASE_DATE Finally, also provide the following convenience functions: const char *OPENSSL_version_text(void); const char *OPENSSL_version_text_full(void); The following macros and functions are deprecated, and while currently existing for backward compatibility, they are expected to disappear: OPENSSL_VERSION_NUMBER OPENSSL_VERSION_TEXT OPENSSL_VERSION OpenSSL_version_num() OpenSSL_version() Also, this function is introduced to replace OpenSSL_version() for all indexes except for OPENSSL_VERSION: OPENSSL_info() For configuration, the option 'newversion-only' is added to disable all the macros and functions that are mentioned as deprecated above. Reviewed-by: -
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:
-
