- Jan 22, 2019
-
-
Richard Levitte authored
One variable misssing Fixes #8060 Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8061)
-
Richard Levitte authored
For good measure, we pass down attributes when calling obj2shlib, obj2lib, obj2dso, obj2bin, or in2script. We currently don't use them in our build file templates, but might as well for future use. Reviewed-by:
-
Richard Levitte authored
We have two classes of scripts to be installed, those that are installed as "normal" programs, and those that are installed as "misc" scripts. These classes are installed in different locations, so the build file templates must pay attention. Because we didn't have the tools to indicate what scripts go where, we had these scripts hard coded in the build template files, with the maintenance issues that may cause. Now that we have attributes, those can be used to classify the installed scripts, and have the build file templates simply check the attributes to know what's what. Furthermore, the 'tsget.pl' script exists both as 'tsget.pl' and 'tsget', which is done by installing a symbolic link (or copy). This link name is now given through an attribute, which results in even less hard coding in the Unix Makefile template. Reviewed-by:
-
Richard Levitte authored
This means that all PROGRAMS_NO_INST, LIBS_NO_INST, ENGINES_NO_INST and SCRIPTS_NO_INST are changed to be PROGRAM, LIBS, ENGINES and SCRIPTS with the associated attribute 'noinst'. Reviewed-by:
-
Richard Levitte authored
Among others, this avoids having special variables like PROGRAMS_NO_INST. Instead, we can have something like this: PROGRAMS{noinst}=foo bar Configure itself is entirely agnostic to these attributes, they are simply passed to the build file templates, to be used as they see fit. Attributes can also have values, for example: SCRIPTS{linkname=foo}=foo.pl This could help indicate to build file templates that care that the perl script 'foo.pl' should also exist with the name 'foo', preferably as a symbolic link. Fixes #7568 Reviewed-by: -
Richard Levitte authored
Reviewed-by:
-
Matt Eaton authored
Minor typo fix to `adjustment` in the line: "In such case you have to pass matching target name to Configure and shouldn't use -D__ANDROID_API__=N. PATH adjustment becomes simpler, $ANDROID_NDK/bin:$PATH suffices." Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8054)
-
- Jan 21, 2019
-
-
Richard Levitte authored
Now that we have the names of libraries on different systems established through platform modules, we can remove the old structure to establish the same thing, i.e. $unified_info{sharednames} and $unified_info{rename}. That means removing support for the RENAME and SHARED_NAME keywords in build.info as well. Reviewed-by:Tim Hudson <tjh@openssl.org> Reviewed-by:
Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/7473)
-
Richard Levitte authored
The platform module collection is made in such a way that any Perl script that wants to take part of the available information can use them just as well as the build system. This change adapts test/recipes/90-test_shlibload.t, util/mkdef.pl, and util/shlib_wrap.sh.in Reviewed-by:
-
Richard Levitte authored
Add platform::Unix, which is a generic Unix module to support product name and extensions functionlity. However, this isn't quite enough, as mingw and Cygwin builds are done using the same templates, but since shared libraries work as on Windows and are named accordingly, platform::mingw and platform::Cygwin were also added to provide the necessary tweaks. This reworks Configurations/unix-Makefile.tmpl to work out product names in platform::Unix et al terms. In this one, we currently do care about the *_extension config attributes, and the modules adapt accordingly where it matters. This change also affected crypto/include/internal/dso_conf.h.in, since the DSO extension is meant to be the same as the short shared library extension, which isn't '.so' everywhere. 'shared_extension' attributes that had the value '.so.\$(SHLIB_VERSION_NUMBER)' are removed, platform::Unix provides an extension where the shared library version number is hard-coded instead. Reviewed-by:
-
Richard Levitte authored
Add platform::VMS, which is a generic VMS module. Additional modules to support specific building aspects (such as specific compilers) may be added later, but since we currently work on file names and those are generic enough, this is also enough. This reworks Configurations/descrip.mms.tmpl to work out product names in platform::VMS terms. Something to be noted is that the new functionality ignores the *_extension config attributes, as they were never used. VMS is very consistent in its use of extensions, so there is no reason to believe much will change in this respect. Reviewed-by:
-
Richard Levitte authored
Add platform::Windows, which is a generic Windows module, and platform::Windows::MSVC, which is a module specifically for MS Visual C. This reworks Configurations/windows-makeffile.tmpl to work out product names in platform::Windows. Something to be noted is that the new functionality ignores the *_extension config attributes, as they were never used. Reviewed-by:
-
Richard Levitte authored
This is the start of a major work to correct some quirks in the buiding system. The base for this is to move certain attributes that lack desired flexibility from Configurations/*.conf to perl modules that can be selected with one single attribute in the config targets. The way this is meant to work is by adding this attribute in select config targets: perl_module => 'Name'; # Name to be replaced Then, in the perl scripts or modules that need the functionality, these lines should be added: use lib catdir($srcdir, 'Configurations'); # Ensure access to platform.pm use lib $blddir; # Ensure access to configdata.pm use platform; # Will load platform::$target{perl_module} Reviewed-by: -
Bernd Edlinger authored
Reviewed-by:
Nicola Tuveri <nic.tuv@gmail.com> Reviewed-by:
-
Bernd Edlinger authored
If this fails try out if mfspr268 works. Use OPENSSL_ppccap=0x20 for enabling mftb, OPENSSL_ppccap=0x40 for enabling mfspr268, and OPENSSL_ppccap=0 for enabling neither. Fixes #8012 Reviewed-by:
-
David von Oheimb authored
Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by:
-
David von Oheimb authored
Reviewed-by:
-
Corey Minyard authored
If you use a BIO and set up your own buffer that is not freed, the memory bio will leak the BIO_BUF_MEM object it allocates. The trouble is that the BIO_BUF_MEM is allocated and kept around, but it is not freed if BIO_NOCLOSE is set. The freeing of BIO_BUF_MEM was fairly confusing, simplify things so mem_buf_free only frees the memory buffer and free the BIO_BUF_MEM in mem_free(), where it should be done. Alse add a test for a leak in the memory bio Setting a memory buffer caused a leak. Signed-off-by:
Corey Minyard <minyard@acm.org> Reviewed-by:
-
- Jan 18, 2019
-
-
Antoine Salon authored
Signed-off-by:
Antoine Salon <asalon@vmware.com> Reviewed-by:
-
Marc authored
1) Add two new flags (-proxy_user & -proxy_pass) to s_client to add support for basic (base64) proxy authentication. 2) Add a "Proxy-Connection: Keep-Alive" HTTP header which is a workaround for some broken proxies which otherwise close the connection when entering tunnel mode (eg Squid 2.6). Reviewed-by:
-
- Jan 16, 2019
-
-
David Benjamin authored
The RSAZ code requires the input be fully-reduced. To be consistent with the other codepaths, move the BN_nnmod logic before the RSAZ check. This fixes an oft-reported fuzzer bug. https://github.com/google/oss-fuzz/issues/1761 Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Some of these functions take char*, which is seldom right, they should have been unsigned char*, because the content isn't expected to be text. Even better is to simply take void* as data type, which also happens to be transparent for any type these functions are called with, be it char* or unsigned char*. This shouldn't break anything. While we're at it, constify the input data parameters. Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/7890)
-
Richard Levitte authored
Having a weak getauxval() and only depending on GNU C without looking at the library we build against meant that it got picked up where not really expected. So we change this to check for the glibc version, and since we know it exists from that version, there's no real need to make it weak. Reviewed-by:
-
Richard Levitte authored
It turns out that AT_SECURE may be defined through other means than our inclusion of sys/auxv.h, so to be on the safe side, we define our own guard and use that to determine if getauxval() should be used or not. Fixes #7932 Reviewed-by:
-
- Jan 15, 2019
-
-
Matt Caswell authored
We don't use this information so we shouldn't fetch it. As noted in the comments in #8005. Reviewed-by:
Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/8020)
-
Matt Caswell authored
Fixes #8005 Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Spotted by OSTIF audit Reviewed-by:
-
- Jan 13, 2019
-
-
Anna Henningsen authored
CLA: trivial Reviewed-by:
-
- Jan 08, 2019
-
-
Matt Caswell authored
We were setting a limit of SSL3_RT_MAX_PLAIN_LENGTH on the size of the ClientHello. AFAIK there is nothing in the standards that requires this limit. The limit goes all the way back to when support for extensions was first added for TLSv1.0. It got converted into a WPACKET max size in 1.1.1. Most likely it was originally added to avoid the complexity of having to grow the init_buf in the middle of adding extensions. With WPACKET this is irrelevant since it will grow automatically. This issue came up when an attempt was made to send a very large certificate_authorities extension in the ClientHello. We should just remove the limit. Reviewed-by:
Viktor Dukhovni <viktor@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7424)
-
Matt Caswell authored
Fixes #7966 Reviewed-by:
-
FdaSilvaYY authored
5. check_return: Calling EVP_EncodeUpdate without checking return value (as is done elsewhere 4 out of 5 times). Fix CID 1371695, 1371698: Resource leak in test/evp_test.c - leaked_storage: Variable edata going out of scope leaks the storage it points to. - leaked_storage: Variable encode_ctx going out of scope leaks the storage it points to Fix CID 1430437, 1430426, 1430429 : Dereference before null check in test/drbg_cavs_test.c check_after_deref: Null-checking drbg suggests that it may be null, but it has already been dereferenced on all paths leading to the check Fix CID 1440765: Dereference before null check in test/ssltestlib.c check_after_deref: Null-checking ctx suggests that it may be null, but it has already been dereferenced on all paths leading to the check. Reviewed-by:
-
- Jan 07, 2019
-
-
Viktor Dukhovni authored
1. In addition to overriding the default application name, one can now also override the configuration file name and flags passed to CONF_modules_load_file(). 2. By default we still keep going when configuration file processing fails. But, applications that want to be strict about initialization errors can now make explicit flag choices via non-null OPENSSL_INIT_SETTINGS that omit the CONF_MFLAGS_IGNORE_RETURN_CODES flag (which had so far been both undocumented and unused). 3. In OPENSSL_init_ssl() do not request OPENSSL_INIT_LOAD_CONFIG if the options already include OPENSSL_INIT_NO_LOAD_CONFIG. 4. Don't set up atexit() handlers when called with INIT_BASE_ONLY. Reviewed-by: -
Viktor Dukhovni authored
Some Travis builds appear to fail because generated objects get 2019 copyrights now, and the diff complains. Reviewed-by:
-
Matt Caswell authored
This was complicated by the fact that we were using this extension for our duplicate extension handling tests. In order to add tests for cryptopro bug the duplicate extension handling tests needed to change first. Reviewed-by:
-
Matt Caswell authored
The cryptopro extension is supposed to be unsolicited and appears in the ServerHello only. Additionally it is unofficial and unregistered - therefore we should really treat it like any other unknown extension if we see it in the ClientHello. Fixes #7747 Reviewed-by:
-
Dr. Matthias St. Pierre authored
This looks like a copy&paste error from req.pod to x509.pod. Reviewed-by:
-
- Jan 06, 2019
-
-
Dmitry Belyavskiy authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
