This project is mirrored from https://github.com/openssl/openssl.git.
Pull mirroring failed .
Last successful update .
Last successful update .
- 06 Aug, 2020 2 commits
-
-
Matt Caswell authored
Reviewed-by:Tomas Mraz <tmraz@fedoraproject.org>
-
Matt Caswell authored
Reviewed-by:
-
- 04 Aug, 2020 14 commits
-
-
Shane Lontis authored
The test added previously used a 16 byte block during the update which does not cause internal buffering in the provider. Some internal variables related to the buffering were not being cleared in the init, which meant that the second update would use the buffered data from the first update. Added test for this scenario with exclusions for ciphers that do not support partial block updates. Found by guidovranken. Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12523)
-
Peter Eisentraut authored
This allows users of this header file to compile their own code with the gcc option -Wunused-parameter. CLA: trivial Reviewed-by:
Shane Lontis <shane.lontis@oracle.com> Reviewed-by:
-
Dr. David von Oheimb authored
Reviewed-by:
Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12534)
-
Richard Levitte authored
When the keymgmt provider and the deserializer provider differ, deserialization uses the deserializer export function instead of the keymgmt load, with a selection of what parts should be exported. That selection was set to OSSL_KEYMGMT_SELECT_ALL_PARAMETERS when it should have been OSSL_KEYMGMT_SELECT_ALL. Reviewed-by:
-
Dr. David von Oheimb authored
Fixes #12268 Reviewed-by:
-
Dr. David von Oheimb authored
Reviewed-by:
-
Dr. David von Oheimb authored
Reviewed-by:
-
Dr. David von Oheimb authored
Reviewed-by:
-
Dr. David von Oheimb authored
Reviewed-by:
-
Dr. David von Oheimb authored
Reviewed-by:
-
Dr. David von Oheimb authored
Reviewed-by:
-
Richard Levitte authored
It should be noted that this may be dodgy if we ever encounter parameter objects that look like something else. However, experience with the OSSL_STORE 'file:' loader, which does exactly this kind of thing, has worked fine so far. A possibility could be that to decode parameters specifically, we demand that there's an incoming data type specifying this, which demands by extension that parameters can only come from a file format that has the parameter type encoded, such as PEM. This would be a future effort. Fixes #12568 Reviewed-by:
-
Norman Ashley authored
Fixes #12531 on master branch. Reviewed-by:
-
Shane Lontis authored
Added der_writer functions for writing octet string primitives. Generate OID's for key wrapping algorithms used by X942 KDF. Reviewed-by:
-
- 03 Aug, 2020 5 commits
-
-
David Woodhouse authored
Reviewed-by:
Viktor Dukhovni <viktor@openssl.org> Reviewed-by:
-
David Woodhouse authored
The X509_VERIFY_PARAM can only take a single IP address, although it can have multiple hostnames. When SSL_add1_host() is given an IP address, don't accept it if there is already one configured. Reviewed-by:
-
David Woodhouse authored
Instead of naïvely trying to truncate at the first colon, use BIO_get_conn_hostname(). That handles IPv6 literals correctly, even stripping the [] from around them. Reviewed-by:
-
David Woodhouse authored
There is a slight mismatch here because X509_VERIFY_PARAM copes only with a single IP address, and doesn't let it be cleared once it's set. But this fixes up the major use case, making things easier for users to get it right. The sconnect demo now works for Legacy IP literals; for IPv6 it needs to fix up the way it tries to split the host:port string, which will happen in a subsequent patch. Reviewed-by:
-
Dr. David von Oheimb authored
Fixes #12514 Reviewed-by:
-
- 01 Aug, 2020 9 commits
-
-
Matt Caswell authored
Commit 6725682d introduced a call to ENGINE_get_digest_engine() into the function asn1_item_digest_with_libctx() to determine whether there is an ENGINE registered to handle the specified digest. However that function increases the ref count on the returned ENGINE object, so it must be freed. Fixes #12558 [extended tests] Reviewed-by:
Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/12560)
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Depending on the BIO used, using BIO_reset() may lead to "interesting" results. For example, a BIO_f_buffer() on top of another BIO that handles BIO_reset() as a BIO_seek(bio, 0), the deserialization process may find itself with a file that's rewound more than expected. Therefore, OSSL_DESERIALIZER_from_{bio,fp}'s behaviour is changed to rely purely on BIO_tell() / BIO_seek(), and since BIO_s_mem() is used internally, it's changed to handle BIO_tell() and BIO_seek() better. This does currently mean that OSSL_DESERIALIZER can't be easily used with streams that don't support BIO_tell() / BIO_seek(). Fixes #12541 Reviewed-by: -
Richard Levitte authored
It's not the best idea to set a whole bunch of parameters in one call, that leads to functions that are hard to update. Better to re-model this into several function made to set one parameter each. This also renames "finalizer" to "constructor", which was suggested earlier but got lost at the time. Reviewed-by:
-
Richard Levitte authored
We use this in test/serdes_test.c, to compare serializations into PEM, which aren't necessarily terminated with a NUL byte when they were written to a BIO_s_mem(). Reviewed-by:
-
Richard Levitte authored
To be able to implement this, there was a need for the standard EVP_PKEY_set1_, EVP_PKEY_get0_ and EVP_PKEY_get1_ functions for ED25519, ED448, X25519 and X448, as well as the corresponding EVP_PKEY_assign_ macros. There was also a need to extend the list of hard coded names that EVP_PKEY_is_a() recognise. Along with this, OSSL_FUNC_keymgmt_load() are implemented for all those key types. The deserializers for these key types are all implemented generically, in providers/implementations/serializers/deserializer_der2key.c. Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
The OSSL_DESERIALIZER API makes the incorrect assumption that the caller must cipher and other pass phrase related parameters to the individual desserializer implementations, when the reality is that they only need a passphrase callback, and will be able to figure out the rest themselves from the input they get. We simplify it further by never passing any explicit passphrase to the provider implementation, and simply have them call the passphrase callback unconditionally when they need, leaving it to libcrypto code to juggle explicit passphrases, cached passphrases and actual passphrase callback calls. Reviewed-by:
-
Richard Levitte authored
This is needed so RSA keys created from different code paths have a chance to compare as equal. Reviewed-by:
-
- 30 Jul, 2020 10 commits
-
-
Richard Levitte authored
For now, that's what we see being used. It's possible that we will have to figure out a way to specific if these should be implicit or explicit on a case by case basis. Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Dr. David von Oheimb authored
Reviewed-by:
-
Dr. David von Oheimb authored
Fixes #12403 Reviewed-by:
-
Dr. David von Oheimb authored
Reviewed-by:
-
Pauli authored
Reviewed-by:
-
Pauli authored
Move the libcrypto serialisation functionality into a place where it can be provided at some point. The serialisation still remains native in the default provider. Add additional code to the list command to display what kind of serialisation each entry is capable of. Having the FIPS provider auto load the base provider is a future (but necessary) enhancement. Reviewed-by:
-
Pauli authored
Reviewed-by:
-
Matt Caswell authored
The test_cmp_cli was failing in the extended tests on cross-compiled mingw builds. This was due to the test not using wine when it should do. The simplest solution is to just skip the test in this case. [extended tests] Reviewed-by:
-
Matt Caswell authored
The only reason we should fallback to legacy codepaths in DigestSignInit/ DigestVerifyInit, is if we have an engine, or we have a legacy algorithm that does not (yet) have a provider based equivalent (e.g. SM2, HMAC, etc). Currently we were falling back even if we have a suitable key manager but the export of the key fails. This might be for legitimate reasons (e.g. we only have the FIPS provider, but we're trying to export a brainpool key). In those circumstances we don't want to fallback to the legacy code. Therefore we tighten then checks for falling back to legacy. Eventually this particular fallback can be removed entirely (once all legacy algorithms have provider based key managers). Reviewed-by:
-
