- 16 Nov, 2018 1 commit
-
-
Andy Polyakov authored
Reviewed-by:
Tim Hudson <tjh@openssl.org> Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7643)
-
- 15 Nov, 2018 9 commits
-
-
Richard Levitte authored
Without this precaution, we end up having directory targets depend on shlib object files for which there are no rules. Reviewed-by:
-
Richard Levitte authored
Fixes #7641 [extended tests] Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7642)
-
Matt Caswell authored
A missing SSLfatal call can result in an assertion failed error if the condition gets triggered. Reviewed-by:
-
Antoine Salon authored
Signed-off-by:
Antoine Salon <asalon@vmware.com> Reviewed-by:
Paul Dale <paul.dale@oracle.com> Reviewed-by:
-
Antoine Salon authored
Signed-off-by:
-
Antoine Salon authored
Signed-off-by:
-
Antoine Salon authored
Signed-off-by:
-
Antoine Salon authored
Signed-off-by:
-
Antoine Salon authored
Signed-off-by:
-
- 14 Nov, 2018 1 commit
-
-
Matt Caswell authored
Reviewed-by:
-
- 13 Nov, 2018 6 commits
-
-
Richard Levitte authored
Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/7633)
-
Richard Levitte authored
We therefore must add defaults. Reviewed-by:
Viktor Dukhovni <viktor@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7626)
-
Richard Levitte authored
When libssl and libcrypto are compiled on Linux with "-rpath", but not "--enable-new-dtags", the RPATH takes precedence over LD_LIBRARY_PATH, and we end up running with the wrong libraries. This is resolved by using full (or at least relative, rather than just the filename to be found on LD_LIBRARY_PATH) paths to the shared objects. Reviewed-by:
-
Shane Lontis authored
Reviewed-by:
-
Richard Levitte authored
HTML comments aren't rendered, so markdown link syntax is irrelevant inside them, and more confusing than useful. Reviewed-by:
Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/7632)
-
Richard Levitte authored
This will hopefully help directing our users to better user support resources as well as give some relevant advice in issue templates. https://help.github.com/articles/setting-up-your-project-for-healthy-contributions/ Reviewed-by:
-
- 12 Nov, 2018 8 commits
-
-
Viktor Dukhovni authored
SSL_get_signature_nid() -- local signature algorithm SSL_get_signature_type_nid() -- local signature algorithm key type SSL_get_peer_tmp_key() -- Peer key-exchange public key SSL_get_tmp_key -- local key exchange public key Aliased pre-existing SSL_get_server_tmp_key(), which was formerly just for clients, to SSL_get_peer_tmp_key(). Changed internal calls to use the new name. Reviewed-by: -
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
SSL(_CTX)?_set_client_CA_list() was a server side only function in 1.1.0. If it was called on the client side then it was ignored. In 1.1.1 it now makes sense to have a CA list defined for both client and server (the client now sends it the the TLSv1.3 certificate_authorities extension). Unfortunately some applications were using the same SSL_CTX for both clients and servers and this resulted in some client ClientHellos being excessively large due to the number of certificate authorities being sent. This commit seperates out the CA list updated by SSL(_CTX)?_set_client_CA_list() and the more generic SSL(_CTX)?_set0_CA_list(). This means that SSL(_CTX)?_set_client_CA_list() still has no effect on the client side. If both CA lists are set then SSL(_CTX)?_set_client_CA_list() takes priority. Fixes #7411 Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
TLSv1.3 is more restrictive about the curve used. There must be a matching sig alg defined for that curve. Therefore if we are using some other curve in our certificate then we should not negotiate TLSv1.3. Fixes #7435 Reviewed-by:
-
Richard Levitte authored
Setting the SipHash hash size and setting its key is done with two independent functions... and yet, the internals depend on both. Unfortunately, the function to change the size wasn't adapted for the possibility that the key was set first, with a different hash size. This changes the hash setting function to fix the internal values (which is easy, fortunately) according to the hash size. evpmac.txt value for digestsize:8 is also corrected. Reviewed-by:
-
- 11 Nov, 2018 1 commit
-
-
Dmitry Belyavskiy authored
Reviewed-by:
-
- 10 Nov, 2018 7 commits
-
-
Tomas Mraz authored
Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Mansour Ahmadi authored
Reviewed-by:
Paul Yang <yang.yang@baishancloud.com> Reviewed-by:
-
Billy Brumley authored
Reviewed-by:
-
David Woodhouse authored
Rather than relying only on mandatory default digests, add a way for the EVP_PKEY to individually report whether each digest algorithm is supported. Reviewed-by:
-
David Woodhouse authored
If the private key says it can only support one specific digest, then don't ask it to perform a different one. Fixes: #7348 Reviewed-by:
-
David Woodhouse authored
ASN1_PKEY_CTRL_DEFAULT_MD_NID is documented to return 2 for a mandatory digest algorithm, when the key can't support any others. That isn't true here, so return 1 instead. Partially fixes #7348 Reviewed-by:
-
- 09 Nov, 2018 2 commits
-
-
Bernd Edlinger authored
Fixes #7022 Reviewed-by:
-
Richard Levitte authored
... otherwise, it's taken to be part of a device name. Reviewed-by:
-
- 08 Nov, 2018 5 commits
-
-
Richard Levitte authored
We only had the main 'install' target depend on 'all'. This changes the dependencies so targets like install_dev, install_runtime_libs, install_engines and install_programs depend on build targets that are correspond to them more specifically. This increases the parallel possibilities. Fixes #7466 Reviewed-by:
-
Richard Levitte authored
When trying 'make -j{n} install', you may occasionally run into trouble because to sub-targets (install_dev and install_runtime) try to install the same shared libraries. That makes parallel install difficult. This is solved by dividing install_runtime into two parts, one for libraries and one for programs, and have install_dev depend on install_runtime_libs instead of installing the shared runtime libraries itself. Fixes #7466 Reviewed-by: -
Richard Levitte authored
The variable extradefines will have the starting comma, if needed. Reviewed-by:
-
Dr. Matthias St. Pierre authored
Commit c7504aeb (pr #6432) fixed a regression for applications in chroot environments, which compensated the fact that the new OpenSSL CSPRNG (based on the NIST DRBG) now reseeds periodically, which the previous one didn't. Now the reseeding could fail in the chroot environment if the DEVRANDOM devices were not present anymore and no other entropy source (e.g. getrandom()) was available. The solution was to keep the file handles for the DEVRANDOM devices open by default. In fact, the fix did more than this, it opened the DEVRANDOM devices early and unconditionally in rand_pool_init(), which had the unwanted side effect that the devices were opened (and kept open) even in cases when they were not used at all, for example when the getrandom() system call was available. Due to a bug (issue #7419) this even happened when the feature was disabled by the application. This commit removes the unconditional opening of all DEVRANDOM devices. They will now only be opened (and kept open) on first use. In particular, if getrandom() is available, the handles will not be opened unnecessarily. This change does not introduce a regression for applications compiled for libcrypto 1.1.0, because the SSLEAY RNG also seeds on first use. So in the above constellation the CSPRNG will only be properly seeded if it is happens before the forking and chrooting. Fixes #7419 Reviewed-by:
-
Dr. Matthias St. Pierre authored
Reviewed-by:
-
