- Feb 27, 2018
-
-
xemdetia authored
CLA: trivial Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5473)
-
Rich Salz authored
And only generate one output "file" at a time for objects.pl Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5432)
-
Richard Levitte authored
Fixes #5471 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5472)
-
Richard Levitte authored
Fixes #5471 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5472)
-
Dr. Matthias St. Pierre authored
Fixes #5405, #1381 The base64 filter BIO reads its input in chunks of B64_BLOCK_SIZE bytes. When processing input in PEM format it can happen in rare cases that - the trailing PEM marker crosses the boundary of a chunk, and - the beginning of the following chunk contains valid base64 encoded data. This happened in issue #5405, where the PEM marker was split into "-----END CER" and "TIFICATE-----" at the end of the first chunk. The decoding of the first chunk terminated correctly at the '-' character, which is treated as an EOF marker, and b64_read() returned. However, when called the second time, b64_read() read the next chunk and interpreted the string "TIFICATE" as valid base64 encoded data, adding 6 extra bytes '4c 81 48 08 04 c4'. This patch restores the assignment of the error code to 'ctx->cont', which was deleted accidentally in commit 5562cfac and which prevents b64_read() from reading additional data on subsequent calls. This issue was observed and reported by Annie Yousar. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5422)
-
Matt Caswell authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
- Feb 26, 2018
-
-
Matt Caswell authored
Otherwise we get a use after free if the test order is randomised. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5467)
-
Andy Polyakov authored
Even though mlock(2) was standardized in POSIX.1-2001, vendors did implement it prior that point. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5460)
-
Andy Polyakov authored
fabs(3m) is customarily inlined, but it's not, one has to link with -lm. Since fabs(3m) is the only reference, it makes more sense to avoid it. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Tatsuhiro Tsujikawa authored
This commit adds SSL_export_keying_material_early() which exports keying material using early exporter master secret. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5252)
-
Richard Levitte authored
With this, we introduce the make variable 'libdir', which differs from 'LIBDIR' not only in casing, but also by being the absolute path to the library installation directory. This variable is intentionally compatible with the GNU coding standards. When --libdir is given an absolute path, it is considered as a value according to GNU coding standards, and the variables LIBDIR and libdir will be this: LIBDIR= libdir=/absolute/path When --libdir is given a relative path (just the name of the desired library directory), or not given at all, it is considered as a "traditional" OpenSSL value, and the variables LIBDIR and libdir will be this: LIBDIR=relativepath libdir=$(INSTALLTOP)/$(LIBDIR) Fixes #5398 Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5446)
-
- Feb 24, 2018
-
-
Andy Polyakov authored
makedepend makes lesser sense in a throw-away build like CI, but it spares some computational time, because with MSVC it takes separate per-file compiler invocation. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5452)
-
Andy Polyakov authored
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5449)
-
Andy Polyakov authored
As it turns out gcc -pedantic doesn't seem to consider __uint128_t as non-standard, unlike __int128 that is. Fix even MSVC warnings in curve25519.c. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5449)
-
Andy Polyakov authored
SPARC condition in __SIZEOF_INT128__==16 is rather performance thing than portability. Even though compiler advertises int128 capability, corresponding operations are inefficient, because they are not directly backed by instruction set. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5449)
-
Andy Polyakov authored
Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5447)
-
- Feb 23, 2018
-
-
Rich Salz authored
Reviewed-by: Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5439)
-
Bernd Edlinger authored
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5426)
-
Bernd Edlinger authored
Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5434)
-
Richard Levitte authored
[extended tests] Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2688)
-
Richard Levitte authored
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2688)
-
Richard Levitte authored
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2688)
-
Richard Levitte authored
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2688)
-
Richard Levitte authored
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2688)
-
Richard Levitte authored
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2688)
-
Richard Levitte authored
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2688)
-
Richard Levitte authored
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2688)
-
Richard Levitte authored
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2688)
-
Richard Levitte authored
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2688)
-
Richard Levitte authored
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2688)
-
Richard Levitte authored
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2688)
-
Pauli authored
The return at the end isn't reachable. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5442)
-
- Feb 22, 2018
-
-
Richard Levitte authored
The reason for this is that some of the C flags affect built in macros that we may depend on. Reviewed-by: Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5436)
-
Rich Salz authored
Reviewed-by: Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5433)
-
Steve Linsell authored
When compiling with -Wall on a machine with an old compiler it gives a false positive that the dc variable which is a structure of type DISPLAY_COLUMNS could be used uninitialised. In fact the dc variable's members will always get set in the case it is used, otherwise it is left uninitialised. This fix just causes the dc variable's members to always get initialised to 0 at declaration, so the false positive will not get flagged. Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5337)
-
Per Sandström authored
CLA: trivial fix typo: EC_point2buf => EC_POINT_point2buf Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5367)
-
Richard Levitte authored
Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5247)
-
Richard Levitte authored
The new message is geared toward issue reports Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5247)
-