- 10 4月, 2018 3 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5918)
-
由 Andy Polyakov 提交于
The warning reads "[cast] may cause misaligned access". Even though this can be application-supplied pointer, misaligned access shouldn't happen, because structure type is "encoded" into data itself, and application would customarily pass correctly aligned pointer. But there is no harm in resolving the warning... Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5894)
-
由 Andy Polyakov 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 09 4月, 2018 2 次提交
-
-
由 Kunxian Xia 提交于
CLA: trivial Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5908)
-
由 Dr. Matthias St. Pierre 提交于
Fixes #5778, #5840 The various IS_*() macros did not work correctly for 8-bit ASCII characters with the high bit set, because the CVT(a) preprocessor macro and'ed the given ASCII value with 0x7F, effectively folding the high value range 128-255 over the low value range 0-127. As a consequence, some of the IS_*() erroneously returned TRUE. This commit fixes the issue by adding range checks instead of cutting off high order bits using a mask. In order avoid multiple evaluation of macro arguments, most of the implementation was moved from macros into a static function is_keytype(). Thanks to Румен Петров for reporting and analyzing the UTF-8 parsing issue #5840. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5903)
-
- 08 4月, 2018 10 次提交
-
-
由 Bernd Edlinger 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5900)
-
由 Andy Polyakov 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5887)
-
由 Andy Polyakov 提交于
Original logic was "if no records found *or* last one is truncated, then leave complete records in queue." Trouble is that if we don't pass on complete records and get complete packet in opposite direction, then queued records will go back to sender. In other words complete records should always be passed on. [Possible alternative would be to match direction in reconstruct_record.] Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5887)
-
由 Andy Polyakov 提交于
Even though removed calls were oiriginally added on Windows, problem they tried to mitigate is not Windows-specific. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5887)
-
由 Andy Polyakov 提交于
Without TCP_NODELAY alerts risk to be dropped between shutdown and close. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5887)
-
由 Andy Polyakov 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5887)
-
由 Andy Polyakov 提交于
HP-UX provides sockets symbols with incompatible prototypes under same name. This caused problems in 64-bit builds. Additional macros force unambiguous symbols with unambiguous prototypes. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5742)
-
由 Andy Polyakov 提交于
hpux64-parisc2-gcc is chosen based on gcc's bitness, and it was overriden unconditionally. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5742)
-
由 Andy Polyakov 提交于
HP-UX gmtime fails with ERANGE past 19011213204552Z, so skip some tests. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5742)
-
由 Rich Salz 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5889)
-
- 06 4月, 2018 5 次提交
-
-
由 Kaoru Toda 提交于
add_attribute_object and add_DN_object have similar code, so move it into a common function build_data. Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NBen Kaduk <kaduk@mit.edu> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4566)
-
由 Matt Caswell 提交于
Fixes #5873 Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5880)
-
由 Matt Caswell 提交于
Adding support for these operations for the EdDSA implementations makes pkeyutl usable for signing/verifying for these algorithms. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5880)
-
由 Rich Salz 提交于
The wrong "set" field was incremented in the wrong place and would create a new RDN, not a multi-valued RDN. RDN inserts would happen after not before. Prepending an entry to an RDN incorrectly created a new RDN Anything which built up an X509_NAME could get a messed-up structure, which would then be "wrong" for anyone using that name. Thanks to Ingo Schwarze for extensive debugging and the initial fix (documented in GitHub issue #5870). Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/5882)
-
由 Rich Salz 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5886)
-
- 05 4月, 2018 11 次提交
-
-
由 Matt Caswell 提交于
Fixes #5739 Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5800)
-
由 Matt Caswell 提交于
There are two undocumented DSA parameter generation options available in the genpkey command line app: dsa_paramgen_md and dsa_paramgen_q_bits. These can also be accessed via the EVP API but only by using EVP_PKEY_CTX_ctrl() or EVP_PKEY_CTX_ctrl_str() directly. There are no helper macros for these options. dsa_paramgen_q_bits sets the length of q in bits (default 160 bits). dsa_paramgen_md sets the digest that is used during the parameter generation (default SHA1). In particular the output length of the digest used must be equal to or greater than the number of bits in q because of this code: if (!EVP_Digest(seed, qsize, md, NULL, evpmd, NULL)) goto err; if (!EVP_Digest(buf, qsize, buf2, NULL, evpmd, NULL)) goto err; for (i = 0; i < qsize; i++) md[i] ^= buf2[i]; /* step 3 */ md[0] |= 0x80; md[qsize - 1] |= 0x01; if (!BN_bin2bn(md, qsize, q)) goto err; qsize here is the number of bits in q and evpmd is the digest set via dsa_paramgen_md. md and buf2 are buffers of length SHA256_DIGEST_LENGTH. buf2 has been filled with qsize bits of random seed data, and md is uninitialised. If the output size of evpmd is less than qsize then the line "md[i] ^= buf2[i]" will be xoring an uninitialised value and the random seed data together to form the least significant bits of q (and not using the output of the digest at all for those bits) - which is probably not what was intended. The same seed is then used as an input to generating p. If the uninitialised data is actually all zeros (as seems quite likely) then the least significant bits of q will exactly match the least significant bits of the seed. This problem only occurs if you use these undocumented and difficult to find options and you set the size of q to be greater than the message digest output size. This is for parameter generation only not key generation. This scenario is considered highly unlikely and therefore the security risk of this is considered negligible. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5800)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5800)
-
由 Matt Caswell 提交于
When libssl is initialised it will attempt to load any config file. This ensures any system_default configuration (as per https://github.com/openssl/openssl/pull/4848) is used. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5818)
-
由 Matt Caswell 提交于
The GOST engine needs to be loaded before we initialise libssl. Otherwise the GOST ciphersuites are not enabled. However the SSL conf module must be loaded before we initialise libcrypto. Otherwise we will fail to read the SSL config from a config file properly. Another problem is that an application may make use of both libcrypto and libssl. If it performs libcrypto stuff first and OPENSSL_init_crypto() is called and loads a config file it will fail if that config file has any libssl stuff in it. This commit separates out the loading of the SSL conf module from the interpretation of its contents. The loading piece doesn't know anything about SSL so this can be moved to libcrypto. The interpretation of what it means remains in libssl. This means we can load the SSL conf data before libssl is there and interpret it when it later becomes available. Fixes #5809 Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5818)
-
由 Richard Levitte 提交于
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/5877)
-
由 Andy Polyakov 提交于
Found by Coverity. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5834)
-
由 Andy Polyakov 提交于
By asking for port 0, you get a free port dynamically assigned by OS. TLSProxy::Proxy now asks for 0 and asks s_server to do the same. The s_server's port is reported in "ACCEPT" line, which TLSProxy::Proxy parses and uses. Because the server port is now a random affair in TLSProxy::Proxy, it's no longer possible to change it with the method 'server_port', and it has become an accessor only. For the sake of orthogonality, so has the method 'server_addr'. Remove all fork calls on Windows, as fork is not to be trusted there. This naturally minimized amount of fork calls on POSIX systems, to 1. Sink s_server's output to 'perl -ne print' which ensures that output is written strictly in lines. This keeps TAP parser happy. Improve synchronization in -naccept +n cases by establishing next connection to s_server *after* s_client finishes instead of before it starts. Improve error handling and clean up some methods. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5843)
-
由 Richard Levitte 提交于
The line saying ACCEPT is extended with a space followed by the the address and port combination on which s_server accepts connections. The address is written in such a way that s_client should be able to accepts as argument for the '-connect' option. Reviewed-by: NAndy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5843)
-
由 Richard Levitte 提交于
When these two functions returned zero, it could mean: 1. that an error occured. In their case, the error is an overflow of the pool, i.e. the correct response from the caller would be to stop trying to fill the pool. 2. that there isn't enought entropy acquired yet, i.e. the correct response from the caller would be to try and add more entropy to the pool. Because of this ambiguity, the returned zero turns out to be useless. This change makes the returned value more consistent. 1 means the addition of new entropy was successful, 0 means it wasn't. To know if the pool has been filled enough, the caller will have to call some other function, such as rand_pool_entropy_available(). Fixes #5846 Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/5876)
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5875)
-
- 04 4月, 2018 9 次提交
-
-
由 Matt Caswell 提交于
Configuration of TLSv1.3 ciphersuites wasn't working in some cases. Fixes #5740 Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5855)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5855)
-
由 Richard Levitte 提交于
We started using $(CPP) instead of $(CC) -E, with the assumption that CPP would be predefined. This is, however, not always true, and rather depends on the 'make' implementation. Furthermore, on platforms where CPP=cpp or something else other than '$(CC) -E', there's a risk that it won't understand machine specific flags that we pass to it. So it turns out that trying to use $(CPP) was a mistake, and we therefore revert that use back to using $(CC) -E directly. Fixes #5867 Note: this affects config targets that use Alpha, ARM, IA64, MIPS, s390x or SPARC assembler modules. Reviewed-by: NAndy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5872)
-
由 cedral 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/5799)
-
由 Bernd Edlinger 提交于
was pointed out in commit aef84bb4 differently. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5863)
-
由 Bernd Edlinger 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5856)
-
由 David Benjamin 提交于
felem_neg does not produce an output within the tight bounds suitable for felem_contract. This affects build configurations which set enable-ec_nistp_64_gcc_128. point_double and point_add, in the non-z*_is_zero cases, tolerate and fix up the wider bounds, so this only affects point_add calls where the other point is infinity. Thus it only affects the final addition in arbitrary-point multiplication, giving the wrong y-coordinate. This is a no-op for ECDH and ECDSA, which only use the x-coordinate of arbitrary-point operations. Note: ecp_nistp521.c has the same issue in that the documented preconditions are violated by the test case. I have not addressed this in this PR. ecp_nistp521.c does not immediately produce the wrong answer; felem_contract there appears to be a bit more tolerant than its documented preconditions. However, I haven't checked the point_add property above holds. ecp_nistp521.c should either get this same fix, to be conservative, or have the bounds analysis and comments reworked for the wider bounds. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5779)
-
由 Pecio 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NAndy Polyakov <appro@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5625)
-
由 Richard Levitte 提交于
Fail harshly (in debug builds) when rand_pool_acquire_entropy isn't delivering the required amount of entropy. In release builds, this produces an error with details. We also take the opportunity to modernise the types used. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5857)
-