- Mar 14, 2018
-
-
Matt Caswell authored
Reviewed-by:
Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5392)
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
With the current mechanism, old cipher strings that used to work in 1.1.0, may inadvertently disable all TLSv1.3 ciphersuites causing connections to fail. This is confusing for users. In reality TLSv1.3 are quite different to older ciphers. They are much simpler and there are only a small number of them so, arguably, they don't need the same level of control that the older ciphers have. This change splits the configuration of TLSv1.3 ciphers from older ones. By default the TLSv1.3 ciphers are on, so you cannot inadvertently disable them through your existing config. Fixes #5359 Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/5604)
-
Matt Caswell authored
As per the latest text in TLSv1.3 draft-26 Reviewed-by:
-
Matt Caswell authored
As of TLSv1.3 draft-25 the record header data must be used as AAD Reviewed-by:
-
Richard Levitte authored
We have '--strict-warnings' for this kind of stuff... also, user flags are added last, so this overrides any warning supression --strict-warnings may put in place (for good reasons). Fixes #5609 Reviewed-by:
-
- Mar 13, 2018
-
-
Richard Levitte authored
Reviewed-by:
Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5608)
-
Richard Levitte authored
... also, name it with "-$$" added instead of ".$$" Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Andy Polyakov authored
Move Android targets to separate file, automate sysroot setup and add support for NDK 16. Reviewed-by:
Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5589)
-
Andy Polyakov authored
Unlike "upstream", Android NDK's arm64 gcc [but not clang] performs 64x64=128-bit multiplications with library calls, which appears to have devastating impact on performance. [The condition is reduced to __ANDROID__ [&& !__clang__], because x86_64 has corresponding assembly module.] Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Richard Levitte authored
With the help of the perl script util/add-depends.pl, which takes all its information directly from configdata.pm, the dependency adding procedure can be streamlined for all support platforms. Reviewed-by:
-
Tim Hudson authored
As per discussion with Peter Sylvester Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5603)
-
- Mar 12, 2018
-
-
Richard Levitte authored
OPENSSL_DIR_read() now returns unique file names on VMS, no generation number. We therefore do not need to handle that case in apps/rehash.c any more. Reviewed-by:
-
Richard Levitte authored
When OPENSSL_DIR_read implemented by LPdir_unix.c gets a Unixy path, it will return file names like you'd expect them on Unix. However, if given a path with VMS syntax, such as "[.foo]", it returns file names with generation numbers, such as "bar.txt;1", which makes sense for VMS expectations, but can be surprising for OpenSSL. Our solution is to simply shave off the generation number if OPENSSL_DIR_read() expects there should be one, and make sure not to return the same file name twice. Note that VMS filesystems are case insensitive, so the check for duplicate file names are done without regard to character case. Reviewed-by:
-
Richard Levitte authored
We want to see that VMS syntax paths are treated correctly. Reviewed-by:
-
Richard Levitte authored
non-VMS syntax inclusion paths get the same treatment as on Unix. Reviewed-by:
-
Matt Caswell authored
We should be using ASN1_OBJECT_free() not OPENSSL_free(). Fixes #5568 Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Benjamin Saunders authored
These functions are similar to SSL_CTX_set_cookie_{generate,verify}_cb, but used for the application-controlled portion of TLS1.3 stateless handshake cookies rather than entire DTLSv1 cookies. Reviewed-by: -
Matt Caswell authored
If a mem allocation failed we would ignore it. This commit fixes it to always check. Reviewed-by:
-
gmile authored
Original source: https://github.com/dstucrypt/openssl-dstu/commit/2c5fc4c92b8244c5026f4f871eb9497f9c28d5af Full list of OIDs is available on related enactment page at http://zakon2.rada.gov.ua/laws/show/z0423-17 CLA: trivial Reviewed-by:
-
Matt Caswell authored
The ossl_shim doesn't know about TLSv1.3 so we should disable that protocol version for all tests for now. This fixes the current Travis failures. [extended tests] Reviewed-by:
-
Todd Short authored
Adds application data into the encrypted session ticket Reviewed-by:
Paul Dale <paul.dale@oracle.com> Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
- Mar 11, 2018
-
-
Kurt Roeckx authored
Reviewed-by:
-
- Mar 10, 2018
-
-
Alex Gaynor authored
Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5574)
-
Andy Polyakov authored
So far assembly modules were built as .pl->.S->.s followed by .s->.o. This posed a problem in build_all_generated rule if it was executed on another computer. So we change rule sequence to .pl->.S and then .S->.s->.o. Reviewed-by:
-
Richard Levitte authored
A missing parenthesis here, a missing comma there... Reviewed-by:
-
Richard Levitte authored
There are things depending on configdata.pm. However, it's perfectly possible that there is one in the source directory from a previous build, and that might disrupt an out of source build. To avoid this conflict, make sure never to use the source tree configdata.pm in that case, i.e. make the hard assumption that it's a generated file in the build tree, which it is. Reviewed-by:
-
Richard Levitte authored
When generating the correct inclusion directory for DEPEND, we mangled it to be relative to the build or the source directory. However, the value we handle already come with a correct directory, so we only need to use it as is. Fixes #5543 Reviewed-by:
-
- Mar 09, 2018
-
-
Dr. Matthias St. Pierre authored
The introduction of thread local public and private DRBG instances (#5547) makes it very cumbersome to change the reseeding (time) intervals for those instances. This commit provides a function to set the default values for all subsequently created DRBG instances. int RAND_DRBG_set_reseed_defaults( unsigned int master_reseed_interval, unsigned int slave_reseed_interval, time_t master_reseed_time_interval, time_t slave_reseed_time_interval ); The function is intended only to be used during application initialization, before any threads are created and before any random bytes are generated. Reviewed-by: -
Ben Kaduk authored
Commit abe256e7 changed the config target element from 'cxx' to 'CXX'; catch up accordingly. Also use a space to offset the template boundary, per convention. [extended tests] Reviewed-by:
-
Benjamin Kaduk authored
X509_STORE_set_verify_cb_func.pod has documentation for various callbacks and function pointers that can be set and retrieved, but neither it nor X509_STORE_new has much documentation for the actual purpose and usage of X509_STORE objects. Remedy this disparity with new documentation for adding certificates and CRLs, expected usage, and for modifying the default verifification behavior. Reviewed-by:
Viktor Dukhovni <viktor@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3958)
-
Ben Kaduk authored
Remove a space from a whitespace-only line. Reviewed-by:
-
Benjamin Kaduk authored
At the core of things is the concept that each extension is only defined in certain context(s) -- the ClientHello, EncryptedExtensions, etc., and sometimes only for a specific protocol or protocol range; we want to enforce that we only parse or generate extensions in the context(s) for which they are defined. There is some subtlety here, in that the protocol version in use is not known when generating the ClientHello (but it is known when the ClientHello extensions are being parsed!), so the SSL_IS_TLS13() macro must be used with caution. Nonetheless, by making assertions about whether we are acting in a server role and whether the current context is (not) a ClientHello, we can consolidate almost all of the logic for determining whether an extension is permitted in a given protocol message, whether we are generating or parsing that message. The only logic that remains separate relates to generating the ClientHello, as it depends on an external factor (the maximum permitted TLS version) that is not defined in the parsing context. Reviewed-by:
-
