Re: [openssl.org #1794] [PATCH] SRP ciphersuites in 1.0.1 and 1.1.0 (updated)

Hi Thomas, [...@openssl.org email corrected] Looking at the latest SRP patch [1], I noticed the use of RAND_bytes: lines 5047 and 5222. Bytes acquired at 5047 are subsequently used in a call to generate B's key pair, while the call at 5222 is later used for A's key pair generation. According to

Re: [openssl.org #1794] [PATCH] SRP ciphersuites in 1.0.1 and 1.1.0 (updated)

Hi Thomas, Looking at the latest SRP patch [1], I noticed the use of RAND_pseudo_bytes. I believe RAND_pseudo_bytes is sufficient for salts and other public values. But it does appear that RAND_pseudo_bytes is being used for keying material at lines 3171 and 3187. The bytes acquired at 3171 and

Re: [openssl.org #1794] [PATCH] SRP ciphersuites in 1.0.1 and 1.1.0 (updated)

Hi Thomas, Looking at the latest SRP patch [1], I noticed the patch was not zeroizing all keying buffers used with RAND_bytes [and perhaps erroneously RAND_pseudo_bytes]. For example, a particular buffer is last used in routine run_srp(const char *username, ...) at line 3171. But the buffer is

[openssl.org #2399] Request: Allow -no-xxx options in ./config for FIPS build

I'm building a FIPS validated module using OpenSSL sources. The system is new, and has absolutely no need for MD2, RC4, MD5, DES, 2DES, 3DES, etc. When the OpenSSL source code is re-validated, please consider allow folks to remove the algorithms. There are a few reasons to allow the removal of

Re: [openssl.org #2399] Request: Allow -no-xxx options in ./config for FIPS build

Hi Doctor, Thanks very much for a reply (I did not expect one for a suggestion). It should be possible to exclude algorithms from the FIPS capable version of OpenSSL, apart from the DES related algorithms. If not that's a bug that will be fixed. Please don't take this as a bug report. I was

Re: [openssl.org #2399] Request: Allow -no-xxx options in ./config for FIPS build

On Fri, Dec 17, 2010 at 7:31 AM, Stephen Henson via RT r...@openssl.org wrote: [noloa...@gmail.com - Fri Dec 17 11:56:52 2010]: When the OpenSSL source code is re-validated, please consider allow folks to remove the algorithms. There are a few reasons to allow the removal of unused

[openssl.org #2401] PATCH: Spelling corrections in FAQ

Yes, folks do read them. FAQ.patch Description: Binary data

[openssl.org #2402] PATCH: config and Configure for Xcode Awareness

The attached will allow a user to call config, Configure, or make from within Xcode. Depending on the project, OpenSSL will be built for Mac OS X, iPhone, iPad, or the simulator. For completeness: Mac OS X: x86_64 i{Phone|Pad}: armv6, no-dso simulator: x86, no-dso config.patch Description:

[openssl.org #2403] Possible Documentation Issue (FIPS User's Guide)

In the November 2009 version of the FIPS User's Guide, Command Sets (Table 3.2.1b, p. 22) states U1 - Linux/Unix, pure C, cross­compiled. However, the build command appears to lack no-asm. __ OpenSSL Project

[openssl.org #3078] Makefile: install rule builds components

From OpenSSL 1.0.1e (https://www.openssl.org/source/openssl-1.0.1e.tar.gz). Makefile.org and Makefile's 'install' rule is: install: all install_docs install_sw The 'all' rule is default and is: all: Makefile build_all openssl.pc libssl.pc libcrypto.pc This should not be a problem from

Re: [openssl.org #3078] Makefile: install rule builds components

Below is a sample from Mac OS X. If this was run for Android, then CC=arm-linuxeabi-gcc and RANLIB=arm-linuxeabi-ranlib. Neither would be found when sudo drops the user's path. $./config shared -no-comp -no-sslv2 -no-sslv3 … $ make depend … $ make ... $ sudo make install Password: making all in

[openssl.org #3080] Android NEON and CFLAGS options

In reference to https://android.googlesource.com/platform/ndk/+/ics-mr0/docs/STANDALONE-TOOLCHAIN.html. It appears there are some flags that should be present when targeting Neon on Android: CFLAGS='-march=armv7-a -mfloat-abi=softfp -mfpu=neon'

[openssl.org #3081] openssl-fips-2.0.N

`make install` does not copy `incore` into openssldirbin/ during `make install`. fipsld and fips_standalone_sha1 are copied into bin/ (and fipsld relies on incore). A user who deletes their [temporary] working openssl-fips-2.0.N and later tries to link via the installed library will experience

[openssl.org #3084] openssl-1.0.1e: Configure lacks disable of SSLV2 and Compression by default

From file `Configure`, around line 720: my %disabled = ( # what = comment [or special keyword experimental] ec_nistp_64_gcc_128 = default, gmp= default, jpake = experimental, md2= default,

[openssl.org #3085] config on *nix does not reject incorrect arguments

I know this is my error, but the following is undesirable behavior: $ ./config fips shared -no-sslv2 -no-sslv3 -no-comp -no-hw -no-engines --openssldir=/usr/local/ssl/$ANDROID_API --with-fipsdir=/usr/local/ssl/$ANDROID_API --with-fipslibdir=/usr/local/ssl/$ANDROID_API/lib/ Operating system:

Re: [openssl.org #3080] Android NEON and CFLAGS options

On Sun, Jun 30, 2013 at 5:54 PM, Andy Polyakov via RT r...@openssl.org wrote: ... OpenSSL doesn't have any floating point, at least not on performance-critical paths, I believe the PRNG interface uses floating point operations (specifically, for the estimate of entropy). Jeff

[openssl.org #3108] bss_dgram.c does not honor OPENSSL_NO_SOCK

Below is from WinRT. Its turning out to be a bastard child. cl /Fotmp32dll\bss_dgram.obj -Iinc32 -Itmp32dll -DOPENSSL_THREADS -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WINRT -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D _CRT_SECURE_NO_DEPRECATE -I\usr\local\ssl\fips-2.0/include -DOPENSSL_NO_SOCK

Re: [openssl.org #3138] 80-bit Elliptic Curves with !MEDIUM !LOW !EXP cipher list

Perhaps there should be a ECLOW, ECMEDIUM, and ECHIGH. Curves with 80-bits of security (e.g., secp160) would be low; while 256-bits of security (e.g., secp521) would be high. I'm not sure how to slice the 128- and 192- bits of security, though. Perhaps a medium-low and medium-high? On Mon, Oct

[openssl.org #3179] Feature Request: Set Preference List for EC Curves in Client

ssl_prepare_clienthello_tlsext has the following in t1_lib.c around line 1690. pref_list[] is hard coded and includes some weaker curves. For example, pref_list[] include NID_secp160r2, which offers 80-bits of security. It would be nice to be able to replace the hard coded list with a list that

[openssl.org #3190] Patch to add -tls switch to s_server

Patch to add -tls switch to s_server. Using the switch allows TLS v1.0 or above for connections. `meth $ git diff apps/s_server.c diff --git a/apps/s_server.c b/apps/s_server.c index 1bac3b4..edda7db 100644 --- a/apps/s_server.c +++ b/apps/s_server.c @@ -314,6 +314,10 @@ static int s_quiet=0;

[openssl.org #3196] Default CRYPTO_THREADID for Mac OS X with Posix Threads

Default CRYPTO_THREADID for Mac OS X with Posix Threads $ git diff crypto/thr_id.c diff --git a/crypto/thr_id.c b/crypto/thr_id.c index 4267526..3b4dc6d 100644 --- a/crypto/thr_id.c +++ b/crypto/thr_id.c @@ -116,6 +116,11 @@ #include cryptlib.h +/* OS X way to determine pthread availability.

[openssl.org #3197] Patch for config and darwin64 on Mac OS X

I don't know if most have had the pleasure of trying to configure on a modern Mac, but we have to specify x86_64 explicitly. We are warned when running just 'config', but PERL does not honor the CTRL-C on Mac OS X. So its usually a process of double-config'ing - first for i686 and then for x86_64.

[openssl.org #3218] Typo in .../demos/cms_dec.c

Reported by a fellow on Stack Overflow (tuxmania) trying to run the cms demos .../demos/cms_enc.c and .../demos/cms_dec.c Around line 50 of cms_dec.c. * OLD: /* Decrypt S/MIME message */ if (!CMS_decrypt(cms, rkey, rcert, out, NULL, 0)) goto err; Causes the following:

[openssl.org #3276] Possible Bug/Opportunity for Improvement when loading ECDSA Key/Cert (Feature Request?)

Re: Server ECDSA certificate requirements for 1.0.1f?, https://groups.google.com/forum/#!topic/mailing.openssl.users/iTID_Hpj6XQ. A ECDSA key and certificate was generated for use on an OpenSSL powered server. The key was saved with the following, and a certifcate was subsequently generated from

[openssl.org #3277] OpenSSL s_client doc missing option

http://www.openssl.org/docs/apps/s_client.html The doc is missing -servername option. __ OpenSSL Project http://www.openssl.org Development Mailing List

[openssl.org #3293] Documentation for PKCS5_PBKDF2_HMAC

A question using PKCS5_PBKDF2_HMAC was recently asked on Stack Overflow. Currently, there is no documentation on the function. The PKCS5_PBKDF2_HMAC.pod is new. It is based on the documentation for EVP_BytesToKey. EVP_BytesToKey was updated to cross reference to PKCS5_PBKDF2_HMAC.

[openssl.org #3294] [PATCH] Documentation for PKCS5_PBKDF2_HMAC

A question using PKCS5_PBKDF2_HMAC was recently asked on Stack Overflow. Currently, there is no documentation on the function. The PKCS5_PBKDF2_HMAC.pod is new. It is based on the documentation for EVP_BytesToKey. EVP_BytesToKey was updated to cross reference to PKCS5_PBKDF2_HMAC.

[openssl.org #3344] PATCH: don't crash or fail in ASN1_print from t_pkey.c

PATCH: don't crash or fail in ASN1_print from crypto/asn1/t_pkey.c. ASN1_print crashes if the BIO is NULL. ASN1_print crashes if the label is NULL. ASN1_print fails *if* the label is empty (i.e., ). This patch fixes the three issues by validating the BIO pointer and providing an alternate

Re: [openssl.org #3344] PATCH: don't crash or fail in ASN1_print from t_pkey.c

Matt - I have not forgot about this I can't find the machine I wrote the code on (my place probably looks a lot like your place - different computers and laptops with different OSes all over the place). Looking at the return values, I don't believe Test 3 should have failed. Also, add a

[openssl.org #3392] EVP_SignFinal smashes the stack with RSA key. RSA key provides n,e,d,p,q.

EVP_SignFinal smashes the stack with RSA key. RSA key provides n,e,d,p,q. RSA_check_key OK. p and q were solved from n,e,d offline because the key check failed without it. * (gdb) r Starting program: /home/jwalton/openssl-test.exe Signature:

[openssl.org #3393] PATCH: EVP_SignInit.pod update

Its not clear that the signature's buffer size, `s`, is not used as an IN parameter. Under the current docs, the only thing stated is at most EVP_PKEY_size(pkey) bytes will be written. Its kind of misleading since it appears EVP_PKEY_size(pkey) WILL be written regardless of the signature's buffer

[openssl.org #3398] PATCH: fix broken compile on android-x86 with no-comp configure option

Discovered after configuring for Android x86 with -no-comp option. The best I can tell, openssl/comp.h is not even needed for the enc program. However, this is the probably the least intrusive change. diff --git a/apps/enc.c b/apps/enc.c index d84c51d..9cdbc57 100644 --- a/apps/enc.c +++

[openssl.org #3408] PATCH: Spelling corrections

Spelling corrections in openssl.cnf $ git diff apps/openssl.cnf diff --git a/apps/openssl.cnf b/apps/openssl.cnf index ccc21a2..c861dd4 100644 --- a/apps/openssl.cnf +++ b/apps/openssl.cnf @@ -40,12 +40,12 @@ default_ca = CA_default# The default ca section [ CA_default ] dir

[openssl.org #3409] PATCH: Update SSL_CTX_add_extra_chain_cert doc

The docs don't state if the application should (or should not) free the X509* presented to SSL_CTX_add_extra_chain_cert. The question recently came up on stack overflow: http://stackoverflow.com/questions/24263913/does-correct-freeing-of-x509-structures-differ-between-chain-and-main-certificat.

[openssl.org #3416] PATCH: EVP_EncryptionInit and AES-NI note

Questions on AES-NI and how to enable them have come up twice recently on the stack exchanges (like stack overflow). This patch documents use of the AES-NI instruction by way of the EVP_* interface. diff --git a/doc/crypto/EVP_EncryptInit.pod b/doc/crypto/EVP_EncryptInit.pod index

Re: [openssl.org #3416] PATCH: EVP_EncryptionInit and AES-NI note

Since this may in future cover much more than just AES-NI... Good observation Doctor, done. Attached is the updated text. diff --git a/doc/crypto/EVP_EncryptInit.pod b/doc/crypto/EVP_EncryptInit.pod index f6e4396..8d7636c 100644 --- a/doc/crypto/EVP_EncryptInit.pod +++

[openssl.org #3421] PATCH: return appropriate error if RDRAND not available

Currently, ENGINE_load_rdrand will clear the error queue if the engine is loaded; but ENGINE_load_rdrand fails to set an error code if RDRAND is not available. This patch adds a check with an appropriate error code so callers can check for failure. Note: crypto/engine/engine.h only provides a

[openssl.org #3422] Misaligned pointers for buffers cast to an unsigned int* in md32_common.h

Running `make test` with Clang sanitizers results in some issues with unaligned pointers surrounding a use of buffers cast to a unsigned int*. The sanitizers used were `-fsanitize=undefined -fsanitize=address`. I believe the issues flagged below are undefined behavior. ---snip---

[openssl.org #3423] Undefined behavior in crypto/cast/c_enc.c

Running `make test` with Clang sanitizers results in some issues with crypto/cast/c_enc.c. The sanitizers used were `-fsanitize=undefined -fsanitize=address`. I believe the shift issue flagged below are undefined behavior. ---snip--- ../util/shlib_wrap.sh ./casttest c_enc.c:79:2: runtime error:

[openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

Running `make test` with Clang sanitizers results in some issues with unaligned pointers surrounding some uses of buffers cast to a size_t*. The sanitizers used were `-fsanitize=undefined -fsanitize=address`. I believe the issues flagged below are undefined behavior. ---snip--- seed

[openssl.org #3425] Potential padding oracle in evp_enc.c

Around line 519 in evp_enc.c: // Line 519 below if (b 1) { if (ctx-buf_len || !ctx-final_used) { EVPerr(EVP_F_EVP_DECRYPTFINAL_EX,EVP_R_WRONG_FINAL_BLOCK_LENGTH); return(0); } OPENSSL_assert(b = sizeof ctx-final);

[openssl.org #3429] PATCH: Update to X509_check_host documentation

Viktor graciously took the time to explain some of the finer details of the new name matching API (see http://www.mail-archive.com/openssl-users@openssl.org/msg74281.html). The discussion was helpful to me, and would likely be helpful to others. The patch incorporates Viktor's comments, and

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

On Tue, Jul 8, 2014 at 4:33 PM, Andy Polyakov via RT r...@openssl.org wrote: As for warning. I personally would argue that we are looking at platform-specific i.e. implementation-defined behaviour, not undefined. Once again, this applies to all three tickets. One is effectively identical to

[openssl.org #3456] PATCH: fix typo in pem.pod

EVP_bytestokey - EVP_BytesToKey Added SEE ALSO section with links to EVP_get_cipherbyname and EVP_BytesToKey. * $ git diff doc/crypto/pem.pod diff --git a/doc/crypto/pem.pod b/doc/crypto/pem.pod index 54414a3..21e9fe3 100644 --- a/doc/crypto/pem.pod +++ b/doc/crypto/pem.pod @@ -450,9 +450,9

[openssl.org #3457] Possible Bugs in EVP_KeyToBytes?

Below is from crypto/evp/evp_key.c. Notice that `addmd` is never set to 1. *If* the routine needs to loop back to the top to finish fulfilling a derivation request, then the previous hash is *not* added back into the computation. That is, this is never executed: if (addmd++)

Re: [openssl.org #3457] AutoReply: Possible Bugs in EVP_KeyToBytes?

Please cancel the first issue of not adding previous hash when looping. I mis-read it (twice!). I believe the return value issue is still valid. On Tue, Jul 15, 2014 at 1:31 PM, The default queue via RT r...@openssl.org wrote: Greetings, This message has been automatically generated in

[openssl.org #3458] PATCH: ensure debug builds with GCC include -g3 -ggdb

PATCH: ensure generic debug builds with GCC include `-g3 -ggdb`. Developer configurations, such as `debug-ben-*`, were not modified. Unfamiliar platforms, such as HP-UX, were not modified. `-g3` provides the highest level of debug information, including symbolic names for constants. `-ggdb` adds

[openssl.org #3461] PATCH: expanded explanation of PEM ENCRYPTION

This patch improves the documentation on the PEM ENCRYPTION algorithm. The improvements attempts to clarify the use of the salt and initialization vector, and include pseudo-code. * diff --git a/doc/crypto/pem.pod b/doc/crypto/pem.pod index 21e9fe3..5c8a1e4 100644 --- a/doc/crypto/pem.pod

[openssl.org #3465] EC command fails to parse ECPrivateKey without optional params

According to RFC 5915 (http://tools.ietf.org/html/rfc5915): ECPrivateKey ::= SEQUENCE { versionINTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1), privateKey OCTET STRING, parameters [0] ECParameters {{ NamedCurve }} OPTIONAL, publicKey [1] BIT STRING OPTIONAL }

[openssl.org #3466] PATCH: fix bad return value in dsa utility when using -noout option

The following fails for a good key (produced by OpenSSL utility). It returns 1 when it should return 0. $ openssl dsa -in dsa-pub.pem -pubin -text -noout read DSA key pub: 29:a1:21:67:5c:d8:85:b3:10:76:80:8a:78:af:0a: dd:1b:4b:92:76:75:cd:be:e9:05:8d:e7:71:ed:69:

[openssl.org #3472] PATCH: Update info on PKCS8 command and -iter option

Following MC's comments at https://groups.google.com/d/msg/mailing.openssl.users/BETH6d-kS38/2BikoVnINp8J: $ cat pkcs8.pod.diff diff --git a/doc/apps/pkcs8.pod b/doc/apps/pkcs8.pod index e946cbd..59954de 100644 --- a/doc/apps/pkcs8.pod +++ b/doc/apps/pkcs8.pod @@ -81,7 +81,8 @@ see the BPASS

[openssl.org #3481] Add space to help compiler/analyzer parse token

This came up during testing. The entire issue is not clear, but here's the issue filed on Github: Minor typo change in ssl/s3_enc.c, https://github.com/openssl/openssl/issues/151: For c/cpp syntax analysis ambiguities, is it possible to change in int ssl3_digest_cached_records(SSL *s)

[openssl.org #3492] BUG: Make dclean creates a 630K+ git diff

$ git rev-parse HEAD 750487899ad2b794078ed998b513a4a14f60f2cc ... $ make clean make dclean $ git diff openssl.diff $ ls -l openssl.diff -rw-r--r-- 1 jwalton staff 636941 Aug 17 02:21 openssl.diff It would be helpful if openssl-dev was cleaned so a useful diff could be produced when touching

[openssl.org #3503] BUG: make dclean deletes the test/ directory, which results in duplicate symbols on subsequent make's

A fresh clone results in duplicate symbols if a make dclean is performed: duplicate symbol _main in: heartbeat_test.o testutil.o ld: 1 duplicate symbol for architecture x86_64 It appears make dclean deletes the test/ directory. After the directory is deleted, all hell

[openssl.org #3504] PATCH: documentation update for dgst command

From Stack Overflow and What key is used by openssl (command) for HMAC if key is not passed in as argument, https://stackoverflow.com/questions/25492833/what-key-is-used-by-openssl-command-for-hmac-if-key-is-not-passed-in-as-argume. The docs don't specify the behavior for the following: echo

Re: [openssl.org #3504] PATCH: documentation update for dgst command

Oops, thanks Rich. On Tue, Aug 26, 2014 at 10:06 AM, Rich Salz via RT r...@openssl.org wrote: The key is not optional with the -hmac option. This is fixed in the rsalz-monolith branch of akamai/openssl on github, to be rpart of release after 1.0.2 thanks. -- Rich Salz, OpenSSL dev team;

Re: [openssl.org #3503] BUG: make dclean deletes the test/ directory, which results in duplicate symbols on subsequent make's

This appears to be the relevant output. It looks like PEM and TXT files are deleted in addition to C files. $ make dclean ... making dclean in apps... ... making dclean in test... /opt/local/bin/perl5 -pe 'if (/^# DO NOT DELETE THIS LINE/) {print; exit(0);}' Makefile Makefile.new mv -f

[openssl-dev] [openssl.org #3690] s_client.c and missing psk_key symbol

Modifying and compiling s_client.c manually results in a compile failure: export OPENSSLDIR=/usr/local/ssl/darwin gcc -DMONOLITH -I$OPENSSLDIR/include -I../ -c apps.c gcc -DMONOLITH -I$OPENSSLDIR/include -I../ -c app_rand.c gcc -DMONOLITH -I$OPENSSLDIR/include -I../ -c s_cb.c gcc

[openssl-dev] [openssl.org #3661] BUG: errstr cannot decode a failed signature verification when using EVP_DigestVerifyFinal

When using EVP_DigestSign and EVP_DigestVerify functions, errstr cannot decode a failed verification error under RSA. To duplicate, create a signature with EVP_DigestSign. Tamper with the signature: sig[0] ^= 0x1. Then run it through EVP_DigestVerify. In the case of OpenSSL 1.0.1: $ ./t-rsa.exe

[openssl-dev] [openssl.org #3659] BUG: EVP_DigestVerifyFinal does not take a const pointer

According to https://www.openssl.org/docs/crypto/EVP_DigestVerifyInit.html, EVP_DigestVerifyFinal does not take a const pointer. The signature already exists, and it was passed into the function as a 'const unsigned char*'. This creates a compile problem in practice: t-hmac.c:212:41: warning:

[openssl-dev] [openssl.org #3648] BUG: Undefined behavior in easy_tls.c

Around line 731 of demos/easy_tls/easy_tls.c: if (tls_dhe1024 == NULL) { int i; RAND_bytes((unsigned char *) i, sizeof i); /* make sure that i is non-negative -- pick one of the provided * seeds */ if (i 0) i = -i; if (i 0) i

[openssl-dev] [openssl.org #3691] Wishlist: separate strings for libcrypto and libssl

A while back, Google started flagging software in Google Play for providing what it believed to be vulnerable versions of OpenSSL. See, for example, Security Alert: You are using a highly vulnerable version of OpenSSL,

[openssl-dev] [openssl.org #3684] Missing stddef.h for source files using offsetof

It appears a couple of source files are using the offsetof macro defined in staddef.h. However, those files are *not* including stddef.h, which is causing intermittent compile problems. For example, http://stackoverflow.com/q/28246642/608639. Please add #include stddef.h to the following files:

[openssl-dev] [openssl.org #3690] s_client.c and missing psk_key symbol

Modifying and compiling s_client.c manually results in a compile failure: export OPENSSLDIR=/usr/local/ssl/darwin gcc -DMONOLITH -I$OPENSSLDIR/include -I../ -c apps.c gcc -DMONOLITH -I$OPENSSLDIR/include -I../ -c app_rand.c gcc -DMONOLITH -I$OPENSSLDIR/include -I../ -c s_cb.c gcc

[openssl-dev] [openssl.org #3822] BUG: Configure does not set RPATH correctly

This discussion relates to 1.0.2a. But I know its applies to other versions from all the changes I've had to make to Makefile.org. I'm not sure if this me using Configure incorrectly, or a bug in Configure. I suspect its the later. Below, I used both --prefix and --openssldir in an attempt to

Re: [openssl-dev] [openssl.org #3822] BUG: Configure does not set RPATH correctly

On Sun, Apr 26, 2015 at 8:21 AM, Kurt Roeckx via RT r...@openssl.org wrote: On Sun, Apr 26, 2015 at 02:09:17PM +0200, noloa...@gmail.com via RT wrote: This discussion relates to 1.0.2a. But I know its applies to other versions from all the changes I've had to make to Makefile.org. I'm

[openssl-dev] [openssl.org #3814] make dclean breaks build and tests

It appears `make dclean` still whacks a bunch of test files in Master. It looks like at east 39 files are deleted: $ git status | grep delete | wc -l 39 * If the test/ directory is deleted, then that means its not possible to test the library after a build. You might as well delete

[openssl-dev] [openssl.org #2561] Re: Memory leak with SSL built-in compressions

Is there any progress on this? Its been about 5 years, and folks are still having trouble with it. For example: * http://stackoverflow.com/questions/29845527/how-to-properly-uninitialize-openssl. * http://openssl.6102.n7.nabble.com/Preferred-way-to-free-ssl-comp-methods-td48573.html *

[openssl-dev] [openssl.org #3824] FEATURE: Please provide a function to unintialize the library

This question crops up on occasion: How do you shutdown the OpenSSL library. See, for example: * How to properly uninitialize OpenSSL, http://stackoverflow.com/questions/29845527/how-to-properly-uninitialize-openssl. * Order of Cleanup to avoid memory leaks?,

[openssl-dev] [openssl.org #3836] DOCUMENTATION: missing documentation for SSL_get_certificate

The ECDH callback needs to query the server's certificate to discover the EC group being used. The callback can then return a temporary key in the field. It looks like SSL_get_certificate can be used for the purpose. SSL_get_certificate is used in apps/s_cb.c, but there's no documentation for it.

[openssl-dev] [openssl.org #3894] PATCH: EVP_PKEY_get_type (new function)

I've found this to be a useful function over the years. I shared it with others, too (see, for example, http://stackoverflow.com/a/30626251/608639). I understand opacity is preferred and this is discouraged, and the additional documentation reflects the sentiment. For me (and the the programmers

Re: [openssl-dev] [openssl.org #3894] AutoReply: PATCH: EVP_PKEY_get_type (new function)

Here's an updated patch that includes the documentation changes. `git diff master` is needed after `git add` because adding doesn't seem to really add things for git :) riemann::openssl-git$ cat evp_pkey_get_type.diff diff --git a/crypto/evp/evp_lib.c b/crypto/evp/evp_lib.c index 1fdde9a..0cd8a42

Re: [openssl-dev] [openssl.org #3894] AutoReply: PATCH: EVP_PKEY_get_type (new function)

03, 2015 at 08:50:25PM +, noloa...@gmail.com via RT wrote: Here's an updated patch that includes the documentation changes. `git diff master` is needed after `git add` because adding doesn't seem to really add things for git :) riemann::openssl-git$ cat evp_pkey_get_type.diff diff --git

[openssl-dev] [openssl.org #3899] PATCH: Update to EVP_BytesToKey.pod documentation

Another small issue revealed on Stack Overflow: Utilizing PBKDF2 with OpenSSL library, http://stackoverflow.com/q/22795471. In the question the OP cited the man page for EVP_BytesToKey. He knew he needed to use PBKDF2 from the man page, but the man page did not explicit call out OpenSSL's

[openssl-dev] [openssl.org #3919] ssl.h uses ALL in its default cipher list

The following is from ssl.h, around line 285: /* * The following cipher list is used by default. It also is substituted when * an application-defined cipher list string starts with 'DEFAULT'. */ # define SSL_DEFAULT_CIPHER_LIST ALL:!aNULL:!eNULL Its 2015, and its probably

[openssl-dev] [openssl.org #3914] Library on Windows does not export SSL_CTX_set_options or SSL_set_options

I was kind of surprised to learn this... The SSL library on Windows does not export SSL_CTX_set_options or SSL_set_options. Below is a dumpbin /exports of ssleay.dll. * 543E8F47 time date stamp Wed Oct 15 11:14:15 2014 0.00 version 1 ordinal base 362 number

Re: [openssl-dev] [openssl.org #3914] Library on Windows does not export SSL_CTX_set_options or SSL_set_options

Dooh I should have known :( Sorry about the extra noise. On Wed, Jun 17, 2015 at 5:10 PM, Joey Yandle via RT r...@openssl.org wrote: I was kind of surprised to learn this... The SSL library on Windows does not export SSL_CTX_set_options or SSL_set_options. That's because it's a macro:

Re: [openssl-dev] [openssl.org #3887] PATCH: rsautl and intelligent retry for Public Key parse after Traditional/Subject Public Key Info parse fails

On Sun, May 31, 2015 at 12:27 PM, Richard Levitte via RT r...@openssl.org wrote: Nice idea, I'm however thinking that much of the trying different formats could be moved to load_key / load_pubkey, all that would be needed is a keyformat denoting try anything. -1, perhaps? I like the idea,

Re: [openssl-dev] [openssl.org #3887] PATCH: rsautl and intelligent retry for Public Key parse after Traditional/Subject Public Key Info parse fails

I submitted this earlier, but I forgot to tweak the docs. The docs were missing the -keyform option, and they needed the behavior change documented. I also fixed a typo in the patch. The following was missing an 'else if': if(keyformat == FORMAT_PEM) { next_format = FORMAT_PEMRSA;

[openssl-dev] [openssl.org #3887] PATCH: rsautl and intelligent retry for Public Key parse after Traditional/Subject Public Key Info parse fails

apps.c has a couple of parsing routines called load_pubkey and load_key. rsautl uses those routines. However, there's no option in rsautil to use anything other than a ASN.1/DER or PEM encoded traditional key (or subject public key info). The code paths are present, we just can't seem to get to

Re: [openssl-dev] [openssl.org #4142] Fail to detect Xcode 7 for Intel AVX code

On Tue, Nov 17, 2015 at 12:43 PM, Jun Sun via RT wrote: > Hi, > > I just found the perl script for x86_64 assembly failed to detect Xcode 7 > environment (Apple LLVM 7.x), and skipped generating AVX code for MAC OS > ($avx variable is always false). The reason is Apple since

[openssl-dev] [openssl.org #3937] OpenSSL and s_client behavior when default CA certificates are available

When s_client is well configured, meaning the library user has placed something like cacerts.cpem (http://curl.haxx.se/docs/caextract.html) in the proper place so s_client has them available by default, then... The following produces unexpected results: #!/bin/bash wget -O Google-CA.der

[openssl-dev] [openssl.org #4056] 1.0.2d and Configure issue under X32 (ARFLAGS is architecture name?)

I experienced this issue under X32. X32 provides 32-bit integers, longs and pointers combined with the richness of x86_64 register set. Debian has a chroot environment for X32 at https://wiki.debian.org/X32Port. It appears ARFLAGS is set to the architecture when using RPATH options in Configure's

[openssl-dev] [openssl.org #4071] Doc Bug: SSL_CTX_set_tmp_dh_callback (and friends) and client code

The docs for SSL_CTX_set_tmp_dh_callback(3) (https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_tmp_dh_callback.html) and friends state the functions are called for DH parameter selection. It fails to state they are only called in servers, and not clients. Please update the docs to make it

[openssl-dev] [openssl.org #4196] BeagleBone Black detected as ARMv4

This seems like an odd result considering the BeagleBone Black processor is closer to a NEON. This particular BBB is running a Debian 8.2 based image. I also believe CFLAGS should include hard-floats (i.e., -mfloat-abi=hard). Without it, entropy estimates for some of the RAND_ functions could

Re: [openssl-dev] [openssl.org #4567] Configure does not honor CFLAGS

On Tue, Jun 14, 2016 at 3:33 AM, Richard Levitte via RT wrote: > Is this enough to satisfy you? > > ./config -DNDEBUG -g3 -O0 Yes, that would be good. no-asm and no-omit-frame-pointer on x86 may be good choices, too. Jeff > On Tue Jun 14 07:24:31 2016, noloa...@gmail.com

Re: [openssl-dev] [openssl.org #4567] Configure does not honor CFLAGS

On Tue, Jun 14, 2016 at 3:43 AM, Richard Levitte via RT wrote: > Cool. That closes this ticket. Thank you very much. > BTW, you're right, we don't honor a CFLAGS env var. We never did. We take the > cflags on the configuration command line. There's always hope. Its eternal

[openssl-dev] [openssl.org #4567] Configure does not honor CFLAGS

Working from latest sources. I'm trying to build a "debug" configuration with both -DNDEBUG (I don't want asserts firing) and -g3 (I want the symbolic constants). $ ./config no-asm -g3 -O0 -fno-omit-frame-pointer Operating system: i86pc-whatever-solaris2 Configuring for solaris64-x86_64-gcc

Re: [openssl-dev] [openssl.org #4434] Gentoo 13, x86_64: 4 failed self tests

On Mon, Jun 13, 2016 at 12:32 PM, Matt Caswell via RT wrote: > On Wed Jun 01 22:20:38 2016, matt wrote: >> Hi Jeff >> >> Please could you try the attached patch? > > > Jeff confirmed to me that the patch solved the problem. Pushed as commit > 25b9d11c0. Confirmed. Its a good,

[openssl-dev] [openssl.org #4565] Fatal error: Command failed for target `link_shlib.solaris'

Just pulled latest source (Camellia changes): $ git rev-parse HEAD 96d06c213d5a2c1af42dd3b5d7bcc4a65df90738 Config OK, Make fails at. Verified twice: SHOBJECTS="./libcrypto.a "; ( :;LIBDEPS="${LIBDEPS:--lresolv -lsocket -lnsl -ldl}"; SHAREDCMD="${SHAREDCMD:-gcc}";

Re: [openssl-dev] [openssl.org #4196] BeagleBone Black detected as ARMv4

On Tue, May 10, 2016 at 6:27 PM, Andy Polyakov via RT wrote: >> This seems like an odd result considering the BeagleBone Black >> processor is closer to a NEON. > > Well, ./config script should add -march=armv7-a option and that is more > than enough to make it NEON-capable. In

Re: [openssl-dev] [openssl.org #4434] AutoReply: Gentoo 13, x86_64: 4 failed self tests

It looks like there's still some problems with our old friend afalgtest. Below is from 1.1.0-pre6 on 1 JUN 2016 ** $ cat gentoo-result.txt ( cd test; \ SRCTOP=../. \ BLDTOP=../. \ PERL="/usr/bin/perl" \ EXE_EXT= \ OPENSSL_ENGINES=.././engines \ /usr/bin/perl

[openssl-dev] [openssl.org #4553] Re: Fedora 1, i386: error: field `next_timeout` has incomplete type

So testing with 1.1.0-pre6 from 1 JUN 2016 appears to show some new issues. ./config detects as i686-linux-whatever. However, there are some issues with CFLAGS. The '-arch x86_64' makes it appear to be configured for quasi-OS X mode. I believe -m32 should be used if an arch is needed. There's

Re: [openssl-dev] [openssl.org #4553] Re: Fedora 1, i386: error: field `next_timeout` has incomplete type

On Wed, Jun 1, 2016 at 4:47 PM, Richard Levitte via RT wrote: > Please give us the full configuration command you used, including environment > variables that may affect it. Just the presence of '-ansi' tells me that you > didn't just say './config' without any arguments. I

Re: [openssl-dev] [openssl.org #4553] Re: Fedora 1, i386: error: field `next_timeout` has incomplete type

On Wed, Jun 1, 2016 at 4:47 PM, Richard Levitte via RT wrote: > Please give us the full configuration command you used, including environment > variables that may affect it. Just the presence of '-ansi' tells me that you > didn't just say './config' without any arguments. Sorry

Re: [openssl-dev] [openssl.org #4379] "arch/async_posix.h:67:24: error: ucontext.h: No such file or directory" under OpenBSD 5.7/64-bit

Hi Matt, I'm testing this now. Jeff On Tue, May 24, 2016 at 6:42 PM, Matt Caswell via RT wrote: > On Wed May 11 10:24:31 2016, matt wrote: >> Hi Jeff >> >> Please could you try the attached patch? > > Hi Jeff > > Were you able to try out the patch? > > Thanks > > Matt > > --

Re: [openssl-dev] [openssl.org #4379] "arch/async_posix.h:67:24: error: ucontext.h: No such file or directory" under OpenBSD 5.7/64-bit

> Please could you try the attached patch? It tested OK. 'make test' executed without any problems. Ship it and close the ticket. Jeff On Wed, May 11, 2016 at 6:24 AM, Matt Caswell via RT wrote: > On Sat Mar 05 02:22:00 2016, noloa...@gmail.com wrote: >> cc -I.. -I../..

[openssl-dev] [openssl.org #4547] Changing function CRYPTO_num_locks() to "#define CRYPTO_num_locks() (0)" breaks compiles

Also see http://stackoverflow.com/q/37517730 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4547 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4566] Re: Fatal error: Command failed for target `link_shlib.solaris'

Close. It looks like it was cleared with Commit 5ec84dd75f7965942a55ef5382aa34b8417336c5. On Mon, Jun 13, 2016 at 4:12 PM, Jeffrey Walton wrote: > Just pulled latest source (Camellia changes): > > $ git rev-parse HEAD > 96d06c213d5a2c1af42dd3b5d7bcc4a65df90738 > > Config OK,

[openssl-dev] [openssl.org #4578] ARMv7a and failed self test

The following is from a CubieBoard. I verified I performed a 'make clean' and 'git pull'. $ git rev-parse HEAD 13c03c8d6da334bb1cde6ce4133e7c75b3b76947 ** using V=1: ../test/recipes/30-test_evp.t .. 1..1 Test line 2163(aligned in-place): unexpected error VALUE_MISMATCH

  1   2   3   >