[openssl.org #1623] Bug report: default CA certs file path ignored

The default CA certs file path is ignored in commands like s_client because if you don't specify -CApath or -CAfile on s_client command line the SSL_CTX_load_verify_locations() will return 0 and the code: if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||

Re: [openssl.org #1623] Bug report: default CA certs file path ignored

On Wed, 2007-12-12 at 20:11 +0100, Tomas Mraz via RT wrote: The default CA certs file path is ignored in commands like s_client ... See also https://bugzilla.redhat.com/show_bug.cgi?id=421011 Oops, should have been https://bugzilla.redhat.com/show_bug.cgi?id=418771 -- Tomas Mraz No matter how

[openssl.org #1629] BUG: SSLv3 only client broken with some servers

OpenSSL 0.9.8g SSLv3 only client (with tlsext support compiled in) is broken when communicating with some servers. Example: openssl s_client -ssl3 -connect irc.mozilla.org:6697 -debug CONNECTED(0003) write to 0x67f3c0 [0x6891b0] (111 bytes = 111 (0x6F)) - 16 03 00 00 6a 01 00 00-66 03 00

Re: [openssl.org #1574] Session Ticket in OpenSSL 0.9.9 and EAP-FAST

We are also interested in supporting EAP-FAST in wpa_supplicant. Can someone from OpenSSL developers comment whether the approach taken in this patch is feasible and if they are willing to accept it into OpenSSL? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back.

[openssl.org #1574] Session Ticket in OpenSSL 0.9.9 and EAP-FAST

We would really appreciate any comments on the possibility of getting the patch into the official OpenSSL sources. Are the OpenSSL developers interested in getting the EAP-FAST support into OpenSSL or they do not want it at all and if so, then why? Thanks for any response, -- Tomas Mraz No

Re: [openssl.org #1853] Bugs in ./crpto/x509/x509_vfy.c and ./crpto/x509/x509_cmp.c

On Mon, 2009-03-09 at 15:10 +0100, Stephen Henson via RT wrote: An update to X509_NAME_cmp() was applied to 0.9.8-stable recently, please try a recent snapshot. I do not think the fix is correct anyway. The only correct thing to do if the value types are different is to return the j. Even with

[openssl.org #2001] Missing commit on the 1.0.0 trunk

The 1.0.0 branch and trunk is missing the check-in http://cvs.openssl.org/chngview?cn=14635 which fixes a memory leak in the RSA_setup_blinding() function. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb

[openssl.org #2002] Mistake in linkage to krb5 library

There is a bug in the Makefile.org which breaks linking libssl to libkrb5. The simple attached patch (against 1.0.0-beta3) solves the problem. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb diff -up

Re: [openssl.org #2020] [PATCH] tsget 1.0.0 b3

On Tue, 2009-08-25 at 08:43 +0200, Keith Beckman via RT wrote: I came up against some of the same problems as this poster to openssl-user: http://www.mail-archive.com/openssl-us...@openssl.org/msg56755.html This diff covers the improperly-capitalized references to WWW::Curl::Easy and a

[openssl.org #2029] Fix openssl dgst -dss1

In the openssl-1.0.0-beta3 the command openssl dgst -dss1 -verify fails with error: Error setting context 139832466196296:error:0A07806A:dsa routines:PKEY_DSA_CTRL:invalid digest type:dsa_pmeth.c:192: See https://bugzilla.redhat.com/show_bug.cgi?id=520152 for detailed test case. I've patched the

[openssl.org #2035] openssl speed camellia-192-cbc segfaults

This was reported in Fedora bugzilla by Pekka Pietikainen : The other variants seem fine, but (gdb) set args speed camellia-192-cbc (gdb) run Starting program: /usr/bin/openssl speed camellia-192-cbc [Thread debugging using libthread_db enabled] Doing camellia-192 cbc for 3s on 16 size blocks:

Re: [openssl.org #2035] openssl speed camellia-192-cbc segfaults

On Sat, 2009-09-12 at 17:32 +0200, Andy Polyakov via RT wrote: Could you complement back-trace with 'info reg' output? (gdb) bt #0 _x86_64_Camellia_encrypt () at cmll-x86_64.s:74 #1 0x77a7a4b4 in Camellia_cbc_encrypt () at cmll-x86_64.s:1686 #2 0x7fffca30 in ?? () #3

Re: [openssl.org #1847] Bug in Openssl 0.9.8j CA.sh script

I've attached integrated changes to CA.sh script from RT #912, RT #1209, and RT #1847 as one patch. Please consider adding this at least to trunk and openssl-1.0 branch CVS. Thanks, -- Tomas Mraz No matter how far down the wrong road you've gone, turn back.

[openssl.org #2072] Avoid potential doublefree and reuse of freed handshake_buffer

The attached patch against 1.0.0 fixes a potential doublefree and reuse of freed handshake_buffer when SSL_clear() is called. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb --- s3_lib.c.hbuf-clear

[openssl.org #2073] Avoid use of freed SSL_CTX in SSL_free()

The attached patch against 1.0.0 fixes a potential use of freed SSL_CTX when SSL_free() is called after SSL_CTX_free() in application. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb diff -up

[openssl.org #2105] Please reconsider the client side of the CVE-2009-3555 fix in 1.0.0

The TLS client in openssl-1.0.0 branch aborts the connection if SSL_OP_ALLOW_UNSAFE_RENEGOTIATION (or SSL_OP_ALL) flag is not set by the calling application and the connected server does not return the extension in the server hello message. Unfortunately too many applications do not set SSL_OP_ALL

Re: [openssl.org #2105] Please reconsider the client side of the CVE-2009-3555 fix in 1.0.0

On Fri, 2009-12-11 at 14:14 +0100, Stephen Henson via RT wrote: The problem of adding fields to SSL_CTX and SSL has been mentioned by a number of people before. How bad is that in practice? SSL_CTX and SSL structures are both allocated dynamically so the size change wont matter. The only

[openssl.org #2127] Missing checks for unavailable algorithms in EVP_PBE_CipherInit

In the function EVP_PBE_CipherInit there are missing checks for unavailable algorithms (such as when they are not compiled in or when OpenSSL_add_all_algorithms() is not called). The attached patch adds the checks although probably new error codes should be added for these failures. -- Tomas

[openssl.org #2128] PKCS12_PBE_add is a noop but maybe it should add the algorithms?

If you call just SSL_library_init() and PKCS12_PBE_add some pkcs12 files will not be loadable and moreover the openssl will crash due to missing checks for ciphers not found. I've reported the crash in a separate report. Perhaps the PKCS12_PBE_add should add the algorithms which are not added in

[openssl.org #1407] Bug - add_cert_dir() logic is broken

The add_cert_dir() function in openssl/crypto/x509/by_dir.c is broken. There is a loop to detect duplicate entries but its results are ignored, it will also go out of bounds on some malformed parameters. See also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206346 Patches against 0.9.8

[openssl.org #1411] Simple enhancement request - allow trusted certs in SSL_CTX_use_certificate_chain_file()

It should be possible to use trusted certificates when SSL_CTX_use_certificate_chain_file() is called. Simply replacing PEM_read_bio_X509 with PEM_read_bio_X509_AUX should work. Or is there some reason why this should not be changed? See also

[openssl.org #2169] OPENSSL_cleanse does not handle zero length gracefully

The various OPENSSL_cleanse assembler implementations in contrast with the C implementation do not handle zero length gracefully - that is returning without touching the memory. Instead they overflow and segfault. Steps to reproduce: echo 'test' | openssl dgst -md5 -hmac '' -- Tomas Mraz No

[openssl.org #2171] ssl2 is unnecessarily rejected as not supporting the safe renegotiation

As SSLv2 does not specify any renegotiation at all does it really make sense to reject it in the ssl23_get_client_hello() if legacy renegotiation is not enabled in the ssl options? openssl s_server when contacted with openssl s_client -sslv2 returns: 140392456742728:error:14076152:SSL

[openssl.org #2347] Wrong help in the openssl cms command

There is -skeyid option described in the help of the openssl cms command. However the cms application expects -keyid option instead. The attached patch corrects the error in the help. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back.

Re: [openssl.org #2395] openssl-1.0.0c bug: Decoding cert causes segv in ASN1 code

int mk_test_cert(int buflen, char* buf) { char* p; char* q; X509* sign_cert; q = unbase64_raw(cert_b64, cert_b64+sizeof(cert_b64)-1, p=buf, std_index_64); if (!d2i_X509(sign_cert, p, q-p) || !sign_cert) { You're passing uninitialized X509* pointer sign_cert to the

[openssl.org #2538] Code error - bad condition in s3_srvr.c

There is code error in s3_srvr.c function ssl3_get_cert_verify(). There is a condition if ((peer != NULL) (type | EVP_PKT_SIGN)) - the second part of the condition is a no-op. The correct condition should be if ((peer != NULL) (type EVP_PKT_SIGN)) although the non-signing certificates with

[openssl.org #2565] More tolerant detection of XMPP starttls sequence

The attached patch written by J.H.M Ray Dassen improves detection of the XMPP starttls sequence for s_client. Please consider applying it. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb diff -ru

[openssl.org #2572] Correct help output in openssl cms

openssl cms help output contains -skeyid option which is actually -keyid option as recognized by the cms code. The attached trivial patch corrects the help output. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish

[openssl.org #2616] Missing initialization in the CHIL engine

There is a missing initialization of a variable in the CHIL engine. In case the uninitialized value of the variable answer is 'C' and there is no prompt, the engine startup will erroneously fail. The attached patch fixes this. -- Tomas Mraz No matter how far down the wrong road you've gone, turn

[openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

Here is analysis by Paolo Bonzini: I compared crypto/x86_64cpuid.pl and crypto/x86cpuid.pl, and the code in the latter is wrong. From x86_64cpuid.pl: mov %edx,%r10d # %r9d:%r10d is copy of %ecx:%edx bt \$27,%r9d # check OSXSAVE bit jnc

[openssl.org #2635] 1/n-1 record splitting technique for CVE-2011-3389

Here is an experimental patch I wrote that implements the 1/n-1 record splitting technique for OpenSSL. I am sending it here for consideration by OpenSSL upstream developers. By default the 0/n split is used but in case the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS flag is set, we split the first record

[openssl.org #2637] Missing documentation for -no_ign_eof option

The attached patch adds missing documentation for the -no_ign_eof option. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb diff -up openssl-1.0.0e/doc/apps/s_client.pod.doc-noeof

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

On Sat, 2011-11-05 at 11:53 +0100, Andy Polyakov via RT wrote: x86cpuid.pl instead is completely broken: - the whole test is bypassed if XSAVE=1, which makes absolutely no sense. x86_64cpuid.pl is right in testing OSXSAVE No, the test is bypassed if XSAVE is 0, not 1. XSAVE being 0

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

On Tue, 2011-11-08 at 22:29 +0100, Andy Polyakov via RT wrote: As for XEN, if it in fact masks XSAVE, but not AVX bits, than even check for XSAVE bit should 'jnc (label(clear_avx));' instead of done. As well as that x86_64cpuid.pl should test for XSAVE... That would also work, but it's

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

On Fri, 2011-11-18 at 12:16 +0100, Andy Polyakov via RT wrote: commit 6c3f6041172b78d5532c6bf3680d304e92ec2e66 Author: Sheng Yang sh...@linux.intel.com Date: Tue Jun 22 13:49:21 2010 +0800 KVM: x86: Enable AVX for guest Enable Intel(R) Advanced Vector Extension(AVX) for

[openssl.org #2641] Move the libraries needed for static linking to Libs.private

The attached patch changes the generated pkgconfig files so the libraries needed for static linking are in Libs.private instead of Libs. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb diff -up

[openssl.org #2710] Add missing checks for load_certs_crls failure

The attached trivial patch adds missing check for load_certs_crls failure in apps.c. It is applicable to 1.0.0 and 1.0.1 branches. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb diff -up

[openssl.org #2711] Fix possible NULL dereference on bad MIME headers

In some cases when a S/MIME message with broken MIME headers is processed a NULL dereference in mime_hdr_cmp can happen. The attached patch guards against this dereference. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back.

[openssl.org #2712] Be more liberal when trying to recognize the XMPP starttls headers

The attached simple patch allows other possible syntaxes of XMPP starttls headers to be recognized. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb diff -ru openssl-1.0.0d.old/apps/s_client.c

[openssl.org #2713] Move libraries that are not needed for dynamic linking to Libs.private in the .pc files

The attached simple patch moves the libraries that are not needed for dynamic linking to the Libs.private section in the OpenSSL .pc files. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb diff -up

[openssl.org #2714] Fix build with no-srp option

OpenSSL-1.0.1-beta2 build with no-srp option fails because there are some missing #ifdef OPENSSL_NO_SRP directives in the s_server code. The attached patch fixes this. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish

[openssl.org #2786] Prevent crash if dctx-get_entropy() fails

This bug report applies to the OpenSSL FIPS 2.0 module. If dctx-get_entropy() fails and thus the tout is set to NULL we will set the output entropy pointer to NULL + blocklen. This will later lead to crash as we check for NULL entropy before calling fips_cleanup_entropy() but it will be invalid

Re: [openssl.org #2786] Prevent crash if dctx-get_entropy() fails

On Sat, 2012-04-07 at 21:44 +0200, Stephen Henson via RT wrote: [tm...@redhat.com - Sat Apr 07 15:39:00 2012]: This bug report applies to the OpenSSL FIPS 2.0 module. If dctx-get_entropy() fails and thus the tout is set to NULL we will set the output entropy pointer to NULL +

Re: [openssl.org #2635] 1/n-1 record splitting technique for CVE-2011-3389

On Sun, 2012-04-15 at 16:45 +0200, Andy Polyakov via RT wrote: Here is an experimental patch I wrote that implements the 1/n-1 record splitting technique for OpenSSL. I am sending it here for consideration by OpenSSL upstream developers. By default the 0/n split is used but in case the

Re: [openssl.org #2635] 1/n-1 record splitting technique for CVE-2011-3389

On Mon, 2012-04-16 at 11:49 +0200, Andy Polyakov via RT wrote: Here is an experimental patch I wrote that implements the 1/n-1 record splitting technique for OpenSSL. I am sending it here for consideration by OpenSSL upstream developers. By default the 0/n split is used but in case the

Re: [openssl.org #2802] 1.0.0's SSL_OP_ALL and SSL_OP_NO_TLSv1_1

On Wed, 2012-04-25 at 10:35 +0200, Andy Polyakov via RT wrote: more secure protocols. Trade-off. As 1.0.0 application is not in position to expect anything above TLS1.0, trade-off can as well be resolved in favor of interoperability. Note that there is not such trade-off in 1.0.1 application

[openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a value of length 4. On little endian systems this is not so critical problem however on big endian 64 bit systems it means the interpretation of the returned value by the code in dgram_ctrl() is completely wrong - you will get a

Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

On Sun, 2012-06-10 at 18:04 +0200, Michael Tuexen wrote: On Jun 10, 2012, at 4:03 PM, Andy Polyakov wrote: The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a value of length 4. On little endian systems this is not so critical problem however on big endian 64 bit systems

[openssl.org #2874] Missing initialization of str in aes_ccm_init_key

The str member of EVP_AES_CCM_CTX structure stays uninitialized when aes ccm is used with the vpaes backend causing it to crash when the str is later called as it is non-NULL. The attached patch fixes the problem. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back.

[openssl.org #2936] Properly set default trusted CA paths if -CAfile and -CApath not used

The current behavior of s_client, s_server and s_time commands in regards to the default trusted CA store path is incorrect. The default paths are loaded only in case SSL_CTX_load_verify_locations() does not fail. This means that you have to use -CApath or -CAfile The attached patch properly sets

Re: [openssl.org #3002] Communication problems with 1.0.1e

On Fri, 2013-03-01 at 22:01 +0100, Kurt Roeckx wrote: I can't either, and yet I have multiple people reporting problems with the 1.0.1e version saying the 1.0.1c version works without problems. This happened recently on Fedora as well. See: https://bugzilla.redhat.com/show_bug.cgi?id=918981

[openssl.org #3176] Locking problem in fips_drgb_rand.c

The fips_drbg_bytes() function calls CRYPTO_w_lock(CRYPTO_LOCK_RAND); unfortunately the FIPS_drbg_generate() function can eventually call drbg_reseed() if sufficiently enough bytes are pulled out of the DRBG. This function in turn pulls bytes from the MD rand using the RAND_SSLeay()-bytes().

Re: [openssl.org #3224] OpenSSL 1.0.1f rsa_pmeth.c duplicate code block

On Pá, 2014-01-10 at 09:53 +0100, Paul Suhler via RT wrote: Lines 612 through 615 of rsa_pmeth.c apparently contain duplicated lines: Line 612: else if (!strcmp(value, oeap)) pm = RSA_PKCS1_OAEP_PADDING; else if (!strcmp(value, oaep))

[openssl.org #3264] openssl req ignores key length set in config file

'openssl req -newkey rsa' ignores keylen set in the openssl config file in the req section. It also misleadingly prints out the configured keylen in 'Generating bit RSA private key.' message when it generates the library hardcoded default of 1024 bits. The attached patch fixes this bug. --

Re: [openssl.org #3264] openssl req ignores key length set in config file

Heh, good :) As we both came independently to the same patch we can declare it right and perhaps the openssl upstream developers can finally commit it to the git repository. __ OpenSSL Project

Re: [openssl.org #3266] [PATCH] Add the SYSTEM cipher keyword

On St, 2014-02-19 at 23:03 +0100, Nikos Mavrogiannopoulos via RT wrote: This keyword allows a program to simply specify SYSTEM in its configuration file and the SSL cipher used will be determined at run-time from a system-specific file. The system default keywords can be extended by appending

Re: [openssl.org #3415] Bug report: Uninitialized memory reads reported by valgrind for ECDSA signatures

On Čt, 2014-07-03 at 23:47 +0200, Matt Caswell via RT wrote: I've put together a fix (see below), but not pushed it because I was working on the assumption that if you had PURIFY defined then you wouldn't care about constant time operation. I've since been told that possibly some distros

Re: [openssl.org #3451] patch for x509.c

On Út, 2014-07-15 at 20:08 +0200, Jan Just Keijser via RT wrote: On 15/07/14 15:20, Daniel Kahn Gillmor wrote: On 07/15/2014 07:58 AM, Salz, Rich via RT wrote: The Globus syntax is strange. :) We should support the ISO date/time standard, and use that throughout and not invent yet

Re: [openssl.org #3451] patch for x509.c

On St, 2014-07-16 at 17:46 +0200, Daniel Kahn Gillmor via RT wrote: On 07/16/2014 11:24 AM, Salz, Rich wrote: do you realistically think we'll ever drop support for the -days argument though? Dropping -days would break a million scripts. No, we'll never drop support for -days. But

[openssl.org #3537] Bug in TS_check_status_info() and misleading comments

In the TS_check_status_info() there is bug where instead of appending the ',' character to the failure info texts this character overwrites the previous failure info text with strcpy() call. Also the TS_STATUS_BUF_SIZE is named incorrectly as it does not relate to status text but to the failure

[openssl.org #3560] OpenSSL selects weak digest for (EC)DH kex signing in TLSv1.2 when connecting to SNI virtual server

When connecting to a virtual, SNI defined host openssl selects SHA1 digest instead of SHA512, as it does for the default host. Steps to Reproduce: 1. openssl req -x509 -newkey rsa:2048 -keyout localhost.key -out localhost.crt -subj /CN=localhost -nodes -batch 2. openssl req -x509 -newkey

Re: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext

On St, 2014-12-10 at 18:35 +0100, Andy Polyakov via RT wrote: Excellent. My summary is: - valgrind complaints about 1.0.1 OpenSLL are extremely unlikely to affect my program in operation (you will probably say will not affect) Well, as there is suggestion of what I would say, I would

Re: [openssl-dev] [openssl.org #3675] Fix key wrapping mode with padding to conform to RFC 5649

Hello OpenSSL developers, can you please include this fix which although a trivial code change nevertheless does have big impact on the encrypted key-wrapped data. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish

Re: [openssl-dev] [openssl.org #3911] 1.0.2c: some kind of regression - fails to connect to server where 1.0.2a works fine

On Po, 2015-06-15 at 14:22 +, Arkadiusz Miskiewicz via RT wrote: Hello. I've just upgraded from 1.0.2a to 1.0.2c and now I no longer can connect from mysql client to my mysql server. Downgrading to 1.0.2a and the problem is gone. That's because mysql server hardcodes 512 bits DH

[openssl-dev] [openssl.org #3913] [RFE] Add a way to application to know a minimum DH size allowed by the client

The current minimum DH size allowed by the client is 768 bits which is a hardcoded constant. It would be nice if the constant was at least #define in public headers or even better if there was an API to query various minimum and maximum bit sizes that are checked in the library such as the maximum

[openssl-dev] [openssl.org #4124] Illegal instruction when using aes-ni-sha256 stitched implementation on AMD CPU

The aes-ni-sha256 stitched implementation causes SIGILL on AMD A4-6210. It is caused by not using the AVX+SSSE3 code path for non-Intel CPUs although the CPU seems to be fully capable of running it. The ia32cap vector is 0x7ED8220B078B but when you set it explicitly with

[openssl-dev] [openssl.org #4240] Document some of the speed options

The attached patch provides documentation of some of the currently undocumented speed options. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) diff

Re: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible

On Út, 2016-06-28 at 22:10 +, Thomas Waldmann via RT wrote: > On 06/28/2016 11:18 PM, Kurt Roeckx via RT wrote: > > > > On Mon, Jun 27, 2016 at 08:50:43PM +, Thomas Waldmann via RT > > wrote: > > > > > > I didn't ask where to get the missing code from, I asked whether > > > you > > >

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

On Po, 2016-04-25 at 13:39 +, Richard Levitte via RT wrote: > In message on > Mon, 25 Apr 2016 13:19:38 +, "Salz, Rich via RT" > said: > > rt> No, he means setting the same value twice.  For example, making > this

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

On Po, 2016-04-25 at 13:08 +, Richard Levitte via RT wrote: >  > rsalz> > If nothing else, all the RSA_set0 routines should test if > the same pointer > rsalz> > value is being replaced if so do not free it. > rsalz> >  > rsalz> > The same logic need to be done for all the RSA_set0_* >

Re: [openssl-dev] [openssl.org #4664] Enhancement: better handling of CFLAGS and LDFLAGS

I would like to join this request as maintainer of OpenSSL for Fedora and Red Hat Enterprise Linux. It would clean up things for us as well. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never

Re: [openssl-dev] [openssl.org #4664] Enhancement: better handling of CFLAGS and LDFLAGS

On Po, 2016-08-29 at 14:27 +, Richard Levitte via RT wrote: > On Mon Aug 29 12:27:59 2016, appro wrote: > >  > > Or maybe ("maybe" is reference to "I don't quite grasp" above) what > > we > > are talking about is Configure reading CFLAGS and LDFLAGS and > > *adding* > > them to generated