- 07 3月, 2018 11 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
BIO_get_mem_data() and BIO_get_mem_ptr() assign to *pp, not pp Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5544)
-
由 Andy Polyakov 提交于
When running iOS application from command line it's impossible to get past the failing capability detection. This is because it's executed under debugger and iOS debugger is impossible to deal with. [If Apple implements SHA512 in silicon, it would have to be detected with sysctlbyname.] Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Andy Polyakov 提交于
-fno-common was removed for all Darwin targets in 0c873419 with rationale "it's either 'ranlib -c' or '-fno-common'." However, it's still absolutely required in 32-bit darwin-ppc-cc. And when trying things out I didn't quite see why it was formulated as one-or-another choice, as 'ranlib -c' shouldn't [and doesn't] have problems with object modules without commons. [Well, to be frank, I didn't manage to reproduce the problem the modification was meaning to resolve either...] Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5533)
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5533)
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5533)
-
由 knekritz 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5372)
-
由 Alex Gaynor 提交于
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5525)
-
由 Bernd Edlinger 提交于
Had been observed with recent gcc-8 snapshot and $ ./config --strict-warnings enable-asan Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5519)
-
由 Kurt Roeckx 提交于
We currently don't support the algorithm from NIST SP 800-90C 10.1.2 to use a weaker DRBG as source Reviewed-by: NDr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> GH: #5506
-
由 Kurt Roeckx 提交于
It was calling the BN_rand() when it should have call BN_priv_rand() Reviewed-by: NTim Hudson <tjh@openssl.org> GH: #5514
-
- 05 3月, 2018 8 次提交
-
-
由 Tomas Mraz 提交于
Either files or directories of *.cnf or *.conf files can be included. Recursive inclusion of directories is not supported. Reviewed-by: NAndy Polyakov <appro@openssl.org> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5351)
-
由 Todd Short 提交于
This fixes an issue raised in PR #4964 by kaduk. Reviewed-by: NBen Kaduk <kaduk@mit.edu> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5491)
-
由 Matt Caswell 提交于
They are valid for use in a CertificateRequest message, but we did not allow it. If a server sent such a message using either of those two extensions then the handshake would abort. This corrects that error, but does not add support for actually processing the extensions. They are simply ignored, and a TODO is inserted to add support at a later time. This was found during interoperability testing with btls: https://gitlab.com/ilari_l/btls Prompted by these errors I reviewed the complete list of extensions and compared them with the latest table in draft-24 to confirm there were no other errors of a similar type. I did not find any. Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/5490)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/5470)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/5470)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/5470)
-
由 Alex Gaynor 提交于
Reviewed-by: NAndy Polyakov <appro@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5508)
-
由 Rich Salz 提交于
Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5504)
-
- 04 3月, 2018 7 次提交
-
-
由 Richard Levitte 提交于
Rely on the build.info constructor to do the right thing. Fixes #5500 Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5501)
-
由 Andy Polyakov 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/5493)
-
由 Andy Polyakov 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/5493)
-
由 Andy Polyakov 提交于
Debugging asserts had implicit casts that triggered the warnings. However, instead of making the casts explicit it's more appropriate to perform checks that ensure that implicit casts were safe. ec/curve448/scalar.c: size_t-fy scalar_decode_short. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5494)
-
由 Andy Polyakov 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5494)
-
由 Bernd Edlinger 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5489)
-
由 Alex Gaynor 提交于
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5498)
-
- 02 3月, 2018 6 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/5481)
-
由 Matt Caswell 提交于
This adds the Ed448 test vectors from RFC8032 and the X448 test vectors from RFC7748. Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/5481)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/5481)
-
由 Matt Caswell 提交于
This adds all of the relevant EVP plumbing required to make X448 and Ed448 work. Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/5481)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/5481)
-
由 Ivan Filenko 提交于
CLA: trivial Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/5458)
-
- 01 3月, 2018 8 次提交
-
-
由 Brad Spencer 提交于
CLA: trivial Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/4966)
-
由 Andy Polyakov 提交于
Why is it redundant? We're looking at carry from addition of small, 11-bit number to 256-bit one. And carry would mean only one thing, resulting first limb being small number and remaing ones - zeros. Hence adding 38 to first limb can't carry. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5476)
-
由 Benjamin Kaduk 提交于
When early data support was first added, this seemed like a good idea, as it would allow applications to just add SSL_read_early_data() calls as needed and have things "Just Work". However, for applications that do not use TLS 1.3 early data, there is a negative side effect. Having a nonzero max_early_data in a SSL_CTX (and thus, SSL objects derived from it) means that when generating a session ticket, tls_construct_stoc_early_data() will indicate to the client that the server supports early data. This is true, in that the implementation of TLS 1.3 (i.e., OpenSSL) does support early data, but does not necessarily indicate that the server application supports early data, when the default value is nonzero. In this case a well-intentioned client would send early data along with its resumption attempt, which would then be ignored by the server application, a waste of network bandwidth. Since, in order to successfully use TLS 1.3 early data, the application must introduce calls to SSL_read_early_data(), it is not much additional burden to require that the application also calls SSL_{CTX_,}set_max_early_data() in order to enable the feature; doing so closes this scenario where early data packets would be sent on the wire but ignored. Update SSL_read_early_data.pod accordingly, and make s_server and our test programs into applications that are compliant with the new requirements on applications that use early data. Fixes #4725 Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5483)
-
由 Kurt Roeckx 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> GH: #4672
-
由 David Makepeace 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/5477)
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4008)
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4008)
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4008)
-