From rt at openssl.org Sat Jan 2 01:57:18 2016 From: rt at openssl.org (Juan Manuel Guerrero via RT) Date: Sat, 02 Jan 2016 01:57:18 +0000 Subject: [openssl-dev] [openssl.org #4212] Compilation of master branch fails with 's_nbio' undeclared (first use in this function). In-Reply-To: <56870460.70406@gmx.de> References: <56870460.70406@gmx.de> Message-ID: I have tried to compile the muster branch using DJGPP and the compilation failed with error: s_server.c:397:5: error: 's_nbio' undeclared (first use in this function) A comparision with OpenSSL_1_0_2-stable, where everthing works flawlessly, shows that s_nbio is only used iff the macro FIONBIO is defined. For some reason the #ifdef FIONBIO/#endif in functions s_server_init and s_server_main have been removed in the master branch. At the same time the static definition of s_nbio at line 230 is enclosed by a #ifdef FIONBIO/#endif. This has the consequence that it becomes impossible to compile the application for all systems that do not define FIONBIO. I have added #ifdef FIONBIO/#endif where appropriate. The bottom line of this is that the usage of #ifdef FIONBIO/#endif is not consistent through the code. I also do not understand if the assumption is licit that all systems have to support non-blocking IO. But that seems to me to be the consecuence if you remove the #ifdef FIONBIO/#endif from the code. Please see patch against master branch. Regards, Juan M. Guerrero diff --git a/apps/s_server.c b/apps/s_server.c index e0eac55..4669723 100644 --- a/apps/s_server.c +++ b/apps/s_server.c @@ -393,7 +393,9 @@ static void s_server_init(void) s_cert_file2 = TEST_CERT2; s_key_file2 = NULL; ctx2 = NULL; +#ifdef FIONBIO s_nbio = 0; +#endif s_nbio_test = 0; ctx = NULL; www = 0; @@ -1224,10 +1226,15 @@ int s_server_main(int argc, char *argv[]) vfyCAfile = opt_arg(); break; case OPT_NBIO: +#ifdef FIONBIO s_nbio = 1; +#endif break; case OPT_NBIO_TEST: - s_nbio = s_nbio_test = 1; +#ifdef FIONBIO + s_nbio = 1; +#endif + s_nbio_test = 1; break; case OPT_IGN_EOF: s_ign_eof = 1; _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sat Jan 2 01:57:18 2016 From: rt at openssl.org (Rainer Jung via RT) Date: Sat, 02 Jan 2016 01:57:18 +0000 Subject: [openssl-dev] [openssl.org #4211] Document Perl requirements for OpenSSL 1.1.0 In-Reply-To: <56855038.4000105@kippdata.de> References: <56855038.4000105@kippdata.de> Message-ID: Trying to build OpenSSL 1.1.0-pre1 on Solaris 10 Sparc I got the opportunity to get some insight in the perl requirements especially for running the new OpenSSL test suite. Solaris 10 Sparc comes with perl 5.8.4 which suffices to build OpenSSL, but not for running the test suite. Current Docs Situation ====================== Currently the OpenSSL distribution contains the info: - NEWS o Reworked test suite, now based on perl, Test::Harness and Test::More Maybe one should point to the main INSTALL "Note on Perl" section here? - INSTALL To install OpenSSL, you will need: ... * Perl 5 with core modules (see 'Note on Perl' further down) ... and further down: Note on Perl ------------ For our scripts, we rely quite a bit on Perl, and increasingly on some core Perl modules. These Perl modules are part of the Perl source, so if you build Perl on your own, you should be set. However, if you install Perl as binary packages, the outcome might differ, and you may have to check that you do get the core modules installed properly. We do not claim to know them all, but experience has told us the following: - on Linux distributions based on Debian, the package 'perl' will install the core Perl modules as well, so you will be fine. - on Linux distributions based on RPMs, you will need to install 'perl-core' rather than just 'perl'. It is highly recommended that you have at least Perl version 5.12 installed. Here I wonder why version 5.12 is recommended. See below for some argument to actually require minimum version 5.10.1 instead of recommending 5.12. - CHANGES *) New testing framework The testing framework has been largely rewritten and is now using perl and the perl modules Test::Harness and an extended variant of Test::More called OpenSSL::Test to do its work. All test scripts in test/ have been rewritten into test recipes, and all direct calls to executables in test/Makefile have become individual recipes using the simplified testing OpenSSL::Test::Simple. For documentation on our testing modules, do: perldoc test/testlib/OpenSSL/Test/Simple.pm perldoc test/testlib/OpenSSL/Test.pm [Richard Levitte] Maybe one should point to the main INSTALL "Note on Perl" section here? - test/README no info. Maybe one should point to the main INSTALL "Note on Perl" section here? Minimum useful Perl Version =========================== Minimum useful version for building and testing OpenSSL 1.1.0 IMHO is 5.10, better 5.10.1. Reasons: - several test suite files contain regexps with "\R" which has only been introduced in 5.10.0. - the module File::Path is need in version >= 2 which was first bundled in 5.10.0 - the module parent.pm is needed, which was first bundled in 5.10.1 The only other requirement, Test::More in version >= 0.96 was first bundled much later in perl 5.13.4. It is probably a bit too new to require that perl version in general. Fortunately adding a newer Test::More to an existing perl is quite trivial, even using a private lib directory when not having write permissions for the perl installation. Since Test::More has no other dependencies and doesn't compile native stuff etc. during its installation, it suffices to add the directory lib/Test from the extracted Test::More download (ie. the following files): Test/Builder/IO/Scalar.pm Test/Builder/Tester/Color.pm Test/Builder/Module.pm Test/Builder/Tester.pm Test/Tester/Capture.pm Test/Tester/CaptureRunner.pm Test/Tester/Delegate.pm Test/use/ok.pm Test/Tutorial.pod Test/Simple.pm Test/Builder.pm Test/Tester.pm Test/More.pm into some directory and add that directory to the PERL5LIB env var before running make test. That is a bit dirty though (doesn't run the module test suite etc.). Using cpan, it typically works to install a module like Test::More to a private directory /my/perl/dir by setting the following env vars before running cpan: PERL_LOCAL_LIB_ROOT=/my/perl/dir PERL_MB_OPT="--install_base /my/perl/dir" PERL_MM_OPT="INSTALL_BASE=/my/perl/dir" PERL5LIB=/my/perl/dir/lib/perl5 then running cpan and "install Test::More" and the setting the env var PERL5LIB=/my/perl/dir/lib/perl5 before building and especially testing OpenSSL. So I wonder why the INSTALL file recommends 5.12? I'd require 5.10.1 and add some info about adding a sufficiently new (0.96) version of Test::More to an existing installation. One can check which module was bundled with which perl version using the "corelist" command, that itself was first bundled a bit before 5.10. Regards, Rainer _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sat Jan 2 11:15:00 2016 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Sat, 02 Jan 2016 11:15:00 +0000 Subject: [openssl-dev] [openssl.org #4213] Error defining ciphersuite 0x0300ff87 In-Reply-To: References: Message-ID: Hello, I've found I made a typo introducing the GOST ciphersuite 0x0300ff87. It's a ciphersuite with NULL encryption and so it is rarely used, that's why I did not catch this mistake during the testing. This specification requires using the "stream MAC" mode for this ciphersuite. The patch is attached. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c index e3e4fd3..50dbbc5 100644 --- a/ssl/s3_lib.c +++ b/ssl/s3_lib.c @@ -3284,7 +3284,7 @@ OPENSSL_GLOBAL const SSL_CIPHER ssl3_ciphers[] = { SSL_GOST12_256, SSL_TLSV1, SSL_STRONG_NONE, - SSL_HANDSHAKE_MAC_GOST12_256 | TLS1_PRF_GOST12_256, + SSL_HANDSHAKE_MAC_GOST12_256 | TLS1_PRF_GOST12_256 | TLS1_STREAM_MAC, 0, 0}, #endif -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From dmitry at addlive.com Sat Jan 2 11:51:14 2016 From: dmitry at addlive.com (Dmitry Sobinov) Date: Sat, 2 Jan 2016 22:51:14 +1100 Subject: [openssl-dev] [GitHub PR] RFC 7714 DTLS-SRTP profiles Message-ID: <166A7D6B-AF20-4490-A78B-DF168E64CE70@addlive.com> Hi, I?ve created a pull request with simple changes to support two new AEAD profiles for DTLS-SRTP. https://github.com/openssl/openssl/pull/521 Regards, Dmitry Sobinov -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sat Jan 2 17:55:07 2016 From: rt at openssl.org (Roumen Petrov via RT) Date: Sat, 02 Jan 2016 17:55:07 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: <56880EEF.4070607@roumenpetrov.info> References: <5678F551.8000406@roumenpetrov.info> <56880EEF.4070607@roumenpetrov.info> Message-ID: Rich Salz via RT wrote: > [SNIP] > out = dup_bio_out(FORMAT_TEXT); > - prog = opt_init(argc, argv, engine_options); > if (!engines || !pre_cmds || !post_cmds) > goto end; > + while ((argv1 = argv[1]) != NULL && *argv1 != '-') { > + sk_OPENSSL_STRING_push(engines, *argv1); > + argc--; > + argv++; > + } > + prog = opt_init(argc, argv, engine_options); > [SNIP] Above patch is not complete. It seems to opt_init stop processing on first non-option argument. In sample like : openssl engine dynamic \ -pre SO_PATH:/lib/libfoo.so \ -pre ID:foo \ -pre LOAD \ -pre "CMD_FOO:some input data" Arguments after dynamic are considered as engines The code try to use engines like "-pre", "ID:foo" and "CMD_FOO:some input data". Another sample is " Or to simply see the list of commands supported by the "foo" ENGINE; openssl engine -vvvv dynamic \ -pre SO_PATH:/lib/libfoo.so \ -pre ID:foo \ -pre LOAD " In above case engine is between "normal" arguments. Roumen From deengert at gmail.com Sat Jan 2 18:13:44 2016 From: deengert at gmail.com (Douglas E Engert) Date: Sat, 2 Jan 2016 12:13:44 -0600 Subject: [openssl-dev] i2c_ASN1_INTEGER not exposed in github master Message-ID: <56881358.5070403@gmail.com> In OpenSSL-1.0.2 opensssl/asn1.h defines both i2c_ASN1_INTEGER and i2c_ASN1_BIT_STRING These are not in development version in github. Was this intentional? -- Douglas E. Engert From rt at openssl.org Sat Jan 2 21:40:33 2016 From: rt at openssl.org (Dmitry Sobinov via RT) Date: Sat, 02 Jan 2016 21:40:33 +0000 Subject: [openssl-dev] [openssl.org #4214] [GitHub PR] RFC 7714 DTLS-SRTP profiles In-Reply-To: <166A7D6B-AF20-4490-A78B-DF168E64CE70@addlive.com> References: <166A7D6B-AF20-4490-A78B-DF168E64CE70@addlive.com> Message-ID: Hi, I?ve created a pull request with simple changes to support two new AEAD profiles for DTLS-SRTP. https://github.com/openssl/openssl/pull/521 Regards, Dmitry Sobinov -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From michel.sales at free.fr Sat Jan 2 22:31:58 2016 From: michel.sales at free.fr (Michel) Date: Sat, 2 Jan 2016 23:31:58 +0100 Subject: [openssl-dev] OCB mode not flagged as AEAD ? Message-ID: <001801d145ad$64865900$2d930b00$@sales@free.fr> Hi, Trying the 1.1 pre-release version, I am surprised that the following assertion failed : assert( EVP_CIPHER_flags( EVP_aes_128_ocb() ) & EVP_CIPH_FLAG_AEAD_CIPHER ); Consequently, my test program doesn't use the requested control command : EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_AEAD_GET_TAG, taglen, tag); EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_AEAD_SET_TAG, taglen, tag); and fails to decrypt data. (as do the openssl enc command, which doesn't return : "AEAD ciphers not supported", but instead ends with "bad decrypt" ). Is there any reason for that ? Do we really need to test : if( AEAD OR OCB ) { . } Thanks, and by the way, I whish you all an Happy New Year. Michel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sun Jan 3 03:25:35 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Sun, 03 Jan 2016 03:25:35 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: References: <5678F551.8000406@roumenpetrov.info> <56880EEF.4070607@roumenpetrov.info> Message-ID: Please see this: https://github.com/openssl/openssl/compare/master...richsalz:rt4194?expand=1 From rt at openssl.org Sun Jan 3 17:52:06 2016 From: rt at openssl.org (Roumen Petrov via RT) Date: Sun, 03 Jan 2016 17:52:06 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: <56895FC0.9060309@roumenpetrov.info> References: <5678F551.8000406@roumenpetrov.info> <56880EEF.4070607@roumenpetrov.info> <56895FC0.9060309@roumenpetrov.info> Message-ID: Salz, Rich via RT wrote: > Please see this: > https://github.com/openssl/openssl/compare/master...richsalz:rt4194?expand=1 > It should fail with openssl engine -vvvv dynamic -pre SO_PATH:/lib/libfoo.so .... Help string looks good. Roumen From rt at openssl.org Sun Jan 3 18:27:45 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Sun, 03 Jan 2016 18:27:45 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: <03af5c2a77594cf0aaa7dd38a94fb7a0@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5678F551.8000406@roumenpetrov.info> <56880EEF.4070607@roumenpetrov.info> <56895FC0.9060309@roumenpetrov.info> <03af5c2a77594cf0aaa7dd38a94fb7a0@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Tweaked, sigh. ; ./util/opensslwrap.sh engine -vvvv dynamic -pre xxxx engine: Cannot mix flags and engine names. engine: Use -help for summary. exit 1 From rt at openssl.org Sun Jan 3 18:31:29 2016 From: rt at openssl.org (Roumen Petrov via RT) Date: Sun, 03 Jan 2016 18:31:29 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: <568968F9.6000509@roumenpetrov.info> References: <5678F551.8000406@roumenpetrov.info> <56880EEF.4070607@roumenpetrov.info> <56895FC0.9060309@roumenpetrov.info> <03af5c2a77594cf0aaa7dd38a94fb7a0@usma1ex-dag1mb1.msg.corp.akamai.com> <568968F9.6000509@roumenpetrov.info> Message-ID: Salz, Rich via RT wrote: > Tweaked, sigh. > ; ./util/opensslwrap.sh engine -vvvv dynamic -pre xxxx > engine: Cannot mix flags and engine names. > engine: Use -help for summary. > exit 1 > If engine name cannot be at any position then please keep it as is. i.e. at last position. In this case please correct documentation with line in change log. From rt at openssl.org Sun Jan 3 18:55:13 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Sun, 03 Jan 2016 18:55:13 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: <3D833A20-69FE-4F32-B65F-06D09ED97180@openssl.org> References: <5678F551.8000406@roumenpetrov.info> <56880EEF.4070607@roumenpetrov.info> <03af5c2a77594cf0aaa7dd38a94fb7a0@usma1ex-dag1mb1.msg.corp.akamai.com> <568968F9.6000509@roumenpetrov.info> <3D833A20-69FE-4F32-B65F-06D09ED97180@openssl.org> Message-ID: The different subcommands act differently in this regard. I think it's time they get streamlined, and yes, I agree with the "any order" paradigm. I might do this tonight... Cheers Richard Roumen Petrov via RT skrev: (3 januari 2016 19:31:29 CET) >Salz, Rich via RT wrote: >> Tweaked, sigh. >> ; ./util/opensslwrap.sh engine -vvvv dynamic -pre xxxx >> engine: Cannot mix flags and engine names. >> engine: Use -help for summary. >> exit 1 >> >If engine name cannot be at any position then please keep it as is. >i.e. >at last position. In this case please correct documentation with line >in >change log. > > >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From rt at openssl.org Sun Jan 3 19:07:56 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Sun, 03 Jan 2016 19:07:56 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: <6477601B-07E8-4435-BBE9-FA0EEF35A765@openssl.org> References: <5678F551.8000406@roumenpetrov.info> <56880EEF.4070607@roumenpetrov.info> <568968F9.6000509@roumenpetrov.info> <3D833A20-69FE-4F32-B65F-06D09ED97180@openssl.org> <6477601B-07E8-4435-BBE9-FA0EEF35A765@openssl.org> Message-ID: Never mind that comment. Wrong thread... Richard Levitte via RT skrev: (3 januari 2016 19:55:13 CET) >The different subcommands act differently in this regard. I think it's >time they get streamlined, and yes, I agree with the "any order" >paradigm. > >I might do this tonight... > >Cheers >Richard > >Roumen Petrov via RT skrev: (3 januari 2016 19:31:29 >CET) >>Salz, Rich via RT wrote: >>> Tweaked, sigh. >>> ; ./util/opensslwrap.sh engine -vvvv dynamic -pre xxxx >>> engine: Cannot mix flags and engine names. >>> engine: Use -help for summary. >>> exit 1 >>> >>If engine name cannot be at any position then please keep it as is. >>i.e. >>at last position. In this case please correct documentation with line >>in >>change log. >> >> >>_______________________________________________ >>openssl-dev mailing list >>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From rsalz at akamai.com Sun Jan 3 19:27:05 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 3 Jan 2016 19:27:05 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: References: <5678F551.8000406@roumenpetrov.info> <56880EEF.4070607@roumenpetrov.info> <56895FC0.9060309@roumenpetrov.info> <03af5c2a77594cf0aaa7dd38a94fb7a0@usma1ex-dag1mb1.msg.corp.akamai.com> <568968F9.6000509@roumenpetrov.info> Message-ID: So you're saying just close this ticket? From rt at openssl.org Sun Jan 3 19:27:08 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Sun, 03 Jan 2016 19:27:08 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: References: <5678F551.8000406@roumenpetrov.info> <56880EEF.4070607@roumenpetrov.info> <03af5c2a77594cf0aaa7dd38a94fb7a0@usma1ex-dag1mb1.msg.corp.akamai.com> <568968F9.6000509@roumenpetrov.info> Message-ID: So you're saying just close this ticket? From rt at openssl.org Sun Jan 3 19:39:39 2016 From: rt at openssl.org (Roumen Petrov via RT) Date: Sun, 03 Jan 2016 19:39:39 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: <568978F8.90004@roumenpetrov.info> References: <5678F551.8000406@roumenpetrov.info> <56880EEF.4070607@roumenpetrov.info> <568968F9.6000509@roumenpetrov.info> <568978F8.90004@roumenpetrov.info> Message-ID: Salz, Rich via RT wrote: > So you're saying just close this ticket? > No. My request is to restore flexible engine command line and optionally help string. I only disagree with proposed partial correction for command line. From rt at openssl.org Sun Jan 3 20:33:33 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Sun, 03 Jan 2016 20:33:33 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: References: <5678F551.8000406@roumenpetrov.info> <56880EEF.4070607@roumenpetrov.info> <568978F8.90004@roumenpetrov.info> Message-ID: The old style of complete intermix of flags and parameters is not going to happen. From beldmit at gmail.com Sun Jan 3 21:47:46 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 4 Jan 2016 00:47:46 +0300 Subject: [openssl-dev] Regression: dgst command Message-ID: Hello, I run my test suite for the openssl 1.1.0 version. Executing the command openssl dgst -md_gost94 -sign rsaseckey.pem -out sig.bin dgst.dat I get an error: Error setting context 47545377098440:error:0408C09D:rsa routines:check_padding_md:invalid digest:rsa_pmeth.c:413: The behavior have changed in 1.1.0. Is it a design decision (and I should fix tests) or misbehavior? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Jan 4 14:07:23 2016 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Mon, 04 Jan 2016 14:07:23 +0000 Subject: [openssl-dev] [openssl.org #4215] Results of regression for some apps In-Reply-To: References: Message-ID: Hello! I found the following problems running my cipher suite with openssl 1.1.0 1. Some apps try to load the default config file twice. In case when we load an engine via the config file and the engine prevents itself from loading more than once, it causes errors. The attached patch contains fixes for the 'req' and 'ts' utilities, but may be there are some more utilities with specific config files. 2. The 'smime' utility erroneously regards the '-signer' option to be the name of input file. It's wrong when the utility uses this option in -verify mode. So the attached patch makes this option to be processed as string, not as input. 3. The 'cms' and 'smime' utilities do not accept the '-inform smime' options. It may be a bug or not a bug (files in SMIME format are accepted) but it is definitely an incompatibility. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- diff --git a/apps/req.c b/apps/req.c index a0da788..9235b2b 100644 --- a/apps/req.c +++ b/apps/req.c @@ -377,13 +377,14 @@ int req_main(int argc, char **argv) BIO_printf(bio_err, "Error getting passwords\n"); goto end; } - + if (template != default_config_file) + { if (verbose) BIO_printf(bio_err, "Using configuration from %s\n", template); req_conf = app_load_config(template); if (!app_load_modules(req_conf)) goto end; - + } if (req_conf != NULL) { p = NCONF_get_string(req_conf, NULL, "oid_file"); if (p == NULL) diff --git a/apps/smime.c b/apps/smime.c index 551a8fd..a1dde89 100644 --- a/apps/smime.c +++ b/apps/smime.c @@ -115,7 +115,7 @@ OPTIONS smime_options[] = { {"noattr", OPT_NOATTR, '-', "Don't include any signed attributes"}, {"binary", OPT_BINARY, '-', "Don't translate message to text"}, {"certfile", OPT_CERTFILE, '<', "Other certificates file"}, - {"signer", OPT_SIGNER, '<', "Signer certificate file"}, + {"signer", OPT_SIGNER, 's', "Signer certificate file"}, {"recip", OPT_RECIP, '<', "Recipient certificate file for decryption"}, {"in", OPT_IN, '<', "Input file"}, {"inform", OPT_INFORM, 'F', "Input format SMIME (default), PEM or DER"}, diff --git a/apps/ts.c b/apps/ts.c index 00b5e53..c1a3b05 100644 --- a/apps/ts.c +++ b/apps/ts.c @@ -319,10 +319,11 @@ int ts_main(int argc, char **argv) goto end; } + if (configfile != default_config_file) { conf = load_config_file(configfile); if (!app_load_modules(conf)) goto end; - + } /* Check parameter consistency and execute the appropriate function. */ switch (mode) { default: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Jan 4 14:35:29 2016 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Mon, 04 Jan 2016 14:35:29 +0000 Subject: [openssl-dev] [openssl.org #4216] ocsp 1.1.0/1.0.2 incompatibility In-Reply-To: References: Message-ID: Hello, I found an incompatibility in behavior of the 'ocsp' utility in the 1.0.2 and 1.1.0 versions. The command line openssl ocsp -issuer cacert.pem -CAfile cacert.pem -md_gost94 -cert cert1.pem -sha1 -cert cert2.pem -reqout request.der returns an error in 1.1.0: ocsp: Digest must be before -cert or -serial ocsp: Use -help for summary. This command line worked well in 1.0.2. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From doctor at doctor.nl2k.ab.ca Mon Jan 4 16:08:31 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 4 Jan 2016 09:08:31 -0700 Subject: [openssl-dev] OPenssl and dependencies such as openssh Message-ID: <20160104160831.GA4457@doctor.nl2k.ab.ca> This might be a croosmail, but necessary. I did us openssl-SNAP-20160104 minorss erros and installed. I tried openssh-SNAP-20160105 and the OpenSSL libraries cannot be found In the openssh configuration file I see # Determine OpenSSL library version { $as_echo "$as_me:${as_lineno-$LINENO}: checking OpenSSL library versi on" >&5 $as_echo_n "checking OpenSSL library version... " >&6; } if test "$cross_compiling" = yes; then : { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: cross compiling: not checking" >&5 $as_echo "$as_me: WARNING: cross compiling: not checking" >&2;} else cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ #include #include #include #include #define DATA "conftest.ssllibver" int main () { FILE *fd; int rc; fd = fopen(DATA,"w"); if(fd == NULL) exit(1); if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), SSLeay_version(SSLEAY_VERSION))) <0) exit(1); exit(0); ; return 0; } _ACEOF if ac_fn_c_try_run "$LINENO"; then : ssl_library_ver=`cat conftest.ssllibver` # Check version is supported. case "$ssl_library_ver" in 0090[0-7]*|009080[0-5]*) as_fn_error $? "OpenSSL >= 0.9.8f requi red (have \"$ssl_library_ver\")" "$LINENO" 5 ;; *) ;; esac { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ssl_l ibrary_ver" >&5 $as_echo "$ssl_library_ver" >&6; } else { $as_echo "$as_me:${as_lineno-$LINENO}: result: not fo und" >&5 $as_echo "not found" >&6; } as_fn_error $? "OpenSSL library not found." "$LINENO" 5 fi rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \ conftest.$ac_objext conftest.beam conftest.$ac_ext fi Could there be anything that is causing openssh not to see the new openssl 1.1 and are any other dependent serverware affacted? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Happy Christmas 2015 and Merry New Year 2016 From openssl-users at dukhovni.org Mon Jan 4 19:22:04 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 4 Jan 2016 19:22:04 +0000 Subject: [openssl-dev] [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160104160831.GA4457@doctor.nl2k.ab.ca> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> Message-ID: <20160104192204.GL18704@mournblade.imrryr.org> On Mon, Jan 04, 2016 at 09:08:31AM -0700, The Doctor wrote: > if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), > SSLeay_version(SSLEAY_VERSION))) <0) > > Could there be anything that is causing openssh not to see the new openssl 1.1 The above. The SSLeay names are gone. The new way is: if ((rc = fprintf(fd ,"%08x (%s)\n", OpenSSL_version_num(), OpenSSL_version(OPENSSL_VERSION))) <0) I think it is likely prudent at this time to restore source- backwards-compatible behaviour, by adding to : #if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < 0x10100000L # include # define SSLeay OpenSSL_version_num # define SSLeay_version OpenSSL_version # define SSLEAY_VERSION_NUMBER OPENSSL_VERSION_NUMBER # define SSLEAY_VERSION OPENSSL_VERSION # define SSLEAY_CFLAGS OPENSSL_CFLAGS # define SSLEAY_BUILT_ON OPENSSL_BUILT_ON # define SSLEAY_PLATFORM OPENSSL_PLATFORM # define SSLEAY_DIR OPENSSL_DIR #endif /* OPENSSL_API_COMPAT */ Users who want to make sure they are avoiding interfaces that are deprecated with 1.1.0 can set OPENSSL_API_COMPAT to 0x10100000L or higher as appropriate. -- Viktor. From rt at openssl.org Mon Jan 4 19:42:48 2016 From: rt at openssl.org (Juan Manuel Guerrero via RT) Date: Mon, 04 Jan 2016 19:42:48 +0000 Subject: [openssl-dev] [openssl.org #4217] Fixing DJGPP port of openssl master branch. In-Reply-To: <568A77AE.8090801@gmx.de> References: <568A77AE.8090801@gmx.de> Message-ID: Unfortunately the DJGPP port is badly brocken in the master branch. The provided patch shall fix the issues. Both patches will fix/improve the following issues: 1) In Configure: For some reason -DTERMIO is set but DJGPP has never offered TERMIO making the build fail. I have changed this to -DTERMIOS as is used to be. 2) In crypto/bio/bss_dgram.c: The superflous macro definitions of sock_write, sock_read and sock_puts enclosed by WATT32 have been removed. 3) In crypto/bio/bss_sock.c: Here the existing macro definitions for sock_write, sock_read and sock_puts are necessary and must be kept but they must be undefined before they can be defined. This is because newer versions of Watt-32 also redefine them. 4) In crypto/conf/conf_def.c: If this port is used on MS-DOS or FreeDOS it becomes necessary to check if the underlying file system supports long file names (aka LFN) or not. If it does not then file names with a leading dot like ".rnd" or ".ca_certs" are ilicit. In function def_load_bio, the macros IS_RANDFILE and IS_CERT_DIR are used to check if the file system offers LFN support so that the file names with leading dots are licit and can be used. If the tests fail then the new function dosify_filename is called and will substitute invalid characters in the file name by valid ones before using them. This check and the call of dosify_filename is enclosed by OPENSSL_SYS_MSDOS. 5) In e_os.h: In the DJGPP section the macros IS_RANDFILE and IS_CERT_DIR are defined. Also some auxiliar macros like HAS_LFN_SUPPORT and FILE_EXISTS are defined. Because neither MS-DOS nor FreeDOS provide 'egd' sockets, the DEVRANDOM_EGD macro is undefined. This shall inhibit the compilation of code that does not work on MS-DOS/FreeDOS. 6) In INSTALL.DJGPP: Update URL of WATT-32 library. I have checked the modified version of the master branch works on linux and Cygwin. They are no issues. This is no surprise because the changes are either enclosed by the __DJGPP__ or OPENSSL_SYS_MSDOS macros. If more informaton is required please mail me. I have attached the patch as gzip'ed file too. Regards, Juan M. Guerrero 2016-01-04 Juan Manuel Guerrero * Configurations/10-main.conf: Replaced -DTERMIO by -DTERMIOS in CFLAGS. * crypto/bio/bss_dgram.c [WATT32]: Remove obsolete redefinition of function names: sock_write, sock_read and sock_puts. * crypto/bio/bss_sock.c [WATT32]: For Watt-32 2.2.11 sock_write, sock_read and sock_puts are redefined to their private names so their names must be undefined first before they can be redefined again. * crypto/conf/conf_def.c (def_load_bio) [OPENSSL_SYS_MSDOS]: Call dosify_filename to replace leading dot if file system does not support it. (dosify_filename): Replace leading dot in passed file name if file system does not support LFN. * e_os.h [__DJGPP__]: Undefine macro DEVRANDOM_EGD. Neither MS-DOS nor FreeDOS provides 'egd' sockets. New macros IS_RANDFILE and IS_CERT_DIR are defined to identify the RANDFILE entry in openssl.cnf and the cert_dir entry in ssleay.conf. New macro RFILE that is defined either to ".rnd" or "_rnd" depending on if LFN support is available or not. * INSTALL.DJGPP: Update URL of WATT-32 library. diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf index a82b95d..fad57a9 100644 --- a/Configurations/10-main.conf +++ b/Configurations/10-main.conf @@ -1299,7 +1299,7 @@ "DJGPP" => { inherit_from => [ asm("x86_asm") ], cc => "gcc", - cflags => "-I/dev/env/WATT_ROOT/inc -DTERMIO -DL_ENDIAN -fomit-frame-pointer -O2 -Wall", + cflags => "-I/dev/env/WATT_ROOT/inc -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O2 -Wall", sys_id => "MSDOS", lflags => "-L/dev/env/WATT_ROOT/lib -lwatt", bn_ops => "BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}", diff --git a/INSTALL.DJGPP b/INSTALL.DJGPP index 1047ec9..23aed6a 100644 --- a/INSTALL.DJGPP +++ b/INSTALL.DJGPP @@ -18,7 +18,7 @@ files to download, see the DJGPP "ZIP PICKER" page at "http://www.delorie.com/djgpp/zip-picker.html". You also need to have the WATT-32 networking package installed before you try to compile - OpenSSL. This can be obtained from "http://www.bgnett.no/~giva/". + OpenSSL. This can be obtained from "http://www.watt-32.net/". The Makefile assumes that the WATT-32 code is in the directory specified by the environment variable WATT_ROOT. If you have watt-32 in directory "watt32" under your main DJGPP directory, specify diff --git a/crypto/bio/bss_dgram.c b/crypto/bio/bss_dgram.c index 5e934ce..ca318cf 100644 --- a/crypto/bio/bss_dgram.c +++ b/crypto/bio/bss_dgram.c @@ -97,12 +97,6 @@ ((a)->s6_addr32[2] == htonl(0x0000ffff))) # endif -# ifdef WATT32 -# define sock_write SockWrite /* Watt-32 uses same names */ -# define sock_read SockRead -# define sock_puts SockPuts -# endif - static int dgram_write(BIO *h, const char *buf, int num); static int dgram_read(BIO *h, char *buf, int size); static int dgram_puts(BIO *h, const char *str); diff --git a/crypto/bio/bss_sock.c b/crypto/bio/bss_sock.c index 1673b32..5cef4f3 100644 --- a/crypto/bio/bss_sock.c +++ b/crypto/bio/bss_sock.c @@ -66,7 +66,11 @@ # include # ifdef WATT32 -# define sock_write SockWrite /* Watt-32 uses same names */ +/* Watt-32 uses same names */ +# undef sock_write +# undef sock_read +# undef sock_puts +# define sock_write SockWrite # define sock_read SockRead # define sock_puts SockPuts # endif diff --git a/crypto/conf/conf_def.c b/crypto/conf/conf_def.c index ac07405..7d33a28 100644 --- a/crypto/conf/conf_def.c +++ b/crypto/conf/conf_def.c @@ -87,6 +87,9 @@ static int def_load_bio(CONF *conf, BIO *bp, long *eline); static int def_dump(const CONF *conf, BIO *bp); static int def_is_number(const CONF *conf, char c); static int def_to_int(const CONF *conf, char c); +#ifdef OPENSSL_SYS_MSDOS +static void dosify_filename(char *filename); +#endif static CONF_METHOD default_method = { "OpenSSL default", @@ -370,6 +373,10 @@ static int def_load_bio(CONF *conf, BIO *in, long *line) if (!str_copy(conf, psection, &(v->value), start)) goto err; +#ifdef OPENSSL_SYS_MSDOS + if (IS_RANDFILE(v->name) || IS_CERT_DIR(v->name)) + dosify_filename(v->value); +#endif if (strcmp(psection, section) != 0) { if ((tv = _CONF_get_section(conf, psection)) == NULL) @@ -678,3 +685,24 @@ static int def_to_int(const CONF *conf, char c) { return c - '0'; } + +#ifdef OPENSSL_SYS_MSDOS +static void dosify_filename(char *filename) +{ + if (filename && *filename && !HAS_LFN_SUPPORT(filename)) + { + char *slash; + int length; + for (length = 0; filename[length]; length++) + ; + for (slash = filename + length - 1; slash > filename && *slash != '/'; slash--) + ; + + /* Leading dot not allowed on plain DOS. */ + if (slash[0] == '.') + slash[0] = '_'; + else if (slash[1] == '.') + slash[1] = '_'; + } +} +#endif diff --git a/e_os.h b/e_os.h index 5ab4c89..9a5f812 100644 --- a/e_os.h +++ b/e_os.h @@ -141,6 +141,7 @@ extern "C" { # define writesocket(s,b,n) send((s),(b),(n),0) # elif defined(__DJGPP__) # define WATT32 +# define WATT32_NO_OLDIES # define get_last_socket_error() errno # define clear_socket_error() errno=0 # define closesocket(s) close_s(s) @@ -194,13 +195,33 @@ extern "C" { # include # include # include +# include # include # include # define _setmode setmode # define _O_TEXT O_TEXT # define _O_BINARY O_BINARY +# if defined (__GNUC__) && (__GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 8)) +# define __gnuc_extension__ __extension__ +# else +# define __gnuc_extension__ +# endif +# define FILE_EXISTS(name) (access((name), R_OK) == 0) +# define HAS_LFN_SUPPORT(name) (pathconf((name), _PC_NAME_MAX) > 12) +# define RFILE \ + (__gnuc_extension__ \ + ({ \ + char *rnd = HAS_LFN_SUPPORT(".rnd") && FILE_EXISTS(".rnd") ? ".rnd" : "_rnd"; \ + rnd; \ + }) \ + ) +# undef DEVRANDOM_EGD /* Neither MS-DOS nor FreeDOS provide 'egd' sockets. */ # undef DEVRANDOM # define DEVRANDOM "/dev/urandom\x24" +# define IS_RANDFILE(n) ((n)[0] == 'R' && (n)[1] == 'A' && (n)[2] == 'N' && (n)[3] == 'D' && \ + (n)[4] == 'F' && (n)[5] == 'I' && (n)[6] == 'L' && (n)[7] == 'E') +# define IS_CERT_DIR(n) ((n)[0] == 'c' && (n)[1] == 'e' && (n)[2] == 'r' && (n)[3] == 't' && \ + (n)[4] == '_' && (n)[5] == 'd' && (n)[6] == 'i' && (n)[7] == 'r') # endif /* __DJGPP__ */ # ifndef S_IFDIR @@ -327,7 +348,9 @@ extern FILE *_imp___iob; # endif # define OPENSSL_CONF "openssl.cnf" # define NUL_DEV "nul" -# define RFILE ".rnd" +# ifndef RFILE +# define RFILE ".rnd" +# endif # ifdef OPENSSL_SYS_WINCE # define DEFAULT_HOME "" # else -------------- next part -------------- A non-text attachment was scrubbed... Name: djgpp-openssl-master.patch.gz Type: application/x-gzip Size: 2325 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Jan 4 20:22:15 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 04 Jan 2016 20:22:15 +0000 Subject: [openssl-dev] [openssl.org #4217] Fixing DJGPP port of openssl master branch. In-Reply-To: <20160104.212201.300039170238726481.levitte@openssl.org> References: <568A77AE.8090801@gmx.de> <20160104.212201.300039170238726481.levitte@openssl.org> Message-ID: Hi Juan, and thanks. I'm looking at your fix, and have a couple of questions: In message on Mon, 04 Jan 2016 19:42:48 +0000, Juan Manuel Guerrero via RT said: rt> --- a/crypto/conf/conf_def.c rt> +++ b/crypto/conf/conf_def.c rt> @@ -87,6 +87,9 @@ static int def_load_bio(CONF *conf, BIO *bp, long *eline); rt> static int def_dump(const CONF *conf, BIO *bp); rt> static int def_is_number(const CONF *conf, char c); rt> static int def_to_int(const CONF *conf, char c); rt> +#ifdef OPENSSL_SYS_MSDOS rt> +static void dosify_filename(char *filename); rt> +#endif rt> rt> static CONF_METHOD default_method = { rt> "OpenSSL default", rt> @@ -370,6 +373,10 @@ static int def_load_bio(CONF *conf, BIO *in, long *line) rt> if (!str_copy(conf, psection, &(v->value), start)) rt> goto err; rt> rt> +#ifdef OPENSSL_SYS_MSDOS rt> + if (IS_RANDFILE(v->name) || IS_CERT_DIR(v->name)) rt> + dosify_filename(v->value); rt> +#endif Why only a specific file and directory? Don't *all* file names have to be "dosified"? rt> + rt> +#ifdef OPENSSL_SYS_MSDOS rt> +static void dosify_filename(char *filename) rt> +{ rt> + if (filename && *filename && !HAS_LFN_SUPPORT(filename)) rt> + { rt> + char *slash; rt> + int length; rt> + for (length = 0; filename[length]; length++) rt> + ; rt> + for (slash = filename + length - 1; slash > filename && *slash != '/'; slash--) rt> + ; rt> + rt> + /* Leading dot not allowed on plain DOS. */ rt> + if (slash[0] == '.') rt> + slash[0] = '_'; rt> + else if (slash[1] == '.') rt> + slash[1] = '_'; rt> + } rt> +} rt> +#endif I don't know DJGPP at all, but I'd be surprised if there isn't a strrchr(), so what would you say about this: #ifdef OPENSSL_SYS_MSDOS static void dosify_filename(char *filename) { if (filename && *filename && !HAS_LFN_SUPPORT(filename)) { char *filenamestart = strrchr(filename, '/'); if (filenamestart) filenamestart++; else filenamestart = filename; /* Leading dot not allowed on plain DOS. */ if (filenamestart[0] == '.') slash[0] = '_'; } } #endif Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From doctor at doctor.nl2k.ab.ca Mon Jan 4 20:29:56 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 4 Jan 2016 13:29:56 -0700 Subject: [openssl-dev] [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160104192204.GL18704@mournblade.imrryr.org> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> Message-ID: <20160104202956.GA24447@doctor.nl2k.ab.ca> On Mon, Jan 04, 2016 at 07:22:04PM +0000, Viktor Dukhovni wrote: > On Mon, Jan 04, 2016 at 09:08:31AM -0700, The Doctor wrote: > > > if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), > > SSLeay_version(SSLEAY_VERSION))) <0) > > > > Could there be anything that is causing openssh not to see the new openssl 1.1 > > The above. The SSLeay names are gone. The new way is: > > if ((rc = fprintf(fd ,"%08x (%s)\n", OpenSSL_version_num(), > OpenSSL_version(OPENSSL_VERSION))) <0) > > I think it is likely prudent at this time to restore source- > backwards-compatible behaviour, by adding to : > > #if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < 0x10100000L > # include > # define SSLeay OpenSSL_version_num > # define SSLeay_version OpenSSL_version > # define SSLEAY_VERSION_NUMBER OPENSSL_VERSION_NUMBER > # define SSLEAY_VERSION OPENSSL_VERSION > # define SSLEAY_CFLAGS OPENSSL_CFLAGS > # define SSLEAY_BUILT_ON OPENSSL_BUILT_ON > # define SSLEAY_PLATFORM OPENSSL_PLATFORM > # define SSLEAY_DIR OPENSSL_DIR > #endif /* OPENSSL_API_COMPAT */ > > Users who want to make sure they are avoiding interfaces that are > deprecated with 1.1.0 can set OPENSSL_API_COMPAT to 0x10100000L or > higher as appropriate. That is one way. Can we get developers to come on baord so that we can launch a new era without incident? > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From doctor at doctor.nl2k.ab.ca Tue Jan 5 00:28:13 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 4 Jan 2016 17:28:13 -0700 Subject: [openssl-dev] OPenssl and dependencies such as openssh In-Reply-To: References: <20160104160831.GA4457@doctor.nl2k.ab.ca> Message-ID: <20160105002812.GA1019@doctor.nl2k.ab.ca> On Tue, Jan 05, 2016 at 11:21:37AM +1100, Darren Tucker wrote: > On Tue, Jan 5, 2016 at 3:08 AM, The Doctor wrote: > > This might be a croosmail, but necessary. > > > > I did us openssl-SNAP-20160104 minorss erros and installed. > > installed onto what kind of system and where? > > > I tried openssh-SNAP-20160105 and the OpenSSL libraries cannot be found > > OpenSSH's config.log will have the details about what failed. > > My guess is that you built only a dynamic libcrypto.so and installed > it somewhere that your runtime linker can't find. Exactly how to fix > that will depend on what kind of system you have (eg /etc/ld.so.conf > on Linuxes). > Both libssl and libcrypto were build. In openssl , it was discovered that an old code was being used to find the libraries. > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From rt at openssl.org Tue Jan 5 03:05:45 2016 From: rt at openssl.org (Juan Manuel Guerrero via RT) Date: Tue, 05 Jan 2016 03:05:45 +0000 Subject: [openssl-dev] [openssl.org #4217] Fixing DJGPP port of openssl master branch. In-Reply-To: <568B25A2.8000705@gmx.de> References: <568A77AE.8090801@gmx.de> <20160104.212201.300039170238726481.levitte@openssl.org> <568B25A2.8000705@gmx.de> Message-ID: Am 04.01.2016 21:22, schrieb Richard Levitte via RT: > Hi Juan, and thanks. > > I'm looking at your fix, and have a couple of questions: > > In message on Mon, 04 Jan 2016 19:42:48 +0000, Juan Manuel Guerrero via RT said: > > rt> --- a/crypto/conf/conf_def.c > rt> +++ b/crypto/conf/conf_def.c > rt> @@ -87,6 +87,9 @@ static int def_load_bio(CONF *conf, BIO *bp, long *eline); > rt> static int def_dump(const CONF *conf, BIO *bp); > rt> static int def_is_number(const CONF *conf, char c); > rt> static int def_to_int(const CONF *conf, char c); > rt> +#ifdef OPENSSL_SYS_MSDOS > rt> +static void dosify_filename(char *filename); > rt> +#endif > rt> > rt> static CONF_METHOD default_method = { > rt> "OpenSSL default", > rt> @@ -370,6 +373,10 @@ static int def_load_bio(CONF *conf, BIO *in, long *line) > rt> if (!str_copy(conf, psection,&(v->value), start)) > rt> goto err; > rt> > rt> +#ifdef OPENSSL_SYS_MSDOS > rt> + if (IS_RANDFILE(v->name) || IS_CERT_DIR(v->name)) > rt> + dosify_filename(v->value); > rt> +#endif > > Why only a specific file and directory? Don't *all* file names have > to be "dosified"? > > rt> + > rt> +#ifdef OPENSSL_SYS_MSDOS > rt> +static void dosify_filename(char *filename) > rt> +{ > rt> + if (filename&& *filename&& !HAS_LFN_SUPPORT(filename)) > rt> + { > rt> + char *slash; > rt> + int length; > rt> + for (length = 0; filename[length]; length++) > rt> + ; > rt> + for (slash = filename + length - 1; slash> filename&& *slash != '/'; slash--) > rt> + ; > rt> + > rt> + /* Leading dot not allowed on plain DOS. */ > rt> + if (slash[0] == '.') > rt> + slash[0] = '_'; > rt> + else if (slash[1] == '.') > rt> + slash[1] = '_'; > rt> + } > rt> +} > rt> +#endif > > I don't know DJGPP at all, but I'd be surprised if there isn't a > strrchr(), so what would you say about this: > > #ifdef OPENSSL_SYS_MSDOS > static void dosify_filename(char *filename) > { > if (filename&& *filename&& !HAS_LFN_SUPPORT(filename)) { > char *filenamestart = strrchr(filename, '/'); > > if (filenamestart) > filenamestart++; > else > filenamestart = filename; > > /* Leading dot not allowed on plain DOS. */ > if (filenamestart[0] == '.') > slash[0] = '_'; > } > } > #endif > > Cheers, > Richard > Hi Richard, the implementation only reflected my personnal taste but the changes proposed by you are OK with me. Please inspect the patch and tell me if there are still some other issues that should be changed. Regards, Juan M. Guerrero 2016-01-04 Juan Manuel Guerrero * Configure: Replaced -DTERMIO by -DTERMIOS in CFLAGS. * crypto/bio/bss_dgram.c [WATT32]: Remove obsolete redefinition of function names: sock_write, sock_read and sock_puts. * crypto/bio/bss_sock.c [WATT32]: For Watt-32 2.2.11 sock_write, sock_read and sock_puts are redefined to their private names so their names must be undefined first before they can be redefined again. * crypto/conf/conf_def.c (def_load_bio) [OPENSSL_SYS_MSDOS]: Call dosify_filename to replace leading dot if file system does not support it. (dosify_filename): Replace leading dot in passed file name if file system does not support LFN. * e_os.h [__DJGPP__]: Undefine macro DEVRANDOM_EGD. Neither MS-DOS nor FreeDOS provide 'egd' sockets. New macro HAS_LEADING_DOT defined to identify those file names starting with a leading dot. New macro RFILE that is defined either to ".rnd" or "_rnd" depending on if LFN support is available or not. * INSTALL.DJGPP: Update URL of WATT-32 library. diff -aprNU5 openssl-SNAP-20160101.orig/Configurations/10-main.conf openssl-SNAP-20160101/Configurations/10-main.conf --- openssl-SNAP-20160101.orig/Configurations/10-main.conf 2015-12-19 10:12:42 +0100 +++ openssl-SNAP-20160101/Configurations/10-main.conf 2016-01-01 22:46:48 +0100 @@ -1297,11 +1297,11 @@ #### DJGPP "DJGPP" => { inherit_from => [ asm("x86_asm") ], cc => "gcc", - cflags => "-I/dev/env/WATT_ROOT/inc -DTERMIO -DL_ENDIAN -fomit-frame-pointer -O2 -Wall", + cflags => "-I/dev/env/WATT_ROOT/inc -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O2 -Wall", sys_id => "MSDOS", lflags => "-L/dev/env/WATT_ROOT/lib -lwatt", bn_ops => "BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}", perlasm_scheme => "a.out", }, diff -aprNU5 openssl-SNAP-20160101.orig/crypto/bio/bss_dgram.c openssl-SNAP-20160101/crypto/bio/bss_dgram.c --- openssl-SNAP-20160101.orig/crypto/bio/bss_dgram.c 2015-12-19 10:12:42 +0100 +++ openssl-SNAP-20160101/crypto/bio/bss_dgram.c 2016-01-01 22:46:48 +0100 @@ -95,16 +95,10 @@ (((a)->s6_addr32[0] == 0) && \ ((a)->s6_addr32[1] == 0) && \ ((a)->s6_addr32[2] == htonl(0x0000ffff))) # endif -# ifdef WATT32 -# define sock_write SockWrite /* Watt-32 uses same names */ -# define sock_read SockRead -# define sock_puts SockPuts -# endif - static int dgram_write(BIO *h, const char *buf, int num); static int dgram_read(BIO *h, char *buf, int size); static int dgram_puts(BIO *h, const char *str); static long dgram_ctrl(BIO *h, int cmd, long arg1, void *arg2); static int dgram_new(BIO *h); diff -aprNU5 openssl-SNAP-20160101.orig/crypto/bio/bss_sock.c openssl-SNAP-20160101/crypto/bio/bss_sock.c --- openssl-SNAP-20160101.orig/crypto/bio/bss_sock.c 2015-12-19 10:12:42 +0100 +++ openssl-SNAP-20160101/crypto/bio/bss_sock.c 2016-01-01 22:46:48 +0100 @@ -64,11 +64,15 @@ #ifndef OPENSSL_NO_SOCK # include # ifdef WATT32 -# define sock_write SockWrite /* Watt-32 uses same names */ +/* Watt-32 uses same names */ +# undef sock_write +# undef sock_read +# undef sock_puts +# define sock_write SockWrite # define sock_read SockRead # define sock_puts SockPuts # endif static int sock_write(BIO *h, const char *buf, int num); diff -aprNU5 openssl-SNAP-20160101.orig/crypto/conf/conf_def.c openssl-SNAP-20160101/crypto/conf/conf_def.c --- openssl-SNAP-20160101.orig/crypto/conf/conf_def.c 2015-12-19 10:12:42 +0100 +++ openssl-SNAP-20160101/crypto/conf/conf_def.c 2016-01-05 00:14:24 +0100 @@ -85,10 +85,13 @@ static int def_destroy_data(CONF *conf); static int def_load(CONF *conf, const char *name, long *eline); static int def_load_bio(CONF *conf, BIO *bp, long *eline); static int def_dump(const CONF *conf, BIO *bp); static int def_is_number(const CONF *conf, char c); static int def_to_int(const CONF *conf, char c); +#ifdef OPENSSL_SYS_MSDOS +static void dosify_filename(char *filename); +#endif static CONF_METHOD default_method = { "OpenSSL default", def_create, def_init_default, @@ -368,10 +371,14 @@ static int def_load_bio(CONF *conf, BIO } OPENSSL_strlcpy(v->name, pname, strlen(pname) + 1); if (!str_copy(conf, psection, &(v->value), start)) goto err; +#ifdef OPENSSL_SYS_MSDOS + if (HAS_LEADING_DOT(v->name)) + dosify_filename(v->value); +#endif if (strcmp(psection, section) != 0) { if ((tv = _CONF_get_section(conf, psection)) == NULL) tv = _CONF_new_section(conf, psection); if (tv == NULL) { @@ -676,5 +683,23 @@ static int def_is_number(const CONF *con static int def_to_int(const CONF *conf, char c) { return c - '0'; } + +#ifdef OPENSSL_SYS_MSDOS +static void dosify_filename(char *filename) +{ + if (filename && *filename && !HAS_LFN_SUPPORT(filename)) { + char *filenamestart = strrchr(filename, '/'); + + if (filenamestart) + filenamestart++; + else + filenamestart = filename; + + /* Leading dot not allowed on plain DOS. */ + if (filenamestart[0] == '.') + filenamestart[0] = '_'; + } +} +#endif diff -aprNU5 openssl-SNAP-20160101.orig/e_os.h openssl-SNAP-20160101/e_os.h --- openssl-SNAP-20160101.orig/e_os.h 2015-12-19 10:12:42 +0100 +++ openssl-SNAP-20160101/e_os.h 2016-01-05 00:28:10 +0100 @@ -139,10 +139,11 @@ extern "C" { # define clear_socket_error() WSASetLastError(0) # define readsocket(s,b,n) recv((s),(b),(n),0) # define writesocket(s,b,n) send((s),(b),(n),0) # elif defined(__DJGPP__) # define WATT32 +# define WATT32_NO_OLDIES # define get_last_socket_error() errno # define clear_socket_error() errno=0 # define closesocket(s) close_s(s) # define readsocket(s,b,n) read_s(s,b,n) # define writesocket(s,b,n) send(s,b,n,0) @@ -192,15 +193,32 @@ extern "C" { # ifdef __DJGPP__ # include # include # include +# include # include # include # define _setmode setmode # define _O_TEXT O_TEXT # define _O_BINARY O_BINARY +# if defined (__GNUC__) && (__GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 8)) +# define __gnuc_extension__ __extension__ +# else +# define __gnuc_extension__ +# endif +# define HAS_LEADING_DOT(name) (*(name) == '.') +# define FILE_EXISTS(name) (access((name), R_OK) == 0) +# define HAS_LFN_SUPPORT(name) (pathconf((name), _PC_NAME_MAX) > 12) +# define RFILE \ + (__gnuc_extension__ \ + ({ \ + char *rnd = HAS_LFN_SUPPORT(".rnd") && FILE_EXISTS(".rnd") ? ".rnd" : "_rnd"; \ + rnd; \ + }) \ + ) +# undef DEVRANDOM_EGD /* Neither MS-DOS nor FreeDOS provide 'egd' sockets. */ # undef DEVRANDOM # define DEVRANDOM "/dev/urandom\x24" # endif /* __DJGPP__ */ # ifndef S_IFDIR @@ -325,11 +343,13 @@ extern FILE *_imp___iob; # ifndef R_OK # define R_OK 4 # endif # define OPENSSL_CONF "openssl.cnf" # define NUL_DEV "nul" -# define RFILE ".rnd" +# ifndef RFILE +# define RFILE ".rnd" +# endif # ifdef OPENSSL_SYS_WINCE # define DEFAULT_HOME "" # else # define DEFAULT_HOME "C:" # endif diff -aprNU5 openssl-SNAP-20160101.orig/INSTALL.DJGPP openssl-SNAP-20160101/INSTALL.DJGPP --- openssl-SNAP-20160101.orig/INSTALL.DJGPP 2015-12-19 10:12:42 +0100 +++ openssl-SNAP-20160101/INSTALL.DJGPP 2016-01-01 22:46:48 +0100 @@ -16,11 +16,11 @@ All of these can be obtained from the usual DJGPP mirror sites or directly at "http://www.delorie.com/pub/djgpp". For help on which files to download, see the DJGPP "ZIP PICKER" page at "http://www.delorie.com/djgpp/zip-picker.html". You also need to have the WATT-32 networking package installed before you try to compile - OpenSSL. This can be obtained from "http://www.bgnett.no/~giva/". + OpenSSL. This can be obtained from "http://www.watt-32.net/". The Makefile assumes that the WATT-32 code is in the directory specified by the environment variable WATT_ROOT. If you have watt-32 in directory "watt32" under your main DJGPP directory, specify WATT_ROOT="/dev/env/DJDIR/watt32". From doctor at doctor.nl2k.ab.ca Tue Jan 5 16:19:32 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 5 Jan 2016 09:19:32 -0700 Subject: [openssl-dev] [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160104192204.GL18704@mournblade.imrryr.org> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> Message-ID: <20160105161932.GA22085@doctor.nl2k.ab.ca> On Mon, Jan 04, 2016 at 07:22:04PM +0000, Viktor Dukhovni wrote: > On Mon, Jan 04, 2016 at 09:08:31AM -0700, The Doctor wrote: > > > if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), > > SSLeay_version(SSLEAY_VERSION))) <0) > > > > Could there be anything that is causing openssh not to see the new openssl 1.1 > > The above. The SSLeay names are gone. The new way is: > > if ((rc = fprintf(fd ,"%08x (%s)\n", OpenSSL_version_num(), > OpenSSL_version(OPENSSL_VERSION))) <0) > > I think it is likely prudent at this time to restore source- > backwards-compatible behaviour, by adding to : > > #if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < 0x10100000L > # include > # define SSLeay OpenSSL_version_num > # define SSLeay_version OpenSSL_version > # define SSLEAY_VERSION_NUMBER OPENSSL_VERSION_NUMBER > # define SSLEAY_VERSION OPENSSL_VERSION > # define SSLEAY_CFLAGS OPENSSL_CFLAGS > # define SSLEAY_BUILT_ON OPENSSL_BUILT_ON > # define SSLEAY_PLATFORM OPENSSL_PLATFORM > # define SSLEAY_DIR OPENSSL_DIR > #endif /* OPENSSL_API_COMPAT */ > > Users who want to make sure they are avoiding interfaces that are > deprecated with 1.1.0 can set OPENSSL_API_COMPAT to 0x10100000L or > higher as appropriate. Tip of the iceberg. Number of changes are needed to be committed before launching. >From inn: tls.o: In function `tmp_dh_cb': /usr/source/inn-CURRENT-20160105/nnrpd/tls.c:219: undefined reference to `DH_generate_parameters' tls.o: In function `tls_init_serverengine': /usr/source/inn-CURRENT-20160105/nnrpd/tls.c:498: undefined reference to `SSLv23_server_method' gmake[1]: *** [nnrpd] Error 1 so 219 and that area gives us default: /* We should check current keylength vs. requested keylength * also, this is an extremely expensive operation! */ dh = DH_generate_parameters(keylength, DH_GENERATOR_2, NULL, NU LL); r = dh; I just comment these 2 lines out for now line 498 is CTX = SSL_CTX_new(SSLv23_server_method()); I just replace as follows CTX = SSL_CTX_new(TLS_server_method()); A better fix is neeeded. And there is Apache 2.4 Making all in support /usr/source/httpd-2.4.18/srclib/apr/libtool --silent --mode=link /usr/bin/gcc -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wpointer-arith -Wformat -Wformat-security -Wall -g -O2 -L/usr/contrib/lib -lssl -lcrypto -lpthread -o ab -static ab.lo -L/usr/lib -lc -lm -ldl -liconv -lintl -lutil -ldb -levent /usr/source/httpd-2.4.18/srclib/apr-util/libaprutil-1.la -lexpat /usr/source/httpd-2.4.18/srclib/apr/libapr-1.la -lpthread -lm ab.o: In function `test': /usr/source/httpd-2.4.18/support/ab.c:1863: undefined reference to `SSL_state' and this piece of code is set_conn_state(c, STATE_CONNECTED); #ifdef USE_SSL if (c->ssl) ssl_proceed_handshake(c); else #endif write_request(c); Looks like a lots of rewriting to do. > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From rt at openssl.org Tue Jan 5 17:36:35 2016 From: rt at openssl.org (Bjorn Kornefalk via RT) Date: Tue, 05 Jan 2016 17:36:35 +0000 Subject: [openssl-dev] [openssl.org #4218] Invalid typecasting in CRYPTO_ctr128_encrypt In-Reply-To: References: Message-ID: OpenSSL 1.0.2e At line 156 of crypto/modes/ctr128.c const unsigned char *in, unsigned char *out, unsigned char ivec[16], unsigned char ecount_buf[16] *(size_t *)(out + n) = *(size_t *)(in + n) ^ *(size_t *)(ecount_buf + n); If the buffers are not aligned, the application crashes due to the invalid type casting of unsigned char (1 byte) to size_t (4 to 8 bytes for most CPU:s). Same errors at line 99 data = (size_t *)counter; The solution is either to change the implementation to work with bytes or to change the input vector to const size_t *in, size_t *out, size_t ivec[16 / sizeof(size_t)], size_t ecount_buf[16 / sizeof(size_t) The workaround is to make sure that the input, output, ivvec and ecount are all aligned, but since they are declared as single byte arrays, there is a violation of the contract between input arguments and the usage of the arguments. Example to provoke this error running 64-bit SunOS core 'core' of 23520: ../out/solaris/pnrg_test ffffffff7efa44b4 CRYPTO_ctr128_encrypt (10010a090, 10010b8c0, 10, ffffffff7fffef58, ffffffff7ffff128, ffffffff7ffff13c) + d8 ffffffff7ef8dd80 AES_ctr128_encrypt (10010a090, 10010b8c0, 10, ffffffff7fffef58, ffffffff7ffff128, ffffffff7ffff13c) + 3c 00000001000057ac PNRG::generateRandomData(unsigned long) (ffffffff7ffff13c, ffffffff7ffff128, 100, 20, 10010a090, 10010a0b0) + 13c In Linux, it does not provoke a core dump. Applicaition is compiled using gcc (GCC) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. Best regards Bj?rn Kornefalk Senior Software Engineer Giesecke & Devrient 3S AB Fredsborgsgatan 24 100 74 Stockholm SWEDEN Tel: (+46) 70 350 5633 -------------- next part -------------- A non-text attachment was scrubbed... Name: pnrg_test.cpp Type: application/octet-stream Size: 5179 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From doctor at doctor.nl2k.ab.ca Tue Jan 5 22:33:50 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 5 Jan 2016 15:33:50 -0700 Subject: [openssl-dev] [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160105161932.GA22085@doctor.nl2k.ab.ca> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> <20160105161932.GA22085@doctor.nl2k.ab.ca> Message-ID: <20160105223350.GB19904@doctor.nl2k.ab.ca> On Tue, Jan 05, 2016 at 09:19:32AM -0700, The Doctor wrote: > On Mon, Jan 04, 2016 at 07:22:04PM +0000, Viktor Dukhovni wrote: > > On Mon, Jan 04, 2016 at 09:08:31AM -0700, The Doctor wrote: > > > > > if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), > > > SSLeay_version(SSLEAY_VERSION))) <0) > > > > > > Could there be anything that is causing openssh not to see the new openssl 1.1 > > > > The above. The SSLeay names are gone. The new way is: > > > > if ((rc = fprintf(fd ,"%08x (%s)\n", OpenSSL_version_num(), > > OpenSSL_version(OPENSSL_VERSION))) <0) > > > > I think it is likely prudent at this time to restore source- > > backwards-compatible behaviour, by adding to : > > > > #if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < 0x10100000L > > # include > > # define SSLeay OpenSSL_version_num > > # define SSLeay_version OpenSSL_version > > # define SSLEAY_VERSION_NUMBER OPENSSL_VERSION_NUMBER > > # define SSLEAY_VERSION OPENSSL_VERSION > > # define SSLEAY_CFLAGS OPENSSL_CFLAGS > > # define SSLEAY_BUILT_ON OPENSSL_BUILT_ON > > # define SSLEAY_PLATFORM OPENSSL_PLATFORM > > # define SSLEAY_DIR OPENSSL_DIR > > #endif /* OPENSSL_API_COMPAT */ > > > > Users who want to make sure they are avoiding interfaces that are > > deprecated with 1.1.0 can set OPENSSL_API_COMPAT to 0x10100000L or > > higher as appropriate. > > > Tip of the iceberg. > > Number of changes are needed to be committed before launching. > > >From inn: > > tls.o: In function `tmp_dh_cb': > /usr/source/inn-CURRENT-20160105/nnrpd/tls.c:219: undefined reference to `DH_generate_parameters' > tls.o: In function `tls_init_serverengine': > /usr/source/inn-CURRENT-20160105/nnrpd/tls.c:498: undefined reference to `SSLv23_server_method' > gmake[1]: *** [nnrpd] Error 1 > > so 219 and that area gives us > > default: > /* We should check current keylength vs. requested keylength > * also, this is an extremely expensive operation! */ > dh = DH_generate_parameters(keylength, DH_GENERATOR_2, NULL, NU > LL); > r = dh; > > I just comment these 2 lines out for now > > line 498 is > > CTX = SSL_CTX_new(SSLv23_server_method()); > > I just replace as follows > > CTX = SSL_CTX_new(TLS_server_method()); > > A better fix is neeeded. > > And there is Apache 2.4 > > Making all in support > /usr/source/httpd-2.4.18/srclib/apr/libtool --silent --mode=link /usr/bin/gcc -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wpointer-arith -Wformat -Wformat-security -Wall -g -O2 -L/usr/contrib/lib -lssl -lcrypto -lpthread -o ab -static ab.lo -L/usr/lib -lc -lm -ldl -liconv -lintl -lutil -ldb -levent /usr/source/httpd-2.4.18/srclib/apr-util/libaprutil-1.la -lexpat /usr/source/httpd-2.4.18/srclib/apr/libapr-1.la -lpthread -lm > ab.o: In function `test': > /usr/source/httpd-2.4.18/support/ab.c:1863: undefined reference to `SSL_state' > > and this piece of code is > > set_conn_state(c, STATE_CONNECTED); > #ifdef USE_SSL > if (c->ssl) > ssl_proceed_handshake(c); > else > #endif > write_request(c); > > Looks like a lots of rewriting to do. > > Here is one from bind-9.6-ESV-R11 (Yes this branch is no longer supported) libtool: link: /usr/bin/gcc -g -O2 -Wall -I/usr/contrib/include/libxml2 -o named builtin.o client.o config.o control.o controlconf.o interfacemgr.o listenlist.o log.o logconf.o main.o notify.o query.o server.o sortlist.o statschannel.o tkeyconf.o tsigconf.o update.o xfrout.o zoneconf.o lwaddr.o lwresd.o lwdclient.o lwderror.o lwdgabn.o lwdgnba.o lwdgrbn.o lwdnoop.o lwsearch.o unix/os.o ../../lib/lwres/.libs/liblwres.a -L/usr/contrib/lib -L/usr/lib ../../lib/dns/.libs/libdns.a ../../lib/bind9/.libs/libbind9.a /usr/source/bind-9.6-ESV-R11/lib/isccfg/.libs/libisccfg.a ../../lib/isccfg/.libs/libisccfg.a /usr/source/bind-9.6-ESV-R11/lib/dns/.libs/libdns.a /usr/source/bind-9.6-ESV-R11/lib/isccc/.libs/libisccc.a -lcrypto ../../lib/isccc/.libs/libisccc.a /usr/source/bind-9.6-ESV-R11/lib/isc/.libs/libisc.a ../../lib/isc/.libs/libisc.a /usr/contrib/lib/libxml2.so /usr/contrib/lib/liblzma.so -lz -lpthread /usr/lib/libiconv.so -lm -ldl -Wl,-rpath -Wl,/usr/contrib/lib -Wl,-rpath -Wl,/usr/contrib/lib ../../lib/dns/.libs/libdns.a(openssl_link.o): In function `dst__openssl_init': /usr/source/bind-9.6-ESV-R11/lib/dns/openssl_link.c:171: undefined reference to `CRYPTO_set_id_callback' ../../lib/dns/.libs/libdns.a(openssl_link.o): In function `dst__openssl_destroy': /usr/source/bind-9.6-ESV-R11/lib/dns/openssl_link.c:304: undefined reference to `ERR_remove_state' ../../lib/dns/.libs/libdns.a(openssldh_link.o): In function `dst__openssldh_init': /usr/source/bind-9.6-ESV-R11/lib/dns/openssldh_link.c:624: undefined reference to `BN_init' /usr/source/bind-9.6-ESV-R11/lib/dns/openssldh_link.c:625: undefined reference to `BN_init' /usr/source/bind-9.6-ESV-R11/lib/dns/openssldh_link.c:626: undefined reference to `BN_init' /usr/source/bind-9.6-ESV-R11/lib/dns/openssldh_link.c:627: undefined reference to `BN_init' ../../lib/dns/.libs/libdns.a(openssldsa_link.o): In function `openssldsa_createctx': /usr/source/bind-9.6-ESV-R11/lib/dns/openssldsa_link.c:65: undefined reference to `EVP_MD_CTX_create' /usr/source/bind-9.6-ESV-R11/lib/dns/openssldsa_link.c:69: undefined reference to `EVP_dss1' /usr/source/bind-9.6-ESV-R11/lib/dns/openssldsa_link.c:70: undefined reference to `EVP_MD_CTX_destroy' ../../lib/dns/.libs/libdns.a(openssldsa_link.o): In function `openssldsa_destroyctx': /usr/source/bind-9.6-ESV-R11/lib/dns/openssldsa_link.c:95: undefined reference to `EVP_MD_CTX_destroy' ../../lib/dns/.libs/libdns.a(opensslrsa_link.o): In function `opensslrsa_createctx': /usr/source/bind-9.6-ESV-R11/lib/dns/opensslrsa_link.c:130: undefined reference to `EVP_MD_CTX_create' /usr/source/bind-9.6-ESV-R11/lib/dns/opensslrsa_link.c:157: undefined reference to `EVP_MD_CTX_destroy' ../../lib/dns/.libs/libdns.a(opensslrsa_link.o): In function `opensslrsa_destroyctx': /usr/source/bind-9.6-ESV-R11/lib/dns/opensslrsa_link.c:234: undefined reference to `EVP_MD_CTX_destroy' *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. > > > > > > -- > > Viktor. > > _______________________________________________ > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! > http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism > Birthdate 29 Jan 1969 Redhill, Surrey, UK > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From rt at openssl.org Tue Jan 5 22:41:59 2016 From: rt at openssl.org (Kurt Roeckx via RT) Date: Tue, 05 Jan 2016 22:41:59 +0000 Subject: [openssl-dev] [openssl.org #4218] Invalid typecasting in CRYPTO_ctr128_encrypt In-Reply-To: <20160105224225.GA9097@roeckx.be> References: <20160105224225.GA9097@roeckx.be> Message-ID: On Tue, Jan 05, 2016 at 05:36:35PM +0000, Bjorn Kornefalk via RT wrote: > OpenSSL 1.0.2e > > At line 156 of crypto/modes/ctr128.c > > const unsigned char *in, > unsigned char *out, > unsigned char ivec[16], > unsigned char ecount_buf[16] > > *(size_t *)(out + n) = > *(size_t *)(in + n) ^ *(size_t *)(ecount_buf + n); > > If the buffers are not aligned, the application crashes due to the invalid > type casting of unsigned char (1 byte) to size_t (4 to 8 bytes for most > CPU:s). You should not run into that issue if STRICT_ALIGNMENT is defined. Currently this is set by: #define STRICT_ALIGNMENT 1 #ifndef PEDANTIC # if defined(__i386) || defined(__i386__) || \ defined(__x86_64) || defined(__x86_64__) || \ defined(_M_IX86) || defined(_M_AMD64) || defined(_M_X64) || \ defined(__aarch64__) || \ defined(__s390__) || defined(__s390x__) # undef STRICT_ALIGNMENT # endif #endif Kurt From zi.lin.cs at gmail.com Tue Jan 5 22:44:32 2016 From: zi.lin.cs at gmail.com (Zi Lin) Date: Tue, 5 Jan 2016 14:44:32 -0800 Subject: [openssl-dev] [PATCH][OpenSSL-1.0.2] making it possible to do async session lookup during session resumption Message-ID: Hi OpenSSL devs, I want to propose a patch that makes OpenSSL compatible with asynchronous session lookup during session resumption. Currently, the session lookup expects the session callback to return immediately with success or failure. Now consider a cluster of hosts that want to pool the ssl session together to improve session resumption, we would like the session lookup callback to adopt the asynchronous paradigm of "cert_cb", i.e. cert_cb can be called repeatedly until cert_cb finished its job. https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/ssl/s3_srvr.c#L916 Piotr Sikora initiated this project with ideas borrowed from BoringSSL code base, and since we have put some efforts to make sure no bug is introduced. Hence this attached patch to enable "get_session_cb" to return a fake session pointer that signals the pending session lookup, and the SSL state machines will adopts such signal to resume the client hello processing instead of err-out. It's not a small patch since we have touched multiple aspects of the SSL state machine. But this patch has been verified in CloudFlare's heavy traffic production environment for quite a while and we consider it is stable to be used by upstream. Any feedback is appreciated! Best, Zi -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-async-session-lookup.patch Type: application/octet-stream Size: 8979 bytes Desc: not available URL: From doctor at doctor.nl2k.ab.ca Tue Jan 5 22:40:03 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 5 Jan 2016 15:40:03 -0700 Subject: [openssl-dev] [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160105161932.GA22085@doctor.nl2k.ab.ca> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> <20160105161932.GA22085@doctor.nl2k.ab.ca> Message-ID: <20160105224002.GB20729@doctor.nl2k.ab.ca> On Tue, Jan 05, 2016 at 09:19:32AM -0700, The Doctor wrote: > On Mon, Jan 04, 2016 at 07:22:04PM +0000, Viktor Dukhovni wrote: > > On Mon, Jan 04, 2016 at 09:08:31AM -0700, The Doctor wrote: > > > > > if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), > > > SSLeay_version(SSLEAY_VERSION))) <0) > > > > > > Could there be anything that is causing openssh not to see the new openssl 1.1 > > > > The above. The SSLeay names are gone. The new way is: > > > > if ((rc = fprintf(fd ,"%08x (%s)\n", OpenSSL_version_num(), > > OpenSSL_version(OPENSSL_VERSION))) <0) > > > > I think it is likely prudent at this time to restore source- > > backwards-compatible behaviour, by adding to : > > > > #if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < 0x10100000L > > # include > > # define SSLeay OpenSSL_version_num > > # define SSLeay_version OpenSSL_version > > # define SSLEAY_VERSION_NUMBER OPENSSL_VERSION_NUMBER > > # define SSLEAY_VERSION OPENSSL_VERSION > > # define SSLEAY_CFLAGS OPENSSL_CFLAGS > > # define SSLEAY_BUILT_ON OPENSSL_BUILT_ON > > # define SSLEAY_PLATFORM OPENSSL_PLATFORM > > # define SSLEAY_DIR OPENSSL_DIR > > #endif /* OPENSSL_API_COMPAT */ > > > > Users who want to make sure they are avoiding interfaces that are > > deprecated with 1.1.0 can set OPENSSL_API_COMPAT to 0x10100000L or > > higher as appropriate. > > > Tip of the iceberg. > > Number of changes are needed to be committed before launching. > > >From inn: > > tls.o: In function `tmp_dh_cb': > /usr/source/inn-CURRENT-20160105/nnrpd/tls.c:219: undefined reference to `DH_generate_parameters' > tls.o: In function `tls_init_serverengine': > /usr/source/inn-CURRENT-20160105/nnrpd/tls.c:498: undefined reference to `SSLv23_server_method' > gmake[1]: *** [nnrpd] Error 1 > > so 219 and that area gives us > > default: > /* We should check current keylength vs. requested keylength > * also, this is an extremely expensive operation! */ > dh = DH_generate_parameters(keylength, DH_GENERATOR_2, NULL, NU > LL); > r = dh; > > I just comment these 2 lines out for now > > line 498 is > > CTX = SSL_CTX_new(SSLv23_server_method()); > > I just replace as follows > > CTX = SSL_CTX_new(TLS_server_method()); > > A better fix is neeeded. > > And there is Apache 2.4 > > Making all in support > /usr/source/httpd-2.4.18/srclib/apr/libtool --silent --mode=link /usr/bin/gcc -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wpointer-arith -Wformat -Wformat-security -Wall -g -O2 -L/usr/contrib/lib -lssl -lcrypto -lpthread -o ab -static ab.lo -L/usr/lib -lc -lm -ldl -liconv -lintl -lutil -ldb -levent /usr/source/httpd-2.4.18/srclib/apr-util/libaprutil-1.la -lexpat /usr/source/httpd-2.4.18/srclib/apr/libapr-1.la -lpthread -lm > ab.o: In function `test': > /usr/source/httpd-2.4.18/support/ab.c:1863: undefined reference to `SSL_state' > > and this piece of code is > > set_conn_state(c, STATE_CONNECTED); > #ifdef USE_SSL > if (c->ssl) > ssl_proceed_handshake(c); > else > #endif > write_request(c); > > Looks like a lots of rewriting to do. > > > In exim we get gcc -o exim tls.o: In function `rsa_callback': tls.o(.text+0x19a): undefined reference to `RSA_generate_key' tls.o: In function `tls_servername_cb': tls.o(.text+0xf32): undefined reference to `SSLv23_server_method' tls.o: In function `tls_init': tls.o(.text+0x1654): undefined reference to `SSLv23_server_method' tls.o(.text+0x165e): undefined reference to `SSLv23_client_method' tls.o(.text+0x18d2): undefined reference to `SSL_CTX_set_tmp_rsa_callback' tls.o: In function `tls_validate_require_cipher': tls.o(.text+0x2a6d): undefined reference to `SSLv23_server_method' tls.o: In function `tls_version_report': tls.o(.text+0x2b29): undefined reference to `SSLeay_version' tls.o(.text+0x2b36): undefined reference to `SSLeay_version' tls.o: In function `vaguely_random_number': tls.o(.text+0x2bf0): undefined reference to `RAND_pseudo_bytes' Do we need more examples? > > > > > -- > > Viktor. > > _______________________________________________ > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! > http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism > Birthdate 29 Jan 1969 Redhill, Surrey, UK > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From matt at openssl.org Wed Jan 6 05:37:02 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 6 Jan 2016 05:37:02 +0000 Subject: [openssl-dev] [PATCH][OpenSSL-1.0.2] making it possible to do async session lookup during session resumption In-Reply-To: References: Message-ID: <568CA7FE.9060204@openssl.org> On 05/01/16 22:44, Zi Lin wrote: > Hi OpenSSL devs, > > I want to propose a patch that makes OpenSSL compatible with > asynchronous session lookup during session resumption. Currently, the > session lookup expects the session callback to return immediately with > success or failure. Now consider a cluster of hosts that want to pool > the ssl session together to improve session resumption, we would like > the session lookup callback to adopt the asynchronous paradigm of > "cert_cb", i.e. cert_cb can be called repeatedly until cert_cb > finished its job. > https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/ssl/s3_srvr.c#L916 > > Piotr Sikora initiated this project with ideas borrowed from BoringSSL > code base, > and since we have put some efforts to make sure no bug is introduced. > > Hence this attached patch to enable "get_session_cb" to return a fake > session pointer that signals the pending session lookup, and the SSL > state machines will adopts such signal to resume the client hello > processing instead of err-out. It's not a small patch since we have > touched multiple aspects of the SSL state machine. But this patch has > been verified in CloudFlare's heavy traffic production environment for quite a > while and we consider it is stable to be used by upstream. Hi Zi That is an interesting idea and something we may consider looking at. However your patch in its current form cannot be accepted because it targets 1.0.2. Such a change would be considered a new feature. The 1.0.2 branch only receives bug fixes. New features should target the master branch. If you take a look at master you will see that there have been substantial and fundamental changes to the state machine code so your patch would need significant work to bring it into line. BTW, please email any future submissions to rt at openssl.org so that they can be properly tracked. Thanks Matt From kurt at roeckx.be Wed Jan 6 06:14:38 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 6 Jan 2016 07:14:38 +0100 Subject: [openssl-dev] [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160105224002.GB20729@doctor.nl2k.ab.ca> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> <20160105161932.GA22085@doctor.nl2k.ab.ca> <20160105224002.GB20729@doctor.nl2k.ab.ca> Message-ID: <20160106061437.GA19399@roeckx.be> On Tue, Jan 05, 2016 at 03:40:03PM -0700, The Doctor wrote: > tls.o(.text+0xf32): undefined reference to `SSLv23_server_method' Are you sure it's finding the correct headers? Kurt From zi.lin.cs at gmail.com Wed Jan 6 06:14:33 2016 From: zi.lin.cs at gmail.com (Zi Lin) Date: Tue, 5 Jan 2016 22:14:33 -0800 Subject: [openssl-dev] [PATCH][OpenSSL-1.0.2] making it possible to do async session lookup during session resumption In-Reply-To: <568CA7FE.9060204@openssl.org> References: <568CA7FE.9060204@openssl.org> Message-ID: Hi Matt, thanks for your time. I am glad to see the big efforts done to make OpenSSL code better in the master branch (and v1.1.0+). I will find a way to start working on the master branch. A quick glance into the master branch state machine: the get_prev_session call happens in process_message "phase", and dealing with cert_cb happens in post_process_message "phase". Moving get_prev_session into post_processing_message "phase" seems non trivial as all those cipher check are in the process_messaage "phase", depending on resumed session. Further, I see this comment. Can you clarify what that means? https://github.com/openssl/openssl/blob/master/ssl/statem/statem_srvr.c#L1150 Only session ticket and further TLS1.3 session resumption are supported in v1.1+? Best, Zi On Tue, Jan 5, 2016 at 9:37 PM, Matt Caswell wrote: > On 05/01/16 22:44, Zi Lin wrote: >> Hi OpenSSL devs, >> >> I want to propose a patch that makes OpenSSL compatible with >> asynchronous session lookup during session resumption. Currently, the >> session lookup expects the session callback to return immediately with >> success or failure. Now consider a cluster of hosts that want to pool >> the ssl session together to improve session resumption, we would like >> the session lookup callback to adopt the asynchronous paradigm of >> "cert_cb", i.e. cert_cb can be called repeatedly until cert_cb >> finished its job. >> https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/ssl/s3_srvr.c#L916 >> >> Piotr Sikora initiated this project with ideas borrowed from BoringSSL >> code base, >> and since we have put some efforts to make sure no bug is introduced. >> >> Hence this attached patch to enable "get_session_cb" to return a fake >> session pointer that signals the pending session lookup, and the SSL >> state machines will adopts such signal to resume the client hello >> processing instead of err-out. It's not a small patch since we have >> touched multiple aspects of the SSL state machine. But this patch has >> been verified in CloudFlare's heavy traffic production environment for quite a >> while and we consider it is stable to be used by upstream. > > Hi Zi > > That is an interesting idea and something we may consider looking at. > However your patch in its current form cannot be accepted because it > targets 1.0.2. Such a change would be considered a new feature. The > 1.0.2 branch only receives bug fixes. New features should target the > master branch. > > If you take a look at master you will see that there have been > substantial and fundamental changes to the state machine code so your > patch would need significant work to bring it into line. > > BTW, please email any future submissions to rt at openssl.org so that they > can be properly tracked. > > Thanks > > Matt > > From openssl-users at dukhovni.org Wed Jan 6 06:17:27 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 6 Jan 2016 01:17:27 -0500 Subject: [openssl-dev] [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160106061437.GA19399@roeckx.be> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> <20160105161932.GA22085@doctor.nl2k.ab.ca> <20160105224002.GB20729@doctor.nl2k.ab.ca> <20160106061437.GA19399@roeckx.be> Message-ID: <150332B3-61C5-4486-9108-7F013A493A5D@dukhovni.org> > On Jan 6, 2016, at 1:14 AM, Kurt Roeckx wrote: > > On Tue, Jan 05, 2016 at 03:40:03PM -0700, The Doctor wrote: >> tls.o(.text+0xf32): undefined reference to `SSLv23_server_method' > > Are you sure it's finding the correct headers? Yes, because we have OPENSSL_NO_DEPRECATED in default builds for now, which disables the backwards-compatible defines. To get a more compatible build: ./Configure --prefix=/some/where deprecated shared make depend make make test make install_sw Adding "deprecated" to the Configure command-line will not disable the various legacy interfaces. Also (OpenSSL team only) see MR 1569. -- Viktor. From openssl-users at dukhovni.org Wed Jan 6 06:21:13 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 6 Jan 2016 06:21:13 +0000 Subject: [openssl-dev] [PATCH][OpenSSL-1.0.2] making it possible to do async session lookup during session resumption In-Reply-To: References: Message-ID: <20160106062113.GC18704@mournblade.imrryr.org> On Tue, Jan 05, 2016 at 02:44:32PM -0800, Zi Lin wrote: > Hi OpenSSL devs, > > I want to propose a patch that makes OpenSSL compatible with > asynchronous session lookup during session resumption. I think this is a bad idea. If you want distributed session caches use session tickets, and implement a distributed mechanism for rotating the keys across the server farm. Actually, there's an RT ticket for that, but the code is not quite what I'd like to see adopted, and is no longer compatible with the substantially modified SSL library in 1.1.0. So I'll likely just implement session ticket key management from scratch when I get a chance. I would strongly recommend against a distributed session store. -- Viktor. From matt at openssl.org Wed Jan 6 06:33:05 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 6 Jan 2016 06:33:05 +0000 Subject: [openssl-dev] [PATCH][OpenSSL-1.0.2] making it possible to do async session lookup during session resumption In-Reply-To: References: <568CA7FE.9060204@openssl.org> Message-ID: <568CB521.9020106@openssl.org> On 06/01/16 06:14, Zi Lin wrote: > Hi Matt, > > thanks for your time. I am glad to see the big efforts done to make > OpenSSL code better in the master branch (and v1.1.0+). I will find a > way to start working on the master branch. A quick glance into the > master branch state machine: the get_prev_session call happens in > process_message "phase", and dealing with cert_cb happens in > post_process_message "phase". Moving get_prev_session into > post_processing_message "phase" seems non trivial as all those cipher > check are in the process_messaage "phase", depending on resumed > session. > > Further, I see this comment. Can you clarify what that means? > https://github.com/openssl/openssl/blob/master/ssl/statem/statem_srvr.c#L1150 > Only session ticket and further TLS1.3 session resumption are > supported in v1.1+? This comment is in specific reference to SSLv2 backwards compatible ClientHellos. While support for SSLv2 itself has been removed from 1.1.0, we still accept SSLv2 backward compat ClientHellos. However we will not allow session resumption in such an instance: if we are resuming a session then we must have previously negotiated a version > SSLv2 so it makes no sense for a client to send a backward compat ClientHello. Matt From doctor at doctor.nl2k.ab.ca Wed Jan 6 12:34:31 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 6 Jan 2016 05:34:31 -0700 Subject: [openssl-dev] [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <150332B3-61C5-4486-9108-7F013A493A5D@dukhovni.org> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> <20160105161932.GA22085@doctor.nl2k.ab.ca> <20160105224002.GB20729@doctor.nl2k.ab.ca> <20160106061437.GA19399@roeckx.be> <150332B3-61C5-4486-9108-7F013A493A5D@dukhovni.org> Message-ID: <20160106123431.GA1929@doctor.nl2k.ab.ca> On Wed, Jan 06, 2016 at 01:17:27AM -0500, Viktor Dukhovni wrote: > > > On Jan 6, 2016, at 1:14 AM, Kurt Roeckx wrote: > > > > On Tue, Jan 05, 2016 at 03:40:03PM -0700, The Doctor wrote: > >> tls.o(.text+0xf32): undefined reference to `SSLv23_server_method' > > > > Are you sure it's finding the correct headers? > > Yes, because we have OPENSSL_NO_DEPRECATED in default builds for now, > which disables the backwards-compatible defines. To get a more compatible > build: > > ./Configure --prefix=/some/where deprecated shared > make depend > make > make test > make install_sw > > Adding "deprecated" to the Configure command-line will not disable the > various legacy interfaces. Also (OpenSSL team only) see MR 1569. > What about the other stuff that openssh picked up? > -- > Viktor. > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From rt at openssl.org Wed Jan 6 12:46:47 2016 From: rt at openssl.org (Hubert Kario via RT) Date: Wed, 06 Jan 2016 12:46:47 +0000 Subject: [openssl-dev] [openssl.org #4206] [PATCH] Add cipher alias for ChaCha20 In-Reply-To: <3477931.tNNbFzrcoV@pintsize.usersys.redhat.com> References: <20151228152843.GA4796@roeckx.be> <3477931.tNNbFzrcoV@pintsize.usersys.redhat.com> Message-ID: On Monday 28 December 2015 15:28:26 Kurt Roeckx via RT wrote: > On Mon, Dec 28, 2015 at 03:01:28PM +0000, Short, Todd via RT wrote: > > Hello OpenSSL.org: > > > > This is a patch for the master branch. The changes in master to add > > ChaCha20 to OpenSSL do not include an alias for the cipher in the > > "openssl cipher" command, nor in the cipher functions., even though > > the necessary constants have been defined. The attached patch adds > > that alias. > > > > The following openssl commands now behave as expected: > > > > openssl ciphers CHACHA20 > > openssl ciphers CHACHA20:AES > > Please at least also update the documentation, like ciphers.pod. > > I'm also not sure if CHACHA20 should only select those in > combination with Poly1305, even if those are currently the only > supported. AES selects both AES-CBC and AES-GCM while AESGCM selects just AES-GCM. Selecting ChaCha20-Poly1305 by just CHACHA20 is consistent with existing flags. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From doctor at doctor.nl2k.ab.ca Wed Jan 6 13:16:30 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 6 Jan 2016 06:16:30 -0700 Subject: [openssl-dev] [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160106123431.GA1929@doctor.nl2k.ab.ca> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> <20160105161932.GA22085@doctor.nl2k.ab.ca> <20160105224002.GB20729@doctor.nl2k.ab.ca> <20160106061437.GA19399@roeckx.be> <150332B3-61C5-4486-9108-7F013A493A5D@dukhovni.org> <20160106123431.GA1929@doctor.nl2k.ab.ca> Message-ID: <20160106131630.GA20125@doctor.nl2k.ab.ca> On Wed, Jan 06, 2016 at 05:34:31AM -0700, The Doctor wrote: > On Wed, Jan 06, 2016 at 01:17:27AM -0500, Viktor Dukhovni wrote: > > > > > On Jan 6, 2016, at 1:14 AM, Kurt Roeckx wrote: > > > > > > On Tue, Jan 05, 2016 at 03:40:03PM -0700, The Doctor wrote: > > >> tls.o(.text+0xf32): undefined reference to `SSLv23_server_method' > > > > > > Are you sure it's finding the correct headers? > > > > Yes, because we have OPENSSL_NO_DEPRECATED in default builds for now, > > which disables the backwards-compatible defines. To get a more compatible > > build: > > > > ./Configure --prefix=/some/where deprecated shared > > make depend > > make > > make test > > make install_sw > > > > Adding "deprecated" to the Configure command-line will not disable the > > various legacy interfaces. Also (OpenSSL team only) see MR 1569. > > > > What about the other stuff that openssh picked up? That should be ./Configure --prefix=/some/where enale-deprecated shared make depend make make test make install > > > -- > > Viktor. > > > > > > > > _______________________________________________ > > openssl-dev mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! > http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism > Birthdate 29 Jan 1969 Redhill, Surrey, UK > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From doctor at doctor.nl2k.ab.ca Wed Jan 6 14:33:27 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 6 Jan 2016 07:33:27 -0700 Subject: [openssl-dev] [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160104192204.GL18704@mournblade.imrryr.org> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> Message-ID: <20160106143327.GA20190@doctor.nl2k.ab.ca> On Mon, Jan 04, 2016 at 07:22:04PM +0000, Viktor Dukhovni wrote: > On Mon, Jan 04, 2016 at 09:08:31AM -0700, The Doctor wrote: > > > if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), > > SSLeay_version(SSLEAY_VERSION))) <0) > > > > Could there be anything that is causing openssh not to see the new openssl 1.1 > > The above. The SSLeay names are gone. The new way is: > > if ((rc = fprintf(fd ,"%08x (%s)\n", OpenSSL_version_num(), > OpenSSL_version(OPENSSL_VERSION))) <0) > > I think it is likely prudent at this time to restore source- > backwards-compatible behaviour, by adding to : > > #if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < 0x10100000L > # include > # define SSLeay OpenSSL_version_num > # define SSLeay_version OpenSSL_version > # define SSLEAY_VERSION_NUMBER OPENSSL_VERSION_NUMBER > # define SSLEAY_VERSION OPENSSL_VERSION > # define SSLEAY_CFLAGS OPENSSL_CFLAGS > # define SSLEAY_BUILT_ON OPENSSL_BUILT_ON > # define SSLEAY_PLATFORM OPENSSL_PLATFORM > # define SSLEAY_DIR OPENSSL_DIR > #endif /* OPENSSL_API_COMPAT */ > > Users who want to make sure they are avoiding interfaces that are > deprecated with 1.1.0 can set OPENSSL_API_COMPAT to 0x10100000L or > higher as appropriate. > With all the other issues (DEPREACTED) identified, let me test the above out. > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From doctor at doctor.nl2k.ab.ca Wed Jan 6 15:28:12 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 6 Jan 2016 08:28:12 -0700 Subject: [openssl-dev] [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160106143327.GA20190@doctor.nl2k.ab.ca> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> <20160106143327.GA20190@doctor.nl2k.ab.ca> Message-ID: <20160106152812.GA20405@doctor.nl2k.ab.ca> On Wed, Jan 06, 2016 at 07:33:27AM -0700, The Doctor wrote: > On Mon, Jan 04, 2016 at 07:22:04PM +0000, Viktor Dukhovni wrote: > > On Mon, Jan 04, 2016 at 09:08:31AM -0700, The Doctor wrote: > > > > > if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), > > > SSLeay_version(SSLEAY_VERSION))) <0) > > > > > > Could there be anything that is causing openssh not to see the new openssl 1.1 > > > > The above. The SSLeay names are gone. The new way is: > > > > if ((rc = fprintf(fd ,"%08x (%s)\n", OpenSSL_version_num(), > > OpenSSL_version(OPENSSL_VERSION))) <0) > > > > I think it is likely prudent at this time to restore source- > > backwards-compatible behaviour, by adding to : > > > > #if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < 0x10100000L > > # include > > # define SSLeay OpenSSL_version_num > > # define SSLeay_version OpenSSL_version > > # define SSLEAY_VERSION_NUMBER OPENSSL_VERSION_NUMBER > > # define SSLEAY_VERSION OPENSSL_VERSION > > # define SSLEAY_CFLAGS OPENSSL_CFLAGS > > # define SSLEAY_BUILT_ON OPENSSL_BUILT_ON > > # define SSLEAY_PLATFORM OPENSSL_PLATFORM > > # define SSLEAY_DIR OPENSSL_DIR > > #endif /* OPENSSL_API_COMPAT */ > > > > Users who want to make sure they are avoiding interfaces that are > > deprecated with 1.1.0 can set OPENSSL_API_COMPAT to 0x10100000L or > > higher as appropriate. > > > > With all the other issues (DEPREACTED) identified, let > me test the above out. > Still a few bumps, but I recommend that this be committed to openssl 1.1 branch. > > -- > > Viktor. > > _______________________________________________ > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! > http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism > Birthdate 29 Jan 1969 Redhill, Surrey, UK > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From rt at openssl.org Wed Jan 6 17:15:58 2016 From: rt at openssl.org (Claus Assmann via RT) Date: Wed, 06 Jan 2016 17:15:58 +0000 Subject: [openssl-dev] [openssl.org #4219] [typos] DANE related docs In-Reply-To: <20160106170432.GB29574@x2.esmtp.org> References: <20160106170432.GB29574@x2.esmtp.org> Message-ID: diff --git a/doc/ssl/SSL_CTX_dane_enable.pod b/doc/ssl/SSL_CTX_dane_enable.pod index 66eb1b3..29fc4db 100644 --- a/doc/ssl/SSL_CTX_dane_enable.pod +++ b/doc/ssl/SSL_CTX_dane_enable.pod @@ -40,7 +40,7 @@ SSL_CTX_dane_mtype_set() may then be called zero or more times to to adjust the supported digest algorithms. This must be done before any SSL handles are created for the context. -The B argument specifies a DANE TLSA matching type and the +The B argument specifies a DANE TLSA matching type and the B argument specifies the associated digest algorithm handle. The B argument specifies a strength ordinal. Algorithms with a larger strength ordinal are considered more secure. Strength @@ -181,7 +181,7 @@ the lifetime of the SSL connection. } ret = SSL_dane_tlsa_add(ssl, usage, selector, mtype, data, len); - /* free data as approriate */ + /* free data as appropriate */ if (ret < 0) /* handle SSL library internal error */ diff --git a/doc/ssl/SSL_set1_host.pod b/doc/ssl/SSL_set1_host.pod index b008a5f..0ef2448 100644 --- a/doc/ssl/SSL_set1_host.pod +++ b/doc/ssl/SSL_set1_host.pod @@ -35,7 +35,7 @@ that can match the peer's certificate. Any previous names set via SSL_set1_host() or SSL_add1_host() are retained, no change is made if B is NULL or empty. When multiple names are configured, the peer is considered verified when any name matches. This function -is required for DANE TLA in the presence of service name indirection +is required for DANE TLSA in the presence of service name indirection via CNAME, MX or SRV records as specified in RFC7671, RFC7672 or RFC7673. _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Jan 6 17:15:58 2016 From: rt at openssl.org (wangjin via RT) Date: Wed, 06 Jan 2016 17:15:58 +0000 Subject: [openssl-dev] [openssl.org #4220] Simple BIO demo make memory leak In-Reply-To: <001101d14853$4522d090$cf6871b0$@haitaichina.com> References: <001101d14853$4522d090$cf6871b0$@haitaichina.com> Message-ID: Dear, Recently, I got an issue on my RHEL6.5 x64 platform with original openssl-1.0.2e without patch. Please find the attached files for testing demo, this simple demo will generate Memory Leak, is it a bug ? I am not sure why? Thank you for in advance. The same test on Win7 x64, VS2008, appear again. Best Regards, _____ Jin Linux -------------- next part -------------- #include #include #include #include "openssl/bio.h" int main(int argc, char* argv[]) { BIO* b = NULL; b = BIO_new(BIO_s_mem()); /* here is not free totally. * I strace and found that, BIO_free() is not * free the inner lhash and stack structure. */ BIO_free_all(b); // or BIO_free(); return 0; } -------------- next part -------------- >>>>GCC version Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) >>> uname -a Linux localhost.localdomain 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 EST 2013 x86_64 x86_64 x86_64 GNU/Linux >>> valgrind ./bio_mem ==14689== Memcheck, a memory error detector ==14689== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==14689== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==14689== Command: ./bio_mem ==14689== ==14689== Conditional jump or move depends on uninitialised value(s) ==14689== at 0x355F417FE6: index (strchr.S:55) ==14689== by 0x355F4075A2: expand_dynamic_string_token (dl-load.c:425) ==14689== by 0x355F4079DD: _dl_map_object (dl-load.c:2301) ==14689== by 0x355F40196D: map_doit (rtld.c:626) ==14689== by 0x355F40E7B5: _dl_catch_error (dl-error.c:177) ==14689== by 0x355F401886: do_preload (rtld.c:815) ==14689== by 0x355F403A8C: dl_main (rtld.c:1629) ==14689== by 0x355F415AA5: _dl_sysdep_start (dl-sysdep.c:249) ==14689== by 0x355F401412: _dl_start (rtld.c:331) ==14689== by 0x355F400AE7: ??? (in /lib64/ld-2.18.so) ==14689== ==14689== Conditional jump or move depends on uninitialised value(s) ==14689== at 0x355F417FEB: index (strchr.S:58) ==14689== by 0x355F4075A2: expand_dynamic_string_token (dl-load.c:425) ==14689== by 0x355F4079DD: _dl_map_object (dl-load.c:2301) ==14689== by 0x355F40196D: map_doit (rtld.c:626) ==14689== by 0x355F40E7B5: _dl_catch_error (dl-error.c:177) ==14689== by 0x355F401886: do_preload (rtld.c:815) ==14689== by 0x355F403A8C: dl_main (rtld.c:1629) ==14689== by 0x355F415AA5: _dl_sysdep_start (dl-sysdep.c:249) ==14689== by 0x355F401412: _dl_start (rtld.c:331) ==14689== by 0x355F400AE7: ??? (in /lib64/ld-2.18.so) ==14689== ==14689== ==14689== HEAP SUMMARY: ==14689== in use at exit: 416 bytes in 6 blocks ==14689== total heap usage: 8 allocs, 2 frees, 552 bytes allocated ==14689== ==14689== LEAK SUMMARY: ==14689== definitely lost: 0 bytes in 0 blocks ==14689== indirectly lost: 0 bytes in 0 blocks ==14689== possibly lost: 0 bytes in 0 blocks ==14689== still reachable: 416 bytes in 6 blocks ==14689== suppressed: 0 bytes in 0 blocks ==14689== Rerun with --leak-check=full to see details of leaked memory ==14689== ==14689== For counts of detected and suppressed errors, rerun with: -v ==14689== Use --track-origins=yes to see where uninitialised values come from ==14689== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From openssl-users at dukhovni.org Wed Jan 6 18:57:26 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 6 Jan 2016 18:57:26 +0000 Subject: [openssl-dev] [openssl.org #4219] [typos] DANE related docs In-Reply-To: References: <20160106170432.GB29574@x2.esmtp.org> Message-ID: <20160106185726.GE18704@mournblade.imrryr.org> On Wed, Jan 06, 2016 at 05:15:58PM +0000, Claus Assmann via RT wrote: > diff --git a/doc/ssl/SSL_CTX_dane_enable.pod b/doc/ssl/SSL_CTX_dane_enable.pod > index 66eb1b3..29fc4db 100644 > diff --git a/doc/ssl/SSL_set1_host.pod b/doc/ssl/SSL_set1_host.pod > index b008a5f..0ef2448 100644 Thanks Claus! Staged for review and adoption. Should be in master soon. -- Viktor. From alessandro at ghedini.me Wed Jan 6 21:03:41 2016 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Wed, 6 Jan 2016 21:03:41 +0000 Subject: [openssl-dev] [PATCH][OpenSSL-1.0.2] making it possible to do async session lookup during session resumption In-Reply-To: <20160106062113.GC18704@mournblade.imrryr.org> References: <20160106062113.GC18704@mournblade.imrryr.org> Message-ID: <20160106210340.GA8432@kronk.local> On Wed, Jan 06, 2016 at 06:21:13AM +0000, Viktor Dukhovni wrote: > On Tue, Jan 05, 2016 at 02:44:32PM -0800, Zi Lin wrote: > > > Hi OpenSSL devs, > > > > I want to propose a patch that makes OpenSSL compatible with > > asynchronous session lookup during session resumption. > > I think this is a bad idea. If you want distributed session caches > use session tickets, That's not really a solution if the client doesn't support session tickets at all. So in those cases you are left with doing no resumption or doing it synchronously with session id in an inefficient way. I think that with the new state machine in master this could be implemented fairly elegantly and since there's an interest from OpenSSL users (even BoringSSL provides this!) it seems like something worth implementing to me. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kurt at roeckx.be Wed Jan 6 22:07:49 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 6 Jan 2016 23:07:49 +0100 Subject: [openssl-dev] [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <150332B3-61C5-4486-9108-7F013A493A5D@dukhovni.org> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> <20160105161932.GA22085@doctor.nl2k.ab.ca> <20160105224002.GB20729@doctor.nl2k.ab.ca> <20160106061437.GA19399@roeckx.be> <150332B3-61C5-4486-9108-7F013A493A5D@dukhovni.org> Message-ID: <20160106220749.GA30088@roeckx.be> On Wed, Jan 06, 2016 at 01:17:27AM -0500, Viktor Dukhovni wrote: > > > On Jan 6, 2016, at 1:14 AM, Kurt Roeckx wrote: > > > > On Tue, Jan 05, 2016 at 03:40:03PM -0700, The Doctor wrote: > >> tls.o(.text+0xf32): undefined reference to `SSLv23_server_method' > > > > Are you sure it's finding the correct headers? > > Yes, because we have OPENSSL_NO_DEPRECATED in default builds for now, > which disables the backwards-compatible defines. The SSLv23* were inside OPENSSL_NO_DEPRECATED at some point, but not anymore. Kurt From rt at openssl.org Thu Jan 7 00:17:35 2016 From: rt at openssl.org (Juan Manuel Guerrero via RT) Date: Thu, 07 Jan 2016 00:17:35 +0000 Subject: [openssl-dev] [openssl.org #4208] : [PATCH] Some DJGPP specific fixes and improvements for OpenSSL_1_0_1-stable and OpenSSL_1_0_2-stable. In-Reply-To: <568DA131.3050208@gmx.de> References: <5682CFF6.20801@gmx.de> <568DA131.3050208@gmx.de> Message-ID: Am 29.12.2015 20:43, schrieb The default queue via RT: > I have been using the DJGPP port of OpenSSL for a couple of years and I would > like to propose some fixes and improvements. No one of the proporsed changes > have impact on any other port. I supply two patches, one for today's OpenSSL_1_0_1-stable > and one for today's openssl-OpenSSL_1_0_2-stable. Patching the master branch > is not so straight forward so it will follow later. [snip] This is the last and final patch to fix the DJGPP port of the OpenSSL_1_0_1-stable branch. It is similar to the one proposed for the master branch. The only difference compared with the initial patch is that it checks mow all file names for LFN validity. The dirname part and the basename part of the file name are now checked for ilicit initial dots in the case that no LFN support is provided by the file system. I have attached the patch as gzip'ed file too. Regards, Juan M. Guerrero 2016-01-06 Juan Manuel Guerrero * Configure: Replaced -DTERMIO by -DTERMIOS in CFLAGS. * crypto/bio/bss_dgram.c [WATT32]: Remove obsolete redefinition of function names: sock_write, sock_read and sock_puts. * crypto/bio/bss_sock.c [WATT32]: For Watt-32 2.2.11 sock_write, sock_read and sock_puts are redefined to their private names so their names must be undefined first before they can be redefined again. * crypto/bio/bss_file.c (file_fopen) [OPENSSL_SYS_MSDOS]: Call dosify_filename to replace leading dot if file system does not support it. (dosify_filename): Replace leading dot in passed file name if file system does not support LFN. Replace all leading dots in the dirname part and the basname part of the file name. * e_os.h [__DJGPP__]: Undefine macro DEVRANDOM_EGD. Neither MS-DOS nor FreeDOS provide 'egd' sockets. New macro HAS_LFN_SUPPORT checks if underlying file system supports long file names or not. * util/mklink.pl: Do not use symlinks for DJGPP. * INSTALL.DJGPP: Update URL of WATT-32 library. diff --git a/Configure b/Configure index 84f627c..9ec48ed 100755 --- a/Configure +++ b/Configure @@ -574,7 +574,7 @@ my %table=( "netware-libc-bsdsock-gcc", "i586-netware-gcc:-nostdinc -I/ndk/libc/include -DNETWARE_BSDSOCK -DL_ENDIAN -DNETWARE_LIBC -DOPENSSL_SYSNAME_NETWARE -DTERMIO -O2 -Wall:::::BN_LLONG ${x86_gcc_opts}::", # DJGPP -"DJGPP", "gcc:-I/dev/env/WATT_ROOT/inc -DTERMIO -DL_ENDIAN -fomit-frame-pointer -O2 -Wall:::MSDOS:-L/dev/env/WATT_ROOT/lib -lwatt:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_asm}:a.out:", +"DJGPP", "gcc:-I/dev/env/WATT_ROOT/inc -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O2 -Wall:::MSDOS:-L/dev/env/WATT_ROOT/lib -lwatt:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_asm}:a.out:", # Ultrix from Bernhard Simon "ultrix-cc","cc:-std1 -O -Olimit 2500 -DL_ENDIAN::(unknown):::::::", diff --git a/crypto/bio/bss_dgram.c b/crypto/bio/bss_dgram.c index d12b83a..1962712 100644 --- a/crypto/bio/bss_dgram.c +++ b/crypto/bio/bss_dgram.c @@ -90,12 +90,6 @@ ((a)->s6_addr32[2] == htonl(0x0000ffff))) # endif -# ifdef WATT32 -# define sock_write SockWrite /* Watt-32 uses same names */ -# define sock_read SockRead -# define sock_puts SockPuts -# endif - static int dgram_write(BIO *h, const char *buf, int num); static int dgram_read(BIO *h, char *buf, int size); static int dgram_puts(BIO *h, const char *str); diff --git a/crypto/bio/bss_file.c b/crypto/bio/bss_file.c index bfba93e..a9e5024 100644 --- a/crypto/bio/bss_file.c +++ b/crypto/bio/bss_file.c @@ -95,6 +95,10 @@ # if !defined(OPENSSL_NO_STDIO) +#ifdef OPENSSL_SYS_MSDOS +# include +static void dosify_filename(const char *filename); +#endif static int MS_CALLBACK file_write(BIO *h, const char *buf, int num); static int MS_CALLBACK file_read(BIO *h, char *buf, int size); static int MS_CALLBACK file_puts(BIO *h, const char *str); @@ -161,6 +165,9 @@ static FILE *file_fopen(const char *filename, const char *mode) file = fopen(filename, mode); } # else +# ifdef OPENSSL_SYS_MSDOS + dosify_filename(filename); +# endif file = fopen(filename, mode); # endif return (file); @@ -467,6 +474,23 @@ static int MS_CALLBACK file_puts(BIO *bp, const char *str) return (ret); } +# ifdef OPENSSL_SYS_MSDOS +static void dosify_filename(const char *filename) +{ + if (filename && *filename && !HAS_LFN_SUPPORT(filename)) { + char *namestart = unconst(filename, char *); + + do { + if (namestart[0] == '/' && namestart[2] != '.' && namestart[2] != '/') { + + /* Leading dot not allowed on plain DOS. */ + if (namestart[1] == '.') + *++namestart = '_'; + } + } while (*++namestart); + } +} +# endif # endif /* OPENSSL_NO_STDIO */ #endif /* HEADER_BSS_FILE_C */ diff --git a/crypto/bio/bss_sock.c b/crypto/bio/bss_sock.c index 6194d2c..7b3bf9c 100644 --- a/crypto/bio/bss_sock.c +++ b/crypto/bio/bss_sock.c @@ -66,7 +66,11 @@ # include # ifdef WATT32 -# define sock_write SockWrite /* Watt-32 uses same names */ +/* Watt-32 uses same names */ +# undef sock_write +# undef sock_read +# undef sock_puts +# define sock_write SockWrite # define sock_read SockRead # define sock_puts SockPuts # endif diff --git a/e_os.h b/e_os.h index 76c471e..7eb072f 100644 --- a/e_os.h +++ b/e_os.h @@ -242,6 +242,8 @@ extern "C" { # define _setmode setmode # define _O_TEXT O_TEXT # define _O_BINARY O_BINARY +# define HAS_LFN_SUPPORT(name) (pathconf((name), _PC_NAME_MAX) > 12) +# undef DEVRANDOM_EGD /* Neither MS-DOS nor FreeDOS provide 'egd' sockets. */ # undef DEVRANDOM # define DEVRANDOM "/dev/urandom\x24" # endif /* __DJGPP__ */ diff --git a/util/mklink.pl b/util/mklink.pl index 61db12c..194f246 100755 --- a/util/mklink.pl +++ b/util/mklink.pl @@ -51,7 +51,7 @@ my $to = join('/', @to_path); my $file; $symlink_exists=eval {symlink("",""); 1}; -if ($^O eq "msys") { $symlink_exists=0 }; +if ($^O eq "msys" || $^O eq 'dos') { $symlink_exists=0 }; foreach $file (@files) { my $err = ""; if ($symlink_exists) { -------------- next part -------------- A non-text attachment was scrubbed... Name: djgpp-openssl-1.0.1-stable-SNAP-20160105.patch.gz Type: application/x-gzip Size: 2113 bytes Desc: not available URL: From rt at openssl.org Thu Jan 7 00:19:16 2016 From: rt at openssl.org (Juan Manuel Guerrero via RT) Date: Thu, 07 Jan 2016 00:19:16 +0000 Subject: [openssl-dev] [openssl.org #4208]: [PATCH] Some DJGPP specific fixes and improvements for OpenSSL_1_0_1-stable and OpenSSL_1_0_2-stable. In-Reply-To: <568DA1A1.2040508@gmx.de> References: <5682CFF6.20801@gmx.de> <568DA1A1.2040508@gmx.de> Message-ID: Am 29.12.2015 20:43, schrieb The default queue via RT: > I have been using the DJGPP port of OpenSSL for a couple of years and I would > like to propose some fixes and improvements. No one of the proporsed changes > have impact on any other port. I supply two patches, one for today's OpenSSL_1_0_1-stable > and one for today's openssl-OpenSSL_1_0_2-stable. Patching the master branch > is not so straight forward so it will follow later. [snip] This is the last and final patch to fix the DJGPP port of the OpenSSL_1_0_2-stable branch. It is similar to the one proposed for the master branch. The only difference compared with the initial patch is that it checks mow all file names for LFN validity. The dirname part and the basename part of the file name are now checked for ilicit initial dots in the case that no LFN support is provided by the file system. I have attached the patch as gzip'ed file too. Regards, Juan M. Guerrero 2016-01-06 Juan Manuel Guerrero * Configure: Replaced -DTERMIO by -DTERMIOS in CFLAGS. * crypto/bio/bss_dgram.c [WATT32]: Remove obsolete redefinition of function names: sock_write, sock_read and sock_puts. * crypto/bio/bss_sock.c [WATT32]: For Watt-32 2.2.11 sock_write, sock_read and sock_puts are redefined to their private names so their names must be undefined first before they can be redefined again. * crypto/bio/bss_file.c (file_fopen) [OPENSSL_SYS_MSDOS]: Call dosify_filename to replace leading dot if file system does not support it. (dosify_filename): Replace leading dot in passed file name if file system does not support LFN. Replace all leading dots in the dirname part and the basname part of the file name. * e_os.h [__DJGPP__]: Undefine macro DEVRANDOM_EGD. Neither MS-DOS nor FreeDOS provide 'egd' sockets. New macro HAS_LFN_SUPPORT checks if underlying file system supports long file names or not. * util/mklink.pl: Do not use symlinks for DJGPP. * INSTALL.DJGPP: Update URL of WATT-32 library. diff --git a/Configure b/Configure index f10287e..88870cf 100755 --- a/Configure +++ b/Configure @@ -628,7 +628,7 @@ my %table=( "netware-libc-bsdsock-gcc", "i586-netware-gcc:-nostdinc -I/ndk/libc/include -DNETWARE_BSDSOCK -DL_ENDIAN -DNETWARE_LIBC -DOPENSSL_SYSNAME_NETWARE -DTERMIO -O2 -Wall:::::BN_LLONG ${x86_gcc_opts}::", # DJGPP -"DJGPP", "gcc:-I/dev/env/WATT_ROOT/inc -DTERMIO -DL_ENDIAN -fomit-frame-pointer -O2 -Wall:::MSDOS:-L/dev/env/WATT_ROOT/lib -lwatt:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_asm}:a.out:", +"DJGPP", "gcc:-I/dev/env/WATT_ROOT/inc -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O2 -Wall:::MSDOS:-L/dev/env/WATT_ROOT/lib -lwatt:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_asm}:a.out:", # Ultrix from Bernhard Simon "ultrix-cc","cc:-std1 -O -Olimit 2500 -DL_ENDIAN::(unknown):::::::", diff --git a/crypto/bio/bss_dgram.c b/crypto/bio/bss_dgram.c index bdd7bf8..b4c2c19 100644 --- a/crypto/bio/bss_dgram.c +++ b/crypto/bio/bss_dgram.c @@ -94,12 +94,6 @@ ((a)->s6_addr32[2] == htonl(0x0000ffff))) # endif -# ifdef WATT32 -# define sock_write SockWrite /* Watt-32 uses same names */ -# define sock_read SockRead -# define sock_puts SockPuts -# endif - static int dgram_write(BIO *h, const char *buf, int num); static int dgram_read(BIO *h, char *buf, int size); static int dgram_puts(BIO *h, const char *str); diff --git a/crypto/bio/bss_file.c b/crypto/bio/bss_file.c index bfba93e..f5cbcaa 100644 --- a/crypto/bio/bss_file.c +++ b/crypto/bio/bss_file.c @@ -95,6 +95,10 @@ # if !defined(OPENSSL_NO_STDIO) +#ifdef OPENSSL_SYS_MSDOS +# include +static void dosify_filename(const char *filename); +#endif static int MS_CALLBACK file_write(BIO *h, const char *buf, int num); static int MS_CALLBACK file_read(BIO *h, char *buf, int size); static int MS_CALLBACK file_puts(BIO *h, const char *str); @@ -161,6 +165,9 @@ static FILE *file_fopen(const char *filename, const char *mode) file = fopen(filename, mode); } # else +# ifdef OPENSSL_SYS_MSDOS + dosify_filename(filename); +# endif file = fopen(filename, mode); # endif return (file); @@ -467,6 +474,23 @@ static int MS_CALLBACK file_puts(BIO *bp, const char *str) return (ret); } +#ifdef OPENSSL_SYS_MSDOS +static void dosify_filename(const char *filename) +{ + if (filename && *filename && !HAS_LFN_SUPPORT(filename)) { + char *namestart = unconst(filename, char *); + + do { + if (namestart[0] == '/' && namestart[2] != '.' && namestart[2] != '/') { + + /* Leading dot not allowed on plain DOS. */ + if (namestart[1] == '.') + *++namestart = '_'; + } + } while (*++namestart); + } +} +#endif # endif /* OPENSSL_NO_STDIO */ #endif /* HEADER_BSS_FILE_C */ diff --git a/crypto/bio/bss_sock.c b/crypto/bio/bss_sock.c index 6194d2c..7b3bf9c 100644 --- a/crypto/bio/bss_sock.c +++ b/crypto/bio/bss_sock.c @@ -66,7 +66,11 @@ # include # ifdef WATT32 -# define sock_write SockWrite /* Watt-32 uses same names */ +/* Watt-32 uses same names */ +# undef sock_write +# undef sock_read +# undef sock_puts +# define sock_write SockWrite # define sock_read SockRead # define sock_puts SockPuts # endif diff --git a/e_os.h b/e_os.h index 1fa36c1..36681fb 100644 --- a/e_os.h +++ b/e_os.h @@ -242,6 +242,8 @@ extern "C" { # define _setmode setmode # define _O_TEXT O_TEXT # define _O_BINARY O_BINARY +# define HAS_LFN_SUPPORT(name) (pathconf((name), _PC_NAME_MAX) > 12) +# undef DEVRANDOM_EGD /* Neither MS-DOS nor FreeDOS provide 'egd' sockets. */ # undef DEVRANDOM # define DEVRANDOM "/dev/urandom\x24" # endif /* __DJGPP__ */ diff --git a/util/mklink.pl b/util/mklink.pl index 61db12c..194f246 100755 --- a/util/mklink.pl +++ b/util/mklink.pl @@ -51,7 +51,7 @@ my $to = join('/', @to_path); my $file; $symlink_exists=eval {symlink("",""); 1}; -if ($^O eq "msys") { $symlink_exists=0 }; +if ($^O eq "msys" || $^O eq 'dos') { $symlink_exists=0 }; foreach $file (@files) { my $err = ""; if ($symlink_exists) { -------------- next part -------------- A non-text attachment was scrubbed... Name: djgpp-openssl-1.0.2-stable-SNAP-20160105.patch.gz Type: application/x-gzip Size: 2112 bytes Desc: not available URL: From rt at openssl.org Thu Jan 7 00:25:20 2016 From: rt at openssl.org (Juan Manuel Guerrero via RT) Date: Thu, 07 Jan 2016 00:25:20 +0000 Subject: [openssl-dev] [openssl.org #4217] Fixing DJGPP port of openssl master branch. In-Reply-To: <568DA30C.6060109@gmx.de> References: <568A77AE.8090801@gmx.de> <20160104.212201.300039170238726481.levitte@openssl.org> <568B25A2.8000705@gmx.de> <568DA30C.6060109@gmx.de> Message-ID: Am 05.01.2016 04:05, schrieb Juan Manuel Guerrero via RT: > Am 04.01.2016 21:22, schrieb Richard Levitte via RT: >> Hi Juan, and thanks. >> >> I'm looking at your fix, and have a couple of questions: [snip] This is the last and final patch to fix the DJGPP port. The only difference compared with the initial patch is that it checks mow all file names for LFN validity. The dirname part and the basename part of the file name are now checked for ilicit initial dots in the case that no LFN support is provided by the file system. I have attached the patch as gzip'ed file too. Similar patches are also provided for the openssl 1.0.1 branch and the openssl 1.0.2 branch too. Regards, Juan M. Guerrero 2016-01-06 Juan Manuel Guerrero * Configure: Replaced -DTERMIO by -DTERMIOS in CFLAGS. * crypto/bio/bss_dgram.c [WATT32]: Remove obsolete redefinition of function names: sock_write, sock_read and sock_puts. * crypto/bio/bss_sock.c [WATT32]: For Watt-32 2.2.11 sock_write, sock_read and sock_puts are redefined to their private names so their names must be undefined first before they can be redefined again. * crypto/bio/bss_file.c (file_fopen) [OPENSSL_SYS_MSDOS]: Call dosify_filename to replace leading dot if file system does not support it. (dosify_filename): Replace leading dot in passed file name if file system does not support LFN. Replace all leading dots in the dirname part and the basname part of the file name. * e_os.h [__DJGPP__]: Undefine macro DEVRANDOM_EGD. Neither MS-DOS nor FreeDOS provide 'egd' sockets. New macro HAS_LFN_SUPPORT checks if underlying file system supports long file names or not. Include sys/un.h. Define WATT32_NO_OLDIES. * INSTALL.DJGPP: Update URL of WATT-32 library. diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf index a82b95d..fad57a9 100644 --- a/Configurations/10-main.conf +++ b/Configurations/10-main.conf @@ -1299,7 +1299,7 @@ "DJGPP" => { inherit_from => [ asm("x86_asm") ], cc => "gcc", - cflags => "-I/dev/env/WATT_ROOT/inc -DTERMIO -DL_ENDIAN -fomit-frame-pointer -O2 -Wall", + cflags => "-I/dev/env/WATT_ROOT/inc -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O2 -Wall", sys_id => "MSDOS", lflags => "-L/dev/env/WATT_ROOT/lib -lwatt", bn_ops => "BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}", diff --git a/INSTALL.DJGPP b/INSTALL.DJGPP index 1047ec9..23aed6a 100644 --- a/INSTALL.DJGPP +++ b/INSTALL.DJGPP @@ -18,7 +18,7 @@ files to download, see the DJGPP "ZIP PICKER" page at "http://www.delorie.com/djgpp/zip-picker.html". You also need to have the WATT-32 networking package installed before you try to compile - OpenSSL. This can be obtained from "http://www.bgnett.no/~giva/". + OpenSSL. This can be obtained from "http://www.watt-32.net/". The Makefile assumes that the WATT-32 code is in the directory specified by the environment variable WATT_ROOT. If you have watt-32 in directory "watt32" under your main DJGPP directory, specify diff --git a/crypto/bio/bss_dgram.c b/crypto/bio/bss_dgram.c index 5e934ce..ca318cf 100644 --- a/crypto/bio/bss_dgram.c +++ b/crypto/bio/bss_dgram.c @@ -97,12 +97,6 @@ ((a)->s6_addr32[2] == htonl(0x0000ffff))) # endif -# ifdef WATT32 -# define sock_write SockWrite /* Watt-32 uses same names */ -# define sock_read SockRead -# define sock_puts SockPuts -# endif - static int dgram_write(BIO *h, const char *buf, int num); static int dgram_read(BIO *h, char *buf, int size); static int dgram_puts(BIO *h, const char *str); diff --git a/crypto/bio/bss_file.c b/crypto/bio/bss_file.c index c09a9a9..f34161c 100644 --- a/crypto/bio/bss_file.c +++ b/crypto/bio/bss_file.c @@ -95,6 +95,10 @@ # if !defined(OPENSSL_NO_STDIO) +#ifdef OPENSSL_SYS_MSDOS +# include +static void dosify_filename(const char *filename); +#endif static int file_write(BIO *h, const char *buf, int num); static int file_read(BIO *h, char *buf, int size); static int file_puts(BIO *h, const char *str); @@ -161,6 +165,9 @@ static FILE *file_fopen(const char *filename, const char *mode) file = fopen(filename, mode); } # else +# ifdef OPENSSL_SYS_MSDOS + dosify_filename(filename); +# endif file = fopen(filename, mode); # endif return (file); @@ -467,6 +474,23 @@ static int file_puts(BIO *bp, const char *str) return (ret); } +#ifdef OPENSSL_SYS_MSDOS +static void dosify_filename(const char *filename) +{ + if (filename && *filename && !HAS_LFN_SUPPORT(filename)) { + char *namestart = unconst(filename, char *); + + do { + if (namestart[0] == '/' && namestart[2] != '.' && namestart[2] != '/') { + + /* Leading dot not allowed on plain DOS. */ + if (namestart[1] == '.') + *++namestart = '_'; + } + } while (*++namestart); + } +} +#endif #else static int file_write(BIO *b, const char *in, int inl) diff --git a/crypto/bio/bss_sock.c b/crypto/bio/bss_sock.c index 1673b32..5cef4f3 100644 --- a/crypto/bio/bss_sock.c +++ b/crypto/bio/bss_sock.c @@ -66,7 +66,11 @@ # include # ifdef WATT32 -# define sock_write SockWrite /* Watt-32 uses same names */ +/* Watt-32 uses same names */ +# undef sock_write +# undef sock_read +# undef sock_puts +# define sock_write SockWrite # define sock_read SockRead # define sock_puts SockPuts # endif diff --git a/e_os.h b/e_os.h index 5ab4c89..6d52f13 100644 --- a/e_os.h +++ b/e_os.h @@ -141,6 +141,7 @@ extern "C" { # define writesocket(s,b,n) send((s),(b),(n),0) # elif defined(__DJGPP__) # define WATT32 +# define WATT32_NO_OLDIES # define get_last_socket_error() errno # define clear_socket_error() errno=0 # define closesocket(s) close_s(s) @@ -194,11 +195,14 @@ extern "C" { # include # include # include +# include # include # include # define _setmode setmode # define _O_TEXT O_TEXT # define _O_BINARY O_BINARY +# define HAS_LFN_SUPPORT(name) (pathconf((name), _PC_NAME_MAX) > 12) +# undef DEVRANDOM_EGD /* Neither MS-DOS nor FreeDOS provide 'egd' sockets. */ # undef DEVRANDOM # define DEVRANDOM "/dev/urandom\x24" # endif /* __DJGPP__ */ -------------- next part -------------- A non-text attachment was scrubbed... Name: djgpp-openssl-SNAP-20160106.patch.gz Type: application/x-gzip Size: 2254 bytes Desc: not available URL: From juan.guerrero at gmx.de Wed Jan 6 23:28:12 2016 From: juan.guerrero at gmx.de (Juan Manuel Guerrero) Date: Thu, 07 Jan 2016 00:28:12 +0100 Subject: [openssl-dev] [openssl.org #4217] Fixing DJGPP port of openssl master branch. In-Reply-To: References: <568A77AE.8090801@gmx.de> <20160104.212201.300039170238726481.levitte@openssl.org> <568B25A2.8000705@gmx.de> Message-ID: <568DA30C.6060109@gmx.de> Am 05.01.2016 04:05, schrieb Juan Manuel Guerrero via RT: > Am 04.01.2016 21:22, schrieb Richard Levitte via RT: >> Hi Juan, and thanks. >> >> I'm looking at your fix, and have a couple of questions: [snip] This is the last and final patch to fix the DJGPP port. The only difference compared with the initial patch is that it checks mow all file names for LFN validity. The dirname part and the basename part of the file name are now checked for ilicit initial dots in the case that no LFN support is provided by the file system. I have attached the patch as gzip'ed file too. Similar patches are also provided for the openssl 1.0.1 branch and the openssl 1.0.2 branch too. Regards, Juan M. Guerrero 2016-01-06 Juan Manuel Guerrero * Configure: Replaced -DTERMIO by -DTERMIOS in CFLAGS. * crypto/bio/bss_dgram.c [WATT32]: Remove obsolete redefinition of function names: sock_write, sock_read and sock_puts. * crypto/bio/bss_sock.c [WATT32]: For Watt-32 2.2.11 sock_write, sock_read and sock_puts are redefined to their private names so their names must be undefined first before they can be redefined again. * crypto/bio/bss_file.c (file_fopen) [OPENSSL_SYS_MSDOS]: Call dosify_filename to replace leading dot if file system does not support it. (dosify_filename): Replace leading dot in passed file name if file system does not support LFN. Replace all leading dots in the dirname part and the basname part of the file name. * e_os.h [__DJGPP__]: Undefine macro DEVRANDOM_EGD. Neither MS-DOS nor FreeDOS provide 'egd' sockets. New macro HAS_LFN_SUPPORT checks if underlying file system supports long file names or not. Include sys/un.h. Define WATT32_NO_OLDIES. * INSTALL.DJGPP: Update URL of WATT-32 library. diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf index a82b95d..fad57a9 100644 --- a/Configurations/10-main.conf +++ b/Configurations/10-main.conf @@ -1299,7 +1299,7 @@ "DJGPP" => { inherit_from => [ asm("x86_asm") ], cc => "gcc", - cflags => "-I/dev/env/WATT_ROOT/inc -DTERMIO -DL_ENDIAN -fomit-frame-pointer -O2 -Wall", + cflags => "-I/dev/env/WATT_ROOT/inc -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O2 -Wall", sys_id => "MSDOS", lflags => "-L/dev/env/WATT_ROOT/lib -lwatt", bn_ops => "BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}", diff --git a/INSTALL.DJGPP b/INSTALL.DJGPP index 1047ec9..23aed6a 100644 --- a/INSTALL.DJGPP +++ b/INSTALL.DJGPP @@ -18,7 +18,7 @@ files to download, see the DJGPP "ZIP PICKER" page at "http://www.delorie.com/djgpp/zip-picker.html". You also need to have the WATT-32 networking package installed before you try to compile - OpenSSL. This can be obtained from "http://www.bgnett.no/~giva/". + OpenSSL. This can be obtained from "http://www.watt-32.net/". The Makefile assumes that the WATT-32 code is in the directory specified by the environment variable WATT_ROOT. If you have watt-32 in directory "watt32" under your main DJGPP directory, specify diff --git a/crypto/bio/bss_dgram.c b/crypto/bio/bss_dgram.c index 5e934ce..ca318cf 100644 --- a/crypto/bio/bss_dgram.c +++ b/crypto/bio/bss_dgram.c @@ -97,12 +97,6 @@ ((a)->s6_addr32[2] == htonl(0x0000ffff))) # endif -# ifdef WATT32 -# define sock_write SockWrite /* Watt-32 uses same names */ -# define sock_read SockRead -# define sock_puts SockPuts -# endif - static int dgram_write(BIO *h, const char *buf, int num); static int dgram_read(BIO *h, char *buf, int size); static int dgram_puts(BIO *h, const char *str); diff --git a/crypto/bio/bss_file.c b/crypto/bio/bss_file.c index c09a9a9..f34161c 100644 --- a/crypto/bio/bss_file.c +++ b/crypto/bio/bss_file.c @@ -95,6 +95,10 @@ # if !defined(OPENSSL_NO_STDIO) +#ifdef OPENSSL_SYS_MSDOS +# include +static void dosify_filename(const char *filename); +#endif static int file_write(BIO *h, const char *buf, int num); static int file_read(BIO *h, char *buf, int size); static int file_puts(BIO *h, const char *str); @@ -161,6 +165,9 @@ static FILE *file_fopen(const char *filename, const char *mode) file = fopen(filename, mode); } # else +# ifdef OPENSSL_SYS_MSDOS + dosify_filename(filename); +# endif file = fopen(filename, mode); # endif return (file); @@ -467,6 +474,23 @@ static int file_puts(BIO *bp, const char *str) return (ret); } +#ifdef OPENSSL_SYS_MSDOS +static void dosify_filename(const char *filename) +{ + if (filename && *filename && !HAS_LFN_SUPPORT(filename)) { + char *namestart = unconst(filename, char *); + + do { + if (namestart[0] == '/' && namestart[2] != '.' && namestart[2] != '/') { + + /* Leading dot not allowed on plain DOS. */ + if (namestart[1] == '.') + *++namestart = '_'; + } + } while (*++namestart); + } +} +#endif #else static int file_write(BIO *b, const char *in, int inl) diff --git a/crypto/bio/bss_sock.c b/crypto/bio/bss_sock.c index 1673b32..5cef4f3 100644 --- a/crypto/bio/bss_sock.c +++ b/crypto/bio/bss_sock.c @@ -66,7 +66,11 @@ # include # ifdef WATT32 -# define sock_write SockWrite /* Watt-32 uses same names */ +/* Watt-32 uses same names */ +# undef sock_write +# undef sock_read +# undef sock_puts +# define sock_write SockWrite # define sock_read SockRead # define sock_puts SockPuts # endif diff --git a/e_os.h b/e_os.h index 5ab4c89..6d52f13 100644 --- a/e_os.h +++ b/e_os.h @@ -141,6 +141,7 @@ extern "C" { # define writesocket(s,b,n) send((s),(b),(n),0) # elif defined(__DJGPP__) # define WATT32 +# define WATT32_NO_OLDIES # define get_last_socket_error() errno # define clear_socket_error() errno=0 # define closesocket(s) close_s(s) @@ -194,11 +195,14 @@ extern "C" { # include # include # include +# include # include # include # define _setmode setmode # define _O_TEXT O_TEXT # define _O_BINARY O_BINARY +# define HAS_LFN_SUPPORT(name) (pathconf((name), _PC_NAME_MAX) > 12) +# undef DEVRANDOM_EGD /* Neither MS-DOS nor FreeDOS provide 'egd' sockets. */ # undef DEVRANDOM # define DEVRANDOM "/dev/urandom\x24" # endif /* __DJGPP__ */ -------------- next part -------------- A non-text attachment was scrubbed... Name: djgpp-openssl-SNAP-20160106.patch.gz Type: application/x-gzip Size: 2254 bytes Desc: not available URL: From rt at openssl.org Thu Jan 7 12:06:49 2016 From: rt at openssl.org (Arijit Nayak via RT) Date: Thu, 07 Jan 2016 12:06:49 +0000 Subject: [openssl-dev] [openssl.org #4222] Wrong definition of the macro SSL_set1_sigalgs in ssl.h (PR #519) In-Reply-To: <478739725.1292081.1452146254823.JavaMail.yahoo@mail.yahoo.com> References: <478739725.1292081.1452146254823.JavaMail.yahoo.ref@mail.yahoo.com> <478739725.1292081.1452146254823.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hello, Here is details of PR #519 Error in the definition of the macro SSL_set1_sigalgs(ctx, slist, slistlen): the third parameter 'slistlen' not used in the substitution code; used 'clistlen' instead. As a result of this, compilation error occurs when any application uses this macro. https://github.com/openssl/openssl/pull/519 Thanks,Arijit -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Jan 7 02:26:19 2016 From: rt at openssl.org (Gueron, Shay via RT) Date: Thu, 07 Jan 2016 02:26:19 +0000 Subject: [openssl-dev] [openssl.org #4221] [PATCH] Accelerating Multi Block (MB) CBC SHA256 on architectures that support AVX512 instructions set In-Reply-To: <3DE91BD01FD68540858FC917201D9B9939D3B22E@hasmsx107.ger.corp.intel.com> References: <3DE91BD01FD68540858FC917201D9B9939D3B22E@hasmsx107.ger.corp.intel.com> Message-ID: Hello all, This patch is a contribution to OpenSSL. It concerns the Multi Block (MB) CBC SHA256 implementation (the function "tls1_1_multi_block_encrypt" and "aesni_cbc_hmac_sha256_ctrl" in "e_aes_cbc_hmac_sha256.c"). The patch extends the number of blocks (currently 8) to 16, when detecting an architecture that supports AVX512. This enhances the performance of parallelized hashing, and as a byproduct speeds up MB CBC SHA256 (AES CBC with HMAC SHA256). The performance gains can be observed by invoking "openssl speed -mb -evp aes-128-cbc-hmac-sha256", when running on a (future) processor with AVX512. Significant improvement can be expected. This patch extends over the previous patch [1] (that efficiently generates random IV's), and incorporates it as well. [1] Patch #3850 - Improved performance Multi Block CBC-SHA1 and CBC-SHA256. https://mta.openssl.org/pipermail/openssl-dev/2015-May/001417.html Developers and authors: *************************************************************************** Shay Gueron (1, 2), Regev Shemy (2) (1) University of Haifa, Israel (2) Intel Corporation, Israel Development Center, Haifa, Israel *************************************************************************** --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- A non-text attachment was scrubbed... Name: sha256_MB_AVX512.PATCH Type: application/octet-stream Size: 228344 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Jan 7 14:54:16 2016 From: rt at openssl.org (Hubert Kario via RT) Date: Thu, 07 Jan 2016 14:54:16 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <2259170.gFmS5kAaJL@pintsize.usersys.redhat.com> References: <11050742.SAcpT9YNAe@pintsize.usersys.redhat.com> <2259170.gFmS5kAaJL@pintsize.usersys.redhat.com> Message-ID: The bug is still present in version tagged as OpenSSL_1_1_0-pre1 Moreover I've verified that the miTLS implementation[1] shows expected behaviour - it accepts the interleaved application data everywhere but between CCS and Finished. Secondly, current draft of TLS 1.3 has support for updating the key[2]. 1 - http://mitls.org/ 2 - https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-6.3.5.3 -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Thu Jan 7 19:41:21 2016 From: rt at openssl.org (Cleveland Watson via RT) Date: Thu, 07 Jan 2016 19:41:21 +0000 Subject: [openssl-dev] [openssl.org #4223] fix request for OpenSSL (not version specific) In-Reply-To: <201601071928.u07JSJN2021708@d03av04.boulder.ibm.com> References: <201601071928.u07JSJN2021708@d03av04.boulder.ibm.com> Message-ID: Hi, I work for IBM supporting an application built in the HP NonStop Open System Services (OSS) environment. The application I support uses OpenSSL, which I compile and integrate into our application. When compiling any version of OpenSSL under OSS, I have to add the highlighted condition in source module apps/ca.c in order to complete the compilation: /home/openssl/openssl-1.0.2e/apps: diff ca.c.orig ca.c 85c85 < # elif !defined(OPENSSL_SYS_VXWORKS) && !defined(OPENSSL_SYS_WINDOWS) && !defined(OPENSSL_SYS_NETWARE) --- > # elif !defined(OPENSSL_SYS_VXWORKS) && !defined(OPENSSL_SYS_WINDOWS) && !defined(OPENSSL_SYS_NETWARE) && !defined(__TANDEM) /home/openssl/openssl-1.0.2e/apps: The code in context is #ifndef W_OK # ifdef OPENSSL_SYS_VMS # if defined(__DECC) # include # else # include # endif # elif !defined(OPENSSL_SYS_VXWORKS) && !defined(OPENSSL_SYS_WINDOWS) && !defined(OPENSSL_SYS_NETWARE) && !defined(__TANDEM) # include # endif #endif Header file is not part of the standard library in OSS, so if the test for __TANDEM is not added, the preprocessor attempts to include the header file and the compilation fails when it is not found. Adding this condtion allows compilation to complete normally. This problem exists in every NonStop OSS environment I have worked in, with every version of OpenSSL I have worked with (starting with 0.9.8). Could this change be considered for permanent inclusion in future releases of OpenSSL? Current OpenSSL version: 1.0.2e Current NonStop OS version: J06.15.00 Best Regards, Cleve Watson watsoncl at us.ibm.com (469) 647-7146 -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Jan 8 11:14:50 2016 From: rt at openssl.org (Michel via RT) Date: Fri, 08 Jan 2016 11:14:50 +0000 Subject: [openssl-dev] [openssl.org #4224] [PATCH] ciphers command does not list supported SRP suites In-Reply-To: <000c01d14a05$b9aa9070$2cffb150$@sales@free.fr> References: <000c01d14a05$b9aa9070$2cffb150$@sales@free.fr> Message-ID: Hello, When the -s option is used with the 'ciphers' command (version 1.1) , the SRP suites are not listed. Here attached is a proposed patch, based on what you did for PSK. Regards, Michel. -------------- next part -------------- A non-text attachment was scrubbed... Name: srp-ciphers.patch Type: application/octet-stream Size: 1700 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Jan 8 15:41:20 2016 From: rt at openssl.org (Short, Todd via RT) Date: Fri, 08 Jan 2016 15:41:20 +0000 Subject: [openssl-dev] [openssl.org #4206] [PATCH] Add cipher alias for ChaCha20 In-Reply-To: <3B8E9345-184A-4401-A029-D02B170DBC04@akamai.com> References: <20151228152843.GA4796@roeckx.be> <3477931.tNNbFzrcoV@pintsize.usersys.redhat.com> <3B8E9345-184A-4401-A029-D02B170DBC04@akamai.com> Message-ID: Updated patch for RT4206, with updated names from draft -04. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-CHACHA20-alias-for-ciphers.patch Type: application/octet-stream Size: 2874 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Jan 8 17:27:39 2016 From: rt at openssl.org (deengert@gmail.com via RT) Date: Fri, 08 Jan 2016 17:27:39 +0000 Subject: [openssl-dev] [openssl.org #4225] OpenSSL 1.1-pre2 EC_KEY_ex_data regression of functionality from 1.0.2 to 1.1 In-Reply-To: <568ECA47.9010900@gmail.com> References: <568ECA47.9010900@gmail.com> Message-ID: OpenSSL 1.1 (from github.com) Now combined ECDSA_METHOD and ECDH_METHOD into one method EC_KEY_METHOD. in 1.0.2 there were ECDSA_get_ex_new_index, ECDSA_set_ex_data and ECDSA_get_ex_data with the EC_KEY and an idx as parameters And there where ECDH versions to: ECDH_get_ex_new_index, ECDH_set_ex_data and ECDH_get_ex_data. The best I can tell when this two methods were combined into a single EC_KEY_METHOD the ability to use CRYPTO_EX_INDEX_ to hang more then one piece of data off the key was lost in 1.1. This is the regression. In 1.0.1 and 1.1 RSA has: RSA_get_ex_new_index, RSA_set_ex_data, RSA_get_ex_data, RSA_set_app_data and RSA_get_app_data which all use the ls CRYPTO_EX_DATA ex_data; in the struct rsa_st. What would it take to add a CRYPTO_EX_DATA ex_data; in the struct ec_key_st with EC_KEY_get_ex_new_index, EC_KEY_set_ex_data, EC_KEY_get_ex_data, EC_KEY_set_app_data and EC_KEY_get_app_data? This would then allow for app_data, as well as allocated indexes, and present the same user interface as for other keys and retain the functionality of having an _ex_data for the key? ec_lcl.h Says: 274 * Basically a 'mixin' for extra data, but available for EC_GROUPs/EC_KEYs 275 * only (with visibility limited to 'package' level for now). We use the 276 * function pointers as index for retrieval; this obviates global 277 * ex_data-style index tables. The "only (with visibility limited to 'package' level for now)." is a problem. You could still keep the EC_EXTRA_DATA *method_data; for internal use if needed. -- Douglas E. Engert _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Jan 8 17:30:40 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Fri, 08 Jan 2016 17:30:40 +0000 Subject: [openssl-dev] [openssl.org #4225] OpenSSL 1.1-pre2 EC_KEY_ex_data regression of functionality from 1.0.2 to 1.1 In-Reply-To: <59c291ff57fd4cb39e481329a843fd39@usma1ex-dag1mb1.msg.corp.akamai.com> References: <568ECA47.9010900@gmail.com> <59c291ff57fd4cb39e481329a843fd39@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: There is a fix for this that is in the internal code-review phase. It's based on patches Roumen sent. From rt at openssl.org Sat Jan 9 11:28:14 2016 From: rt at openssl.org (=?UTF-8?B?SmFuIMW9w6Fr?= via RT) Date: Sat, 09 Jan 2016 11:28:14 +0000 Subject: [openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format In-Reply-To: References: Message-ID: This implementation is not enough, beacuse it works only for openssl s_client app. However it should work for all apps using openssl as a library (eg. curl, nginx). SSLKEYLOGFILE env var is a good current standard, so I think openssl should use it as well. Regards, Jan Zak On Tue, Dec 29, 2015 at 12:53 AM, Matt Caswell via RT wrote: > On Mon Dec 28 22:01:04 2015, rsalz at akamai.com wrote: > > Yes we would be interested in this but someone would almost definitely > > have to be provided as a complete patch because it seems unlikely > > anyone on the team will get around to doing it by 1.1 release. > > > > Actually I think this capability is already in 1.1.0...or rather it *was* > but > now seems to be broken. > > See commit 189ae368d91 and RT ticket 3352. > > I suspect the big apps cleanup broke it. > > Matt > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From doctor at doctor.nl2k.ab.ca Sat Jan 9 13:54:47 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 9 Jan 2016 06:54:47 -0700 Subject: [openssl-dev] openssl-SNAP-20160109 issue Message-ID: <20160109135447.GA22497@doctor.nl2k.ab.ca> In a amke && make test I got making all in engines/ccgost... gcc -I.. -I../include -I../crypto/include -I../fips -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=i486 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c jpaketest.c jpaketest.c: In function `main': jpaketest.c:119: warning: implicit declaration of function `CRYPTO_set_mem_debug_functions' jpaketest.c:120: parse error before "CRYPTO_mem_ctrl" jpaketest.c:179: warning: implicit declaration of function `CRYPTO_mem_leaks' *** Error code 1 Stop. *** Error code 1 Stop. Please fix. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From rt at openssl.org Sat Jan 9 16:25:09 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Sat, 09 Jan 2016 16:25:09 +0000 Subject: [openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format In-Reply-To: <6d483a4ef653400ab42791cbb37a616e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <6d483a4ef653400ab42791cbb37a616e@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > SSLKEYLOGFILE env var is a good current standard, so I think openssl should > use it as well. Patches to implement all of this would be helpful, otherwise it will probably not make it into the next relese. From rsalz at akamai.com Sat Jan 9 16:30:39 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 9 Jan 2016 16:30:39 +0000 Subject: [openssl-dev] [openssl-users] openssl-SNAP-20160109 issue In-Reply-To: <20160109135447.GA22497@doctor.nl2k.ab.ca> References: <20160109135447.GA22497@doctor.nl2k.ab.ca> Message-ID: <2f898861830c477ba0ff6d9140a9a987@usma1ex-dag1mb1.msg.corp.akamai.com> Does this fix it? ; g diff test/jpaketest.c diff --git a/test/jpaketest.c b/test/jpaketest.c index 2771e51..62ea37b 100644 --- a/test/jpaketest.c +++ b/test/jpaketest.c @@ -176,7 +176,9 @@ int main(int argc, char **argv) CRYPTO_cleanup_all_ex_data(); ERR_remove_thread_state(NULL); ERR_free_strings(); +#ifdef CRYPTO_MDEBUG CRYPTO_mem_leaks(bio_err); +#endif return 0; } ; -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz > -----Original Message----- > From: The Doctor [mailto:doctor at doctor.nl2k.ab.ca] > Sent: Saturday, January 09, 2016 8:55 AM > To: openssl-dev at openssl.org; openssl-users at openssl.org > Subject: [openssl-users] openssl-SNAP-20160109 issue > > In a amke && make test > > I got > > making all in engines/ccgost... > gcc -I.. -I../include -I../crypto/include -I../fips -fPIC -DOPENSSL_PIC - > DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE - > D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN - > DTERMIOS -fomit-frame-pointer -O2 -march=i486 -Wall -g - > DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE - > DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT - > DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM - > DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM - > DECP_NISTZ256_ASM -c jpaketest.c > jpaketest.c: In function `main': > jpaketest.c:119: warning: implicit declaration of function > `CRYPTO_set_mem_debug_functions' > jpaketest.c:120: parse error before "CRYPTO_mem_ctrl" > jpaketest.c:179: warning: implicit declaration of function > `CRYPTO_mem_leaks' > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > > Please fix. > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici > doctor@@nl2k.ab.ca God,Queen and country!Never Satan President > Republic!Beware AntiChrist rising! > http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism > Birthdate 29 Jan 1969 Redhill, Surrey, UK > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From deengert at gmail.com Sat Jan 9 18:59:52 2016 From: deengert at gmail.com (Douglas E Engert) Date: Sat, 9 Jan 2016 12:59:52 -0600 Subject: [openssl-dev] [openssl.org #4225] OpenSSL 1.1-pre2 EC_KEY_ex_data regression of functionality from 1.0.2 to 1.1 In-Reply-To: References: <568ECA47.9010900@gmail.com> <59c291ff57fd4cb39e481329a843fd39@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <569158A8.4070405@gmail.com> Thanks, Roumen's patches looks good and also include EC_KEY_set_method to replace the working ECDSA_set_method and ECDH_set_method in 1.0.2. Any idea when these will be in github? On 1/8/2016 11:30 AM, Salz, Rich via RT wrote: > There is a fix for this that is in the internal code-review phase. It's based on patches Roumen sent. > > > -- Douglas E. Engert From rt at openssl.org Sat Jan 9 19:07:44 2016 From: rt at openssl.org (deengert@gmail.com via RT) Date: Sat, 09 Jan 2016 19:07:44 +0000 Subject: [openssl-dev] [openssl.org #4225] OpenSSL 1.1-pre2 EC_KEY_ex_data regression of functionality from 1.0.2 to 1.1 In-Reply-To: <569158A8.4070405@gmail.com> References: <568ECA47.9010900@gmail.com> <59c291ff57fd4cb39e481329a843fd39@usma1ex-dag1mb1.msg.corp.akamai.com> <569158A8.4070405@gmail.com> Message-ID: Thanks, Roumen's patches looks good and also include EC_KEY_set_method to replace the working ECDSA_set_method and ECDH_set_method in 1.0.2. Any idea when these will be in github? On 1/8/2016 11:30 AM, Salz, Rich via RT wrote: > There is a fix for this that is in the internal code-review phase. It's based on patches Roumen sent. > > > -- Douglas E. Engert From paul.l.kehrer at gmail.com Sat Jan 9 20:20:22 2016 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Sat, 9 Jan 2016 12:20:22 -0800 Subject: [openssl-dev] [PATCH] Declare/Implement ASN1_FUNCTIONS for NAME_CONSTRAINTS Message-ID: The ASN1 functions for NAME_CONSTRAINTS are not declared or implemented in the current OpenSSL releases. This is inconsistent with other extension structs and (I believe) means you either need to declare them yourself or attempt to build NAME_CONSTRAINTS using nconf functions. Below is a patch to current git master that adds support for these functions.? If there's a preferred way to test that these macros behave as expected I'll be happy to add the tests to this patch. -Paul Kehrer? diff --git a/crypto/x509v3/v3_ncons.c b/crypto/x509v3/v3_ncons.c? index d3f79ba..e679f0a 100644? --- a/crypto/x509v3/v3_ncons.c? +++ b/crypto/x509v3/v3_ncons.c? @@ -109,7 +109,7 @@ ASN1_SEQUENCE(NAME_CONSTRAINTS) = {? ?? ?? ?IMPLEMENT_ASN1_ALLOC_FUNCTIONS(GENERAL_SUBTREE)? -IMPLEMENT_ASN1_ALLOC_FUNCTIONS(NAME_CONSTRAINTS)? +IMPLEMENT_ASN1_FUNCTIONS(NAME_CONSTRAINTS)? ?? ?static void *v2i_NAME_CONSTRAINTS(const X509V3_EXT_METHOD *method,? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?X509V3_CTX *ctx, STACK_OF(CONF_VALUE) *nval)? diff --git a/include/openssl/x509v3.h b/include/openssl/x509v3.h? index b5ea84a..f2e8598 100644? --- a/include/openssl/x509v3.h? +++ b/include/openssl/x509v3.h? @@ -591,7 +591,7 @@ DECLARE_ASN1_ITEM(GENERAL_SUBTREE)? ?DECLARE_ASN1_ALLOC_FUNCTIONS(GENERAL_SUBTREE)? ?? ?DECLARE_ASN1_ITEM(NAME_CONSTRAINTS)? -DECLARE_ASN1_ALLOC_FUNCTIONS(NAME_CONSTRAINTS)? +DECLARE_ASN1_FUNCTIONS(NAME_CONSTRAINTS)? ?? ?DECLARE_ASN1_ALLOC_FUNCTIONS(POLICY_CONSTRAINTS)? ?DECLARE_ASN1_ITEM(POLICY_CONSTRAINTS)? From paul.l.kehrer at gmail.com Sat Jan 9 20:26:35 2016 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Sat, 9 Jan 2016 12:26:35 -0800 Subject: [openssl-dev] Backporting opaque struct getter/setter functions Message-ID: With OpenSSL 1.1.0 opaquing most of the structs getter/setter functions are required to perform many operations. What do people think about backporting those accessors into the 1.0.2 branch? It might simplify supporting 1.1.0 (but only as projects drop 0.9.8/1.0.0/1.0.1 support of course). -Paul Kehrer From rsalz at akamai.com Sat Jan 9 22:43:19 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 9 Jan 2016 22:43:19 +0000 Subject: [openssl-dev] [openssl.org #4225] OpenSSL 1.1-pre2 EC_KEY_ex_data regression of functionality from 1.0.2 to 1.1 In-Reply-To: <569158A8.4070405@gmail.com> References: <568ECA47.9010900@gmail.com> <59c291ff57fd4cb39e481329a843fd39@usma1ex-dag1mb1.msg.corp.akamai.com> <569158A8.4070405@gmail.com> Message-ID: <2a1f2961a18d4ce7b367b2e3a110c286@usma1ex-dag1mb1.msg.corp.akamai.com> > Any idea when these will be in github? Hopefully in time for the next alpha 1.1 release, in a week or two. From rt at openssl.org Sat Jan 9 22:43:31 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Sat, 09 Jan 2016 22:43:31 +0000 Subject: [openssl-dev] [openssl.org #4225] OpenSSL 1.1-pre2 EC_KEY_ex_data regression of functionality from 1.0.2 to 1.1 In-Reply-To: <2a1f2961a18d4ce7b367b2e3a110c286@usma1ex-dag1mb1.msg.corp.akamai.com> References: <568ECA47.9010900@gmail.com> <59c291ff57fd4cb39e481329a843fd39@usma1ex-dag1mb1.msg.corp.akamai.com> <569158A8.4070405@gmail.com> <2a1f2961a18d4ce7b367b2e3a110c286@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > Any idea when these will be in github? Hopefully in time for the next alpha 1.1 release, in a week or two. From rsalz at akamai.com Sat Jan 9 22:45:52 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 9 Jan 2016 22:45:52 +0000 Subject: [openssl-dev] Backporting opaque struct getter/setter functions In-Reply-To: References: Message-ID: > required to perform many operations. What do people think about > backporting those accessors into the 1.0.2 branch? Another possibility is to have a just a single (new) header file that has #define's for the accessors that turn into raw structure access. From rsalz at akamai.com Sat Jan 9 22:49:32 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 9 Jan 2016 22:49:32 +0000 Subject: [openssl-dev] [PATCH] Declare/Implement ASN1_FUNCTIONS for NAME_CONSTRAINTS In-Reply-To: References: Message-ID: <614298e7515d42029c70b7ea7275f2a3@usma1ex-dag1mb1.msg.corp.akamai.com> You might also take a look at https://rt.openssl.org/Ticket/Display.html?id=3502 -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz > -----Original Message----- > From: Paul Kehrer [mailto:paul.l.kehrer at gmail.com] > Sent: Saturday, January 09, 2016 3:20 PM > To: openssl-dev at openssl.org > Subject: [openssl-dev] [PATCH] Declare/Implement ASN1_FUNCTIONS for > NAME_CONSTRAINTS > > The ASN1 functions for NAME_CONSTRAINTS are not declared or > implemented in the current OpenSSL releases. This is inconsistent with other > extension structs and (I believe) means you either need to declare them > yourself or attempt to build NAME_CONSTRAINTS using nconf functions. > Below is a patch to current git master that adds support for these functions. > > If there's a preferred way to test that these macros behave as expected I'll > be happy to add the tests to this patch. > > > -Paul Kehrer > > > > diff --git a/crypto/x509v3/v3_ncons.c b/crypto/x509v3/v3_ncons.c index > d3f79ba..e679f0a 100644 > --- a/crypto/x509v3/v3_ncons.c > +++ b/crypto/x509v3/v3_ncons.c > @@ -109,7 +109,7 @@ ASN1_SEQUENCE(NAME_CONSTRAINTS) = { > > > ?IMPLEMENT_ASN1_ALLOC_FUNCTIONS(GENERAL_SUBTREE) > -IMPLEMENT_ASN1_ALLOC_FUNCTIONS(NAME_CONSTRAINTS) > +IMPLEMENT_ASN1_FUNCTIONS(NAME_CONSTRAINTS) > > ?static void *v2i_NAME_CONSTRAINTS(const X509V3_EXT_METHOD > *method, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?X509V3_CTX *ctx, STACK_OF(CONF_VALUE) *nval) diff --git > a/include/openssl/x509v3.h b/include/openssl/x509v3.h index > b5ea84a..f2e8598 100644 > --- a/include/openssl/x509v3.h > +++ b/include/openssl/x509v3.h > @@ -591,7 +591,7 @@ DECLARE_ASN1_ITEM(GENERAL_SUBTREE) > ?DECLARE_ASN1_ALLOC_FUNCTIONS(GENERAL_SUBTREE) > > ?DECLARE_ASN1_ITEM(NAME_CONSTRAINTS) > -DECLARE_ASN1_ALLOC_FUNCTIONS(NAME_CONSTRAINTS) > +DECLARE_ASN1_FUNCTIONS(NAME_CONSTRAINTS) > > ?DECLARE_ASN1_ALLOC_FUNCTIONS(POLICY_CONSTRAINTS) > ?DECLARE_ASN1_ITEM(POLICY_CONSTRAINTS) > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From steve at openssl.org Sun Jan 10 01:13:51 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Sun, 10 Jan 2016 01:13:51 +0000 Subject: [openssl-dev] [PATCH] Declare/Implement ASN1_FUNCTIONS for NAME_CONSTRAINTS In-Reply-To: References: Message-ID: <20160110011351.GA27275@openssl.org> On Sat, Jan 09, 2016, Paul Kehrer wrote: > The ASN1 functions for NAME_CONSTRAINTS are not declared or implemented in the current OpenSSL releases. This is inconsistent with other extension structs and (I believe) means you either need to declare them yourself or attempt to build NAME_CONSTRAINTS using nconf functions. Below is a patch to current git master that adds support for these functions.? > > If there's a preferred way to test that these macros behave as expected I'll be happy to add the tests to this patch. > Why do you need the i2d/d2i functions? It is possible to encode and decode the extension using X509_get_ext_d2i() and X509_add1_ext_i2d(). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From richmoore44 at gmail.com Sun Jan 10 01:19:15 2016 From: richmoore44 at gmail.com (Richard Moore) Date: Sun, 10 Jan 2016 01:19:15 +0000 Subject: [openssl-dev] Backporting opaque struct getter/setter functions In-Reply-To: References: Message-ID: On 9 January 2016 at 22:45, Salz, Rich wrote: > > > required to perform many operations. What do people think about > > backporting those accessors into the 1.0.2 branch? > > Another possibility is to have a just a single (new) header file that has > #define's for the accessors that turn into raw structure access. > > ?That would not help anyone who needs function pointers.? ?Rich. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.sales at free.fr Sun Jan 10 13:39:53 2016 From: michel.sales at free.fr (Michel) Date: Sun, 10 Jan 2016 14:39:53 +0100 Subject: [openssl-dev] cannot build current master under windows 7 /VS 2015 Message-ID: <000c01d14bac$632da950$2988fbf0$@sales@free.fr> Hi, Trying to see if updates of version 1.1 solved my previous problem with s_client/s_server, I am not able to build the current sources (but still succeed with 1.1-pre) : (Windows 7, Visual Studio 2015 Community Edition) cl /Fotmp32\statem_srvr.obj -I.\include -Itmp32 -I.\crypto\include -DOP ENSSL_NO_HEARTBEATS -DOPENSSL_NO_BUF_FREELISTS -DOPENSSL_NO_COMP /MT /Ox /O2 /O b2 -DOPENSSL_THREADS -DDSO_WIN32 -DOPENSSL_NO_HEARTBEATS -DOPENSSL_NO_BUF_FREEL ISTS -W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32 _SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA5 12_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DOPENSSL_NO_RC2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_ NO_MD4 -DOPENSSL_NO_SSL3 -DOPENSSL_NO_GOST -DOPENSSL_NO_HW -DOPENSSL_NO_JPAKE -D OPENSSL_NO_DYNAMIC_ENGINE /Zl /Zi /Fdtmp32/lib -c .\ssl\statem\statem_srvr.c statem_srvr.c E:\openssl-master.git\ssl\statem\statem_srvr.c : fatal error C1001: An internal error has occurred in the compiler. (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 246) To work around this problem, try simplifying or changing the program near the l ocations listed above. Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information INTERNAL COMPILER ERROR in 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\ VC\BIN\cl.EXE' Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0 \VC\BIN\cl.EXE"' : return code '0x1' Stop. Can you please help in this matter ? Regards, Michel -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalten at au1.ibm.com Mon Jan 11 01:09:47 2016 From: pwalten at au1.ibm.com (Peter Waltenberg) Date: Mon, 11 Jan 2016 01:09:47 +0000 Subject: [openssl-dev] Backporting opaque struct getter/setter functions In-Reply-To: References: , Message-ID: <201601110110.u0B1A1JX029122@d23av03.au.ibm.com> An HTML attachment was scrubbed... URL: From wilson.judson at gmail.com Mon Jan 11 01:35:23 2016 From: wilson.judson at gmail.com (Judson Wilson) Date: Sun, 10 Jan 2016 17:35:23 -0800 Subject: [openssl-dev] Backporting opaque struct getter/setter functions In-Reply-To: <201601110110.u0B1A1JX029122@d23av03.au.ibm.com> References: <201601110110.u0B1A1JX029122@d23av03.au.ibm.com> Message-ID: If some users find 1.1 to be a worse alternative to 1.0.2, but they have the power to use a very new version of 1.0.2, then this makes sense for reverse compatibility. On Sun, Jan 10, 2016 at 5:09 PM, Peter Waltenberg wrote: > The point of using accessor FUNCTIONS is that the code doesn't break if > the structure size or offsets of fields in the underlying structures change > across binaries. > > Where that mainly has an impact is updating the crypto/ssl libs underneath > existing binaries is more likely to just work. > > #defines in the headers do not help at all here. > > > Peter > > > -----"openssl-dev" wrote: ----- > To: openssl-dev at openssl.org > From: Richard Moore > Sent by: "openssl-dev" > Date: 01/10/2016 11:20AM > Subject: Re: [openssl-dev] Backporting opaque struct getter/setter > functions > > > > > On 9 January 2016 at 22:45, Salz, Rich wrote: > >> >> > required to perform many operations. What do people think about >> > backporting those accessors into the 1.0.2 branch? >> >> Another possibility is to have a just a single (new) header file that has >> #define's for the accessors that turn into raw structure access. >> >> > ?That would not help anyone who needs function pointers.? > > > ?Rich. > ? > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Jan 11 10:08:37 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 11 Jan 2016 10:08:37 +0000 Subject: [openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format In-Reply-To: References: Message-ID: On Mon Dec 28 23:53:02 2015, matt wrote: > On Mon Dec 28 22:01:04 2015, rsalz at akamai.com wrote: > > Yes we would be interested in this but someone would almost > > definitely > > have to be provided as a complete patch because it seems unlikely > > anyone on the team will get around to doing it by 1.1 release. > > > > Actually I think this capability is already in 1.1.0...or rather it > *was* but > now seems to be broken. > > See commit 189ae368d91 and RT ticket 3352. > > I suspect the big apps cleanup broke it. This is now fixed. Keeping this ticket open for now because of the request for support beyond just the apps. Matt From tmraz at redhat.com Mon Jan 11 10:23:12 2016 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 11 Jan 2016 11:23:12 +0100 Subject: [openssl-dev] Backporting opaque struct getter/setter functions In-Reply-To: <201601110110.u0B1A1JX029122@d23av03.au.ibm.com> References: , <201601110110.u0B1A1JX029122@d23av03.au.ibm.com> Message-ID: <1452507792.23391.2.camel@redhat.com> On Po, 2016-01-11 at 01:09 +0000, Peter Waltenberg wrote: > The point of using accessor FUNCTIONS is that the code doesn't break > if the structure size or offsets of fields in the underlying > structures change across binaries. > > Where that mainly has an impact is updating the crypto/ssl libs > underneath existing binaries is more likely to just work. > > #defines in the headers do not help at all here. > The point is in achieving reverse API compatibility between 1.1 and 1.0.2. No binary compatibility is expected between those branches. I think that having the API compatibility would be really useful thing easing porting application code to 1.1 branch. -- 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.) From wilson.judson at gmail.com Mon Jan 11 11:34:00 2016 From: wilson.judson at gmail.com (Judson Wilson) Date: Mon, 11 Jan 2016 03:34:00 -0800 Subject: [openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format In-Reply-To: References: Message-ID: Here is an OpenSSL port of a patch in BoringSSL. It requires a call from the application to set a file BIO. You could probably do this from within SSL_CTX_new or something like that if you want a solution that doesn't change the application. https://github.com/JudsonWilson/openssl/commit/20e035a293756976b519ce028d5bcfe95544794b On Mon, Jan 11, 2016 at 2:08 AM, Matt Caswell via RT wrote: > On Mon Dec 28 23:53:02 2015, matt wrote: > > On Mon Dec 28 22:01:04 2015, rsalz at akamai.com wrote: > > > Yes we would be interested in this but someone would almost > > > definitely > > > have to be provided as a complete patch because it seems unlikely > > > anyone on the team will get around to doing it by 1.1 release. > > > > > > > Actually I think this capability is already in 1.1.0...or rather it > > *was* but > > now seems to be broken. > > > > See commit 189ae368d91 and RT ticket 3352. > > > > I suspect the big apps cleanup broke it. > > This is now fixed. Keeping this ticket open for now because of the request > for > support beyond just the apps. > > Matt > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Jan 11 11:34:13 2016 From: rt at openssl.org (Judson Wilson via RT) Date: Mon, 11 Jan 2016 11:34:13 +0000 Subject: [openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format In-Reply-To: References: Message-ID: Here is an OpenSSL port of a patch in BoringSSL. It requires a call from the application to set a file BIO. You could probably do this from within SSL_CTX_new or something like that if you want a solution that doesn't change the application. https://github.com/JudsonWilson/openssl/commit/20e035a293756976b519ce028d5bcfe95544794b On Mon, Jan 11, 2016 at 2:08 AM, Matt Caswell via RT wrote: > On Mon Dec 28 23:53:02 2015, matt wrote: > > On Mon Dec 28 22:01:04 2015, rsalz at akamai.com wrote: > > > Yes we would be interested in this but someone would almost > > > definitely > > > have to be provided as a complete patch because it seems unlikely > > > anyone on the team will get around to doing it by 1.1 release. > > > > > > > Actually I think this capability is already in 1.1.0...or rather it > > *was* but > > now seems to be broken. > > > > See commit 189ae368d91 and RT ticket 3352. > > > > I suspect the big apps cleanup broke it. > > This is now fixed. Keeping this ticket open for now because of the request > for > support beyond just the apps. > > Matt > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From rsalz at akamai.com Mon Jan 11 15:06:05 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 11 Jan 2016 15:06:05 +0000 Subject: [openssl-dev] Do you need EGD support? Message-ID: <11d84bf7c4d847a0b9e03f9a3ea16b44@usma1ex-dag1mb1.msg.corp.akamai.com> We are considering removing EGD support in 1.1 If your platform still needs it, please reply soon. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From doctor at doctor.nl2k.ab.ca Mon Jan 11 16:52:27 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 11 Jan 2016 09:52:27 -0700 Subject: [openssl-dev] Still seeing errors in Openssl 1.1 pre Message-ID: <20160111165227.GA28108@doctor.nl2k.ab.ca> Still seeing jpaketest.c: In function `main': jpaketest.c:119: warning: implicit declaration of function `CRYPTO_set_mem_debug_functions' jpaketest.c:120: parse error before "CRYPTO_mem_ctrl" Please fix. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From rsalz at akamai.com Mon Jan 11 17:08:40 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 11 Jan 2016 17:08:40 +0000 Subject: [openssl-dev] Still seeing errors in Openssl 1.1 pre In-Reply-To: <20160111165227.GA28108@doctor.nl2k.ab.ca> References: <20160111165227.GA28108@doctor.nl2k.ab.ca> Message-ID: <034cdaa2fad245ec9aa340ec5f08752a@usma1ex-dag1mb1.msg.corp.akamai.com> I posted a patch and asked if that fixes the issue. Did you not see it? -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz > -----Original Message----- > From: The Doctor [mailto:doctor at doctor.nl2k.ab.ca] > Sent: Monday, January 11, 2016 11:52 AM > To: openssl-dev at openssl.org > Subject: [openssl-dev] Still seeing errors in Openssl 1.1 pre > > > Still seeing > > jpaketest.c: In function `main': > jpaketest.c:119: warning: implicit declaration of function > `CRYPTO_set_mem_debug_functions' > jpaketest.c:120: parse error before "CRYPTO_mem_ctrl" > > Please fix. > > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici > doctor@@nl2k.ab.ca God,Queen and country!Never Satan President > Republic!Beware AntiChrist rising! > http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism > Birthdate 29 Jan 1969 Redhill, Surrey, UK > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From doctor at doctor.nl2k.ab.ca Mon Jan 11 17:38:11 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 11 Jan 2016 10:38:11 -0700 Subject: [openssl-dev] Still seeing errors in Openssl 1.1 pre In-Reply-To: <034cdaa2fad245ec9aa340ec5f08752a@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160111165227.GA28108@doctor.nl2k.ab.ca> <034cdaa2fad245ec9aa340ec5f08752a@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160111173811.GA6578@doctor.nl2k.ab.ca> On Mon, Jan 11, 2016 at 05:08:40PM +0000, Salz, Rich wrote: > I posted a patch and asked if that fixes the issue. Did you not see it? > > -- > Senior Architect, Akamai Technologies > IM: richsalz at jabber.at Twitter: RichSalz > > > > -----Original Message----- > > From: The Doctor [mailto:doctor at doctor.nl2k.ab.ca] > > Sent: Monday, January 11, 2016 11:52 AM > > To: openssl-dev at openssl.org > > Subject: [openssl-dev] Still seeing errors in Openssl 1.1 pre > > > > > > Still seeing > > > > jpaketest.c: In function `main': > > jpaketest.c:119: warning: implicit declaration of function > > `CRYPTO_set_mem_debug_functions' > > jpaketest.c:120: parse error before "CRYPTO_mem_ctrl" > > > > Please fix. > > Not yet Rich. Please repost. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From rsalz at akamai.com Mon Jan 11 17:40:53 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 11 Jan 2016 17:40:53 +0000 Subject: [openssl-dev] Still seeing errors in Openssl 1.1 pre In-Reply-To: <20160111173811.GA6578@doctor.nl2k.ab.ca> References: <20160111165227.GA28108@doctor.nl2k.ab.ca> <034cdaa2fad245ec9aa340ec5f08752a@usma1ex-dag1mb1.msg.corp.akamai.com> <20160111173811.GA6578@doctor.nl2k.ab.ca> Message-ID: <84e3e4215ccd4cb8a9bf60fcb17a93d9@usma1ex-dag1mb1.msg.corp.akamai.com> > Not yet Rich. > > Please repost. Steve fixed it already :) So the next snapshot won't fail for this. From openssl-users at dukhovni.org Mon Jan 11 18:29:57 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 11 Jan 2016 13:29:57 -0500 Subject: [openssl-dev] Backporting opaque struct getter/setter functions In-Reply-To: <1452507792.23391.2.camel@redhat.com> References: <201601110110.u0B1A1JX029122@d23av03.au.ibm.com> <1452507792.23391.2.camel@redhat.com> Message-ID: <766C9619-D75C-416E-AE17-F5B825A061BD@dukhovni.org> > On Jan 11, 2016, at 5:23 AM, Tomas Mraz wrote: > > On Po, 2016-01-11 at 01:09 +0000, Peter Waltenberg wrote: >> The point of using accessor FUNCTIONS is that the code doesn't break >> if the structure size or offsets of fields in the underlying >> structures change across binaries. >> >> Where that mainly has an impact is updating the crypto/ssl libs >> underneath existing binaries is more likely to just work. >> >> #defines in the headers do not help at all here. >> > > The point is in achieving reverse API compatibility between 1.1 and > 1.0.2. No binary compatibility is expected between those branches. > > I think that having the API compatibility would be really useful thing > easing porting application code to 1.1 branch. Yes, although in practice may users of 1.0.x will have previous releases that don't have the accessors, so the issue is difficult to address retroactively in OpenSSL. In Postfix, I add the macros myself: #if OPENSSL_VERSION_NUMBER < 0x10100000L #define X509_up_ref(x) (CRYPTO_add(&x->references, 1, CRYPTO_LOCK_X509)) #endif Which means that interestingly enough adding these to 1.0.x would break my code and similar code elsewhere. So on the whole forward-compatibility macros don't fully address the problem, and may do as much harm as good. I think that applications porting to 1.1.0 can and should implement their own macros against a stable 1.0.x API that we don't change at the last minute. Providing your own forward-compatible glue is easy enough... -- Viktor. From openssl-users at dukhovni.org Mon Jan 11 19:07:34 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 11 Jan 2016 14:07:34 -0500 Subject: [openssl-dev] Backporting opaque struct getter/setter functions In-Reply-To: <201601110110.u0B1A1JX029122@d23av03.au.ibm.com> References: <201601110110.u0B1A1JX029122@d23av03.au.ibm.com> Message-ID: > On Jan 10, 2016, at 8:09 PM, Peter Waltenberg wrote: > > The point of using accessor FUNCTIONS is that the code doesn't break if the structure size or offsets of fields in the underlying structures change across binaries. > > Where that mainly has an impact is updating the crypto/ssl libs underneath existing binaries is more likely to just work. > > #defines in the headers do not help at all here. Well, this is why 1.1.0 is switching to functions, and making the structures opaque. As a result 1.1.0 is NOT binary compatible with 1.0.x. It is too late to change 1.0.x. It will be easier to maintain a stable ABI starting with 1.1.0. Switching from 1.0.x to 1.1.0 will require re-compilation, and some source code changes. -- Viktor. From matt at openssl.org Mon Jan 11 19:20:45 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 11 Jan 2016 19:20:45 +0000 Subject: [openssl-dev] Backporting opaque struct getter/setter functions In-Reply-To: <766C9619-D75C-416E-AE17-F5B825A061BD@dukhovni.org> References: <201601110110.u0B1A1JX029122@d23av03.au.ibm.com> <1452507792.23391.2.camel@redhat.com> <766C9619-D75C-416E-AE17-F5B825A061BD@dukhovni.org> Message-ID: <5694008D.20502@openssl.org> On 11/01/16 18:29, Viktor Dukhovni wrote: > >> On Jan 11, 2016, at 5:23 AM, Tomas Mraz wrote: >> >> On Po, 2016-01-11 at 01:09 +0000, Peter Waltenberg wrote: >>> The point of using accessor FUNCTIONS is that the code doesn't break >>> if the structure size or offsets of fields in the underlying >>> structures change across binaries. >>> >>> Where that mainly has an impact is updating the crypto/ssl libs >>> underneath existing binaries is more likely to just work. >>> >>> #defines in the headers do not help at all here. >>> >> >> The point is in achieving reverse API compatibility between 1.1 and >> 1.0.2. No binary compatibility is expected between those branches. >> >> I think that having the API compatibility would be really useful thing >> easing porting application code to 1.1 branch. > > Yes, although in practice may users of 1.0.x will have previous releases > that don't have the accessors, so the issue is difficult to address > retroactively in OpenSSL. In Postfix, I add the macros myself: > > #if OPENSSL_VERSION_NUMBER < 0x10100000L > #define X509_up_ref(x) (CRYPTO_add(&x->references, 1, CRYPTO_LOCK_X509)) > #endif > > Which means that interestingly enough adding these to 1.0.x would break > my code and similar code elsewhere. > > So on the whole forward-compatibility macros don't fully address the > problem, and may do as much harm as good. > > I think that applications porting to 1.1.0 can and should implement > their own macros against a stable 1.0.x API that we don't change > at the last minute. Providing your own forward-compatible glue > is easy enough... > Perhaps someone from the community could contribute a (separately maintained) compatibility layer to provide the relevant macros? Matt From rt at openssl.org Mon Jan 11 19:47:11 2016 From: rt at openssl.org (Kurt Roeckx via RT) Date: Mon, 11 Jan 2016 19:47:11 +0000 Subject: [openssl-dev] [openssl.org #4151] [PATCH] Function pop_info in crypto/mem_dbg.c returns a dangling pointer In-Reply-To: <20160111194707.GA14119@roeckx.be> References: <20160111194707.GA14119@roeckx.be> Message-ID: The patch has been applied. Kurt From lutz at lutz-jaenicke.de Mon Jan 11 20:25:35 2016 From: lutz at lutz-jaenicke.de (=?UTF-8?Q?Lutz_J=c3=a4nicke?=) Date: Mon, 11 Jan 2016 21:25:35 +0100 Subject: [openssl-dev] [openssl-users] Do you need EGD support? In-Reply-To: References: <11d84bf7c4d847a0b9e03f9a3ea16b44@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <56940FBF.8040603@lutz-jaenicke.de> On 11.01.2016 17:02, Scott Neugroschl wrote: > > Will you still support PRNGD? I need PRNGD, as I?m on a platform > without a built-in random device or cpu instructions. > PRNGD is a direct replacement for EGD, so if the interface to EGD is removed from OpenSSL, PRNGD stops to work for it as well. Best regards, Lutz > > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *Salz, Rich > *Sent:* Monday, January 11, 2016 7:06 AM > *To:* openssl-dev at openssl.org; openssl-users at openssl.org > *Subject:* [openssl-users] Do you need EGD support? > > > > We are considering removing EGD support in 1.1 If your platform still > needs it, please reply soon. > > > > -- > > Senior Architect, Akamai Technologies > > IM: richsalz at jabber.at Twitter: RichSalz > > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Jan 11 20:32:42 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 11 Jan 2016 20:32:42 +0000 Subject: [openssl-dev] [openssl-users] Do you need EGD support? In-Reply-To: <56940FBF.8040603@lutz-jaenicke.de> References: <11d84bf7c4d847a0b9e03f9a3ea16b44@usma1ex-dag1mb1.msg.corp.akamai.com> <56940FBF.8040603@lutz-jaenicke.de> Message-ID: >>Will you still support PRNGD?? I need PRNGD, as I?m on a platform without a built-in random device or cpu instructions. > PRNGD is a direct replacement for EGD, so if the interface to EGD is removed from OpenSSL, PRNGD stops to work for it as well. Thanks. That means we should not remove it right away. (Although perhaps we need only use it in the library, not the command-line?) From lutz at lutz-jaenicke.de Mon Jan 11 21:12:54 2016 From: lutz at lutz-jaenicke.de (=?UTF-8?Q?Lutz_J=c3=a4nicke?=) Date: Mon, 11 Jan 2016 22:12:54 +0100 Subject: [openssl-dev] [openssl-users] Do you need EGD support? In-Reply-To: References: <11d84bf7c4d847a0b9e03f9a3ea16b44@usma1ex-dag1mb1.msg.corp.akamai.com> <56940FBF.8040603@lutz-jaenicke.de> Message-ID: <56941AD6.7030401@lutz-jaenicke.de> On 11.01.2016 21:32, Salz, Rich wrote: >>> Will you still support PRNGD? I need PRNGD, as I?m on a platform without a built-in random device or cpu instructions. >> PRNGD is a direct replacement for EGD, so if the interface to EGD is removed from OpenSSL, PRNGD stops to work for it as well. > Thanks. That means we should not remove it right away. (Although perhaps we need only use it in the library, not the command-line?) Removing it from the command line tools would make the apps with random number requirements useless... Best regards, Lutz From rt at openssl.org Mon Jan 11 23:58:35 2016 From: rt at openssl.org (Ole Tange via RT) Date: Mon, 11 Jan 2016 23:58:35 +0000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: References: Message-ID: 1 GB works as expected: $ openssl rand 1000000000 | wc -c 1000000000 But 10 GB does not: $ apps/openssl rand 10000000000 | wc -c 1410065408 2 GB +1 is also bad: $ openssl rand 2147483649 | wc -c rand: Use -help for summary. 0 2 GB -1 is good: $ apps/openssl rand 2147483647 | wc -c 2147483647 It seems the counter (num in rand.c) is a 32-bit int. These days it should at least be 64-bit. In any case there should be a decent error message if the number is out of the supported range. I am a bit worried when I see C-beginner mistakes like this in a security suite: When using sscanf on data you have not produced yourself, you should always assume they will be bigger that your largest buffer/variable and deal correctly with that. Tested on: openssl-1.1.0-pre1 git-6ac11bd0b /Ole _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Jan 11 23:58:36 2016 From: rt at openssl.org (=?UTF-8?B?SmFuIMW9w6Fr?= via RT) Date: Mon, 11 Jan 2016 23:58:36 +0000 Subject: [openssl-dev] [openssl.org #4228] Feature request: Support AEAD ciphers in enc app In-Reply-To: References: Message-ID: Is there any particiular reason, why AEAD ciphers are not supported in the enc app? https://github.com/openssl/openssl/blob/700b4a4/apps/enc.c#L294 I have implemented it as a small part of my Master thesis, maybe I could polish it and submit a PR. Regards, Jan Zak -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Jan 11 23:58:37 2016 From: rt at openssl.org (Gomes, Robert via RT) Date: Mon, 11 Jan 2016 23:58:37 +0000 Subject: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue... In-Reply-To: <0282ac07112643ff8f6275bab024a048@USRIPVDMAIL3.gtk.gtech.com> References: <0282ac07112643ff8f6275bab024a048@USRIPVDMAIL3.gtk.gtech.com> Message-ID: Hi, I am attempting to build OpenSSL 1.0.2e on AIX and I'm seeing an issue with the "stvx" assembler instruction in the sha256p8-ppc.s module. I have built prior version OpenSSL packages on AIX without issue until now (prior was 1.0.1c), and I haven't varied the steps I typically use. Specifics are: AIX: 5200-08 ./Configure threads aix64-cc -no-mdc2 -no-idea -no-rc5 make depend (works ok) make (gets the following errors): cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q64 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM -c -o sha256p8-ppc.o sha256p8-ppc.s Assembler: sha256p8-ppc.s: line 11: invalid opcode or pseudo-op sha256p8-ppc.s: line 14: invalid opcode or pseudo-op sha256p8-ppc.s: line 16: invalid opcode or pseudo-op sha256p8-ppc.s: line 18: invalid opcode or pseudo-op sha256p8-ppc.s: line 20: invalid opcode or pseudo-op sha256p8-ppc.s: line 22: invalid opcode or pseudo-op sha256p8-ppc.s: line 24: invalid opcode or pseudo-op sha256p8-ppc.s: line 26: invalid opcode or pseudo-op sha256p8-ppc.s: line 28: invalid opcode or pseudo-op sha256p8-ppc.s: line 30: invalid opcode or pseudo-op . . . similar diagnostics . . . sha256p8-ppc.s: line 760: invalid opcode or pseudo-op sha256p8-ppc.s: line 762: invalid opcode or pseudo-op sha256p8-ppc.s: line 764: invalid opcode or pseudo-op sha256p8-ppc.s: line 766: invalid opcode or pseudo-op sha256p8-ppc.s: line 767: invalid opcode or pseudo-op make: The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 1. Stop. CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC and/or its subsidiaries and may contain proprietary, confidential or trade secret information. This message is intended solely for the use of the addressee. If you are not the intended recipient and have received this message in error, please delete this message from your system. Any unauthorized reading, distribution, copying, or other use of this message or its attachments is strictly prohibited. -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Jan 12 00:00:09 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 12 Jan 2016 00:00:09 +0000 Subject: [openssl-dev] [openssl.org #4228] Feature request: Support AEAD ciphers in enc app In-Reply-To: References: Message-ID: > I have implemented it as a small part of my Master thesis, maybe I could > polish it and submit a PR. Please do this. From rt at openssl.org Tue Jan 12 00:01:29 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 12 Jan 2016 00:01:29 +0000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: References: Message-ID: > I am a bit worried when I see C-beginner mistakes like this in a security suite: > When using sscanf on data you have not produced yourself, you should > always assume they will be bigger that your largest buffer/variable and deal > correctly with that. That's a bit of an exaggeration here. It's not network data coming in from somewhere else, it's a number typed on the command line in a local program. From openssl-users at dukhovni.org Tue Jan 12 00:11:31 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 11 Jan 2016 19:11:31 -0500 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: References: Message-ID: > On Jan 11, 2016, at 7:01 PM, Salz, Rich via RT wrote: > >> I am a bit worried when I see C-beginner mistakes like this in a security suite: >> When using sscanf on data you have not produced yourself, you should >> always assume they will be bigger that your largest buffer/variable and deal >> correctly with that. > > That's a bit of an exaggeration here. It's not network data coming in from somewhere else, it's a number typed on the command line in a local program. And, in new code, we do try to do better, this is from s_client.c in master used to parse decimal integers 0..255, but deals with overflow/underflow to ensure that we get exactly what the user typed. Similar code could be used to parse the requested byte count for rand(1). Not necessarily an urgent priority, but something we should get to at some point, so I'd keep the ticket open, at low priority. static ossl_ssize_t checked_uint8(const char **inptr, void *out) { uint8_t *result = (uint8_t *)out; const char *in = *inptr; char *endp; long v; int e; save_errno(); v = strtol(in, &endp, 10); e = restore_errno(); if (((v == LONG_MIN || v == LONG_MAX) && e == ERANGE) || endp == in || !isspace(*endp) || v != (*result = (uint8_t) v)) { return -1; } for (in = endp; isspace(*in); ++in) continue; *inptr = in; return 1; } -- Viktor. From rt at openssl.org Tue Jan 12 00:11:36 2016 From: rt at openssl.org (Viktor Dukhovni via RT) Date: Tue, 12 Jan 2016 00:11:36 +0000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: References: Message-ID: > On Jan 11, 2016, at 7:01 PM, Salz, Rich via RT wrote: > >> I am a bit worried when I see C-beginner mistakes like this in a security suite: >> When using sscanf on data you have not produced yourself, you should >> always assume they will be bigger that your largest buffer/variable and deal >> correctly with that. > > That's a bit of an exaggeration here. It's not network data coming in from somewhere else, it's a number typed on the command line in a local program. And, in new code, we do try to do better, this is from s_client.c in master used to parse decimal integers 0..255, but deals with overflow/underflow to ensure that we get exactly what the user typed. Similar code could be used to parse the requested byte count for rand(1). Not necessarily an urgent priority, but something we should get to at some point, so I'd keep the ticket open, at low priority. static ossl_ssize_t checked_uint8(const char **inptr, void *out) { uint8_t *result = (uint8_t *)out; const char *in = *inptr; char *endp; long v; int e; save_errno(); v = strtol(in, &endp, 10); e = restore_errno(); if (((v == LONG_MIN || v == LONG_MAX) && e == ERANGE) || endp == in || !isspace(*endp) || v != (*result = (uint8_t) v)) { return -1; } for (in = endp; isspace(*in); ++in) continue; *inptr = in; return 1; } -- Viktor. From rt at openssl.org Tue Jan 12 00:13:56 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 12 Jan 2016 00:13:56 +0000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: <047ac1afe9d1444cbfd85300f1218cf5@usma1ex-dag1mb1.msg.corp.akamai.com> References: <047ac1afe9d1444cbfd85300f1218cf5@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: And also opt_int and opt_long in apps/opt.c are useful. From rt at openssl.org Tue Jan 12 03:36:59 2016 From: rt at openssl.org (Kaduk, Ben via RT) Date: Tue, 12 Jan 2016 03:36:59 +0000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: <569474D7.9070504@akamai.com> References: <569474D7.9070504@akamai.com> Message-ID: On 01/11/2016 06:01 PM, Salz, Rich via RT wrote: >> I am a bit worried when I see C-beginner mistakes like this in a security suite: >> When using sscanf on data you have not produced yourself, you should >> always assume they will be bigger that your largest buffer/variable and deal >> correctly with that. > That's a bit of an exaggeration here. It's not network data coming in from somewhere else, it's a number typed on the command line in a local program. > There's also the part where asking 'openssl rand' for gigabytes of data is not necessarily a good idea -- I believe in the default configuration on unix, it ends up reading 32 bytes from /dev/random and using that to seed EAY's md_rand.c scheme, which is not exactly a state-of-the-art CSPRNG these days... From rt at openssl.org Tue Jan 12 03:56:58 2016 From: rt at openssl.org (Ole Tange via RT) Date: Tue, 12 Jan 2016 03:56:58 +0000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: References: <569474D7.9070504@akamai.com> Message-ID: On Tue, Jan 12, 2016 at 4:36 AM, Kaduk, Ben via RT wrote: > On 01/11/2016 06:01 PM, Salz, Rich via RT wrote: >>> I am a bit worried when I see C-beginner mistakes like this in a security suite: >>> When using sscanf on data you have not produced yourself, you should >>> always assume they will be bigger that your largest buffer/variable and deal >>> correctly with that. >> That's a bit of an exaggeration here. It's not network data coming in from somewhere else, it's a number typed on the command line in a local program. The worry is not about this particular case (where it does not seem to be possible to abuse), but as a general observation: If the rest of the code has the same quality, then we will be screwed. > There's also the part where asking 'openssl rand' for gigabytes of data > is not necessarily a good idea -- I believe in the default configuration > on unix, it ends up reading 32 bytes from /dev/random and using that to > seed EAY's md_rand.c scheme, which is not exactly a state-of-the-art > CSPRNG these days... We do not know what they will be using these data for (in my case a user wanted it for overwriting a harddrive, so the quality mattered less than the speed). But if it is unsafe for generating GB's of data based on a 32-byte seed, then by all means read another 32-byte seed now and then (but please do it from /dev/urandom: http://www.2uo.de/myths-about-urandom/). /Ole From paul.dale at oracle.com Tue Jan 12 04:01:50 2016 From: paul.dale at oracle.com (Paul Dale) Date: Tue, 12 Jan 2016 14:01:50 +1000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: References: <569474D7.9070504@akamai.com> Message-ID: <2830155.lzPakPjRS7@acid> On Tue, 12 Jan 2016 03:36:59 AM Kaduk, Ben via RT wrote: > There's also the part where asking 'openssl rand' for gigabytes of data > is not necessarily a good idea -- I believe in the default configuration > on unix, it ends up reading 32 bytes from /dev/random and using that to > seed EAY's md_rand.c scheme, which is not exactly a state-of-the-art > CSPRNG these days... This matches my understanding, although I thought these bytes would be read from /dev/urandom first. The unwritten but implied part is that, in the default configuration, the deterministic generator is never reseeded -- those 32 bytes are all the entropy it will ever get. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Jan 12 04:02:11 2016 From: rt at openssl.org (paul.dale@oracle.com via RT) Date: Tue, 12 Jan 2016 04:02:11 +0000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: <2830155.lzPakPjRS7@acid> References: <569474D7.9070504@akamai.com> <2830155.lzPakPjRS7@acid> Message-ID: On Tue, 12 Jan 2016 03:36:59 AM Kaduk, Ben via RT wrote: > There's also the part where asking 'openssl rand' for gigabytes of data > is not necessarily a good idea -- I believe in the default configuration > on unix, it ends up reading 32 bytes from /dev/random and using that to > seed EAY's md_rand.c scheme, which is not exactly a state-of-the-art > CSPRNG these days... This matches my understanding, although I thought these bytes would be read from /dev/urandom first. The unwritten but implied part is that, in the default configuration, the deterministic generator is never reseeded -- those 32 bytes are all the entropy it will ever get. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From rt at openssl.org Tue Jan 12 04:06:37 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 12 Jan 2016 04:06:37 +0000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: <6c083a2ddb11447787a6a722e0211688@usma1ex-dag1mb1.msg.corp.akamai.com> References: <569474D7.9070504@akamai.com> <6c083a2ddb11447787a6a722e0211688@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > The worry is not about this particular case (where it does not seem to be > possible to abuse), but as a general observation: If the rest of the code has > the same quality, then we will be screwed. Shrug. We do the best we can. We try to do a good job. Almost everyone would agree that the code is getting better. From rt at openssl.org Tue Jan 12 06:02:04 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 12 Jan 2016 06:02:04 +0000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: References: Message-ID: Fixed in bd4850df648bee9d8e0595b7e1147266e6f55a3e Strict range-checking was added to all app number-parsing. It was mostly already all there (except for, sigh, rand) but range-checking was not done. Now it is. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From doctor at doctor.nl2k.ab.ca Tue Jan 12 08:33:58 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 12 Jan 2016 01:33:58 -0700 Subject: [openssl-dev] Still seeing errors in Openssl 1.1 pre In-Reply-To: <84e3e4215ccd4cb8a9bf60fcb17a93d9@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160111165227.GA28108@doctor.nl2k.ab.ca> <034cdaa2fad245ec9aa340ec5f08752a@usma1ex-dag1mb1.msg.corp.akamai.com> <20160111173811.GA6578@doctor.nl2k.ab.ca> <84e3e4215ccd4cb8a9bf60fcb17a93d9@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160112083358.GA23320@doctor.nl2k.ab.ca> On Mon, Jan 11, 2016 at 05:40:53PM +0000, Salz, Rich wrote: > > Not yet Rich. > > > > Please repost. > > Steve fixed it already :) So the next snapshot won't fail for this. And we get jpaketest.c: In function `main': jpaketest.c:120: warning: implicit declaration of function `CRYPTO_set_mem_debug_functions' jpaketest.c:121: parse error before "CRYPTO_mem_ctrl" *** Error code 1 Stop. *** Error code 1 Stop. SNAP-20160112 > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From rt at openssl.org Tue Jan 12 11:35:14 2016 From: rt at openssl.org (Ole Tange via RT) Date: Tue, 12 Jan 2016 11:35:14 +0000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: References: Message-ID: On Tue, Jan 12, 2016 at 7:02 AM, Rich Salz via RT wrote: > Fixed in bd4850df648bee9d8e0595b7e1147266e6f55a3e Great to see. May I suggest the bug also becomes a wish for support for > 2GB numbers, as that is what the user originally wanted? /Ole From openssl-users at dukhovni.org Tue Jan 12 15:58:48 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 12 Jan 2016 10:58:48 -0500 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: References: Message-ID: <6B8E2284-91E5-4532-8C00-005FCE823299@dukhovni.org> > On Jan 12, 2016, at 6:35 AM, Ole Tange via RT wrote: > > On Tue, Jan 12, 2016 at 7:02 AM, Rich Salz via RT wrote: >> Fixed in bd4850df648bee9d8e0595b7e1147266e6f55a3e > > Great to see. > > May I suggest the bug also becomes a wish for support for > 2GB > numbers, as that is what the user originally wanted? key=$(openssl rand -hex 16) iv=$(openssl rand -hex 16) cat /dev/zero | openssl enc -aes-128-cbc -K $key -iv $iv is a better way to produce a random stream of arbitrary length, it is also hardware accelerated (AESNI) on many systems. -- -- Viktor. From rt at openssl.org Tue Jan 12 15:58:59 2016 From: rt at openssl.org (Viktor Dukhovni via RT) Date: Tue, 12 Jan 2016 15:58:59 +0000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: <6B8E2284-91E5-4532-8C00-005FCE823299@dukhovni.org> References: <6B8E2284-91E5-4532-8C00-005FCE823299@dukhovni.org> Message-ID: > On Jan 12, 2016, at 6:35 AM, Ole Tange via RT wrote: > > On Tue, Jan 12, 2016 at 7:02 AM, Rich Salz via RT wrote: >> Fixed in bd4850df648bee9d8e0595b7e1147266e6f55a3e > > Great to see. > > May I suggest the bug also becomes a wish for support for > 2GB > numbers, as that is what the user originally wanted? key=$(openssl rand -hex 16) iv=$(openssl rand -hex 16) cat /dev/zero | openssl enc -aes-128-cbc -K $key -iv $iv is a better way to produce a random stream of arbitrary length, it is also hardware accelerated (AESNI) on many systems. -- -- Viktor. From rsalz at akamai.com Tue Jan 12 17:05:56 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 12 Jan 2016 17:05:56 +0000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: References: Message-ID: <9710aba8b5a7443ba720946bc109944f@usma1ex-dag1mb1.msg.corp.akamai.com> > May I suggest the bug also becomes a wish for support for > 2GB numbers, > as that is what the user originally wanted? Unlikely to happen in 1.1 because of portability issues. Call it multiple times or, better, write a small program to generate a PRNG stream. From rt at openssl.org Tue Jan 12 17:06:02 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 12 Jan 2016 17:06:02 +0000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: <9710aba8b5a7443ba720946bc109944f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <9710aba8b5a7443ba720946bc109944f@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > May I suggest the bug also becomes a wish for support for > 2GB numbers, > as that is what the user originally wanted? Unlikely to happen in 1.1 because of portability issues. Call it multiple times or, better, write a small program to generate a PRNG stream. From rt at openssl.org Tue Jan 12 18:26:53 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 12 Jan 2016 18:26:53 +0000 Subject: [openssl-dev] [openssl.org #4117] [PATCH] Remove useless locking code In-Reply-To: <20151031130932.GA13588@kronk.local> References: <20151031130932.GA13588@kronk.local> Message-ID: commit done awhile ago. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From uri at ll.mit.edu Tue Jan 12 18:24:26 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 12 Jan 2016 18:24:26 +0000 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: <20151210215657.GA7104@openssl.org> References: <20151210.093931.1997199079828500981.levitte@openssl.org> <20151210173244.GA938@openssl.org> <20151210215657.GA7104@openssl.org> Message-ID: On 12/10/15, 16:56 , "openssl-dev on behalf of Dr. Stephen Henson" wrote: >On Thu, Dec 10, 2015, Blumenthal, Uri - 0553 - MITLL wrote: >... > >> >Temporary fix is to set the second argument in EVP_PKEY_CTX_new to NULL >> >in pkeyutl.c >> >> With your proposed (temporary) fix, the signature both generated and >> verified successfully (see below). Could I ask to push this fix to the >> master, and maybe/hopefully to 1_0_2 branch? >> > >As I indicated the fix I suggested it temporary. Sometimes a user will >want >that behaviour so we'd need a new command line option indicating the >private >key engine only. I?ve submitted a PR that does what you suggested, and has been reviewed favorable (thanks, R$, :-). When could it be merged? (So it has a chance to percolate down to the actual distros, and I can return to running openssl from a standard build that somebody else maintains, rather than my own github clone :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From rt at openssl.org Tue Jan 12 20:41:37 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 12 Jan 2016 20:41:37 +0000 Subject: [openssl-dev] [openssl.org #2485] Heap walking in RAND_poll causes deadlock in process on Windows Server 2008 R2 (x64) that uses libCurl, OpenSSL and ADO In-Reply-To: References: Message-ID: See https://github.com/openssl/openssl/pull/512 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Jan 12 20:46:38 2016 From: rt at openssl.org (Kaduk, Ben via RT) Date: Tue, 12 Jan 2016 20:46:38 +0000 Subject: [openssl-dev] [openssl.org #4230] apps/speed.c does not handle ghash in the no-SIGALRM case In-Reply-To: <56956629.50300@akamai.com> References: <56956629.50300@akamai.com> Message-ID: It looks like in the #ifndef SIGALRM case, c[D_GHASH][0] is set, but not c[D_GHASH][i] for larger i. (Where is the no-SIGALRM code used?) _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Jan 13 00:22:01 2016 From: rt at openssl.org (Ole Tange via RT) Date: Wed, 13 Jan 2016 00:22:01 +0000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: References: <6B8E2284-91E5-4532-8C00-005FCE823299@dukhovni.org> Message-ID: On Tue, Jan 12, 2016 at 4:58 PM, Viktor Dukhovni via RT wrote: > >> On Jan 12, 2016, at 6:35 AM, Ole Tange via RT wrote: >> >> May I suggest the bug also becomes a wish for support for > 2GB >> numbers, as that is what the user originally wanted? > > key=$(openssl rand -hex 16) > iv=$(openssl rand -hex 16) > cat /dev/zero | openssl enc -aes-128-cbc -K $key -iv $iv > > is a better way to produce a random stream of arbitrary length, > it is also hardware accelerated (AESNI) on many systems. Great. But the normal user does not know this, and it is so complex that even an advanced user like me will have to look it up every time. Is there any reason why the above is not run instead of what `openssl rand` runs today? In other words: Why not change `openssl rand` to run what you would recommend people run anyway? /Ole From rt at openssl.org Wed Jan 13 00:27:22 2016 From: rt at openssl.org (Ole Tange via RT) Date: Wed, 13 Jan 2016 00:27:22 +0000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: References: <9710aba8b5a7443ba720946bc109944f@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: On Tue, Jan 12, 2016 at 6:06 PM, Salz, Rich via RT wrote: >> May I suggest the bug also becomes a wish for support for > 2GB numbers, >> as that is what the user originally wanted? > > Unlikely to happen in 1.1 because of portability issues. > Call it multiple times or, better, write a small program to generate a PRNG stream. Great. But the normal user does not know this. Why not just use `openssl rand` as the wrapper that does the above? No need to change the interface for the functions - simply put the wrapper in `openssl rand` with a counter and then generate 2 GB at a time (like now) until enough has been generated. In other words: Why not change `openssl rand` to run what you would recommend people run anyway? /Ole From openssl-users at dukhovni.org Wed Jan 13 00:32:39 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 13 Jan 2016 00:32:39 +0000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: References: <6B8E2284-91E5-4532-8C00-005FCE823299@dukhovni.org> Message-ID: <20160113003239.GI18704@mournblade.imrryr.org> On Wed, Jan 13, 2016 at 12:22:01AM +0000, Ole Tange via RT wrote: > > key=$(openssl rand -hex 16) > > iv=$(openssl rand -hex 16) > > cat /dev/zero | openssl enc -aes-128-cbc -K $key -iv $iv > > > > is a better way to produce a random stream of arbitrary length, > > it is also hardware accelerated (AESNI) on many systems. > > Great. But the normal user does not know this, and it is so complex > that even an advanced user like me will have to look it up every time. > Is there any reason why the above is not run instead of what `openssl > rand` runs today? > > In other words: Why not change `openssl rand` to run what you would > recommend people run anyway? Because "openssl rand" is not at present a stream generator, and was never intended to be one. It is also substantially slower than the above. There are better crypto-random stream generators like SHAKE256, but it is faily new, and not yet available in OpenSSL. In most cases, just overwriting a disk with zeros is as good as with any other pattern. -- Viktor. From paul.dale at oracle.com Wed Jan 13 01:00:09 2016 From: paul.dale at oracle.com (Paul Dale) Date: Wed, 13 Jan 2016 11:00:09 +1000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: <20160113003239.GI18704@mournblade.imrryr.org> References: <20160113003239.GI18704@mournblade.imrryr.org> Message-ID: <1613354.bDXbD2iLFD@acid> On Wed, 13 Jan 2016 12:32:39 AM Viktor Dukhovni wrote: > In most cases, just overwriting a disk with zeros is as good as > with any other pattern. Peter Gutmann published a paper showing that it is possible to read zeroed bits with the right equipment: https://www.usenix.org/legacy/publications/library/proceedings/sec96/full_papers/gutmann/index.html I remember a report not long after the original paper was published where the writer zeroed a drive and went to several data recovery companies who couldn't retrieve anything (sorry, can't find the reference). Also note that this technique doesn't work on newer drives: http://seclists.org/bugtraq/2005/Jul/464 If you are protecting against governments or extremely well equipped organisations, a zeroed disc might be recoverable with a large investment of time and effort. If you are in this case and what you are protecting is worth that much, follow use one of the approved secure disc erasure methods -- several times. - Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From stevenx.linsell at intel.com Wed Jan 13 02:01:48 2016 From: stevenx.linsell at intel.com (Linsell, StevenX) Date: Wed, 13 Jan 2016 02:01:48 +0000 Subject: [openssl-dev] ec_key_method_st defined only in ec_lcl.h - master branch Message-ID: I was just moving an OpenSSL Engine over to use the restructured ECDH and ECDSA methods on the master branch where structures ecdsa_method (ECDSA_METHOD)and ecdh_method (ECDH_METHOD) have been amalgamated into ec_key_method_st (EC_KEY_METHOD). Traditionally there has been what could be considered a 'bug' where the ecdh_method and ecdsa_method structures are defined within private headers ech_locl.h and ecs_locl.h respectively instead of the public headers. This forces an OpenSSL engine that wants to provide its own implementations to include the local header files, and hardcode an include path to them, as they don't exist in the public headers directory. Following Steve's ec_key_method_st changes the data structure we need to now use for our own implementations remains only defined in ec_lcl.h and not part of the public interface. For mainline OpenSSL 1.1.0 there has been a focus on making many of the data structures opaque which shouldn't have been part of the public interface. I was wondering whether it was a conscious decision on Steve or the teams part to keep the ec_key_method_st only defined in the local header file, because of trying to keep data structures opaque, or whether it was just not considered as part of the tidyup? I was interested to know if it was something I could change, and raise a pull request for, or whether I was wasting my time as it is intentional? -- Steve Linsell Intel Shannon DCG/CID Software Development Team Stevenx.Linsell at intel.com -------------------------------------------------------------- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jan 13 02:07:04 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 13 Jan 2016 02:07:04 +0000 Subject: [openssl-dev] ec_key_method_st defined only in ec_lcl.h - master branch In-Reply-To: References: Message-ID: <188adb69b98d4ebfa79fbd8458bdc7fb@usma1ex-dag1mb1.msg.corp.akamai.com> We will be fixing that with new accessors and documentation to get/set method. Hopefully it will be in the next alpha release. From kurt at roeckx.be Wed Jan 13 06:39:48 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 13 Jan 2016 07:39:48 +0100 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: <1613354.bDXbD2iLFD@acid> References: <20160113003239.GI18704@mournblade.imrryr.org> <1613354.bDXbD2iLFD@acid> Message-ID: <20160113063947.GA5087@roeckx.be> On Wed, Jan 13, 2016 at 11:00:09AM +1000, Paul Dale wrote: > On Wed, 13 Jan 2016 12:32:39 AM Viktor Dukhovni wrote: > > In most cases, just overwriting a disk with zeros is as good as > > with any other pattern. > > Peter Gutmann published a paper showing that it is possible to read zeroed bits with the right equipment: https://www.usenix.org/legacy/publications/library/proceedings/sec96/full_papers/gutmann/index.html > > I remember a report not long after the original paper was published where the writer zeroed a drive and went to several data recovery companies who couldn't retrieve anything (sorry, can't find the reference). > > Also note that this technique doesn't work on newer drives: http://seclists.org/bugtraq/2005/Jul/464 > > > If you are protecting against governments or extremely well equipped organisations, a zeroed disc might be recoverable with a large investment of time and effort. If you are in this case and what you are protecting is worth that much, follow use one of the approved secure disc erasure methods -- several times. There are various ways to do that, including: http://www.dban.org/ https://wiki.archlinux.org/index.php/Securely_wipe_disk http://www.killdisk.com/ Kurt From doctor at doctor.nl2k.ab.ca Wed Jan 13 08:32:41 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 13 Jan 2016 01:32:41 -0700 Subject: [openssl-dev] Still seeing errors in Openssl 1.1 pre In-Reply-To: <20160112083358.GA23320@doctor.nl2k.ab.ca> References: <20160111165227.GA28108@doctor.nl2k.ab.ca> <034cdaa2fad245ec9aa340ec5f08752a@usma1ex-dag1mb1.msg.corp.akamai.com> <20160111173811.GA6578@doctor.nl2k.ab.ca> <84e3e4215ccd4cb8a9bf60fcb17a93d9@usma1ex-dag1mb1.msg.corp.akamai.com> <20160112083358.GA23320@doctor.nl2k.ab.ca> Message-ID: <20160113083240.GA12874@doctor.nl2k.ab.ca> On Tue, Jan 12, 2016 at 01:33:58AM -0700, The Doctor wrote: > On Mon, Jan 11, 2016 at 05:40:53PM +0000, Salz, Rich wrote: > > > Not yet Rich. > > > > > > Please repost. > > > > Steve fixed it already :) So the next snapshot won't fail for this. > > And we get > > jpaketest.c: In function `main': > jpaketest.c:120: warning: implicit declaration of function `CRYPTO_set_mem_debug_functions' > jpaketest.c:121: parse error before "CRYPTO_mem_ctrl" > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > > SNAP-20160112 Now to add openssl-SNAP-20160113 issues making all in crypto/evp... gcc -I.. -I../.. -I../modes -I../include -I../../include -fPIC -DOPENSSL_PIC - DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDS O_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -m arch=i486 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -D OPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_AS M -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -DECP_ NISTZ256_ASM -c e_rc5.c e_rc5.c:80: parse error before "EVP_RC5_KEY" e_rc5.c:85: warning: return type defaults to `int' e_rc5.c: In function `IMPLEMENT_BLOCK_CIPHER': e_rc5.c:86: storage class specified for parameter `rc5_ctrl' e_rc5.c:86: parse error before '{' token e_rc5.c:86: declaration for parameter `rc5_ctrl' but no such parameter e_rc5.c:98: case label not within a switch statement e_rc5.c:99: case label not within a switch statement e_rc5.c:100: case label not within a switch statement e_rc5.c:101: warning: implicit declaration of function `EVP_C_DATA' e_rc5.c:101: parse error before "EVP_RC5_KEY" e_rc5.c:104: `default' label not within a switch statement e_rc5.c: At top level: e_rc5.c:109: parse error before "default" e_rc5.c: In function `r_32_12_16_init_key': e_rc5.c:117: parse error before "EVP_RC5_KEY" evp_locl.h: At top level: e_rc5.c:116: warning: `r_32_12_16_init_key' defined but not used e_rc5.c:71: warning: `rc5_ctrl' declared `static' but never defined *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. What changed? The last time make && make test passed was openssl-SNAP-20160104 Since then failures are cropping up. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From openssl-users at dukhovni.org Wed Jan 13 09:07:45 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 13 Jan 2016 04:07:45 -0500 Subject: [openssl-dev] Still seeing errors in Openssl 1.1 pre In-Reply-To: <20160113083240.GA12874@doctor.nl2k.ab.ca> References: <20160111165227.GA28108@doctor.nl2k.ab.ca> <034cdaa2fad245ec9aa340ec5f08752a@usma1ex-dag1mb1.msg.corp.akamai.com> <20160111173811.GA6578@doctor.nl2k.ab.ca> <84e3e4215ccd4cb8a9bf60fcb17a93d9@usma1ex-dag1mb1.msg.corp.akamai.com> <20160112083358.GA23320@doctor.nl2k.ab.ca> <20160113083240.GA12874@doctor.nl2k.ab.ca> Message-ID: <7C9192FC-749B-4010-8B30-E925B71C8F41@dukhovni.org> > On Jan 13, 2016, at 3:32 AM, The Doctor wrote: > > gcc -I.. -I../.. -I../modes -I../include -I../../include -fPIC -DOPENSSL_PIC - > DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDS > O_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -m > arch=i486 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -D > OPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_AS > M -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -DECP_ > NISTZ256_ASM -c e_rc5.c RC5 is disabled by default, so this did not get caught. The fix is simple: openssl base64 -d < +# include # include # include "evp_locl.h" # include -- Viktor. From stevenx.linsell at intel.com Wed Jan 13 09:57:24 2016 From: stevenx.linsell at intel.com (Linsell, StevenX) Date: Wed, 13 Jan 2016 09:57:24 +0000 Subject: [openssl-dev] ec_key_method_st defined only in ec_lcl.h - master branch In-Reply-To: References: Message-ID: On 13/01/16 02:07, Rich Salz wrote: > We will be fixing that with new accessors and documentation to get/set method. Hopefully it will be in the next alpha release. Thanks for the heads up Rich. I'll hold off then and keep an eye out for the commits. -- Steve Linsell???????????????????????????????????? Intel Shannon DCG/CID Software Development Team Stevenx.Linsell at intel.com????????????????????????????? -------------------------------------------------------------- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From levitte at openssl.org Wed Jan 13 10:03:10 2016 From: levitte at openssl.org (Richard Levitte) Date: Wed, 13 Jan 2016 11:03:10 +0100 Subject: [openssl-dev] Still seeing errors in Openssl 1.1 pre In-Reply-To: <20160113083240.GA12874@doctor.nl2k.ab.ca> References: <20160111165227.GA28108@doctor.nl2k.ab.ca> <034cdaa2fad245ec9aa340ec5f08752a@usma1ex-dag1mb1.msg.corp.akamai.com> <20160111173811.GA6578@doctor.nl2k.ab.ca> <84e3e4215ccd4cb8a9bf60fcb17a93d9@usma1ex-dag1mb1.msg.corp.akamai.com> <20160112083358.GA23320@doctor.nl2k.ab.ca> <20160113083240.GA12874@doctor.nl2k.ab.ca> Message-ID: <2A6C8980-F094-4003-BA7F-F38AD116F8A9@openssl.org> That one is of particular interest to me, I will have a look later today. Cheers Richard On January 13, 2016 9:32:41 AM GMT+01:00, The Doctor wrote: >On Tue, Jan 12, 2016 at 01:33:58AM -0700, The Doctor wrote: >> On Mon, Jan 11, 2016 at 05:40:53PM +0000, Salz, Rich wrote: >> > > Not yet Rich. >> > > >> > > Please repost. >> > >> > Steve fixed it already :) So the next snapshot won't fail for >this. >> >> And we get >> >> jpaketest.c: In function `main': >> jpaketest.c:120: warning: implicit declaration of function >`CRYPTO_set_mem_debug_functions' >> jpaketest.c:121: parse error before "CRYPTO_mem_ctrl" >> *** Error code 1 >> >> Stop. >> *** Error code 1 >> >> Stop. >> >> SNAP-20160112 > >Now to add openssl-SNAP-20160113 issues > > >making all in crypto/evp... >gcc -I.. -I../.. -I../modes -I../include -I../../include -fPIC >-DOPENSSL_PIC - >DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE >-D_REENTRANT -DDS >O_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS >-fomit-frame-pointer -O2 -m >arch=i486 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE >-DOPENSSL_EXPERIMENTAL_STORE -D >OPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m >-DSHA1_AS >M -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM >-DGHASH_ASM -DECP_ >NISTZ256_ASM -c e_rc5.c >e_rc5.c:80: parse error before "EVP_RC5_KEY" >e_rc5.c:85: warning: return type defaults to `int' >e_rc5.c: In function `IMPLEMENT_BLOCK_CIPHER': >e_rc5.c:86: storage class specified for parameter `rc5_ctrl' >e_rc5.c:86: parse error before '{' token >e_rc5.c:86: declaration for parameter `rc5_ctrl' but no such parameter >e_rc5.c:98: case label not within a switch statement >e_rc5.c:99: case label not within a switch statement >e_rc5.c:100: case label not within a switch statement >e_rc5.c:101: warning: implicit declaration of function `EVP_C_DATA' >e_rc5.c:101: parse error before "EVP_RC5_KEY" >e_rc5.c:104: `default' label not within a switch statement >e_rc5.c: At top level: >e_rc5.c:109: parse error before "default" >e_rc5.c: In function `r_32_12_16_init_key': >e_rc5.c:117: parse error before "EVP_RC5_KEY" >evp_locl.h: At top level: >e_rc5.c:116: warning: `r_32_12_16_init_key' defined but not used >e_rc5.c:71: warning: `rc5_ctrl' declared `static' but never defined >*** Error code 1 > >Stop. >*** Error code 1 > >Stop. >*** Error code 1 > >Stop. > >What changed? > >The last time make && make test passed was openssl-SNAP-20160104 > >Since then failures are cropping up. -- levitte at openssl.org From hkario at redhat.com Wed Jan 13 13:28:16 2016 From: hkario at redhat.com (Hubert Kario) Date: Wed, 13 Jan 2016 14:28:16 +0100 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: References: <6B8E2284-91E5-4532-8C00-005FCE823299@dukhovni.org> Message-ID: <2218450.dTgliEWeiC@pintsize.usersys.redhat.com> On Tuesday 12 January 2016 15:58:59 Viktor Dukhovni via RT wrote: > > On Jan 12, 2016, at 6:35 AM, Ole Tange via RT > > wrote: > > > > On Tue, Jan 12, 2016 at 7:02 AM, Rich Salz via RT wrote: > >> Fixed in bd4850df648bee9d8e0595b7e1147266e6f55a3e > > > > Great to see. > > > > May I suggest the bug also becomes a wish for support for > 2GB > > numbers, as that is what the user originally wanted? > > key=$(openssl rand -hex 16) > iv=$(openssl rand -hex 16) > cat /dev/zero | openssl enc -aes-128-cbc -K $key -iv $iv > > is a better way to produce a random stream of arbitrary length, > it is also hardware accelerated (AESNI) on many systems. I would upgrade that to aes-128-ctr, but it's not bad per-se -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rt at openssl.org Wed Jan 13 13:28:41 2016 From: rt at openssl.org (Hubert Kario via RT) Date: Wed, 13 Jan 2016 13:28:41 +0000 Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not produce 10000000000 random bytes In-Reply-To: <2218450.dTgliEWeiC@pintsize.usersys.redhat.com> References: <6B8E2284-91E5-4532-8C00-005FCE823299@dukhovni.org> <2218450.dTgliEWeiC@pintsize.usersys.redhat.com> Message-ID: On Tuesday 12 January 2016 15:58:59 Viktor Dukhovni via RT wrote: > > On Jan 12, 2016, at 6:35 AM, Ole Tange via RT > > wrote: > > > > On Tue, Jan 12, 2016 at 7:02 AM, Rich Salz via RT wrote: > >> Fixed in bd4850df648bee9d8e0595b7e1147266e6f55a3e > > > > Great to see. > > > > May I suggest the bug also becomes a wish for support for > 2GB > > numbers, as that is what the user originally wanted? > > key=$(openssl rand -hex 16) > iv=$(openssl rand -hex 16) > cat /dev/zero | openssl enc -aes-128-cbc -K $key -iv $iv > > is a better way to produce a random stream of arbitrary length, > it is also hardware accelerated (AESNI) on many systems. I would upgrade that to aes-128-ctr, but it's not bad per-se -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Wed Jan 13 14:05:24 2016 From: rt at openssl.org (hu_jin via RT) Date: Wed, 13 Jan 2016 14:05:24 +0000 Subject: [openssl-dev] [openssl.org #4231] bug openssl rc4 overflow In-Reply-To: References: Message-ID: X64?Linux?system?to?compile?the?OpenSSL?bit?X32?setarch i386 ./config -m32overflow?src -------------- next part -------------- A non-text attachment was scrubbed... Name: x32.png Type: application/octet-stream Size: 5751 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: x.zip Type: application/octet-stream Size: 1432 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From paul.l.kehrer at gmail.com Wed Jan 13 14:14:57 2016 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Wed, 13 Jan 2016 08:14:57 -0600 Subject: [openssl-dev] [PATCH] Declare/Implement ASN1_FUNCTIONS for NAME_CONSTRAINTS In-Reply-To: <20160110011351.GA27275@openssl.org> References: <20160110011351.GA27275@openssl.org> Message-ID: I can only plead ignorance. Those functions do indeed do what I need. With that I don't have any direct need for the d2i implementation, although it is still a bit odd for them to be defined on all the other extensions but not NAME_CONSTRAINTS. Thanks for the help! -Paul On January 9, 2016 at 7:14:12 PM, Dr. Stephen Henson (steve at openssl.org) wrote: On Sat, Jan 09, 2016, Paul Kehrer wrote: > The ASN1 functions for NAME_CONSTRAINTS are not declared or implemented in the current OpenSSL releases. This is inconsistent with other extension structs and (I believe) means you either need to declare them yourself or attempt to build NAME_CONSTRAINTS using nconf functions. Below is a patch to current git master that adds support for these functions.? > > If there's a preferred way to test that these macros behave as expected I'll be happy to add the tests to this patch. > Why do you need the i2d/d2i functions? It is possible to encode and decode the extension using X509_get_ext_d2i() and X509_add1_ext_i2d(). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Jan 13 14:29:52 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 13 Jan 2016 14:29:52 +0000 Subject: [openssl-dev] [openssl.org #4231] bug openssl rc4 overflow In-Reply-To: <4d60eedaa173427692383998ed9c3859@usma1ex-dag1mb1.msg.corp.akamai.com> References: <4d60eedaa173427692383998ed9c3859@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: The output of encryption is not a string, it is an array of binary bytes. I don't think there is a bug here. From rt at openssl.org Wed Jan 13 15:16:01 2016 From: rt at openssl.org (hu_jin via RT) Date: Wed, 13 Jan 2016 15:16:01 +0000 Subject: [openssl-dev] =?utf-8?b?6L2s5Y+R77yaIFtvcGVuc3NsLm9yZyAjNDIzMV0g?= =?utf-8?q?bug_openssl_rc4_overflow?= In-Reply-To: References: <4d60eedaa173427692383998ed9c3859@usma1ex-dag1mb1.msg.corp.akamai.com>, rt-4.0.19-15568-1452695392-1830.4231-6-0@openssl.org, 87b6c38c-6bf0-4b72-9d57-c13ffd9210af.hu_jin@microdesktop.com, 0c7c4b30-2a93-4258-9c03-dc7c4d61d039.hu_jin@microdesktop.com Message-ID: ------------------------------------------------------------------????hu_jin ?????2016?1?13?(???) 23:04????openssl-dev ???????[openssl-dev] [openssl.org #4231] bug openssl rc4 overflow------------------------------------------------------------------????hu_jin ?????2016?1?13?(???) 22:46????rt ????openssl-dev ???????[openssl-dev] [openssl.org #4231] bug openssl rc4 overflowx64 system and x32 openssl?x64 system and x64 openssl?------------------------------------------------------------------????Salz, Rich via RT ?????2016?1?13?(???) 22:30????hu_jin ????openssl-dev ????RE: [openssl-dev] [openssl.org #4231] bug openssl rc4 overflowThe?output?of?encryption?is?not?a?string,?it?is?an?array?of?binary?bytes.I?don't?think?there?is?a?bug?here. -------------- next part -------------- A non-text attachment was scrubbed... Name: 12.png Type: application/octet-stream Size: 7955 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 13.png Type: application/octet-stream Size: 7338 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Jan 13 15:16:01 2016 From: rt at openssl.org (hu_jin via RT) Date: Wed, 13 Jan 2016 15:16:01 +0000 Subject: [openssl-dev] =?utf-8?b?562U5aSN77yaIFtvcGVuc3NsLm9yZyAjNDIzMV0g?= =?utf-8?q?bug_openssl_rc4_overflow?= In-Reply-To: <87b6c38c-6bf0-4b72-9d57-c13ffd9210af.hu_jin@microdesktop.com> References: <4d60eedaa173427692383998ed9c3859@usma1ex-dag1mb1.msg.corp.akamai.com>, rt-4.0.19-15568-1452695392-1830.4231-6-0@openssl.org <87b6c38c-6bf0-4b72-9d57-c13ffd9210af.hu_jin@microdesktop.com> Message-ID: x64 system and x32 openssl?x64 system and x64 openssl?------------------------------------------------------------------????Salz, Rich via RT ?????2016?1?13?(???) 22:30????hu_jin ????openssl-dev ????RE: [openssl-dev] [openssl.org #4231] bug openssl rc4 overflowThe?output?of?encryption?is?not?a?string,?it?is?an?array?of?binary?bytes.I?don't?think?there?is?a?bug?here. -------------- next part -------------- A non-text attachment was scrubbed... Name: 12.png Type: application/octet-stream Size: 7955 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 13.png Type: application/octet-stream Size: 7338 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rsalz at akamai.com Wed Jan 13 15:23:51 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 13 Jan 2016 15:23:51 +0000 Subject: [openssl-dev] =?utf-8?b?6L2s5Y+R77yaIFtvcGVuc3NsLm9yZyAjNDIzMV0g?= =?utf-8?q?bug_openssl_rc4_overflow?= In-Reply-To: References: <4d60eedaa173427692383998ed9c3859@usma1ex-dag1mb1.msg.corp.akamai.com>, rt-4.0.19-15568-1452695392-1830.4231-6-0@openssl.org, 87b6c38c-6bf0-4b72-9d57-c13ffd9210af.hu_jin@microdesktop.com, 0c7c4b30-2a93-4258-9c03-dc7c4d61d039.hu_jin@microdesktop.com Message-ID: Are you sure that your application is built with the same -march, etc., flags that the library is built with? From rt at openssl.org Wed Jan 13 15:23:56 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 13 Jan 2016 15:23:56 +0000 Subject: [openssl-dev] =?utf-8?b?6L2s5Y+R77yaIFtvcGVuc3NsLm9yZyAjNDIzMV0g?= =?utf-8?q?bug_openssl_rc4_overflow?= In-Reply-To: References: <4d60eedaa173427692383998ed9c3859@usma1ex-dag1mb1.msg.corp.akamai.com>, rt-4.0.19-15568-1452695392-1830.4231-6-0@openssl.org, 87b6c38c-6bf0-4b72-9d57-c13ffd9210af.hu_jin@microdesktop.com, 0c7c4b30-2a93-4258-9c03-dc7c4d61d039.hu_jin@microdesktop.com Message-ID: Are you sure that your application is built with the same -march, etc., flags that the library is built with? _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Jan 13 16:29:47 2016 From: rt at openssl.org (Claus Assmann via RT) Date: Wed, 13 Jan 2016 16:29:47 +0000 Subject: [openssl-dev] [openssl.org #4232] [cosmetic] s_client.c: double space in usage In-Reply-To: <20160113154017.GA25639@x2.esmtp.org> References: <20160113154017.GA25639@x2.esmtp.org> Message-ID: Not sure whether this is worth reporting via RT... BTW: maybe the entry should state how long the "sleep" is? diff --git a/apps/s_client.c b/apps/s_client.c index 05b626f..08b0dc6 100644 --- a/apps/s_client.c +++ b/apps/s_client.c @@ -666,7 +666,7 @@ OPTIONS s_client_options[] = { "DANE TLSA rrdata presentation form"}, {"reconnect", OPT_RECONNECT, '-', "Drop and re-make the connection with the same Session-ID"}, - {"pause", OPT_PAUSE, '-', "Sleep after each read and write system call"}, + {"pause", OPT_PAUSE, '-', "Sleep after each read and write system call"}, {"showcerts", OPT_SHOWCERTS, '-', "Show all certificates in the chain"}, {"debug", OPT_DEBUG, '-', "Extra output"}, {"msg", OPT_MSG, '-', "Show protocol messages"}, _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Jan 13 16:29:47 2016 From: rt at openssl.org (hu_jin via RT) Date: Wed, 13 Jan 2016 16:29:47 +0000 Subject: [openssl-dev] =?utf-8?b?6L2s5Y+R77yaIOi9rOWPke+8miBbb3BlbnNzbC5v?= =?utf-8?q?rg_=234231=5D_bug_openssl_rc4_overflow?= In-Reply-To: <4ca25cb5-bef5-4796-b0b9-69b3bd52079e.hu_jin@microdesktop.com> References: <4d60eedaa173427692383998ed9c3859@usma1ex-dag1mb1.msg.corp.akamai.com>, 0c7c4b30-2a93-4258-9c03-dc7c4d61d039.hu_jin@microdesktop.com , rt-4.0.19-15568-1452698636-2.4231-6-0@openssl.org <4ca25cb5-bef5-4796-b0b9-69b3bd52079e.hu_jin@microdesktop.com> Message-ID: surex64 system and x32 openssl buildsetarch i386 ./config -m32?0.2 ?makex64 system and x64 openssl build01. make------------------------------------------------------------------????Salz, Rich via RT ?????2016?1?13?(???) 23:24????hu_jin ????openssl-dev ????RE: [openssl-dev] ??? [openssl.org #4231] bug openssl rc4 overflowAre?you?sure?that?your?application?is?built?with?the?same?-march,?etc.,?flags?that?the?library?is?built?with?_______________________________________________openssl-bugs-mod?mailing?listopenssl-bugs-mod at openssl.orghttps://mta.openssl.org/mailman/listinfo/openssl-bugs-mod -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Jan 13 16:40:43 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 13 Jan 2016 16:40:43 +0000 Subject: [openssl-dev] =?utf-8?b?562U5aSN77yaIFtvcGVuc3NsLm9yZyAjNDIzMV0g?= =?utf-8?q?bug_openssl_rc4_overflow?= In-Reply-To: <40c32ca6c37c4d93a7b5997b3bcdd1b6@usma1ex-dag1mb1.msg.corp.akamai.com> References: <4d60eedaa173427692383998ed9c3859@usma1ex-dag1mb1.msg.corp.akamai.com>, rt-4.0.19-15568-1452695392-1830.4231-6-0@openssl.org <87b6c38c-6bf0-4b72-9d57-c13ffd9210af.hu_jin@microdesktop.com> <40c32ca6c37c4d93a7b5997b3bcdd1b6@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: There is something unusual in your local environment. ; cat a.c #include #include #include int main() { char code[64]={0}; char outbuffer[64]; int codelen = sizeof (code); RC4_KEY rc4_key; strcpy(code,"This is secrect"); RC4_set_key(&rc4_key,7,(unsigned char *)"zenraoli"); RC4(&rc4_key,codelen,(unsigned char *)code,outbuffer); memset(code,0,sizeof(code)); RC4_set_key(&rc4_key,7,(unsigned char *)"zenraoli"); RC4(&rc4_key,codelen,outbuffer,(unsigned char *)code); printf("|%s|\n", code); return 0; } ; gcc a.c -lcrypto ; ./a.out |This is secrect| _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Jan 13 17:05:29 2016 From: rt at openssl.org (hu_jin via RT) Date: Wed, 13 Jan 2016 17:05:29 +0000 Subject: [openssl-dev] =?utf-8?b?6L2s5Y+R77yaIOetlOWkje+8miBbb3BlbnNzbC5v?= =?utf-8?q?rg_=234231=5D_bug_openssl_rc4_overflow?= In-Reply-To: <94cf44ae-8f84-4c8a-8bc5-7600987c4d2a.hu_jin@microdesktop.com> References: <4d60eedaa173427692383998ed9c3859@usma1ex-dag1mb1.msg.corp.akamai.com>, rt-4.0.19-15568-1452695392-1830.4231-6-0@openssl.org <87b6c38c-6bf0-4b72-9d57-c13ffd9210af.hu_jin@microdesktop.com> <40c32ca6c37c4d93a7b5997b3bcdd1b6@usma1ex-dag1mb1.msg.corp.akamai.com>, rt-4.0.19-15567-1452703243-462.4231-6-0@openssl.org <94cf44ae-8f84-4c8a-8bc5-7600987c4d2a.hu_jin@microdesktop.com> Message-ID: I?need?the?x64?system?to?run?the?X32?programyour example is?x64?system?to?run?the?x64?programX64?system?running?x64?program?is?correct,?but?the?x64?system?running?X32?program?is?wrongcan you help me?------------------------------------------------------------------????Salz, Rich via RT ?????2016?1?14?(???) 00:40????hu_jin ????openssl-dev ????RE: [openssl-dev] ??? [openssl.org #4231] bug openssl rc4 overflowThere?is?something?unusual?in?your?local?environment.;?cat?a.c#include?#include?#includeint?main(){????char?code[64]={0};????char?outbuffer[64];????int?codelen?=?sizeof?(code);????RC4_KEY?rc4_key;????strcpy(code,"This?is?secrect");????RC4_set_key(&rc4_key,7,(unsigned?char?*)"zenraoli");????RC4(&rc4_key,codelen,(unsigned?char?*)code,outbuffer);????memset(code,0,sizeof(code));????RC4_set_key(&rc4_key,7,(unsigned?char?*)"zenraoli");????RC4(&rc4_key,codelen,outbuffer,(unsigned?char?*)code);????printf("|%s|\n",?code);????return?0;};?gcc?a.c?-lcrypto;?./a.out|This?is?secrect|_______________________________________________openssl-bugs-mod?mailing?listopenssl-bugs-mod at openssl.orghttps://mta.openssl.org/mailman/listinfo/openssl-bugs-mod -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Jan 13 17:43:47 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 13 Jan 2016 17:43:47 +0000 Subject: [openssl-dev] [openssl.org #4231] bug openssl rc4 overflow In-Reply-To: References: Message-ID: This is not a bug, so I am closing it. I suggest you post details on openssl-users and see if anyone can help. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From wrowe at rowe-clan.net Wed Jan 13 18:15:16 2016 From: wrowe at rowe-clan.net (William A Rowe Jr) Date: Wed, 13 Jan 2016 12:15:16 -0600 Subject: [openssl-dev] Out-of-date [ req ] defaults in apps/openssl.cnf? Message-ID: I note that on the 1.0.1q package openssl.cnf, default_bits is still 1024, while it has been updated to 2048 for the 1.0.2e release. Both still include no default_md, and I would expect that should now look like [ req ] default_md = sha256 default_bits = 2048 on both 1.0.1 and 1.0.2 future releases, to conform with the current guidance? Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Jan 13 18:58:14 2016 From: rt at openssl.org (Zak Blacher via RT) Date: Wed, 13 Jan 2016 18:58:14 +0000 Subject: [openssl-dev] [openssl.org #4233] [bug][openssl verify] pre-valid certificate return code inconsistency In-Reply-To: References: Message-ID: Hi folks, I've found an inconsistency in the return status of 'openssl verify'. I've attached a custom dummy ca, and an example certificate. This certificate is valid for some date range in the future. On my redhat machine (openssl 1.0.1e), running openssl verify will return a status code of 2, but in osx (openssl 0.98zg), the return status is 0. In both cases, I correctly see an error 9 in the function output. The behavior of validating an expired certificate returns a status code of 0 on both systems. -Zak *Zak Blacher* Software Engineer Security Infrastructure 206.453.9955 zblacher at linkedin.com linkedin.com/in/zakblacher -------------- next part -------------- A non-text attachment was scrubbed... Name: dates_+10y_to_+20y.pem Type: application/x-x509-ca-cert Size: 2078 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dummy-ca.crt Type: application/x-x509-ca-cert Size: 7581 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From uri at ll.mit.edu Wed Jan 13 19:29:27 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 13 Jan 2016 19:29:27 +0000 Subject: [openssl-dev] pkeyutl does not invoke hash? Message-ID: I?m not sure whether this is a bug (as I suspect ? hence sending to openssl-dev), or a poorly-documented ?feature? (so copying to openssl-users). I am trying to use ?openssl pkeyutl? to digitally sign (and verify) a file. When the file size matches the size of the specified digest (32 bytes for SHA256, 48 bytes for SHA384, etc), everything seems fine: $ openssl pkeyutl -engine pkcs11 -keyform engine -sign -inkey "pkcs11:object=SIGN%20key;object-type=private" -pkeyopt digest:sha384 -out t384.ecdsa.sig -in t384.dat engine "pkcs11" set. PKCS#11 token PIN: $ openssl pkeyutl -engine pkcs11 -keyform engine -verify -pubin -inkey "pkcs11:object=SIGN%20pubkey;object-type=public" -sigfile t384.ecdsa.sig -in t384.dat engine "pkcs11" set. Signature Verified Successfully $ However, if I try to feed it a larger file, it complains regardless of whether I specify a hash-function to digest the file: $ openssl pkeyutl -engine pkcs11 -keyform engine -sign -inkey "pkcs11:object=SIGN%20key;object-type=private" -pkeyopt digest:sha1 -out t2570.ecdsa.sig -in t2570.dat engine "pkcs11" set. PKCS#11 token PIN: Public Key operation error 140735120921424:error:80029001:PKCS11 library:func(41):Cancel:p11_ops.c:61: $ openssl pkeyutl -engine pkcs11 -keyform engine -sign -inkey "pkcs11:object=SIGN%20key;object-type=private" -pkeyopt digest:sha384 -out t2570.ecdsa.sig -in t2570.dat engine "pkcs11" set. PKCS#11 token PIN: Public Key operation error 140735120921424:error:80029001:PKCS11 library:func(41):Cancel:p11_ops.c:61: $ openssl pkeyutl -engine pkcs11 -keyform engine -sign -inkey "pkcs11:object=SIGN%20key;object-type=private" -out t2570.ecdsa.sig -in t2570.dat engine "pkcs11" set. PKCS#11 token PIN: Public Key operation error 140735120921424:error:80029001:PKCS11 library:func(41):Cancel:p11_ops.c:61: $ If the input to "pkeyutl ?sign? is supposed to be digest output only ? then what?s the point of having command line arguments specifying the digest to use? And if the input can be an arbitrary file (like for ?dgst?), then why it doesn?t seem to work? I?d appreciate comments, guidance, etc. Thanks! -- Regards, Uri Blumenthal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From steve at openssl.org Wed Jan 13 21:19:14 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 13 Jan 2016 21:19:14 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: References: Message-ID: <20160113211914.GA29513@openssl.org> On Wed, Jan 13, 2016, Blumenthal, Uri - 0553 - MITLL wrote: > > > If the input to "pkeyutl ???sign??? is supposed to be digest output only ??? then > what???s the point of having command line arguments specifying the digest to > use? And if the input can be an arbitrary file (like for ???dgst???), then why > it doesn???t seem to work? > > I???d appreciate comments, guidance, etc. > The dgst utility performs hash+sign the pkeyutl utility is supplied with the data to sign (which is usually but not always a hash). The reason you can specify which hash the digest is for is that without that the utility just sees binary data of a certain length. By specifying the digest it can sanity check the length and in some schemes (e.g. RSA) include the digest algorithm in the data being signed (PKCS#1 DigestInfo structure for some RSA padding modes). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From uri at ll.mit.edu Wed Jan 13 21:32:47 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 13 Jan 2016 21:32:47 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: <20160113211914.GA29513@openssl.org> References: <20160113211914.GA29513@openssl.org> Message-ID: On 1/13/16, 16:19 , "openssl-dev on behalf of Dr. Stephen Henson" wrote: >On Wed, Jan 13, 2016, Blumenthal, Uri - 0553 - MITLL wrote: >> >> >> If the input to "pkeyutl -sign" is supposed to be digest output only - >>then >> what?s the point of having command line arguments specifying the digest >>to >> use? And if the input can be an arbitrary file (like for ?dgst"), then >>why >> it doesn?t seem to work? >> >> I?d appreciate comments, guidance, etc. >> > >The dgst utility performs hash+sign; the pkeyutl utility is supplied with >the >data to sign (which is usually but not always a hash). I see. Thank you for explaining! >The reason you can specify which hash the digest is for is that without >that >the utility just sees binary data of a certain length. By specifying the >digest it can sanity check the length and in some schemes (e.g. RSA) >include >the digest algorithm in the data being signed (PKCS#1 DigestInfo structure >for some RSA padding modes). Can I suggest and ask that all of the above explanation is added to/included in the pkeyutl man page? I?m sure it would save some grief to other users. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From openssl-users at dukhovni.org Wed Jan 13 22:44:26 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 13 Jan 2016 22:44:26 +0000 Subject: [openssl-dev] [openssl.org #4233] [bug][openssl verify] pre-valid certificate return code inconsistency In-Reply-To: References: Message-ID: <20160113224426.GD28324@mournblade.imrryr.org> On Wed, Jan 13, 2016 at 06:58:14PM +0000, Zak Blacher via RT wrote: > I've found an inconsistency in the return status of 'openssl verify'. I've > attached a custom dummy ca, and an example certificate. This certificate is > valid for some date range in the future. > > On my redhat machine (openssl 1.0.1e), running openssl verify will return a > status code of 2, but in osx (openssl 0.98zg), the return status is 0. In > both cases, I correctly see an error 9 in the function output. > > The behavior of validating an expired certificate returns a status code of > 0 on both systems. Yes, certain errors were ignored in verify(1), allowing chain verification to continue, but should have been noted at the end. I have a fix for the master release pending review, should appear in 1.1.0 alpha2 if it gets reviewed today. Backports to 1.0.1 and 1.0.2 later if deemed appropriate. 0.9.8 and 1.0.0 are EOL, so they'll not get fixed. -- Viktor. From rt at openssl.org Wed Jan 13 22:44:31 2016 From: rt at openssl.org (Viktor Dukhovni via RT) Date: Wed, 13 Jan 2016 22:44:31 +0000 Subject: [openssl-dev] [openssl.org #4233] [bug][openssl verify] pre-valid certificate return code inconsistency In-Reply-To: <20160113224426.GD28324@mournblade.imrryr.org> References: <20160113224426.GD28324@mournblade.imrryr.org> Message-ID: On Wed, Jan 13, 2016 at 06:58:14PM +0000, Zak Blacher via RT wrote: > I've found an inconsistency in the return status of 'openssl verify'. I've > attached a custom dummy ca, and an example certificate. This certificate is > valid for some date range in the future. > > On my redhat machine (openssl 1.0.1e), running openssl verify will return a > status code of 2, but in osx (openssl 0.98zg), the return status is 0. In > both cases, I correctly see an error 9 in the function output. > > The behavior of validating an expired certificate returns a status code of > 0 on both systems. Yes, certain errors were ignored in verify(1), allowing chain verification to continue, but should have been noted at the end. I have a fix for the master release pending review, should appear in 1.1.0 alpha2 if it gets reviewed today. Backports to 1.0.1 and 1.0.2 later if deemed appropriate. 0.9.8 and 1.0.0 are EOL, so they'll not get fixed. -- Viktor. From rt at openssl.org Wed Jan 13 23:36:38 2016 From: rt at openssl.org (Zak Blacher via RT) Date: Wed, 13 Jan 2016 23:36:38 +0000 Subject: [openssl-dev] [openssl.org #4233] [bug][openssl verify] pre-valid certificate return code inconsistency In-Reply-To: References: <20160113224426.GD28324@mournblade.imrryr.org> Message-ID: Darn, and I was hoping to be able to patch it myself :) -Zak *Zak Blacher* Software Engineer Security Infrastructure 206.453.9955 zblacher at linkedin.com linkedin.com/in/zakblacher On Wed, Jan 13, 2016 at 2:44 PM, Viktor Dukhovni via RT wrote: > On Wed, Jan 13, 2016 at 06:58:14PM +0000, Zak Blacher via RT wrote: > > > I've found an inconsistency in the return status of 'openssl verify'. > I've > > attached a custom dummy ca, and an example certificate. This certificate > is > > valid for some date range in the future. > > > > On my redhat machine (openssl 1.0.1e), running openssl verify will > return a > > status code of 2, but in osx (openssl 0.98zg), the return status is 0. In > > both cases, I correctly see an error 9 in the function output. > > > > The behavior of validating an expired certificate returns a status code > of > > 0 on both systems. > > Yes, certain errors were ignored in verify(1), allowing chain > verification to continue, but should have been noted at the end. > > I have a fix for the master release pending review, should appear > in 1.1.0 alpha2 if it gets reviewed today. > > Backports to 1.0.1 and 1.0.2 later if deemed appropriate. 0.9.8 > and 1.0.0 are EOL, so they'll not get fixed. > > -- > Viktor. > > > From openssl-users at dukhovni.org Wed Jan 13 23:39:24 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 13 Jan 2016 18:39:24 -0500 Subject: [openssl-dev] [openssl.org #4233] [bug][openssl verify] pre-valid certificate return code inconsistency In-Reply-To: References: <20160113224426.GD28324@mournblade.imrryr.org> Message-ID: <9FCCF09B-9FF3-48A0-B02E-A8D8079D9900@dukhovni.org> > On Jan 13, 2016, at 6:36 PM, Zak Blacher via RT wrote: > > Darn, and I was hoping to be able to patch it myself :) The 1.1.0 fix is now on Github, and will be in 1.1.0-alpha2. Similar changes can be made to earlier releases, the bulk of the work is making the test-suite run again, given that some of test certs expired long ago. -- Viktor. From rt at openssl.org Wed Jan 13 23:39:29 2016 From: rt at openssl.org (Viktor Dukhovni via RT) Date: Wed, 13 Jan 2016 23:39:29 +0000 Subject: [openssl-dev] [openssl.org #4233] [bug][openssl verify] pre-valid certificate return code inconsistency In-Reply-To: <9FCCF09B-9FF3-48A0-B02E-A8D8079D9900@dukhovni.org> References: <20160113224426.GD28324@mournblade.imrryr.org> <9FCCF09B-9FF3-48A0-B02E-A8D8079D9900@dukhovni.org> Message-ID: > On Jan 13, 2016, at 6:36 PM, Zak Blacher via RT wrote: > > Darn, and I was hoping to be able to patch it myself :) The 1.1.0 fix is now on Github, and will be in 1.1.0-alpha2. Similar changes can be made to earlier releases, the bulk of the work is making the test-suite run again, given that some of test certs expired long ago. -- Viktor. From rt at openssl.org Thu Jan 14 03:30:13 2016 From: rt at openssl.org (Kaduk, Ben via RT) Date: Thu, 14 Jan 2016 03:30:13 +0000 Subject: [openssl-dev] [openssl.org #4234] disable EGD by default In-Reply-To: <5697163F.5070100@akamai.com> References: <5697163F.5070100@akamai.com> Message-ID: Since we can't remove EGD entirely yet, let's do the next best thing. https://github.com/openssl/openssl/pull/547 contains a patch to add a no-egd configure option and disable egd support by default. -Ben _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rsalz at akamai.com Thu Jan 14 04:00:48 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 14 Jan 2016 04:00:48 +0000 Subject: [openssl-dev] simplifying rand_egd API Message-ID: There are currently three functions related to the EGD: int RAND_egd(const char *path); int RAND_egd_bytes(const char *path, int bytes); int RAND_query_egd_bytes(const char *path, unsigned char *buf, int bytes); I would like to just have a single function Int RAND_add_egd(const char* path) Does anyone use those three functions? -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From rt at openssl.org Thu Jan 14 04:18:56 2016 From: rt at openssl.org (Srinivas Koripella via RT) Date: Thu, 14 Jan 2016 04:18:56 +0000 Subject: [openssl-dev] [openssl.org #4193] AutoReply: Minor Issue with X509_STORE_CTX_init and it's callers. In-Reply-To: References: Message-ID: Thanks ViKtor. I tested your patch and it is holding up well on our environment. Srinivas -----Original Message----- From: The default queue via RT [mailto:rt at openssl.org] Sent: Tuesday, December 22, 2015 10:04 AM To: Srinivas Koripella Subject: [openssl.org #4193] AutoReply: Minor Issue with X509_STORE_CTX_init and it's callers. Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Minor Issue with X509_STORE_CTX_init and it's callers.", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [openssl.org #4193]. Please include the string: [openssl.org #4193] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, rt at openssl.org ------------------------------------------------------------------------- Hello all, There is a minor issue with X509_STORE_CTX_init and its usage. Most of the callers of X509_STORE_CTX_init use a stack variable and pass its address as the ctx argument to this function. However, X509_STORE_CTX_init in case of an error in the call to CRYPTO_new_ex_data does an OPENSSL_free on this stack variable. This in theory should be ok as the underlying free implementation should probably be a no-op as this address is from the stack. However, on systems that does strict checks on allocated memory heap this can be a problem. One potential fix could be to remove the OPENSSL_free and let the caller take responsibility for his memory. Thanks. Srinivas From openssl-users at dukhovni.org Thu Jan 14 04:27:30 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 13 Jan 2016 23:27:30 -0500 Subject: [openssl-dev] [openssl.org #4193] AutoReply: Minor Issue with X509_STORE_CTX_init and it's callers. In-Reply-To: References: Message-ID: <3584235F-825C-4274-92CF-131C89823AD0@dukhovni.org> > On Jan 13, 2016, at 11:18 PM, Srinivas Koripella via RT wrote: > > Thanks ViKtor. I tested your patch and it is holding up well on our environment. This is now in the git versions of all supported branches: 1.0.1, 1.0.1 and master == 1.1.0-dev So you can test those, or wait for the next release. Thanks again for the report, the code in question did need some attention. Feel free to close the ticket. -- Viktor. From rt at openssl.org Thu Jan 14 04:27:33 2016 From: rt at openssl.org (Viktor Dukhovni via RT) Date: Thu, 14 Jan 2016 04:27:33 +0000 Subject: [openssl-dev] [openssl.org #4193] AutoReply: Minor Issue with X509_STORE_CTX_init and it's callers. In-Reply-To: <3584235F-825C-4274-92CF-131C89823AD0@dukhovni.org> References: <3584235F-825C-4274-92CF-131C89823AD0@dukhovni.org> Message-ID: > On Jan 13, 2016, at 11:18 PM, Srinivas Koripella via RT wrote: > > Thanks ViKtor. I tested your patch and it is holding up well on our environment. This is now in the git versions of all supported branches: 1.0.1, 1.0.1 and master == 1.1.0-dev So you can test those, or wait for the next release. Thanks again for the report, the code in question did need some attention. Feel free to close the ticket. -- Viktor. From steffen at sdaoden.eu Thu Jan 14 10:26:14 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 14 Jan 2016 11:26:14 +0100 Subject: [openssl-dev] simplifying rand_egd API In-Reply-To: References: Message-ID: <20160114102614.lkgKEqOJx%steffen@sdaoden.eu> "Salz, Rich" wrote: |There are currently three functions related to the EGD: | int RAND_egd(const char *path); | int RAND_egd_bytes(const char *path, int bytes); | int RAND_query_egd_bytes(const char *path, unsigned char *buf\ | , int bytes); | |I would like to just have a single function | Int RAND_add_egd(const char* path) | |Does anyone use those three functions? For obvious reasons preprocessor conditionalized i do maintain the first. Yes i think that is a sane one to have. (Whereas i personally don't have a strong opinion on that topic at all i do think that having an easy way to use a random source of choice may be interesting for, e.g., students or researchers. So i truly think that saying "please keep this interface" isn't backed by noone, wether they speak up or not today.) P.S.: i like the new website; i had Matt Caswell's message laying around for many weeks but a reply never made it. Not that it matters, anyway. Ciao, --steffen From hkario at redhat.com Thu Jan 14 12:33:59 2016 From: hkario at redhat.com (Hubert Kario) Date: Thu, 14 Jan 2016 13:33:59 +0100 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: References: <20160113211914.GA29513@openssl.org> Message-ID: <2517679.4s7L9EX7XN@pintsize.usersys.redhat.com> On Wednesday 13 January 2016 21:32:47 Blumenthal, Uri - 0553 - MITLL wrote: > On 1/13/16, 16:19 , "openssl-dev on behalf of Dr. Stephen Henson" > > wrote: > >The reason you can specify which hash the digest is for is that > >without that > >the utility just sees binary data of a certain length. By specifying > >the digest it can sanity check the length and in some schemes (e.g. > >RSA) include > >the digest algorithm in the data being signed (PKCS#1 DigestInfo > >structure for some RSA padding modes). > > Can I suggest and ask that all of the above explanation is added > to/included in the pkeyutl man page? I?m sure it would save some grief > to other users. from pkeyutl(1ssl) in OpenSSL 1.0.1: ----->8------ Unless otherwise mentioned all algorithms support the digest:alg option which specifies the digest in use for sign, verify and verifyrecover operations. The value alg should represent a digest name as used in the EVP_get_digestbyname() function for example sha1. (...) -rsa_padding_mode:mode (...) In PKCS#1 padding if the message digest is not set then the supplied data is signed or verified directly instead of using a DigestInfo structure. If a digest is set then the a DigestInfo structure is used and its the length must correspond to the digest type. (...) EXAMPLES (...) Sign data using a message digest value (this is currently only valid for RSA): openssl pkeyutl -sign -in file -inkey key.pem -out sig -pkeyopt digest:sha256 ----->8------ So it looks documented to me. What is missing in your opinion? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rsalz at akamai.com Thu Jan 14 13:31:09 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 14 Jan 2016 13:31:09 +0000 Subject: [openssl-dev] simplifying rand_egd API In-Reply-To: <20160114102614.lkgKEqOJx%steffen@sdaoden.eu> References: <20160114102614.lkgKEqOJx%steffen@sdaoden.eu> Message-ID: <5fbd19b87cbf4b5792b857d0af375637@usma1ex-dag1mb1.msg.corp.akamai.com> > truly think that saying "please keep this interface" isn't backed by noone, > wether they speak up or not today.) Yes, I know. It is however the best we can do. My issue with the other two API's is that they are really EGD functions, not OpenSSL functions. > P.S.: i like the new website; i had Matt Caswell's message laying around for > many weeks but a reply never made it. Not that it matters, anyway. Always nice to hear a kind word. Thanks! From rt at openssl.org Thu Jan 14 13:37:24 2016 From: rt at openssl.org (Alexandre PAQUE via RT) Date: Thu, 14 Jan 2016 13:37:24 +0000 Subject: [openssl-dev] [openssl.org #4235] Crash on ssleay_rand_bytes - global variable is not protected In-Reply-To: References: Message-ID: *?Context:?* openssl 1.0.2e Windows 2012 gsoap 2.8.7 - WSSE Application multithread *crash dump: * d:\opensource\openssl-1.0.2e\crypto\sha\sha_locl.h (320): sha1_block_data_order d:\opensource\openssl-1.0.2e\tmp32\md32_common.h (343): SHA1_Update d:\opensource\openssl-1.0.2e\crypto\evp\m_sha1.c (78): update d:\opensource\openssl-1.0.2e\crypto\rand\md_rand.c (496): ssleay_rand_bytes d:\opensource\openssl-1.0.2e\crypto\rand\md_rand.c (544): ssleay_rand_pseudo_bytes d:\dev\3rdparty\gsoap-2.8\gsoap\plugin\wsseapi.cpp (3545): calc_nonce d:\dev\3rdparty\gsoap-2.8\gsoap\plugin\wsseapi.cpp (1718): soap_wsse_add_UsernameTokenDigest *Analyze:* I think this issue occurs because of the global static variable "state" is not protected into the functions (md_rand.c). sample: int ssleay_rand_bytes(unsigned char *buf, int num, int pseudo, int lock) { ... *if (lock)* * CRYPTO_w_lock(CRYPTO_LOCK_RAND);* * /* prevent ssleay_rand_bytes() from trying to obtain the lock again */* * CRYPTO_w_lock(CRYPTO_LOCK_RAND2);* * CRYPTO_THREADID_current(&locking_threadid);* * CRYPTO_w_unlock(CRYPTO_LOCK_RAND2);* * crypto_lock_rand = 1;* if (!initialized) { RAND_poll(); initialized = 1; } if (!stirred_pool) do_stir_pool = 1; ok = (entropy >= ENTROPY_NEEDED); if (!ok) { /* * If the PRNG state is not yet unpredictable, then seeing the PRNG * output may help attackers to determine the new state; thus we have * to decrease the entropy estimate. Once we've had enough initial * seeding we don't bother to adjust the entropy count, though, * because we're not ambitious to provide *information-theoretic* * randomness. NOTE: This approach fails if the program forks before * we have enough entropy. Entropy should be collected in a separate * input pool and be transferred to the output pool only when the * entropy limit has been reached. */ entropy -= num; if (entropy < 0) entropy = 0; } if (do_stir_pool) { /* * In the output function only half of 'md' remains secret, so we * better make sure that the required entropy gets 'evenly * distributed' through 'state', our randomness pool. The input * function (ssleay_rand_add) chains all of 'md', which makes it more * suitable for this purpose. */ int n = STATE_SIZE; /* so that the complete pool gets accessed */ while (n > 0) { #if MD_DIGEST_LENGTH > 20 # error "Please adjust DUMMY_SEED." #endif #define DUMMY_SEED "...................." /* at least MD_DIGEST_LENGTH */ /* * Note that the seed does not matter, it's just that * ssleay_rand_add expects to have something to hash. */ ssleay_rand_add(DUMMY_SEED, MD_DIGEST_LENGTH, 0.0); n -= MD_DIGEST_LENGTH; } if (ok) stirred_pool = 1; } st_idx = state_index; st_num = state_num; md_c[0] = md_count[0]; md_c[1] = md_count[1]; memcpy(local_md, md, sizeof md); state_index += num_ceil; if (state_index > state_num) state_index %= state_num; /* * state[st_idx], ..., state[(st_idx + num_ceil - 1) % st_num] are now * ours (but other threads may use them too) */ md_count[0] += 1; /* before unlocking, we must clear 'crypto_lock_rand' */ crypto_lock_rand = 0; * if (lock)* * CRYPTO_w_unlock(CRYPTO_LOCK_RAND);* while (num > 0) { /* num_ceil -= MD_DIGEST_LENGTH/2 */ j = (num >= MD_DIGEST_LENGTH / 2) ? MD_DIGEST_LENGTH / 2 : num; num -= j; MD_Init(&m); #ifndef GETPID_IS_MEANINGLESS if (curr_pid) { /* just in the first iteration to save time */ MD_Update(&m, (unsigned char *)&curr_pid, sizeof curr_pid); curr_pid = 0; } #endif MD_Update(&m, local_md, MD_DIGEST_LENGTH); MD_Update(&m, (unsigned char *)&(md_c[0]), sizeof(md_c)); #ifndef PURIFY /* purify complains */ /* * The following line uses the supplied buffer as a small source of * entropy: since this buffer is often uninitialised it may cause * programs such as purify or valgrind to complain. So for those * builds it is not used: the removal of such a small source of * entropy has negligible impact on security. */ MD_Update(&m, buf, j); #endif // no lock to protect "state" global variable k = (st_idx + MD_DIGEST_LENGTH / 2) - st_num; if (k > 0) { MD_Update(&m, &(state[st_idx]), MD_DIGEST_LENGTH / 2 - k); * MD_Update(&m, &(state[0]), k); // CRASH* } else MD_Update(&m, &(state[st_idx]), MD_DIGEST_LENGTH / 2); MD_Final(&m, local_md); for (i = 0; i < MD_DIGEST_LENGTH / 2; i++) { /* may compete with other threads */ state[st_idx++] ^= local_md[i]; if (st_idx >= st_num) st_idx = 0; if (i < j) *(buf++) = local_md[i + MD_DIGEST_LENGTH / 2]; } } MD_Init(&m); MD_Update(&m, (unsigned char *)&(md_c[0]), sizeof(md_c)); MD_Update(&m, local_md, MD_DIGEST_LENGTH); * if (lock)* * CRYPTO_w_lock(CRYPTO_LOCK_RAND);* MD_Update(&m, md, MD_DIGEST_LENGTH); MD_Final(&m, md); * if (lock)* * CRYPTO_w_unlock(CRYPTO_LOCK_RAND);* EVP_MD_CTX_cleanup(&m); Best Regards, Alex -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Jan 14 14:29:52 2016 From: rt at openssl.org (Srinivas Koripella via RT) Date: Thu, 14 Jan 2016 14:29:52 +0000 Subject: [openssl-dev] [openssl.org #4193] AutoReply: Minor Issue with X509_STORE_CTX_init and it's callers. In-Reply-To: References: <3584235F-825C-4274-92CF-131C89823AD0@dukhovni.org> Message-ID: Ok thanks. How do i close the ticket? I want to mark this resolved. Srinivas -----Original Message----- From: Viktor Dukhovni via RT [mailto:rt at openssl.org] Sent: Thursday, January 14, 2016 9:58 AM To: Srinivas Koripella Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4193] AutoReply: Minor Issue with X509_STORE_CTX_init and it's callers. > On Jan 13, 2016, at 11:18 PM, Srinivas Koripella via RT wrote: > > Thanks ViKtor. I tested your patch and it is holding up well on our environment. This is now in the git versions of all supported branches: 1.0.1, 1.0.1 and master == 1.1.0-dev So you can test those, or wait for the next release. Thanks again for the report, the code in question did need some attention. Feel free to close the ticket. -- Viktor. From uri at ll.mit.edu Thu Jan 14 14:41:20 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 14 Jan 2016 14:41:20 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? Message-ID: <20160114144128.17780804.28529.45238@ll.mit.edu> If you already know what Dr. Henson explained in the quoted emails - then the man page is crystal clear. However, if you don't - then it is very easy (it was to me) to make an erroneous assumption (that is not explicitly contradicted) that the digest you specify would be applied to the data you are signing by pkeyutl itself.? This is why I'm asking to include a statement (taking the relevant paragraph from Steve's email seems the best and the simplest way to me) somewhere in the beginning of the Notes section. That added statement/paragraph would makeit unambiguously clear that specified or implied digest and it's parameters are used by pkeyutl ONLY for sanity checks and inclusion into the signature structure, but are NOT applied to the input data by pkeyutl (which instead the user must himself perform prior to invoking pkeyutl). Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Hubert Kario Sent: Thursday, January 14, 2016 07:34 To: openssl-dev at openssl.org; openssl-users at openssl.org Reply To: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? On Wednesday 13 January 2016 21:32:47 Blumenthal, Uri - 0553 - MITLL wrote: > On 1/13/16, 16:19 , "openssl-dev on behalf of Dr. Stephen Henson" > > wrote: > >The reason you can specify which hash the digest is for is that > >without that > >the utility just sees binary data of a certain length. By specifying > >the digest it can sanity check the length and in some schemes (e.g. > >RSA) include > >the digest algorithm in the data being signed (PKCS#1 DigestInfo > >structure for some RSA padding modes). > > Can I suggest and ask that all of the above explanation is added > to/included in the pkeyutl man page? I?m sure it would save some grief > to other users. from pkeyutl(1ssl) in OpenSSL 1.0.1: ----->8------ Unless otherwise mentioned all algorithms support the digest:alg option which specifies the digest in use for sign, verify and verifyrecover operations. The value alg should represent a digest name as used in the EVP_get_digestbyname() function for example sha1. (...) -rsa_padding_mode:mode (...) In PKCS#1 padding if the message digest is not set then the supplied data is signed or verified directly instead of using a DigestInfo structure. If a digest is set then the a DigestInfo structure is used and its the length must correspond to the digest type. (...) EXAMPLES (...) Sign data using a message digest value (this is currently only valid for RSA): openssl pkeyutl -sign -in file -inkey key.pem -out sig -pkeyopt digest:sha256 ----->8------ So it looks documented to me. What is missing in your opinion? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From levitte at openssl.org Thu Jan 14 14:44:18 2016 From: levitte at openssl.org (Richard Levitte) Date: Thu, 14 Jan 2016 15:44:18 +0100 (CET) Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published Message-ID: <20160114.154418.799119456171028604.levitte@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.1.0 pre release 2 (alpha) =========================================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 2 has now been made available. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.1.0-notes.html Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. The alpha release is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0-pre2.tar.gz Size: 4948288 SHA1 checksum: d7a26cce5d4cc2b491996489d5385e0640bb92ef SHA256 checksum: 09e7470462e263ae853bc7a8fdb07fa439651c5f70aab4573c1a87ee2537a7ac The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0-pre2.tar.gz openssl sha256 openssl-1.1.0-pre2.tar.gz Please download and check this alpha release as soon as possible. Bug reports should go to rt at openssl.org. Please check the release notes and mailing lists to avoid duplicate reports of known issues. Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWl7A8AAoJENXp5D99+e6MB2kQAJU5fn49JZ7YPx1VByhn873B UptNfbXozRn7ceLoDxMuZlwhbZEV/2BVc37bocagTsuU2gu2RedCE4WS/Kdk9j7q 9IK7pgInLgK2gTMXuPzKFz2qxAxtSi5QJC7BRqq88gR03dl0qXuJ+eCW2Y+zKiDt 2WgAFKrbTW9reDZs2a6WLJEY2lQdsc4eKMkVfCPZTPNpwMUsXipv7egJYC5XchBG ZM1nq8KbmwtVn1EIjH3pUxKbRIPhfza3OCwKQqWsx1XHga7fA4Cz/u+NiswcubGv fC+Aei30Ygi3oR8QG2tdEYMWQaa54hvn06/1bh6tVi8GcXGhFXj+gUTr6dw4TlGx wB/H3bII9slNkGC3w5kcVbSdCmH7ThTDKqeHbqPTVooOJMXMKj5EBXGKkkJ/O8Xg P3cDhqw48LgTW6BtM0ItZE7yHrApPaJr4MWTBQj4uqUIQz0SSUnxCE7xpSJS5UPE A/oi0p+Mzr3bJG+39lzDEqhFWxR/WP5cU9mWo68b002qwSzcOPm8RpMfqGfNJDyg P5OVJnykeI0JU8rR85fTdJFvcGgESOfv1HnSa9sGIMLhEA6Y4GwDhM804AV9xQ3+ trLd1Y5WYTcgc8yx181psw541N1Hsxl15Jm2sPcMMYdiK5YVbi1y+K3NGfnmKnYT /79DbTCo0r02h0k1X8JI =It+h -----END PGP SIGNATURE----- From rt at openssl.org Thu Jan 14 15:26:42 2016 From: rt at openssl.org (Alexandre PAQUE via RT) Date: Thu, 14 Jan 2016 15:26:42 +0000 Subject: [openssl-dev] [openssl.org #4235] AutoReply: Crash on ssleay_rand_bytes - global variable is not protected In-Reply-To: References: Message-ID: I'm not sure that the issue is the lock on the "state" variable because this is a char array with a fixed size. No dynamic allocations and free. However, the crash is on this part of code: ? MD_Update(&m, &(state[0]), k); ? On 14 January 2016 at 14:37, The default queue via RT wrote: > > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "Crash on ssleay_rand_bytes - global variable is not protected", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [openssl.org #4235]. > > Please include the string: > > [openssl.org #4235] > > in the subject line of all future correspondence about this issue. To do > so, > you may reply to this message. > > Thank you, > rt at openssl.org > > ------------------------------------------------------------------------- > *?Context:?* > > openssl 1.0.2e > Windows 2012 > gsoap 2.8.7 - WSSE > Application multithread > > > *crash dump: * > > d:\opensource\openssl-1.0.2e\crypto\sha\sha_locl.h (320): > sha1_block_data_order > d:\opensource\openssl-1.0.2e\tmp32\md32_common.h (343): SHA1_Update > d:\opensource\openssl-1.0.2e\crypto\evp\m_sha1.c (78): update > d:\opensource\openssl-1.0.2e\crypto\rand\md_rand.c (496): ssleay_rand_bytes > d:\opensource\openssl-1.0.2e\crypto\rand\md_rand.c (544): > ssleay_rand_pseudo_bytes > d:\dev\3rdparty\gsoap-2.8\gsoap\plugin\wsseapi.cpp (3545): calc_nonce > d:\dev\3rdparty\gsoap-2.8\gsoap\plugin\wsseapi.cpp (1718): > soap_wsse_add_UsernameTokenDigest > > *Analyze:* > > I think this issue occurs because of the global static variable "state" is > not protected into the functions (md_rand.c). > > sample: > > int ssleay_rand_bytes(unsigned char *buf, int num, int pseudo, int lock) > { > ... > > *if (lock)* > * CRYPTO_w_lock(CRYPTO_LOCK_RAND);* > > * /* prevent ssleay_rand_bytes() from trying to obtain the lock again > */* > * CRYPTO_w_lock(CRYPTO_LOCK_RAND2);* > * CRYPTO_THREADID_current(&locking_threadid);* > * CRYPTO_w_unlock(CRYPTO_LOCK_RAND2);* > * crypto_lock_rand = 1;* > > if (!initialized) { > RAND_poll(); > initialized = 1; > } > > if (!stirred_pool) > do_stir_pool = 1; > > ok = (entropy >= ENTROPY_NEEDED); > if (!ok) { > /* > * If the PRNG state is not yet unpredictable, then seeing the PRNG > * output may help attackers to determine the new state; thus we > have > * to decrease the entropy estimate. Once we've had enough initial > * seeding we don't bother to adjust the entropy count, though, > * because we're not ambitious to provide *information-theoretic* > * randomness. NOTE: This approach fails if the program forks > before > * we have enough entropy. Entropy should be collected in a > separate > * input pool and be transferred to the output pool only when the > * entropy limit has been reached. > */ > entropy -= num; > if (entropy < 0) > entropy = 0; > } > > if (do_stir_pool) { > /* > * In the output function only half of 'md' remains secret, so we > * better make sure that the required entropy gets 'evenly > * distributed' through 'state', our randomness pool. The input > * function (ssleay_rand_add) chains all of 'md', which makes it > more > * suitable for this purpose. > */ > > int n = STATE_SIZE; /* so that the complete pool gets accessed > */ > while (n > 0) { > #if MD_DIGEST_LENGTH > 20 > # error "Please adjust DUMMY_SEED." > #endif > #define DUMMY_SEED "...................." /* at least MD_DIGEST_LENGTH */ > /* > * Note that the seed does not matter, it's just that > * ssleay_rand_add expects to have something to hash. > */ > ssleay_rand_add(DUMMY_SEED, MD_DIGEST_LENGTH, 0.0); > n -= MD_DIGEST_LENGTH; > } > if (ok) > stirred_pool = 1; > } > > st_idx = state_index; > st_num = state_num; > md_c[0] = md_count[0]; > md_c[1] = md_count[1]; > memcpy(local_md, md, sizeof md); > > state_index += num_ceil; > if (state_index > state_num) > state_index %= state_num; > > /* > * state[st_idx], ..., state[(st_idx + num_ceil - 1) % st_num] are now > * ours (but other threads may use them too) > */ > > md_count[0] += 1; > > /* before unlocking, we must clear 'crypto_lock_rand' */ > crypto_lock_rand = 0; > * if (lock)* > * CRYPTO_w_unlock(CRYPTO_LOCK_RAND);* > > while (num > 0) { > /* num_ceil -= MD_DIGEST_LENGTH/2 */ > j = (num >= MD_DIGEST_LENGTH / 2) ? MD_DIGEST_LENGTH / 2 : num; > num -= j; > MD_Init(&m); > #ifndef GETPID_IS_MEANINGLESS > if (curr_pid) { /* just in the first iteration to save time > */ > MD_Update(&m, (unsigned char *)&curr_pid, sizeof curr_pid); > curr_pid = 0; > } > #endif > MD_Update(&m, local_md, MD_DIGEST_LENGTH); > MD_Update(&m, (unsigned char *)&(md_c[0]), sizeof(md_c)); > > #ifndef PURIFY /* purify complains */ > /* > * The following line uses the supplied buffer as a small source of > * entropy: since this buffer is often uninitialised it may cause > * programs such as purify or valgrind to complain. So for those > * builds it is not used: the removal of such a small source of > * entropy has negligible impact on security. > */ > MD_Update(&m, buf, j); > #endif > > // no lock to protect "state" global variable > > k = (st_idx + MD_DIGEST_LENGTH / 2) - st_num; > if (k > 0) { > MD_Update(&m, &(state[st_idx]), MD_DIGEST_LENGTH / 2 - k); > * > ?? > MD_Update(&m, &(state[0]), k); // CRASH* > } else > MD_Update(&m, &(state[st_idx]), MD_DIGEST_LENGTH / 2); > MD_Final(&m, local_md); > > for (i = 0; i < MD_DIGEST_LENGTH / 2; i++) { > /* may compete with other threads */ > state[st_idx++] ^= local_md[i]; > if (st_idx >= st_num) > st_idx = 0; > if (i < j) > *(buf++) = local_md[i + MD_DIGEST_LENGTH / 2]; > } > } > > MD_Init(&m); > MD_Update(&m, (unsigned char *)&(md_c[0]), sizeof(md_c)); > MD_Update(&m, local_md, MD_DIGEST_LENGTH); > * if (lock)* > * CRYPTO_w_lock(CRYPTO_LOCK_RAND);* > MD_Update(&m, md, MD_DIGEST_LENGTH); > MD_Final(&m, md); > * if (lock)* > * CRYPTO_w_unlock(CRYPTO_LOCK_RAND);* > > EVP_MD_CTX_cleanup(&m); > > > > Best Regards, > Alex > > From rsalz at akamai.com Thu Jan 14 15:42:04 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 14 Jan 2016 15:42:04 +0000 Subject: [openssl-dev] [openssl.org #4193] AutoReply: Minor Issue with X509_STORE_CTX_init and it's callers. In-Reply-To: References: <3584235F-825C-4274-92CF-131C89823AD0@dukhovni.org> Message-ID: You can't, only someone one the team can. I'll close it. From rt at openssl.org Thu Jan 14 15:42:09 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 14 Jan 2016 15:42:09 +0000 Subject: [openssl-dev] [openssl.org #4193] AutoReply: Minor Issue with X509_STORE_CTX_init and it's callers. In-Reply-To: References: <3584235F-825C-4274-92CF-131C89823AD0@dukhovni.org> Message-ID: You can't, only someone one the team can. I'll close it. From skoripella at juniper.net Thu Jan 14 14:29:39 2016 From: skoripella at juniper.net (Srinivas Koripella) Date: Thu, 14 Jan 2016 14:29:39 +0000 Subject: [openssl-dev] [openssl.org #4193] AutoReply: Minor Issue with X509_STORE_CTX_init and it's callers. In-Reply-To: References: <3584235F-825C-4274-92CF-131C89823AD0@dukhovni.org> Message-ID: Ok thanks. How do i close the ticket? I want to mark this resolved. Srinivas -----Original Message----- From: Viktor Dukhovni via RT [mailto:rt at openssl.org] Sent: Thursday, January 14, 2016 9:58 AM To: Srinivas Koripella Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4193] AutoReply: Minor Issue with X509_STORE_CTX_init and it's callers. > On Jan 13, 2016, at 11:18 PM, Srinivas Koripella via RT wrote: > > Thanks ViKtor. I tested your patch and it is holding up well on our environment. This is now in the git versions of all supported branches: 1.0.1, 1.0.1 and master == 1.1.0-dev So you can test those, or wait for the next release. Thanks again for the report, the code in question did need some attention. Feel free to close the ticket. -- Viktor. From luky-37 at hotmail.com Thu Jan 14 16:06:33 2016 From: luky-37 at hotmail.com (Lukas Tribus) Date: Thu, 14 Jan 2016 17:06:33 +0100 Subject: [openssl-dev] OCSP_SINGLERESP_get0_id() accessor Message-ID: Hi list, since 1.1.0 API will be freezed soon, can you review the following pull-request Remi posted some time ago: Add an OCSP_SINGLERESP_get0_id() accessor to the OCSP_CERTID of a OCSP_SINGLERESP https://github.com/openssl/openssl/pull/334 Thank you! Lukas From rt at openssl.org Thu Jan 14 16:33:50 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 14 Jan 2016 16:33:50 +0000 Subject: [openssl-dev] [openssl.org #4232] [cosmetic] s_client.c: double space in usage In-Reply-To: <20160113154017.GA25639@x2.esmtp.org> References: <20160113154017.GA25639@x2.esmtp.org> Message-ID: So it turns out that the flag actually does nothing. It calls an undocumented API which sets a flag in the SSL structure which is never ever used. So lots of code and docs just got removed :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From j at w1.fi Thu Jan 14 16:47:49 2016 From: j at w1.fi (Jouni Malinen) Date: Thu, 14 Jan 2016 18:47:49 +0200 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160114.154418.799119456171028604.levitte@openssl.org> References: <20160114.154418.799119456171028604.levitte@openssl.org> Message-ID: <20160114164749.GA15188@w1.fi> On Thu, Jan 14, 2016 at 03:44:18PM +0100, Richard Levitte wrote: > OpenSSL version 1.1.0 pre release 2 (alpha) > OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 2 has now > been made available. For details of changes and known issues see the > release notes at: > > http://www.openssl.org/news/openssl-1.1.0-notes.html I needed to do following updates to hostapd/wpa_supplicant to build against this (to a snapshot that worked with 1.1.0 pre release 1): - use EVP_CIPHER_CTX_new() and dynamic allocation instead of having EVP_CIPHER_CTX ctx on stack and using EVP_CIPHER_CTX_init(&ctx) (I guess this was an expected change, but for some reason, pre release 1 did not force this) - replace "SSL_CIPHER **cipher" with "const SSL_CIPHER **cipher" in the SSL_set_session_secret_cb() callback function (I did not notice any comment about this in the changelog; was there supposed to be something? This broke API compatibility.. The change itself is fine and I already had to do some with BoringSSL, but it would be nice to get this type of incompatible API changes noted clearly) As far as functionality is concerned, I did see number of new issues when running through my automated test setup and especially the EAP test cases. I haven't yet looked at what exactly caused these, but these did not look exactly good, so that's why a quick note here first to see if anything sounds familiar and someone would already know why the behavior changed between pre release 1 and 2. Many of the negative test cases that verify that server certificate chain validation works by using mismatching trust roots (i.e., server certificate is not issued by any of the trusted CA certificates) are failing. OpenSSL allows the TLS handshake to be completed with the verify callback (set with SSL_set_verify(ssl, SSL_VERIFY_PEER, func)) reports preverify_ok=1 and err=0 for the root CA and the server certificate even though the client side has not configured that root CA as trusted. This worked fine with pre release 1, so I'm quite concerned about the change in behavior when nothing in the application side changed and an untrusted server certificate suddenly became trusted by OpenSSL update.. Is there really an intentional change in OpenSSL requiring something additional to be done to configure peer certificate validation to result in failure with the latest pre release? EAP server side is crashing (segmentation fault) in a pretty strange way when using CRL validation as part of the TLS handshake. This is my test case ap_wpa2_eap_tls_check_crl which shows following in valgrind for the hostapd process that went through the TLS server side exchange. It looks like a crash in OpenSSL check_revocation(), but I guess I'll need to enable more debug symbols somewhere to get bit more helpful output. This same test case worked fine with pre release 1. The test case ends up using a code path that executes cs = SSL_CTX_get_cert_store() and X509_STORE_set_flags(cs, X509_V_FLAG_CRL_CHECK). ==627== Conditional jump or move depends on uninitialised value(s) ==627== at 0x6174D5: check_revocation (in /home/jm/Git/hostap/hostapd/hostapd) ==627== by 0x618280: verify_chain (in /home/jm/Git/hostap/hostapd/hostapd) ==627== by 0x55782F: ssl_add_cert_chain (in /home/jm/Git/hostap/hostapd/hostapd) ==627== by 0x575157: ssl3_output_cert_chain (in /home/jm/Git/hostap/hostapd/hostapd) ==627== by 0x569D3C: ossl_statem_server_construct_message (in /home/jm/Git/hostap/hostapd/hostapd) ==627== by 0x56461D: state_machine (in /home/jm/Git/hostap/hostapd/hostapd) ==627== by 0x5513BB: SSL_accept (in /home/jm/Git/hostap/hostapd/hostapd) ==627== by 0x50AF9C: openssl_handshake (tls_openssl.c:3180) ==627== by 0x50AF9C: openssl_connection_handshake (tls_openssl.c:3273) ==627== by 0x508A21: eap_server_tls_phase1 (eap_server_tls_common.c:316) ==627== by 0x4C41B1: eap_tls_process_msg (eap_server_tls.c:247) ==627== by 0x508C6B: eap_server_tls_process (eap_server_tls_common.c:468) ==627== by 0x4C40C3: eap_tls_process (eap_server_tls.c:259) ==627== ==627== Use of uninitialised value of size 8 ==627== at 0x61742D: check_revocation (in /home/jm/Git/hostap/hostapd/hostapd) ==627== by 0x662C55F: ??? ==627== by 0xEFFFFFFFF: ??? ==627== by 0x654653F: ??? ==627== vex amd64->IR: unhandled instruction bytes: 0x6E 0x6F 0x6E 0x65 0x0 0x52 0x53 0x41 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==627== Invalid read of size 4 ==627== at 0x75FFEA: ??? (in /home/jm/Git/hostap/hostapd/hostapd) ==627== by 0xFFF00038F: ??? ==627== by 0x20441A6D1E48C1FF: ??? ==627== by 0xFFF00038F: ??? ==627== by 0xFFF00038F: ??? ==627== by 0x1: ??? ==627== by 0x654653F: ??? ==627== Address 0x1003029407 is not stack'd, malloc'd or (recently) free'd -- Jouni Malinen PGP id EFC895FA From openssl-users at dukhovni.org Thu Jan 14 17:08:06 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 14 Jan 2016 12:08:06 -0500 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160114164749.GA15188@w1.fi> References: <20160114.154418.799119456171028604.levitte@openssl.org> <20160114164749.GA15188@w1.fi> Message-ID: <6DFE1F6B-C85F-4833-A453-5B5653F7A867@dukhovni.org> > On Jan 14, 2016, at 11:47 AM, Jouni Malinen wrote: > > Many of the negative test cases that verify that server certificate > chain validation works by using mismatching trust roots (i.e., server > certificate is not issued by any of the trusted CA certificates) are > failing. OpenSSL allows the TLS handshake to be completed with the > verify callback (set with SSL_set_verify(ssl, SSL_VERIFY_PEER, func)) > reports preverify_ok=1 and err=0 for the root CA and the server > certificate even though the client side has not configured that root CA > as trusted. This worked fine with pre release 1, so I'm quite concerned > about the change in behavior when nothing in the application side > changed and an untrusted server certificate suddenly became trusted by > OpenSSL update.. Is there really an intentional change in OpenSSL > requiring something additional to be done to configure peer certificate > validation to result in failure with the latest pre release? > > EAP server side is crashing (segmentation fault) in a pretty strange way > when using CRL validation as part of the TLS handshake. This is my test > case ap_wpa2_eap_tls_check_crl which shows following in valgrind for the > hostapd process that went through the TLS server side exchange. It looks > like a crash in OpenSSL check_revocation(), but I guess I'll need to > enable more debug symbols somewhere to get bit more helpful output. This > same test case worked fine with pre release 1. The test case ends up > using a code path that executes cs = SSL_CTX_get_cert_store() and > X509_STORE_set_flags(cs, X509_V_FLAG_CRL_CHECK). Well I rewrote the certificate chain verification code, perhaps some more polish is needed. Please, if possible, send the chain being verified (the leaf and and "untrusted" certs), plus the trusted roots (clearly marked as such), and I'll look into it. -- -- Viktor. From rt at openssl.org Thu Jan 14 17:08:13 2016 From: rt at openssl.org (Daniel Stenberg via RT) Date: Thu, 14 Jan 2016 17:08:13 +0000 Subject: [openssl-dev] [openssl.org #4236] SSL_connect() crash with CRL In-Reply-To: References: Message-ID: Hey I've had this crash for a while with current openssl git master. It is perfectly reproducable using curl test 313 and I have an openssl build here with debug symbols so I can provide more info to help someone diagnose this, just let me know. The test case works fine with all previously released OpenSSL versions I've tried it with. Program received signal SIGSEGV, Segmentation fault. 0x00007fffffffd158 in ?? () (gdb) bt #0 0x00007fffffffd158 in ?? () #1 0x00000000005804ca in check_cert (ctx=0x7fffffffd010) at x509_vfy.c:708 #2 0x00000000005803d5 in check_revocation (ctx=0x7fffffffd010) at x509_vfy.c:685 #3 0x000000000057f3bc in verify_chain (ctx=0x7fffffffd010) at x509_vfy.c:209 #4 0x000000000057f643 in X509_verify_cert (ctx=0x7fffffffd010) at x509_vfy.c:278 #5 0x00000000004c5c32 in ssl_verify_cert_chain (s=0x9ff630, sk=0xa0cb50) at ssl_cert.c:532 #6 0x00000000004df0b7 in tls_process_server_certificate (s=0x9ff630, pkt=0x7fffffffd1f0) at statem/statem_clnt.c:1332 #7 0x00000000004dde03 in ossl_statem_client_process_message (s=0x9ff630, pkt=0x7fffffffd1f0) at statem/statem_clnt.c:739 #8 0x00000000004d57b8 in read_state_machine (s=0x9ff630) at statem/statem.c:610 #9 0x00000000004d538f in state_machine (s=0x9ff630, server=0) at statem/statem.c:430 #10 0x00000000004d4e4c in ossl_statem_connect (s=0x9ff630) at statem/statem.c:218 #11 0x00000000004c2e01 in SSL_do_handshake (s=0x9ff630) at ssl_lib.c:2926 #12 0x00000000004c007c in SSL_connect (s=0x9ff630) at ssl_lib.c:1419 #13 0x0000000000487d28 in ossl_connect_step2 (conn=0x9fc938, sockindex=0) at vtls/openssl.c:2084 #14 0x0000000000489b73 in ossl_connect_common (conn=0x9fc938, sockindex=0, nonblocking=true, done=0x7fffffffd63c) at vtls/openssl.c:2813 #15 0x0000000000489ca4 in Curl_ossl_connect_nonblocking (conn=0x9fc938, sockindex=0, done=0x7fffffffd63c) at vtls/openssl.c:2847 [snipped off more layers of libcurl code that isn't relevant here] (gdb) fr 1 #1 0x00000000005804ca in check_cert (ctx=0x7fffffffd010) at x509_vfy.c:708 708 ok = ctx->get_crl(ctx, &crl, x); (gdb) p ctx $1 = (X509_STORE_CTX *) 0x7fffffffd010 (gdb) p crl $2 = (X509_CRL *) 0x0 (gdb) p x $3 = (X509 *) 0xa0cbb0 (gdb) p ctx->get_crl $5 = (int (*)(X509_STORE_CTX *, X509_CRL **, X509 *)) 0x7fffffffd158 This looks like it points to illegal memory? -- / daniel.haxx.se _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From openssl-users at dukhovni.org Thu Jan 14 17:22:34 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 14 Jan 2016 17:22:34 +0000 Subject: [openssl-dev] [openssl.org #4236] SSL_connect() crash with CRL In-Reply-To: References: Message-ID: <20160114172234.GE646@mournblade.imrryr.org> On Thu, Jan 14, 2016 at 05:08:13PM +0000, Daniel Stenberg via RT wrote: > I've had this crash for a while with current openssl git master. Please don't be shy about reporting problems *before* we cut a release... > (gdb) fr 1 > #1 0x00000000005804ca in check_cert (ctx=0x7fffffffd010) at x509_vfy.c:708 > 708 ok = ctx->get_crl(ctx, &crl, x); > (gdb) p ctx > $1 = (X509_STORE_CTX *) 0x7fffffffd010 > (gdb) p crl > $2 = (X509_CRL *) 0x0 > (gdb) p x > $3 = (X509 *) 0xa0cbb0 > (gdb) p ctx->get_crl > $5 = (int (*)(X509_STORE_CTX *, X509_CRL **, X509 *)) 0x7fffffffd158 Looks like the ctx->get_crl argument is not set. This should fix it: diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c index 73339f3..c395acc 100644 --- a/crypto/x509/x509_vfy.c +++ b/crypto/x509/x509_vfy.c @@ -2150,6 +2150,8 @@ int X509_STORE_CTX_init(X509_STORE_CTX *ctx, X509_STORE *store, X509 *x509, if (store && store->get_crl) ctx->get_crl = store->get_crl; + else + ctx->get_crl = NULL; if (store && store->check_crl) ctx->check_crl = store->check_crl; Dynamically allocated X509_STORE_CTX_new() zeroes out all the structure members, but your's is most likely stack allocated, it might not be zeroed, so the NULL assignment is necessary. -- Viktor. From openssl-users at dukhovni.org Thu Jan 14 17:39:39 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 14 Jan 2016 17:39:39 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160114164749.GA15188@w1.fi> References: <20160114.154418.799119456171028604.levitte@openssl.org> <20160114164749.GA15188@w1.fi> Message-ID: <20160114173939.GF646@mournblade.imrryr.org> On Thu, Jan 14, 2016 at 06:47:49PM +0200, Jouni Malinen wrote: > EAP server side is crashing (segmentation fault) in a pretty strange way > when using CRL validation as part of the TLS handshake. This is my test > case ap_wpa2_eap_tls_check_crl which shows following in valgrind for the > hostapd process that went through the TLS server side exchange. It looks > like a crash in OpenSSL check_revocation(), but I guess I'll need to > enable more debug symbols somewhere to get bit more helpful output. This > same test case worked fine with pre release 1. The test case ends up > using a code path that executes cs = SSL_CTX_get_cert_store() and > X509_STORE_set_flags(cs, X509_V_FLAG_CRL_CHECK). > > ==627== Conditional jump or move depends on uninitialised value(s) > ==627== at 0x6174D5: check_revocation (in /home/jm/Git/hostap/hostapd/hostapd) > ==627== by 0x618280: verify_chain (in /home/jm/Git/hostap/hostapd/hostapd) > ==627== by 0x55782F: ssl_add_cert_chain (in /home/jm/Git/hostap/hostapd/hostapd) > ==627== by 0x575157: ssl3_output_cert_chain (in /home/jm/Git/hostap/hostapd/hostapd) > ==627== by 0x569D3C: ossl_statem_server_construct_message (in /home/jm/Git/hostap/hostapd/hostapd) > ==627== by 0x56461D: state_machine (in /home/jm/Git/hostap/hostapd/hostapd) > ==627== by 0x5513BB: SSL_accept (in /home/jm/Git/hostap/hostapd/hostapd) > ==627== by 0x50AF9C: openssl_handshake (tls_openssl.c:3180) > ==627== by 0x50AF9C: openssl_connection_handshake (tls_openssl.c:3273) > ==627== by 0x508A21: eap_server_tls_phase1 (eap_server_tls_common.c:316) > ==627== by 0x4C41B1: eap_tls_process_msg (eap_server_tls.c:247) > ==627== by 0x508C6B: eap_server_tls_process (eap_server_tls_common.c:468) > ==627== by 0x4C40C3: eap_tls_process (eap_server_tls.c:259) > ==627== > ==627== Use of uninitialised value of size 8 > ==627== at 0x61742D: check_revocation (in /home/jm/Git/hostap/hostapd/hostapd) > ==627== by 0x662C55F: ??? > ==627== by 0xEFFFFFFFF: ??? > ==627== by 0x654653F: ??? See patch just posted, and also pushed to github. This will likely fix the CRL issue. commit 311f27852a18fb9c10f0c1283b639f12eea06de2 Author: Viktor Dukhovni Date: Thu Jan 14 12:23:35 2016 -0500 Always initialize X509_STORE_CTX get_crl pointer -- Viktor. From j at w1.fi Thu Jan 14 18:14:42 2016 From: j at w1.fi (Jouni Malinen) Date: Thu, 14 Jan 2016 20:14:42 +0200 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160114173939.GF646@mournblade.imrryr.org> References: <20160114.154418.799119456171028604.levitte@openssl.org> <20160114164749.GA15188@w1.fi> <20160114173939.GF646@mournblade.imrryr.org> Message-ID: <20160114181442.GA13743@w1.fi> On Thu, Jan 14, 2016 at 05:39:39PM +0000, Viktor Dukhovni wrote: > See patch just posted, and also pushed to github. This will likely fix > the CRL issue. > > commit 311f27852a18fb9c10f0c1283b639f12eea06de2 > Author: Viktor Dukhovni > Date: Thu Jan 14 12:23:35 2016 -0500 > > Always initialize X509_STORE_CTX get_crl pointer Thanks! This applied on top of pre-rel 2 does indeed resolve the CRL issue I saw. -- Jouni Malinen PGP id EFC895FA From openssl-users at dukhovni.org Thu Jan 14 18:31:01 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 14 Jan 2016 18:31:01 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160114164749.GA15188@w1.fi> References: <20160114.154418.799119456171028604.levitte@openssl.org> <20160114164749.GA15188@w1.fi> Message-ID: <20160114183101.GH646@mournblade.imrryr.org> On Thu, Jan 14, 2016 at 06:47:49PM +0200, Jouni Malinen wrote: > Many of the negative test cases that verify that server certificate > chain validation works by using mismatching trust roots (i.e., server > certificate is not issued by any of the trusted CA certificates) are > failing. You should be able to test chains with "openssl verify(1)". This runs X509_verify_cert() in pretty much the same manner as with a live TLS connection. # Trusted root set and matching purpose: $ openssl verify \ -trusted rootcert.pem \ -untrusted rootcert.pem -untrusted cacert.pem \ -purpose sslserver eecert.pem; echo $? eecert.pem; excho $? eecert.pem: OK 0 # No trusted root $ openssl verify \ -untrusted rootcert.pem -untrusted cacert.pem \ -purpose sslserver eecert.pem; echo $? CN = Issuer CA error 20 at 1 depth lookup: unable to get local issuer certificate error eecert.pem: verification failed 2 # Wrong purpose $ openssl verify \ -trusted rootcert.pem \ -untrusted rootcert.pem -untrusted cacert.pem \ -purpose sslclient eecert.pem; echo $? CN = example.com error 26 at 0 depth lookup: unsupported certificate purpose error eecert.pem: verification failed 2 Instead of "-trusted" you can use "-CAfile" and/or "-CApath" as usual, but "-trusted" gives more precise control, because then *only* the certs in that file are trusted, otherwise the default verify locations may also be in play. It would be great if you could reproduce any failures outside of EAP, just by checking the chain. > OpenSSL allows the TLS handshake to be completed with the > verify callback (set with SSL_set_verify(ssl, SSL_VERIFY_PEER, func)) > reports preverify_ok=1 and err=0 for the root CA and the server > certificate even though the client side has not configured that root CA > as trusted. Please send the chain, and the trust store certificates. Are you using CAfile/CApath/both? > Is there really an intentional change in OpenSSL > requiring something additional to be done to configure peer certificate > validation to result in failure with the latest pre release? No, but the implementation has changed considerably, for the better in terms of code maintainability, but new issues are a possibility. -- Viktor. From j at w1.fi Thu Jan 14 18:35:26 2016 From: j at w1.fi (Jouni Malinen) Date: Thu, 14 Jan 2016 20:35:26 +0200 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <6DFE1F6B-C85F-4833-A453-5B5653F7A867@dukhovni.org> References: <20160114.154418.799119456171028604.levitte@openssl.org> <20160114164749.GA15188@w1.fi> <6DFE1F6B-C85F-4833-A453-5B5653F7A867@dukhovni.org> Message-ID: <20160114183526.GA13933@w1.fi> On Thu, Jan 14, 2016 at 12:08:06PM -0500, Viktor Dukhovni wrote: > Well I rewrote the certificate chain verification code, perhaps some more > polish is needed. Please, if possible, send the chain being verified > (the leaf and and "untrusted" certs), plus the trusted roots (clearly > marked as such), and I'll look into it. I'm not sure this is going to be helpful since this is a very basic case and I cannot reproduce this with openssl verify. Anyway, the incorrect CA and the only certificate that was configured as trusted on the client was this one: http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/ca-incorrect.pem while the server used this certificate: http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/server.pem and this issuer: http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/ca.pem Not even the issue subject name match here.. Still, I'm getting this with pre-rel 2 on the client: SSL: SSL_connect:SSLv3/TLS read server hello OpenSSL: RX ver=0x303 content_type=22 (handshake/certificate) TLS: tls_verify_cb - preverify_ok=1 err=0 (ok) ca_cert_verify=1 depth=1 buf='/C=FI/O=w1.fi/CN=Root CA' TLS: tls_verify_cb - preverify_ok=1 err=0 (ok) ca_cert_verify=1 depth=0 buf='/C=FI/O=w1.fi/CN=server.w1.fi' And TLS handshake completes successfully. With OpenSSL 1.0.2d, this fails (as expected): SSL: SSL_connect:SSLv3 read server hello A OpenSSL: RX ver=0x303 content_type=22 (handshake/certificate) TLS: Certificate verification failed, error 19 (self signed certificate in certificate chain) depth 1 for '/C=FI/O=w1.fi/CN=Root CA' So this has to be something with how the chain verification code gets configured.. I'll see if I can find the commit that changed the behavior to make it a bit more easier to figure out what exactly may have happened. -- Jouni Malinen PGP id EFC895FA From hkario at redhat.com Thu Jan 14 18:56:54 2016 From: hkario at redhat.com (Hubert Kario) Date: Thu, 14 Jan 2016 19:56:54 +0100 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: <20160114144128.17780804.28529.45238@ll.mit.edu> References: <20160114144128.17780804.28529.45238@ll.mit.edu> Message-ID: <16513294.pb9p7bj2dx@pintsize.usersys.redhat.com> On Thursday 14 January 2016 14:41:20 Blumenthal, Uri - 0553 - MITLL wrote: > If you already know what Dr. Henson explained in the quoted emails - > then the man page is crystal clear. However, if you don't - then it > is very easy (it was to me) to make an erroneous assumption (that is > not explicitly contradicted) that the digest you specify would be > applied to the data you are signing by pkeyutl itself. > > This is why I'm asking to include a statement (taking the relevant > paragraph from Steve's email seems the best and the simplest way to > me) somewhere in the beginning of the Notes section. That added > statement/paragraph would makeit unambiguously clear that specified > or implied digest and it's parameters are used by pkeyutl ONLY for > sanity checks and inclusion into the signature structure, but are NOT > applied to the input data by pkeyutl (which instead the user must > himself perform prior to invoking pkeyutl). How about such change?: --------->8---------- While the man page of pkeyutl mentions usage of hashes of data, it is not explicit in that the data should be passed in is the result of hashing and that the function will no perform any hashing on the input data. This patch adds a note that makes this explicit. --- doc/apps/pkeyutl.pod | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/doc/apps/pkeyutl.pod b/doc/apps/pkeyutl.pod index 27be9a9..b6f9e40 100644 --- a/doc/apps/pkeyutl.pod +++ b/doc/apps/pkeyutl.pod @@ -135,6 +135,10 @@ and its implementation. The OpenSSL operations and options are indicated below. Unless otherwise mentioned all algorithms support the B option which specifies the digest in use for sign, verify and verifyrecover operations. +This value is used only for sanity-checking the lengths of passed in data and +setting the values of signature structures (e.g. B) of the +generated signature. In other words, if the value of digest is B the +input should be 20 bytes long binary encoding of SHA-1 hash function. The value B should represent a digest name as used in the EVP_get_digestbyname() function for example B. -- 2.4.3 -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From uri at ll.mit.edu Thu Jan 14 19:11:54 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 14 Jan 2016 19:11:54 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: <16513294.pb9p7bj2dx@pintsize.usersys.redhat.com> References: <20160114144128.17780804.28529.45238@ll.mit.edu> <16513294.pb9p7bj2dx@pintsize.usersys.redhat.com> Message-ID: On 1/14/16, 13:56 , "Hubert Kario" wrote: >On Thursday 14 January 2016 14:41:20 Blumenthal, Uri - 0553 - MITLL wrote: >> If you already know what Dr. Henson explained in the quoted emails - >> then the man page is crystal clear. However, if you don't - then it >> is very easy (it was to me) to make an erroneous assumption (that is >> not explicitly contradicted) that the digest you specify would be >> applied to the data you are signing by pkeyutl itself. >> >> This is why I'm asking to include a statement (taking the relevant >> paragraph from Steve's email seems the best and the simplest way to >> me) somewhere in the beginning of the Notes section. That added >> statement/paragraph would make it unambiguously clear that specified >> or implied digest and it's parameters are used by pkeyutl ONLY for >> sanity checks and inclusion into the signature structure, but are NOT >> applied to the input data by pkeyutl (which instead the user must >> himself perform prior to invoking pkeyutl). >How about such change?: >--------->8---------- > >While the man page of pkeyutl mentions usage of hashes of data, >it is not explicit in that the data should be passed in >is the result of hashing and that the function will no perform >any hashing on the input data. I must admit that the above confuses me, even though now I *know* what it should mean. I would prefer something much simpler, like: Pkeyutl will not perform any hashing of the input data. The input data to be signed may or may not be a result of Hashing. Its size must be either equal to the digest output size if digest is specified or implied, or not greater than the size of the public key field or modulus otherwise. >This patch adds a note that makes this explicit. >--- > doc/apps/pkeyutl.pod | 4 ++++ > 1 file changed, 4 insertions(+) > >diff --git a/doc/apps/pkeyutl.pod b/doc/apps/pkeyutl.pod >index 27be9a9..b6f9e40 100644 >--- a/doc/apps/pkeyutl.pod >+++ b/doc/apps/pkeyutl.pod >@@ -135,6 +135,10 @@ and its implementation. The OpenSSL operations and >options are indicated below. > > Unless otherwise mentioned all algorithms support the B >option > which specifies the digest in use for sign, verify and verifyrecover >operations. >+This value is used only for sanity-checking the lengths of passed in >data and +This value and that of the corresponding parameters if specified, is used +only for sanity-checking the lengths of passed in data and >+setting the values of signature structures (e.g. B) of the >+generated signature. In other words, if the value of digest is B >the >+input should be 20 bytes long binary encoding of SHA-1 hash function. > The value B should represent a digest name as used in the > EVP_get_digestbyname() function for example B. +If the digest is neither specified nor implied, the length of the +passed in data must be no greater than the public key modulus or +field size. > >-- >2.4.3 What do you think of the above? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From rt at openssl.org Thu Jan 14 19:33:25 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 14 Jan 2016 19:33:25 +0000 Subject: [openssl-dev] [openssl.org #4237] Failed self-tests on AARCH64 (ARM64) In-Reply-To: References: Message-ID: Working from Master on a LeMaker HiKey (http://www.96boards.org/products/ce/hikey/ and http://www.amazon.com/dp/B019O3QTSA). Its a native build, and not a cross-compile. $ uname -a Linux hikey 3.18.0-linaro-hikey #1 SMP PREEMPT Mon Nov 30 00:11:03 UTC 2015 aarch64 GNU/Linux $ make test ... ../test/recipes/80-test_dane.t ............ ok ../test/recipes/80-test_ocsp.t ............ ok ../test/recipes/80-test_ssl.t ............. 1/43 # Failed test 'test sslv3 with client authentication via BIO pair' # at ../test/recipes/80-test_ssl.t line 345. # Looks like you failed 1 test of 27. ../test/recipes/80-test_ssl.t ............. 3/43 # Failed test 'standard SSL tests' # at ../test/recipes/80-test_ssl.t line 385. ../test/recipes/80-test_ssl.t ............. 9/43 # Failed test at ../test/recipes/80-test_ssl.t line 695. # Failed test at ../test/recipes/80-test_ssl.t line 914. # Failed test at ../test/recipes/80-test_ssl.t line 918. # Looks like you failed 3 tests of 425. ../test/recipes/80-test_ssl.t ............. 11/43 # Failed test 'Version min/max tests' # at ../test/recipes/80-test_ssl.t line 1079. ../test/recipes/80-test_ssl.t ............. 33/43 # Looks like you failed 2 tests of 43. ../test/recipes/80-test_ssl.t ............. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/43 subtests ../test/recipes/80-test_tsa.t ............. ok ../test/recipes/90-test_async.t ........... ok ../test/recipes/90-test_constant_time.t ... ok ... ../test/recipes/90-test_srp.t ............. ok ../test/recipes/90-test_v3name.t .......... ok Test Summary Report ------------------- ../test/recipes/80-test_ssl.t (Wstat: 512 Tests: 43 Failed: 2) Failed tests: 3, 11 Non-zero exit status: 2 Files=69, Tests=281, 140 wallclock secs ( 3.17 usr 0.33 sys + 101.84 cusr 9.26 csys = 114.60 CPU) Result: FAIL Failed 1/69 test programs. 2/281 subtests failed. Makefile:162: recipe for target 'tests' failed make[1]: *** [tests] Error 255 make[1]: Leaving directory '/home/jwalton/openssl/test' Makefile:448: recipe for target 'tests' failed make: *** [tests] Error 2 _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From openssl-users at dukhovni.org Thu Jan 14 19:38:51 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 14 Jan 2016 19:38:51 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160114183526.GA13933@w1.fi> References: <20160114.154418.799119456171028604.levitte@openssl.org> <20160114164749.GA15188@w1.fi> <6DFE1F6B-C85F-4833-A453-5B5653F7A867@dukhovni.org> <20160114183526.GA13933@w1.fi> Message-ID: <20160114193851.GI646@mournblade.imrryr.org> On Thu, Jan 14, 2016 at 08:35:26PM +0200, Jouni Malinen wrote: > Anyway, the incorrect > CA and the only certificate that was configured as trusted on the client > was this one: > http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/ca-incorrect.pem > while the server used this certificate: > > http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/server.pem > and this issuer: > http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/ca.pem Thanks. That's enough info. Patch below. diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c index c395acc..24ca9e3 100644 --- a/crypto/x509/x509_vfy.c +++ b/crypto/x509/x509_vfy.c @@ -580,7 +580,11 @@ static int check_trust(X509_STORE_CTX *ctx, int num_untrusted) int num = sk_X509_num(ctx->chain); int trust; - if (DANETLS_HAS_TA(dane) && num_untrusted > 0) { + /* + * Check for a DANE issuer at depth 1 or greater, if it is a DANE-TA(2) + * match, we're done, otherwise we'll merely record the match depth. + */ + if (DANETLS_HAS_TA(dane) && num_untrusted > 0 && num_untrusted < num) { switch (trust = check_dane_issuer(ctx, num_untrusted)) { case X509_TRUST_TRUSTED: case X509_TRUST_REJECTED: @@ -614,12 +618,13 @@ static int check_trust(X509_STORE_CTX *ctx, int num_untrusted) return X509_TRUST_UNTRUSTED; } - if (ctx->param->flags & X509_V_FLAG_PARTIAL_CHAIN) { + if (num_untrusted > num && ctx->param->flags & X509_V_FLAG_PARTIAL_CHAIN) { /* * Last-resort call with no new trusted certificates, check the leaf * for a direct trust store match. */ - x = sk_X509_value(ctx->chain, 0); + i = 0; + x = sk_X509_value(ctx->chain, i); mx = lookup_cert_match(ctx, x); if (!mx) return X509_TRUST_UNTRUSTED; @@ -2894,7 +2899,7 @@ static int build_chain(X509_STORE_CTX *ctx) trust = check_dane_pkeys(ctx); if (trust == X509_TRUST_UNTRUSTED && sk_X509_num(ctx->chain) == ctx->num_untrusted) - trust = check_trust(ctx, 1); + trust = check_trust(ctx, ctx->num_untrusted+1); } switch (trust) { -- Viktor. From rsalz at akamai.com Thu Jan 14 19:52:17 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 14 Jan 2016 19:52:17 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: References: <20160114144128.17780804.28529.45238@ll.mit.edu> <16513294.pb9p7bj2dx@pintsize.usersys.redhat.com> Message-ID: Okay, how about this. First, remove the NOTES subhead. Add this to the end of the first paragraph: This program does not hash the input data and requires the input data to be of the proper size, and must not be greater than the size of the public key field or modulus. See dgst(1) for a unified Interace. From openssl-users at dukhovni.org Thu Jan 14 20:15:12 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 14 Jan 2016 15:15:12 -0500 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160114193851.GI646@mournblade.imrryr.org> References: <20160114.154418.799119456171028604.levitte@openssl.org> <20160114164749.GA15188@w1.fi> <6DFE1F6B-C85F-4833-A453-5B5653F7A867@dukhovni.org> <20160114183526.GA13933@w1.fi> <20160114193851.GI646@mournblade.imrryr.org> Message-ID: > On Jan 14, 2016, at 2:38 PM, Viktor Dukhovni wrote: > > Thanks. That's enough info. Patch below. Or pull the master branch from github. -- Viktor. From j at w1.fi Thu Jan 14 20:21:56 2016 From: j at w1.fi (Jouni Malinen) Date: Thu, 14 Jan 2016 22:21:56 +0200 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: References: <20160114.154418.799119456171028604.levitte@openssl.org> <20160114164749.GA15188@w1.fi> <6DFE1F6B-C85F-4833-A453-5B5653F7A867@dukhovni.org> <20160114183526.GA13933@w1.fi> <20160114193851.GI646@mournblade.imrryr.org> Message-ID: <20160114202156.GA27894@w1.fi> On Thu, Jan 14, 2016 at 03:15:12PM -0500, Viktor Dukhovni wrote: > > > On Jan 14, 2016, at 2:38 PM, Viktor Dukhovni wrote: > > > > Thanks. That's enough info. Patch below. > > Or pull the master branch from github. Thanks! I confirmed that both the patch on top of pre-rel 2 (+ CRL fix) and the current master branch snapshot fixed all the test cases that I saw failing previously. -- Jouni Malinen PGP id EFC895FA From openssl-users at dukhovni.org Thu Jan 14 20:35:48 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 14 Jan 2016 15:35:48 -0500 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160114202156.GA27894@w1.fi> References: <20160114.154418.799119456171028604.levitte@openssl.org> <20160114164749.GA15188@w1.fi> <6DFE1F6B-C85F-4833-A453-5B5653F7A867@dukhovni.org> <20160114183526.GA13933@w1.fi> <20160114193851.GI646@mournblade.imrryr.org> <20160114202156.GA27894@w1.fi> Message-ID: > On Jan 14, 2016, at 3:21 PM, Jouni Malinen wrote: > > On Thu, Jan 14, 2016 at 03:15:12PM -0500, Viktor Dukhovni wrote: >> >>> On Jan 14, 2016, at 2:38 PM, Viktor Dukhovni wrote: >>> >>> Thanks. That's enough info. Patch below. >> >> Or pull the master branch from github. > > Thanks! I confirmed that both the patch on top of pre-rel 2 (+ CRL fix) > and the current master branch snapshot fixed all the test cases that I > saw failing previously. Thanks for the prompt error report. If you're willing to share your test chains, and if it is likely to be not too difficult to include them with the OpenSSL bundled tests, that might be worth looking into. We definitely need more chain verification test cases, and yours failed with the unpatched "openssl verify" when used just right: $ openssl verify -trusted ca-incorrect.pem -untrusted ca.pem \ -purpose sslserver server.pem The untrusted ca.pem came up trusted incorrectly. The new DANE-specific chain tests are much more comprehensive at this time than the non-DANE ones, we'll need to address that before the final release. From levitte at openssl.org Thu Jan 14 20:59:03 2016 From: levitte at openssl.org (Richard Levitte) Date: Thu, 14 Jan 2016 21:59:03 +0100 (CET) Subject: [openssl-dev] Upcoming build system change Message-ID: <20160114.215903.813205413779228431.levitte@openssl.org> Hi, there's an effort going on to revamp the build system for future OpenSSL, coining it as "unified". The intention is to have one and the same base of information for all platforms, instead of having to maintain one set of files for Unixly platforms, one makefile generator for Windowsy platforms, and one pile of scripts with a serious case of bit rot for VMS. In particular, this is of interest for the VMS folks, as it's the only currently workable build system for upcoming version 1.1. Finding it ========== For now, this change is available on here: https://github.com/levitte/openssl/tree/refactor-build which is git repo https://github.com/levitte/openssl.git, branch refactor-build. Using it ======== Requirements ------------ On all platforms, it requires - Perl! Reports tell me that version 5.10.1 works fine but might need some extra perl modules (Test::More and possibly others. Feedback welcome!). Unix usually has it installed or easy to find. For VMS, there's an install kit on sourceforge (https://sourceforge.net/projects/vmsperlkit/files/Archive/), and Windows, we've always recommended ActiveState Perl (http://www.activestate.com/ActivePerl). - The Perl module Text::Template, which is the driver behind the generation Makefile and other files. This branch relies quite heavily on templates. On Unix, it requires - the usual developmemt stuff. cc, as and make would be the really bare minimum, and maybe I'm forgetting something, but what is usually considered the normal tool chain should work out. On VMS, it requires - DEC C... It's called HP C these days and might be called something else again when VSI starts shipping. It needs to be recent enough to support the qualifiers /NAMES=(AS_IS,SHORTENED) and /REPOSITORY (I welcome feedback on which the minimum version for this is!) - DECset, at the very least MMS. Alternatively, MMK can be used if you can find it (if anyone knows of a place that has it for sure, feedback is welcome!) - Of course, the rest of the tool chain, but that comes with the operating system, no worries there. [I certainly hope I didn't forget anything, but if I did, feedback is welcome!] Config and build ---------------- For Unix users, who are used to the usual generation of a top Makefile from Makefile.org... that is, Makefile.in since recently, this it still the default, but you can always use the unified build as an alternative by adding the flag --unified, like so: ./config --unified make make test # There is no install target yet, it's coming up! You will get One Top Makefile that does everything. It will not touch any other Makefile. For VMS users, the unified build is the only one available in this branch, the old scripts are simply gone. Instead, you configure just like you would on any other platform (well, almost, there isn't any config.com yet, so you'll have to jump directly to the Configure script), and that will generate a descrip.mms: perl Configure vms-alpha ! or vms-ia64 mms mms test ! There is no install target yet. ! As a matter of fact, I'd like to talk about exactly where it ! should install. Let's talk! Features ======== There are a few features in the unified build that are worth testing: 1. Out of source tree builds! It's perfectly possible to do this: mkdir ../build cd ../build perl ../openssl-src/config make make test (and yes, on VMS as well) 2. The generated Makefile supports parallell make: make -j9 (carefull, though, don't try the silliness I tried: make -j9 clean all) Future ====== I plan on making the generated Makefile / descrip.mms full featured, which means at least adding install targets. Then, on to a template for a Windows makefile. ================= Feedback welcome! ================= Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From steve at openssl.org Thu Jan 14 21:51:34 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 14 Jan 2016 21:51:34 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: References: <20160114144128.17780804.28529.45238@ll.mit.edu> <16513294.pb9p7bj2dx@pintsize.usersys.redhat.com> Message-ID: <20160114215134.GA5911@openssl.org> On Thu, Jan 14, 2016, Salz, Rich wrote: > Okay, how about this. First, remove the NOTES subhead. Add this to the end of the first paragraph: > > This program does not hash the input data and requires the input data > to be of the proper size, and must not be greater than the size of > the public key field or modulus. See dgst(1) for a unified > Interace. > The comment about the public key field or modulus is only true for some public key algorithms (e.g. RSA). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From uri at ll.mit.edu Thu Jan 14 21:55:55 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 14 Jan 2016 21:55:55 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: <20160114215134.GA5911@openssl.org> References: <20160114144128.17780804.28529.45238@ll.mit.edu> <16513294.pb9p7bj2dx@pintsize.usersys.redhat.com> <20160114215134.GA5911@openssl.org> Message-ID: On 1/14/16, 16:51 , "openssl-dev on behalf of Dr. Stephen Henson" wrote: >On Thu, Jan 14, 2016, Salz, Rich wrote: > >> Okay, how about this. First, remove the NOTES subhead. Add this to >>the end of the first paragraph: >> >> This program does not hash the input data and requires the input data >> to be of the proper size, and must not be greater than the size of >> the public key field or modulus. See dgst(1) for a unified >> Interace. >> > >The comment about the public key field or modulus is only true for some >public >key algorithms (e.g. RSA). Public key modulus would be true for RSA and DSA. Field would be true for ECDSA (and I daresay EdDSA). What other signatures do we have? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From steve at openssl.org Fri Jan 15 00:02:43 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 15 Jan 2016 00:02:43 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: References: <20160114144128.17780804.28529.45238@ll.mit.edu> <16513294.pb9p7bj2dx@pintsize.usersys.redhat.com> <20160114215134.GA5911@openssl.org> Message-ID: <20160115000243.GB5911@openssl.org> On Thu, Jan 14, 2016, Blumenthal, Uri - 0553 - MITLL wrote: > On 1/14/16, 16:51 , "openssl-dev on behalf of Dr. Stephen Henson" > wrote: > > >On Thu, Jan 14, 2016, Salz, Rich wrote: > > > >> Okay, how about this. First, remove the NOTES subhead. Add this to > >>the end of the first paragraph: > >> > >> This program does not hash the input data and requires the input data > >> to be of the proper size, and must not be greater than the size of > >> the public key field or modulus. See dgst(1) for a unified > >> Interace. > >> > > > >The comment about the public key field or modulus is only true for some > >public > >key algorithms (e.g. RSA). > > Public key modulus would be true for RSA and DSA. Field would be true for > ECDSA (and I daresay EdDSA). What other signatures do we have? For RSA the maximum size depends on the padding mode and is typically less than the modulus. For ECDSA it can be exceed the field size: it is truncated in that case. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From director at openca.org Fri Jan 15 00:25:40 2016 From: director at openca.org (Massimiliano Pala) Date: Thu, 14 Jan 2016 19:25:40 -0500 Subject: [openssl-dev] tls_enc() and pad/aad failures (detected behavior change after 1.0.1p) Message-ID: <56983C84.6070809@openca.org> Hi all, we are facing a weird problem that we started to notice recently and we could not really find the source of the issue. The issue presented itself when starting using OpenSSL v1.0.1p (upgrading from v1.0.1m) in TLS connections. We started noticing the following error: error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert ad record mac This seems to be related to the SSL_AD_BAD_RECORD_MAC. Since this error happens randomly and it is very difficult to reproduce, I tried to see the changes in the tls1_enc() function (t1_enc.c) from the ssl, which is used in the SSL_ENC_METHOD for enc/dec the records. I noticed the following change: /* openssl v1.0.1m/ssl/t1_enc.c */: 812: pad = EVP_CIPHER_CTX_ctrl(ds, EVP_CTRL_AEAD_TLS1_AAD, 13, buf); 813: if (send) { While in the updated version: /* openssl v1.0.1p/ssl/t1_enc.c */ 812: pad = EVP_CIPHER_CTX_ctrl(ds, EVP_CTRL_AEAD_TLS1_AAD, 813: EVP_AEAD_TLS1_AAD_LEN, buf); 814: if (pad <= 0) 815: return -1; 816: if (send) { This change seems pretty interesting, as it might be related to the errors we have started seeing after the upgrade. Now, my questions are (given this might be the source of the error): * Has anybody noticed the different behavior (the same code from 1.0.1p is in the current 1.0.2e - plus some additional checks for DTLS) ? * If the pad <= 0 is detected (not checked before), what can cause the error ? Network errors should be detected at the TCP level, so... it might be an application-level error ? Corrupted buffers ? Shooting in the dark here... Any ideas on how to fix the issue and/or to understand if this is an OpenSSL issue or an application layer issue that would be really appreciated. I am not sure how to proceed at this point.. help ? Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From j at w1.fi Fri Jan 15 09:05:41 2016 From: j at w1.fi (Jouni Malinen) Date: Fri, 15 Jan 2016 11:05:41 +0200 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: References: <20160114.154418.799119456171028604.levitte@openssl.org> <20160114164749.GA15188@w1.fi> <6DFE1F6B-C85F-4833-A453-5B5653F7A867@dukhovni.org> <20160114183526.GA13933@w1.fi> <20160114193851.GI646@mournblade.imrryr.org> <20160114202156.GA27894@w1.fi> Message-ID: <20160115090541.GA7097@w1.fi> On Thu, Jan 14, 2016 at 03:35:48PM -0500, Viktor Dukhovni wrote: > Thanks for the prompt error report. If you're willing to share your > test chains, and if it is likely to be not too difficult to include > them with the OpenSSL bundled tests, that might be worth looking into. All the test case I use with hostapd/wpa_supplicant hwsim testing are available in the public git://w1.fi/hostap.git repository under the tests/hwsim directory. Most cases that are of interest to OpenSSL are in these files: http://w1.fi/cgit/hostap/plain/tests/hwsim/test_ap_eap.py http://w1.fi/cgit/hostap/plain/tests/hwsim/test_suite_b.py The certificates used in the tests are in this directory: http://w1.fi/cgit/hostap/tree/tests/hwsim/auth_serv For the time being, all the certificates are from the repository, but some of the OCSP responses used in the test cases are created dynamically when executing the test cases. > We definitely need more chain verification test cases, and yours failed > with the unpatched "openssl verify" when used just right: > > $ openssl verify -trusted ca-incorrect.pem -untrusted ca.pem \ > -purpose sslserver server.pem > > The untrusted ca.pem came up trusted incorrectly. The new DANE-specific > chain tests are much more comprehensive at this time than the non-DANE > ones, we'll need to address that before the final release. Ah, I didn't even think of the possibility of the CA certificate sent by the server getting trusted, so I just ran openssl verify with -CAfile.. I have been mainly focusing on different areas for EAP-TLS/TTLS/PEAP/FAST testing, so the number of chain verification tests that depend on internal OpenSSL functionality is still quite small. I'm hoping to increase this, but it will take quite a bit of time and effort to get that done.. I have higher priority on covering the additional constraints for validation based on the steps that wpa_supplicant can do on top of the OpenSSL chain validation (e.g., checking specific domain suffix and other subject/altsubject information and OCSP) and handling different formats of certificate and private key encoding. Based on a quick search through the test cases, these are the trivial combinations that can be executed with openssl verify. This assumes the commands are run within that tests/hwsim/auth_server directory. OPENSSL=openssl echo "Should succeed" $OPENSSL verify -trusted ca.pem -purpose sslserver server.pem $OPENSSL verify -trusted ca.pem -untrusted ca.pem -purpose sslserver server.pem $OPENSSL verify -trusted ca.pem -purpose sslclient user.pem $OPENSSL verify -trusted iCA-user/ca-and-root.pem -untrusted iCA-server/cacert.pem -purpose sslserver iCA-server/server.pem $OPENSSL verify -trusted iCA-server/ca-and-root.pem -untrusted iCA-user/cacert.pem -purpose sslclient iCA-user/user.pem $OPENSSL verify -trusted ca.pem -purpose sslserver server-eku-client-server.pem $OPENSSL verify -trusted ca.pem -purpose sslserver server-long-duration.pem $OPENSSL verify -trusted sha512-ca.pem -purpose sslserver sha512-server.pem $OPENSSL verify -trusted sha512-ca.pem -purpose sslserver sha384-server.pem $OPENSSL verify -trusted sha512-ca.pem -purpose sslclient sha512-user.pem $OPENSSL verify -trusted sha512-ca.pem -purpose sslclient sha384-user.pem $OPENSSL verify -trusted ec-ca.pem -purpose sslserver ec-server.pem $OPENSSL verify -trusted ec-ca.pem -purpose sslclient ec-user.pem $OPENSSL verify -trusted ec2-ca.pem -purpose sslserver ec2-server.pem $OPENSSL verify -trusted ec2-ca.pem -purpose sslclient ec2-user.pem echo "Should fail" $OPENSSL verify -trusted ca-incorrect.pem -untrusted ca.pem -purpose sslserver server.pem $OPENSSL verify -trusted ca-incorrect.pem -purpose sslserver server.pem $OPENSSL verify -trusted ca-incorrect.pem -untrusted ca.pem -purpose sslclient user.pem $OPENSSL verify -trusted ca-incorrect.pem -purpose sslclient user.pem $OPENSSL verify -trusted ca.pem -purpose sslserver server-eku-client.pem $OPENSSL verify -trusted ca.pem -purpose sslserver server-expired.pem -- Jouni Malinen PGP id EFC895FA From hkario at redhat.com Fri Jan 15 12:00:34 2016 From: hkario at redhat.com (Hubert Kario) Date: Fri, 15 Jan 2016 13:00:34 +0100 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: References: <20160114144128.17780804.28529.45238@ll.mit.edu> <16513294.pb9p7bj2dx@pintsize.usersys.redhat.com> Message-ID: <1777847.88KJYcgRvU@pintsize.usersys.redhat.com> On Thursday 14 January 2016 19:11:54 Blumenthal, Uri - 0553 - MITLL wrote: > On 1/14/16, 13:56 , "Hubert Kario" wrote: > >On Thursday 14 January 2016 14:41:20 Blumenthal, Uri - 0553 - MITLL wrote: > >> If you already know what Dr. Henson explained in the quoted emails > >> - > >> then the man page is crystal clear. However, if you don't - then it > >> is very easy (it was to me) to make an erroneous assumption (that > >> is > >> not explicitly contradicted) that the digest you specify would be > >> applied to the data you are signing by pkeyutl itself. > >> > >> This is why I'm asking to include a statement (taking the relevant > >> paragraph from Steve's email seems the best and the simplest way to > >> me) somewhere in the beginning of the Notes section. That added > >> statement/paragraph would make it unambiguously clear that > >> specified > >> or implied digest and it's parameters are used by pkeyutl ONLY for > >> sanity checks and inclusion into the signature structure, but are > >> NOT > >> applied to the input data by pkeyutl (which instead the user must > >> himself perform prior to invoking pkeyutl). > > > >How about such change?: > >--------->8---------- > > > >While the man page of pkeyutl mentions usage of hashes of data, > >it is not explicit in that the data should be passed in > >is the result of hashing and that the function will no perform > >any hashing on the input data. > > I must admit that the above confuses me, even though now I *know* what > it should mean. I would prefer something much simpler, like: > > Pkeyutl will not perform any hashing of the input data. > The input data to be signed may or may not be a result of > Hashing. Its size must be either equal to the digest > output size if digest is specified or implied, or not > greater than the size of the public key field or modulus > otherwise. The above was just a a comment to the patch, it needs to be understandable only by the developers :), but yes, the wording was quite clumsy. What was below it is what matters as that's what ends up in the man page. Second try: ------------->8------------- From a4f4971fc3bcc03c5aaead6844beded7f92ab01c Mon Sep 17 00:00:00 2001 From: Hubert Kario Date: Fri, 15 Jan 2016 12:58:22 +0100 Subject: [PATCH] clarify pkeyutl man page Because pkeyutl does not perform hashing of any inputs but the man page mentions data hashes, it's not obvious whether the inputs to this function should be results of hashing or the data itself. This patch adds a note that makes this behaviour explicit. --- doc/apps/pkeyutl.pod | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/doc/apps/pkeyutl.pod b/doc/apps/pkeyutl.pod index 27be9a9..e885474 100644 --- a/doc/apps/pkeyutl.pod +++ b/doc/apps/pkeyutl.pod @@ -135,6 +135,13 @@ and its implementation. The OpenSSL operations and options are indicated below. Unless otherwise mentioned all algorithms support the B option which specifies the digest in use for sign, verify and verifyrecover operations. +This value is used only for sanity-checking the lengths of data passed in to +the B and for setting the values of the structures making up the +signature (e.g. B). In other words, if the value of digest is +B the input should be 20 bytes long binary encoding of SHA-1 hash +function output. In case the digest algorithm is not specified and is not +implied by the key type and/or padding mode, the length of data must not be +bigger than the key's modulus or field size (depending on key type). The value B should represent a digest name as used in the EVP_get_digestbyname() function for example B. -- 2.4.3 ------------->8------------- -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From uri at ll.mit.edu Fri Jan 15 13:29:57 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 15 Jan 2016 13:29:57 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? Message-ID: <20160115133005.17789001.92824.45456@ll.mit.edu> Yes you are correct. But... For RSA ?the max size cannot be greater than the modulus, and while I agree that usually it would be less, in general it doesn't have to be, with no negative impact on security when data to be signed is large enough to leave no room for padding. For ECDSA truncating data to be signed before the actual signing isn't going to win many friends in the security community, especially when this data is not a crypto hash output.? Semi-related: pkeyutl man page says "only SHA1 for ECDSA". Is it still correct? And why such a limitation? Thanks! Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Dr. Stephen Henson? Sent: Thursday, January 14, 2016 19:03 To: openssl-dev at openssl.org Reply To: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? On Thu, Jan 14, 2016, Blumenthal, Uri - 0553 - MITLL wrote: > On 1/14/16, 16:51 , "openssl-dev on behalf of Dr. Stephen Henson" > wrote: > > >On Thu, Jan 14, 2016, Salz, Rich wrote: > > > >> Okay, how about this. First, remove the NOTES subhead. Add this to > >>the end of the first paragraph: > >> > >> This program does not hash the input data and requires the input data > >> to be of the proper size, and must not be greater than the size of > >> the public key field or modulus. See dgst(1) for a unified > >> Interace. > >> > > > >The comment about the public key field or modulus is only true for some > >public > >key algorithms (e.g. RSA). > > Public key modulus would be true for RSA and DSA. Field would be true for > ECDSA (and I daresay EdDSA). What other signatures do we have? For RSA the maximum size depends on the padding mode and is typically less than the modulus. For ECDSA it can be exceed the field size: it is truncated in that case. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From rt at openssl.org Fri Jan 15 13:53:00 2016 From: rt at openssl.org (Albe Laurenz via RT) Date: Fri, 15 Jan 2016 13:53:00 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <11050742.SAcpT9YNAe@pintsize.usersys.redhat.com> <2259170.gFmS5kAaJL@pintsize.usersys.redhat.com> Message-ID: Hubert Kario wrote: > The bug is still present in version tagged as OpenSSL_1_1_0-pre1 > > Moreover I've verified that the miTLS implementation[1] shows expected > behaviour - it accepts the interleaved application data everywhere but > between CCS and Finished. I don't know if that is feasible, but maybe it would be an option to introduce a cache for all Application Data messages received during a renegotiation handshake. The wouldn't be processed right away, but are kept until the handshake has finished and get processed after that. Essentially a reordering of the received messages to avoid the problems. Or is that a silly idea? Yoours, Laurenz Albe From uri at ll.mit.edu Fri Jan 15 14:03:33 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 15 Jan 2016 14:03:33 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: <1777847.88KJYcgRvU@pintsize.usersys.redhat.com> References: <20160114144128.17780804.28529.45238@ll.mit.edu> <16513294.pb9p7bj2dx@pintsize.usersys.redhat.com> <1777847.88KJYcgRvU@pintsize.usersys.redhat.com> Message-ID: <20160115140342.17789001.711.45471@ll.mit.edu> Yes, and I can live with this update.? I still think it would be nice to inform the user of ?what to expect in the (unlikely but possible) case when his data is not an output of some cryptographic hash function.? Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Hubert Kario Sent: Friday, January 15, 2016 07:00 To: Blumenthal, Uri - 0553 - MITLL Cc: openssl-dev at openssl.org; openssl-users at openssl.org Subject: Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? On Thursday 14 January 2016 19:11:54 Blumenthal, Uri - 0553 - MITLL wrote: > On 1/14/16, 13:56 , "Hubert Kario" wrote: > >On Thursday 14 January 2016 14:41:20 Blumenthal, Uri - 0553 - MITLL wrote: > >> If you already know what Dr. Henson explained in the quoted emails > >> - > >> then the man page is crystal clear. However, if you don't - then it > >> is very easy (it was to me) to make an erroneous assumption (that > >> is > >> not explicitly contradicted) that the digest you specify would be > >> applied to the data you are signing by pkeyutl itself. > >> > >> This is why I'm asking to include a statement (taking the relevant > >> paragraph from Steve's email seems the best and the simplest way to > >> me) somewhere in the beginning of the Notes section. That added > >> statement/paragraph would make it unambiguously clear that > >> specified > >> or implied digest and it's parameters are used by pkeyutl ONLY for > >> sanity checks and inclusion into the signature structure, but are > >> NOT > >> applied to the input data by pkeyutl (which instead the user must > >> himself perform prior to invoking pkeyutl). > > > >How about such change?: > >--------->8---------- > > > >While the man page of pkeyutl mentions usage of hashes of data, > >it is not explicit in that the data should be passed in > >is the result of hashing and that the function will no perform > >any hashing on the input data. > > I must admit that the above confuses me, even though now I *know* what > it should mean. I would prefer something much simpler, like: > > Pkeyutl will not perform any hashing of the input data. > The input data to be signed may or may not be a result of > Hashing. Its size must be either equal to the digest > output size if digest is specified or implied, or not > greater than the size of the public key field or modulus > otherwise. The above was just a a comment to the patch, it needs to be understandable only by the developers :), but yes, the wording was quite clumsy. What was below it is what matters as that's what ends up in the man page. Second try: ------------->8------------- >From a4f4971fc3bcc03c5aaead6844beded7f92ab01c Mon Sep 17 00:00:00 2001 From: Hubert Kario Date: Fri, 15 Jan 2016 12:58:22 +0100 Subject: [PATCH] clarify pkeyutl man page Because pkeyutl does not perform hashing of any inputs but the man page mentions data hashes, it's not obvious whether the inputs to this function should be results of hashing or the data itself. This patch adds a note that makes this behaviour explicit. --- doc/apps/pkeyutl.pod | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/doc/apps/pkeyutl.pod b/doc/apps/pkeyutl.pod index 27be9a9..e885474 100644 --- a/doc/apps/pkeyutl.pod +++ b/doc/apps/pkeyutl.pod @@ -135,6 +135,13 @@ and its implementation. The OpenSSL operations and options are indicated below. Unless otherwise mentioned all algorithms support the B option which specifies the digest in use for sign, verify and verifyrecover operations. +This value is used only for sanity-checking the lengths of data passed in to +the B and for setting the values of the structures making up the +signature (e.g. B). In other words, if the value of digest is +B the input should be 20 bytes long binary encoding of SHA-1 hash +function output. In case the digest algorithm is not specified and is not +implied by the key type and/or padding mode, the length of data must not be +bigger than the key's modulus or field size (depending on key type). The value B should represent a digest name as used in the EVP_get_digestbyname() function for example B. -- 2.4.3 ------------->8------------- -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 455 bytes Desc: not available URL: From hkario at redhat.com Fri Jan 15 14:08:18 2016 From: hkario at redhat.com (Hubert Kario) Date: Fri, 15 Jan 2016 15:08:18 +0100 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: <20160115140342.17789001.711.45471@ll.mit.edu> References: <20160114144128.17780804.28529.45238@ll.mit.edu> <1777847.88KJYcgRvU@pintsize.usersys.redhat.com> <20160115140342.17789001.711.45471@ll.mit.edu> Message-ID: <3414390.HukVQldkV1@pintsize.usersys.redhat.com> On Friday 15 January 2016 14:03:33 Blumenthal, Uri - 0553 - MITLL wrote: > Yes, and I can live with this update. Submitted as https://github.com/openssl/openssl/pull/554 -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rt at openssl.org Fri Jan 15 15:32:12 2016 From: rt at openssl.org (Anupam Datta via RT) Date: Fri, 15 Jan 2016 15:32:12 +0000 Subject: [openssl-dev] [openssl.org #4238] DTLS v1.2 not supported In-Reply-To: References: Message-ID: Hi, My openssl version is OpenSSL 1.1.0-pre2-dev xx XXX xxxx But when calling DTLSv1_2_client_method() , it shows compiler error as undefined reference to DTLSv1_2_client_method() Can you please look at this matter ? -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Jan 15 15:32:12 2016 From: rt at openssl.org (Zi Lin via RT) Date: Fri, 15 Jan 2016 15:32:12 +0000 Subject: [openssl-dev] [openssl.org #4239] [PATCH] fixing wildcard matching on punycode domains In-Reply-To: References: Message-ID: Hi OpenSSL Devs, I have this bug fix for a broken wildcard matching on punycode domain in OpenSSL. Specifically, the current implementation actually can't match "www.xn--foobar.com" against a certificate using SAN "*.xn--foobar.com". I filed a issue on github too. https://github.com/openssl/openssl/issues/419 This patch fixes the problem and also introduces a good check/reject on invalid domain names that starts with '-'. The wildcard matching algorithm also needs some improvement, but that is out of the scope of this bug fix. The patch can be applied by "patch -p1 < puny-code-wildcard-match.patch". My build system is Ubuntu 14.04, the version of OpenSSL targeted is the master branch on github. A separate fix for branch OpenSSL_1_0_2-stable is attached as well. The reason we need that separate patch is the test file paths in master and v1.0.2-stable deviated. Any feedback is appreciated. Best, Zi -------------- next part -------------- A non-text attachment was scrubbed... Name: puny-code-wildcard-match.patch Type: application/octet-stream Size: 3125 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: puny-code-wildcard-match-v102.patch Type: application/octet-stream Size: 3468 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Jan 15 15:32:14 2016 From: rt at openssl.org (Tomas Mraz via RT) Date: Fri, 15 Jan 2016 15:32:14 +0000 Subject: [openssl-dev] [openssl.org #4240] Document some of the speed options In-Reply-To: <1452853997.4141.1.camel@redhat.com> References: <1452853997.4141.1.camel@redhat.com> Message-ID: 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.) -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-apps-speed-doc.patch Type: text/x-patch Size: 940 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Jan 15 15:32:14 2016 From: rt at openssl.org (Hanno Boeck via RT) Date: Fri, 15 Jan 2016 15:32:14 +0000 Subject: [openssl-dev] [openssl.org #4241] OpenSSL accepting curve coordinates outside mod p In-Reply-To: <20160115122726.641b7574@pc1> References: <20160115122726.641b7574@pc1> Message-ID: I wanted to report a behavior of the OpenSSL API that I find at least highly unusual and unexpected and I suggest to change. It's regarding these functions to set curve coordinates: EC_POINT_set_affine_coordinates_GFp EC_POINT_set_compressed_coordinates_GFp It is possible to pass them a parameter for the coordinates that is larger than the curves p parameter. It will automatically reduce them modulo p. (See code example attached.) One may argue whether that's a wanted behavior by defining that coordinates > p are considered valid. However that might have unintended consequences, for example (I haven't tested this) it is probably possible to send values larger than p in a TLS ECDHE key exchange as the ephemeral key. This could be used as a fingerprinting mechanism (other crypto libs I've tested reject such coordinates). I find it unlikely that any code relies on this behavior and I suggest changing it so that curve parameters outside the modulus p of the given curve are rejected with an error. -------------- next part -------------- A non-text attachment was scrubbed... Name: point-coordinate-outside-of-p.c Type: text/x-c++src Size: 682 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Jan 15 15:32:16 2016 From: rt at openssl.org (balducci@units.it via RT) Date: Fri, 15 Jan 2016 15:32:16 +0000 Subject: [openssl-dev] [openssl.org #4243] 1.1.0-pre2: bug: EVP_CIPHER_CTX isn't completely opaque In-Reply-To: <11110.1452869847@dschgrazlin2.units.it> References: <11110.1452869847@dschgrazlin2.units.it> Message-ID: hello, apologies if I am missing something here. There seems to be an inconsistency in 1.1.0-pre2 (didn't check -pre1). EVP_CIPHER_CTX is typedef'd in ossl_typ.h like this: typedef struct evp_cipher_ctx_st EVP_CIPHER_CTX; but struct evp_cipher_ctx_st isn't exposed any longer (it used to be in evp.h in 1.0, but has been moved into evp_locl.h in 1.1) This seems to be the reason why trying to build openssh-7.1p2 (with -DOPENSSL_API_COMPAT=0x10000000L) fails with: In file included from ssh_api.h:26:0, from ssh_api.c:21: cipher.h:69:17: error: field 'evp' has incomplete type EVP_CIPHER_CTX evp; Running on linux: Linux 4.4.0 #1 SMP Mon Jan 11 11:49:05 CET 2016 x86_64 GNU/Linux ciao gabriele _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Jan 15 15:32:16 2016 From: rt at openssl.org (Hanno Boeck via RT) Date: Fri, 15 Jan 2016 15:32:16 +0000 Subject: [openssl-dev] [openssl.org #4242] OpenSSL ECC coordinate functions accept invalid curve points In-Reply-To: <20160115123059.2bf5ae32@pc1> References: <20160115123059.2bf5ae32@pc1> Message-ID: The EC_POINT_* API functions accept invalid curve points and don't do point verification. Invalid curve points are one of the major implementation pitfalls in ECC and can lead to attacks [1]. OpenSSL properly validates points in the _oct2point functions, but I still find this risky. This looks like an API behavior that could easily lead to desasters if someone not aware of that behavior decided to implement a crypto protocol and use OpenSSL's EC_ functions for it. BoringSSL changed this recently [2]. They now always do a check with EC_POINT_is_on_curve() when setting curve coordinates. I would recommend doing a similar change in OpenSSL and thus make the API more resistant to misuse that could lead to fatal security issues. [1] http://web-in-security.blogspot.dk/2015/09/practical-invalid-curve-attacks.html [2] https://boringssl.googlesource.com/boringssl/+/38feb990a183362397ebc62774cc07374d146c83%5E%21/#F0 _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From hanno at hboeck.de Fri Jan 15 15:37:28 2016 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Fri, 15 Jan 2016 16:37:28 +0100 Subject: [openssl-dev] Behavior of OpenSSL EC API regarding point setting In-Reply-To: References: <20151215232149.5d33a1cd@pc1> Message-ID: <20160115163728.0062f76d@pc1> On Wed, 16 Dec 2015 16:01:02 +0000 "Salz, Rich" wrote: > > I would recommend and find it generally a cleaner approach if the > > curve point setting functions would reject both invalid points and > > point coordinates larger than p. > > Certainly out-of-range. Not sure about point invalidity. But can > you open one or two tickets for this? Done now, RT tickets #4241 and #4242. -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rt at openssl.org Fri Jan 15 15:41:49 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 15 Jan 2016 15:41:49 +0000 Subject: [openssl-dev] [openssl.org #4238] DTLS v1.2 not supported In-Reply-To: References: Message-ID: On Fri Jan 15 15:32:12 2016, adbd04 at gmail.com wrote: > Hi, > My openssl version is OpenSSL 1.1.0-pre2-dev xx XXX xxxx > But when calling DTLSv1_2_client_method() , it shows compiler error as > undefined reference to DTLSv1_2_client_method() > Can you please look at this matter ? This has been answered here: https://stackoverflow.com/questions/34788659/openssl-support-for-dtls-v1-2 Closing this ticket Matt From rt at openssl.org Fri Jan 15 17:15:28 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Fri, 15 Jan 2016 17:15:28 +0000 Subject: [openssl-dev] [openssl.org #4243] 1.1.0-pre2: bug: EVP_CIPHER_CTX isn't completely opaque In-Reply-To: <11110.1452869847@dschgrazlin2.units.it> References: <11110.1452869847@dschgrazlin2.units.it> Message-ID: This is according to our interpretation of "type opacity", meaning that the type name is available but not its content. "Data hiding" is another way to put it. This means that there will be a need to adapt, stack allocated EVP_CIPHER_CTX is no longer allowed, but there are functions to allocate and free them on/from the heap (EVP_CIPHER_CTX_new and EVP_CIPHER_CTX_free). What's your interpretation of type opacity? I'm not going to say that you're wrong and we're perfect, we're interested in feedback and constructive arguments. I just wanted to let you know our thinking so far. Cheers, Richard Vid Fre, 15 Jan 2016 kl. 15.32.15, skrev balducci at units.it: > hello, > > apologies if I am missing something here. > > There seems to be an inconsistency in 1.1.0-pre2 (didn't check -pre1). > > EVP_CIPHER_CTX is typedef'd in ossl_typ.h like this: > > typedef struct evp_cipher_ctx_st EVP_CIPHER_CTX; > > but struct evp_cipher_ctx_st isn't exposed any longer (it used to be > in evp.h in 1.0, but has been moved into evp_locl.h in 1.1) > > This seems to be the reason why trying to build openssh-7.1p2 (with > -DOPENSSL_API_COMPAT=0x10000000L) fails with: > > In file included from ssh_api.h:26:0, > from ssh_api.c:21: > cipher.h:69:17: error: field 'evp' has incomplete type > EVP_CIPHER_CTX evp; > > Running on linux: > Linux 4.4.0 #1 SMP Mon Jan 11 11:49:05 CET 2016 x86_64 GNU/Linux > > > ciao > gabriele > > _______________________________________________ > openssl-bugs-mod mailing list > openssl-bugs-mod at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod -- Richard Levitte levitte at openssl.org From rt at openssl.org Fri Jan 15 17:15:32 2016 From: rt at openssl.org (Eric Mumpower via RT) Date: Fri, 15 Jan 2016 17:15:32 +0000 Subject: [openssl-dev] [openssl.org #4244] dhparam -check should In-Reply-To: <892C51C9-EDF8-436A-8E58-F440C4145ECB@akamai.com> References: <892C51C9-EDF8-436A-8E58-F440C4145ECB@akamai.com> Message-ID: Code inspection suggests that when running "openssl dhparam -check -out foo 2048", the safety of the generated prime is only indicated via stdout. I suggest one of three safety improvements here, in order of what I believe to be decreasing safety: (1) Regardless of whether the "-check" flag is specified, dhparam should always call DH_check() on values it generates, and should never output (in any form) the value of an unsafe DH parameter it generated. When problems are found, I don't care whether it errors out or retries, so long as this behavior is clearly documented in the dhparam manpage. (2) If the "-check" flag is specified, "dhparam -check" should never output (in any form) the value of an unsafe DH parameter it generated. When problems are found, I don't care whether it errors out or retries, so long as this behavior is clearly documented in the dhparam manpage. (3) If the "-check" flag is specified, and DH_check() reports any problems, the program exit status should indicate failure, in addition to the current stdout warning. This allows easy programmatic usage without needing to recognize the stdout syntax used by dhparam. From doctor at doctor.nl2k.ab.ca Fri Jan 15 17:11:09 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 15 Jan 2016 10:11:09 -0700 Subject: [openssl-dev] [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160104202956.GA24447@doctor.nl2k.ab.ca> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> <20160104202956.GA24447@doctor.nl2k.ab.ca> Message-ID: <20160115171109.GA22842@doctor.nl2k.ab.ca> On Mon, Jan 04, 2016 at 01:29:56PM -0700, The Doctor wrote: > On Mon, Jan 04, 2016 at 07:22:04PM +0000, Viktor Dukhovni wrote: > > On Mon, Jan 04, 2016 at 09:08:31AM -0700, The Doctor wrote: > > > > > if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), > > > SSLeay_version(SSLEAY_VERSION))) <0) > > > > > > Could there be anything that is causing openssh not to see the new openssl 1.1 > > > > The above. The SSLeay names are gone. The new way is: > > > > if ((rc = fprintf(fd ,"%08x (%s)\n", OpenSSL_version_num(), > > OpenSSL_version(OPENSSL_VERSION))) <0) > > > > I think it is likely prudent at this time to restore source- > > backwards-compatible behaviour, by adding to : > > > > #if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < 0x10100000L > > # include > > # define SSLeay OpenSSL_version_num > > # define SSLeay_version OpenSSL_version > > # define SSLEAY_VERSION_NUMBER OPENSSL_VERSION_NUMBER > > # define SSLEAY_VERSION OPENSSL_VERSION > > # define SSLEAY_CFLAGS OPENSSL_CFLAGS > > # define SSLEAY_BUILT_ON OPENSSL_BUILT_ON > > # define SSLEAY_PLATFORM OPENSSL_PLATFORM > > # define SSLEAY_DIR OPENSSL_DIR > > #endif /* OPENSSL_API_COMPAT */ > > > > Users who want to make sure they are avoiding interfaces that are > > deprecated with 1.1.0 can set OPENSSL_API_COMPAT to 0x10100000L or > > higher as appropriate. > > That is one way. > > Can we get developers to come on baord so that > we can launch a new era without incident? All right, can the above be committed and any other source-backwards-compatible behaviour ? This will help API developers a lot. BTW, I got openssl-SNAP-20160115 to behave nicely. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From rsalz at akamai.com Fri Jan 15 17:21:56 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 15 Jan 2016 17:21:56 +0000 Subject: [openssl-dev] [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160115171109.GA22842@doctor.nl2k.ab.ca> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> <20160104202956.GA24447@doctor.nl2k.ab.ca> <20160115171109.GA22842@doctor.nl2k.ab.ca> Message-ID: <0cb2942f10ef4a8c93abf96b5786b4d1@usma1ex-dag1mb1.msg.corp.akamai.com> > All right, can the above be committed and any other source-backwards- > compatible behaviour ? > > This will help API developers a lot. It was done and is part of the yesterday's alpha release. From rt at openssl.org Fri Jan 15 18:08:38 2016 From: rt at openssl.org (Viktor Dukhovni via RT) Date: Fri, 15 Jan 2016 18:08:38 +0000 Subject: [openssl-dev] [openssl.org #4239] [PATCH] fixing wildcard matching on punycode domains In-Reply-To: References: Message-ID: > On Jan 15, 2016, at 10:32 AM, Zi Lin via RT wrote: > > Yes, this will get fixed. Thanks. -- Viktor. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1963 bytes Desc: not available URL: From rainer.jung at kippdata.de Fri Jan 15 18:18:25 2016 From: rainer.jung at kippdata.de (Rainer Jung) Date: Fri, 15 Jan 2016 19:18:25 +0100 Subject: [openssl-dev] Website "Downloads": remove 1.1.0pre1 from list of downloadable files Message-ID: <569937F1.6000203@kippdata.de> Hi, the list of downloadable files on http://openssl.org/source/ contains pre1 *and* pre2 files for 1.1. Furthermore pre1 is listed above pre2. IMHO pre2 is what people should test and pre1 is no longer entitled to be listed on that page. So I suggest to remove pre1 from the list. I don't know how this list is maintained, if auto-generated or manually. It seems the web git is not public. In addition one could wish to put the preferred major version (1.0.2?) first in the list. Despite the version explanations in front of the list, it would help people to choose the right one. But of course what is preferred might change over time and is harder to automate with scripting. Thanks and regards, Rainer From levitte at openssl.org Fri Jan 15 18:34:40 2016 From: levitte at openssl.org (Richard Levitte) Date: Fri, 15 Jan 2016 19:34:40 +0100 (CET) Subject: [openssl-dev] Website "Downloads": remove 1.1.0pre1 from list of downloadable files In-Reply-To: <569937F1.6000203@kippdata.de> References: <569937F1.6000203@kippdata.de> Message-ID: <20160115.193440.616803330404655392.levitte@openssl.org> In message <569937F1.6000203 at kippdata.de> on Fri, 15 Jan 2016 19:18:25 +0100, Rainer Jung said: rainer.jung> Hi, rainer.jung> rainer.jung> the list of downloadable files on http://openssl.org/source/ contains rainer.jung> pre1 *and* pre2 files for 1.1. Furthermore pre1 is listed above rainer.jung> pre2. IMHO pre2 is what people should test and pre1 is no longer rainer.jung> entitled to be listed on that page. So I suggest to remove pre1 from rainer.jung> the list. You're entirely correct. I'm going in and fixing now. rainer.jung> I don't know how this list is maintained, if auto-generated or rainer.jung> manually. It seems the web git is not public. Our release script should have dealt with it, but it's possible we've failed to adapt it the pre-release format files. I'll have a look later. rainer.jung> In addition one could wish to put the preferred major version (1.0.2?) rainer.jung> first in the list. Despite the version explanations in front of the rainer.jung> list, it would help people to choose the right one. But of course what rainer.jung> is preferred might change over time and is harder to automate with rainer.jung> scripting. Food for thought. Not promising anything, but will certainly look into it. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From uri at ll.mit.edu Fri Jan 15 18:38:32 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 15 Jan 2016 18:38:32 +0000 Subject: [openssl-dev] Website "Downloads": remove 1.1.0pre1 from list of downloadable files In-Reply-To: <20160115.193440.616803330404655392.levitte@openssl.org> References: <569937F1.6000203@kippdata.de> <20160115.193440.616803330404655392.levitte@openssl.org> Message-ID: On 1/15/16, 13:34 , "openssl-dev on behalf of Richard Levitte" wrote: >In message <569937F1.6000203 at kippdata.de> on Fri, 15 Jan 2016 19:18:25 >+0100, Rainer Jung said: > >rainer.jung> In addition one could wish to put the preferred major >version (1.0.2?) >rainer.jung> first in the list. Despite the version explanations in front >of the >rainer.jung> list, it would help people to choose the right one. But of >course what >rainer.jung> is preferred might change over time and is harder to >automate with >rainer.jung> scripting. > >Food for thought. Not promising anything, but will certainly look >into it. Another option is to have a ?latest? symlink in that directory pointing to the current/latest file to pick, updated as a new release appears on the server? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From levitte at openssl.org Fri Jan 15 18:48:21 2016 From: levitte at openssl.org (Richard Levitte) Date: Fri, 15 Jan 2016 19:48:21 +0100 (CET) Subject: [openssl-dev] Website "Downloads": remove 1.1.0pre1 from list of downloadable files In-Reply-To: References: <569937F1.6000203@kippdata.de> <20160115.193440.616803330404655392.levitte@openssl.org> Message-ID: <20160115.194821.878029035218974164.levitte@openssl.org> In message on Fri, 15 Jan 2016 18:38:32 +0000, "Blumenthal, Uri - 0553 - MITLL" said: uri> On 1/15/16, 13:34 , "openssl-dev on behalf of Richard Levitte" uri> wrote: uri> uri> >In message <569937F1.6000203 at kippdata.de> on Fri, 15 Jan 2016 19:18:25 uri> >+0100, Rainer Jung said: uri> > uri> >rainer.jung> In addition one could wish to put the preferred major uri> >version (1.0.2?) uri> >rainer.jung> first in the list. Despite the version explanations in front uri> >of the uri> >rainer.jung> list, it would help people to choose the right one. But of uri> >course what uri> >rainer.jung> is preferred might change over time and is harder to uri> >automate with uri> >rainer.jung> scripting. uri> > uri> >Food for thought. Not promising anything, but will certainly look uri> >into it. uri> uri> Another option is to have a ?latest? symlink in that directory pointing to uri> the current/latest file to pick, updated as a new release appears on the uri> server? We used to have that before we remade the site (for the better, all things considered)... it seems that got lost in the process. I'll look into it. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Fri Jan 15 19:42:28 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 15 Jan 2016 14:42:28 -0500 Subject: [openssl-dev] [openssl.org #4243] 1.1.0-pre2: bug: EVP_CIPHER_CTX isn't completely opaque In-Reply-To: References: <11110.1452869847@dschgrazlin2.units.it> Message-ID: > On Jan 15, 2016, at 10:32 AM, balducci at units.it via RT wrote: > > This seems to be the reason why trying to build openssh-7.1p2 (with > -DOPENSSL_API_COMPAT=0x10000000L) fails with: > > In file included from ssh_api.h:26:0, > from ssh_api.c:21: > cipher.h:69:17: error: field 'evp' has incomplete type > EVP_CIPHER_CTX evp; Note that OPENSSL_API_COMPAT does not guarantee full source compatibility, rather it merely prevents the suppression of *deprecated* interfaces. Interfaces that changed incompatibly as a result of newly opaque data structures still require code changes. With OPENSSL_API_COMPAT you get as much compatibility as is still available with that API, but not 100%, because making structures opaque did force some incompatible changes. -- Viktor. From rt at openssl.org Fri Jan 15 19:42:40 2016 From: rt at openssl.org (Viktor Dukhovni via RT) Date: Fri, 15 Jan 2016 19:42:40 +0000 Subject: [openssl-dev] [openssl.org #4243] 1.1.0-pre2: bug: EVP_CIPHER_CTX isn't completely opaque In-Reply-To: References: <11110.1452869847@dschgrazlin2.units.it> Message-ID: > On Jan 15, 2016, at 10:32 AM, balducci at units.it via RT wrote: > > This seems to be the reason why trying to build openssh-7.1p2 (with > -DOPENSSL_API_COMPAT=0x10000000L) fails with: > > In file included from ssh_api.h:26:0, > from ssh_api.c:21: > cipher.h:69:17: error: field 'evp' has incomplete type > EVP_CIPHER_CTX evp; Note that OPENSSL_API_COMPAT does not guarantee full source compatibility, rather it merely prevents the suppression of *deprecated* interfaces. Interfaces that changed incompatibly as a result of newly opaque data structures still require code changes. With OPENSSL_API_COMPAT you get as much compatibility as is still available with that API, but not 100%, because making structures opaque did force some incompatible changes. -- Viktor. From rt at openssl.org Fri Jan 15 19:45:43 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Fri, 15 Jan 2016 19:45:43 +0000 Subject: [openssl-dev] [openssl.org #4245] OpenSSL-1.1-pre2 e_oss.h and inline conflicts In-Reply-To: References: Message-ID: e_os.2 line 327:: # if !defined(inline) && !defined(__cplusplus) Should this be: # if !defined(ossl_inline) && !defined(__cplusplus) The purpose of this section is to end up with a good definition for ossl_inline If some preceding header file (and I have run across this) does a #define inline The e_os2.h will not change the ossl_inline and the safestack.h and other header files will prodice pages of errors. -- Douglas E. Engert > -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From openssl-users at dukhovni.org Fri Jan 15 20:34:58 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 15 Jan 2016 20:34:58 +0000 Subject: [openssl-dev] [openssl.org #4239] [PATCH] fixing wildcard matching on punycode domains In-Reply-To: References: Message-ID: <20160115203458.GM646@mournblade.imrryr.org> On Fri, Jan 15, 2016 at 03:32:12PM +0000, Zi Lin via RT wrote: > I have this bug fix for a broken wildcard matching on punycode domain > in OpenSSL. Specifically, the current implementation actually can't > match "www.xn--foobar.com" against a certificate using SAN > "*.xn--foobar.com". I filed a issue on github too. > https://github.com/openssl/openssl/issues/419 Thanks, these are now in the 1.0.2 and master trees, fixed in the next release. -- Viktor. From rt at openssl.org Fri Jan 15 22:09:50 2016 From: rt at openssl.org (deengert@gmail.com via RT) Date: Fri, 15 Jan 2016 22:09:50 +0000 Subject: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl req fails to use engine In-Reply-To: <56996C4C.5090303@gmail.com> References: <56996C4C.5090303@gmail.com> Message-ID: req.c (and many of the other apps) appear to have lost the ability to use an engine. The attached diff is against the github.com verison using Tag OpenSSL_1_1-pre2 In the req_options[] table: OPT_KEY is set to "S" so pre- checking of the parameters does not drop the string passed to the engine. OPT_KEY_FORM is set to "f" so pre-checking will allow engine The engine is saved: e = setup_engine(opt_arg(), 1); (I turned on debug, may want that off. ) to allow the theOPT_KEY_FORM to be an engine: if (!opt_format(opt_arg(), OPT_FMT_PEMDER|OPT_FMT_ENGINE, &keyform)) This was tested with a modified version of OpenSC using ECDSA key on card to generate a self signed certificate. openssl req -config /tmp/genreq.6156.openssl.conf -engine pkcs11 -keyform e -sha256 -new -key slot_1-id_2 -out /tmp/selfsigned.pem -x509 -text P.S. The EC_KEY_* functions appear to be working too (#4225) Have not tried the ECDH yet. -- Douglas E. Engert -------------- next part -------------- A non-text attachment was scrubbed... Name: req.c.diff Type: text/x-patch Size: 1418 bytes Desc: not available URL: From rt at openssl.org Fri Jan 15 23:24:16 2016 From: rt at openssl.org (Blumenthal, Uri - 0553 - MITLL via RT) Date: Fri, 15 Jan 2016 23:24:16 +0000 Subject: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl req fails to use engine In-Reply-To: <20160115230320.17788998.66913.45627@ll.mit.edu> References: <20160115230320.17788998.66913.45627@ll.mit.edu> Message-ID: Doug, could you please take a look at PR #548 (or is it #549)? It also addresses this KEY_FORM issue. Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: deengert at gmail.com via RT Sent: Friday, January 15, 2016 17:10 Reply To: rt at openssl.org Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl req fails to use engine req.c (and many of the other apps) appear to have lost the ability to use an engine. The attached diff is against the github.com verison using Tag OpenSSL_1_1-pre2 In the req_options[] table: OPT_KEY is set to "S" so pre- checking of the parameters does not drop the string passed to the engine. OPT_KEY_FORM is set to "f" so pre-checking will allow engine The engine is saved: e = setup_engine(opt_arg(), 1); (I turned on debug, may want that off. ) to allow the theOPT_KEY_FORM to be an engine: if (!opt_format(opt_arg(), OPT_FMT_PEMDER|OPT_FMT_ENGINE, &keyform)) This was tested with a modified version of OpenSC using ECDSA key on card to generate a self signed certificate. openssl req -config /tmp/genreq.6156.openssl.conf -engine pkcs11 -keyform e -sha256 -new -key slot_1-id_2 -out /tmp/selfsigned.pem -x509 -text P.S. The EC_KEY_* functions appear to be working too (#4225) Have not tried the ECDH yet. -- Douglas E. Engert -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From rt at openssl.org Sat Jan 16 03:14:17 2016 From: rt at openssl.org (Rainer Jung via RT) Date: Sat, 16 Jan 2016 03:14:17 +0000 Subject: [openssl-dev] [openssl.org #4247] 1.1.0-pre2 on Sparc: incomplete adjustments for EVP_CIPHER_CTX opaqueness In-Reply-To: <5699B519.5070002@kippdata.de> References: <5699B519.5070002@kippdata.de> Message-ID: Building 1.1.0-pre2 on Solaris Sparc I get compilation errors, e.g. e_des.c: In function 'des_init_key': e_des.c:250:23: error: dereferencing pointer to incomplete type int mode = ctx->cipher->flags & EVP_CIPH_MODE; The following patch fixes them: Index: crypto/evp/e_camellia.c --- crypto/evp/e_camellia.c 2016-01-14 10:51:32.000000000 +0100 +++ crypto/evp/e_camellia.c 2016-01-16 04:01:44.443269000 +0100 @@ -119,10 +119,10 @@ const unsigned char *iv, int enc) { int ret, mode, bits; - EVP_CAMELLIA_KEY *dat = (EVP_CAMELLIA_KEY *) ctx->cipher_data; + EVP_CAMELLIA_KEY *dat = (EVP_CAMELLIA_KEY *) EVP_CIPHER_CTX_cipher_data(ctx); - mode = ctx->cipher->flags & EVP_CIPH_MODE; - bits = ctx->key_len * 8; + mode = EVP_CIPHER_CTX_mode(ctx); + bits = EVP_CIPHER_CTX_key_length(ctx) * 8; cmll_t4_set_key(key, bits, &dat->ks); Index: crypto/evp/e_des.c --- crypto/evp/e_des.c 2016-01-14 10:51:32.000000000 +0100 +++ crypto/evp/e_des.c 2016-01-16 03:56:50.834081000 +0100 @@ -247,7 +247,7 @@ dat->stream.cbc = NULL; # if defined(SPARC_DES_CAPABLE) if (SPARC_DES_CAPABLE) { - int mode = ctx->cipher->flags & EVP_CIPH_MODE; + int mode = EVP_CIPHER_CTX_mode(ctx); if (mode == EVP_CIPH_CBC_MODE) { des_t4_key_expand(key, &dat->ks.ks); Index: crypto/evp/e_des3.c --- crypto/evp/e_des3.c 2016-01-14 10:51:32.000000000 +0100 +++ crypto/evp/e_des3.c 2016-01-16 03:57:51.607381000 +0100 @@ -270,7 +270,7 @@ dat->stream.cbc = NULL; # if defined(SPARC_DES_CAPABLE) if (SPARC_DES_CAPABLE) { - int mode = ctx->cipher->flags & EVP_CIPH_MODE; + int mode = EVP_CIPHER_CTX_mode(ctx); if (mode == EVP_CIPH_CBC_MODE) { des_t4_key_expand(&deskey[0], &dat->ks1); @@ -297,7 +297,7 @@ dat->stream.cbc = NULL; # if defined(SPARC_DES_CAPABLE) if (SPARC_DES_CAPABLE) { - int mode = ctx->cipher->flags & EVP_CIPH_MODE; + int mode = EVP_CIPHER_CTX_mode(ctx); if (mode == EVP_CIPH_CBC_MODE) { des_t4_key_expand(&deskey[0], &dat->ks1); Thanks and regards, Rainer From rt at openssl.org Sat Jan 16 03:14:17 2016 From: rt at openssl.org (marc.stern@approach.be via RT) Date: Sat, 16 Jan 2016 03:14:17 +0000 Subject: [openssl-dev] [openssl.org #4248] Link error under Windows In-Reply-To: <5698E644.1080209@approach.be> References: <5698E644.1080209@approach.be> Message-ID: On any version of Windows (32 or 64 bits), if using the "no-deprecated" configure flag, some functions (see list below) are not compiled but they are still referenced in LIBEAY32.DEF. This gives the following error: LIBEAY32.def : error LNK2001: unresolved external symbol ... List of functions: - BN_BLINDING_get_thread_id - BN_BLINDING_set_thread_id - BN_CTX_init - BN_generate_prime - BN_get_params - BN_is_prime - BN_is_prime_fasttest - BN_set_params - CRYPTO_get_id_callback - CRYPTO_set_id_callback - CRYPTO_thread_id - DH_generate_parameters - DSA_generate_parameters - ERR_remove_state - RSA_generate_key - bn_dup_expand From rt at openssl.org Sat Jan 16 03:48:21 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 16 Jan 2016 03:48:21 +0000 Subject: [openssl-dev] [openssl.org #4247] 1.1.0-pre2 on Sparc: incomplete adjustments for EVP_CIPHER_CTX opaqueness In-Reply-To: <5699B519.5070002@kippdata.de> References: <5699B519.5070002@kippdata.de> Message-ID: Fix committed ecdd0ff733985fb573d687fe85fa533f62f6cfd8 thanks -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat Jan 16 06:17:14 2016 From: rt at openssl.org (Joey Yandle via RT) Date: Sat, 16 Jan 2016 06:17:14 +0000 Subject: [openssl-dev] [openssl.org #4248] Link error under Windows In-Reply-To: <5699E05E.3060508@dancingdragon.be> References: <5698E644.1080209@approach.be> <5699E05E.3060508@dancingdragon.be> Message-ID: This appears to be the same issue as when building with no-engine: https://github.com/openssl/openssl/issues/536 Hopefully Richard Levitte's new build system will be able to handle this. Presumably in the old system this would be handled by the last lines of ms\do_win64a.bat: perl util\mkdef.pl 32 libeay > ms\libeay32.def perl util\mkdef.pl 32 ssleay > ms\ssleay32.def On 1/15/2016 7:14 PM, marc.stern at approach.be via RT wrote: > On any version of Windows (32 or 64 bits), if using the "no-deprecated" > configure flag, some functions (see list below) are not compiled but > they are still referenced in LIBEAY32.DEF. This gives the following > error: LIBEAY32.def : error LNK2001: unresolved external symbol ... > > List of functions: > - BN_BLINDING_get_thread_id > - BN_BLINDING_set_thread_id > - BN_CTX_init > - BN_generate_prime > - BN_get_params > - BN_is_prime > - BN_is_prime_fasttest > - BN_set_params > - CRYPTO_get_id_callback > - CRYPTO_set_id_callback > - CRYPTO_thread_id > - DH_generate_parameters > - DSA_generate_parameters > - ERR_remove_state > - RSA_generate_key > - bn_dup_expand > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From dragon at dancingdragon.be Sat Jan 16 06:13:20 2016 From: dragon at dancingdragon.be (Joey Yandle) Date: Fri, 15 Jan 2016 22:13:20 -0800 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160114.215903.813205413779228431.levitte@openssl.org> References: <20160114.215903.813205413779228431.levitte@openssl.org> Message-ID: <5699DF80.6030609@dancingdragon.be> I tried building your branch on windows, but the windows Configure targets appear to be missing: c:\src\openssl>perl Configure VC-WIN64A Configuring OpenSSL version 1.1.0-pre3-dev (0x0x10100003L) ... Configuring for VC-WIN64A Warning! target VC-WIN64A doesn't exist! Can't use an undefined value as an ARRAY reference at Configure line 825. I verified that the windows targets are present in Configurations/10-main.conf: "VC-WIN64A" => { inherit_from => [ "VC-common", asm("x86_64_asm") ], cflags => add(" ", "-DUNICODE -D_UNICODE"), sys_id => "WIN64A", bn_ops => "SIXTY_FOUR_BIT RC4_CHUNK_LL DES_INT EXPORT_VAR_AS_FN", bn_obj => sub { my $r=join(" ", at _); $r=~s/x86_64\-gcc/bn_asm/; $r; }, perlasm_scheme => "auto", build_scheme => [ "mk1mf", "VC-W64" ], }, Am I doing something wrong? Your email didn't actually say anything about the windows build... cheers, Joey On 1/14/2016 12:59 PM, Richard Levitte wrote: > Hi, > > there's an effort going on to revamp the build system for future > OpenSSL, coining it as "unified". The intention is to have one and > the same base of information for all platforms, instead of having to > maintain one set of files for Unixly platforms, one makefile generator > for Windowsy platforms, and one pile of scripts with a serious case of > bit rot for VMS. > > In particular, this is of interest for the VMS folks, as it's the only > currently workable build system for upcoming version 1.1. > > > Finding it > ========== > > For now, this change is available on here: > > https://github.com/levitte/openssl/tree/refactor-build > > which is git repo https://github.com/levitte/openssl.git, branch > refactor-build. > > > Using it > ======== > > Requirements > ------------ > > On all platforms, it requires > > - Perl! Reports tell me that version 5.10.1 works fine but might need > some extra perl modules (Test::More and possibly others. Feedback > welcome!). Unix usually has it installed or easy to find. For VMS, > there's an install kit on sourceforge > (https://sourceforge.net/projects/vmsperlkit/files/Archive/), and > Windows, we've always recommended ActiveState Perl > (http://www.activestate.com/ActivePerl). > - The Perl module Text::Template, which is the driver behind the > generation Makefile and other files. This branch relies quite > heavily on templates. > > On Unix, it requires > > - the usual developmemt stuff. cc, as and make would be the really > bare minimum, and maybe I'm forgetting something, but what is > usually considered the normal tool chain should work out. > > On VMS, it requires > > - DEC C... It's called HP C these days and might be called something > else again when VSI starts shipping. It needs to be recent enough > to support the qualifiers /NAMES=(AS_IS,SHORTENED) and /REPOSITORY > (I welcome feedback on which the minimum version for this is!) > - DECset, at the very least MMS. Alternatively, MMK can be used if > you can find it (if anyone knows of a place that has it for sure, > feedback is welcome!) > - Of course, the rest of the tool chain, but that comes with the > operating system, no worries there. > > [I certainly hope I didn't forget anything, but if I did, feedback is > welcome!] > > Config and build > ---------------- > > For Unix users, who are used to the usual generation of a top Makefile > from Makefile.org... that is, Makefile.in since recently, this it > still the default, but you can always use the unified build as an > alternative by adding the flag --unified, like so: > > ./config --unified > make > make test > # There is no install target yet, it's coming up! > > You will get One Top Makefile that does everything. It will not touch > any other Makefile. > > > For VMS users, the unified build is the only one available in this > branch, the old scripts are simply gone. Instead, you configure just > like you would on any other platform (well, almost, there isn't any > config.com yet, so you'll have to jump directly to the Configure > script), and that will generate a descrip.mms: > > perl Configure vms-alpha ! or vms-ia64 > mms > mms test > ! There is no install target yet. > ! As a matter of fact, I'd like to talk about exactly where it > ! should install. Let's talk! > > > Features > ======== > > There are a few features in the unified build that are worth testing: > > 1. Out of source tree builds! It's perfectly possible to do this: > > mkdir ../build > cd ../build > perl ../openssl-src/config > make > make test > > (and yes, on VMS as well) > > 2. The generated Makefile supports parallell make: > > make -j9 > > (carefull, though, don't try the silliness I tried: make -j9 clean all) > > > Future > ====== > > I plan on making the generated Makefile / descrip.mms full featured, > which means at least adding install targets. Then, on to a template > for a Windows makefile. > > > ================= > Feedback welcome! > ================= > > > Cheers, > Richard > From dragon at dancingdragon.be Sat Jan 16 06:17:02 2016 From: dragon at dancingdragon.be (Joey Yandle) Date: Fri, 15 Jan 2016 22:17:02 -0800 Subject: [openssl-dev] [openssl.org #4248] Link error under Windows In-Reply-To: References: <5698E644.1080209@approach.be> Message-ID: <5699E05E.3060508@dancingdragon.be> This appears to be the same issue as when building with no-engine: https://github.com/openssl/openssl/issues/536 Hopefully Richard Levitte's new build system will be able to handle this. Presumably in the old system this would be handled by the last lines of ms\do_win64a.bat: perl util\mkdef.pl 32 libeay > ms\libeay32.def perl util\mkdef.pl 32 ssleay > ms\ssleay32.def On 1/15/2016 7:14 PM, marc.stern at approach.be via RT wrote: > On any version of Windows (32 or 64 bits), if using the "no-deprecated" > configure flag, some functions (see list below) are not compiled but > they are still referenced in LIBEAY32.DEF. This gives the following > error: LIBEAY32.def : error LNK2001: unresolved external symbol ... > > List of functions: > - BN_BLINDING_get_thread_id > - BN_BLINDING_set_thread_id > - BN_CTX_init > - BN_generate_prime > - BN_get_params > - BN_is_prime > - BN_is_prime_fasttest > - BN_set_params > - CRYPTO_get_id_callback > - CRYPTO_set_id_callback > - CRYPTO_thread_id > - DH_generate_parameters > - DSA_generate_parameters > - ERR_remove_state > - RSA_generate_key > - bn_dup_expand > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From rt at openssl.org Sat Jan 16 08:16:57 2016 From: rt at openssl.org (balducci@units.it via RT) Date: Sat, 16 Jan 2016 08:16:57 +0000 Subject: [openssl-dev] [openssl.org #4243] 1.1.0-pre2: bug: EVP_CIPHER_CTX isn't completely opaque In-Reply-To: <642.1452932211@dschgrazlin2.units.it> References: Your message of Jan 2016 17:15:28 +0000." <642.1452932211@dschgrazlin2.units.it> Message-ID: > This is according to our interpretation of "type opacity", meaning that the > type name is available but not its content. "Data hiding" is another way to p ut > it. This means that there will be a need to adapt, stack allocated > EVP_CIPHER_CTX is no longer allowed, but there are functions to allocate and > free them on/from the heap (EVP_CIPHER_CTX_new and EVP_CIPHER_CTX_free). > > What's your interpretation of type opacity? I'm not going to say that you're > wrong and we're perfect, we're interested in feedback and constructive > arguments. I just wanted to let you know our thinking so far. > > > > > apologies if I am missing something here. > > ...it is evident that I was missing something! A simple search for "opaque type" brings me to, eg, wikipedia (yes, that popular!) where I find: "In computer science, an opaque data type is a data type whose concrete data structure is not defined in an interface." ie exactly what I naively called "inconsistency" (!) I'm sorry for the noise: I promise next time I'll double check before disturbing thanks for your patience and politeness ciao gabriele From rainer.jung at kippdata.de Sat Jan 16 10:12:28 2016 From: rainer.jung at kippdata.de (Rainer Jung) Date: Sat, 16 Jan 2016 11:12:28 +0100 Subject: [openssl-dev] [openssl-commits] [openssl] master update In-Reply-To: <1452916037.569399.13452.nullmailer@dev.openssl.org> References: <1452916037.569399.13452.nullmailer@dev.openssl.org> Message-ID: <569A178C.5000308@kippdata.de> Please note that the patch in RT4247 also contains a hunk for crypto/evp/e_camellia.c. This was not committed here, but without it one gets the same type of compilation error on SPARC. Since the RT is already closed I thought I better ask. The missing part is: Index: crypto/evp/e_camellia.c --- crypto/evp/e_camellia.c 2016-01-14 10:51:32.000000000 +0100 +++ crypto/evp/e_camellia.c 2016-01-16 04:01:44.443269000 +0100 @@ -119,10 +119,10 @@ const unsigned char *iv, int enc) { int ret, mode, bits; - EVP_CAMELLIA_KEY *dat = (EVP_CAMELLIA_KEY *) ctx->cipher_data; + EVP_CAMELLIA_KEY *dat = (EVP_CAMELLIA_KEY *) EVP_CIPHER_CTX_cipher_data(ctx); - mode = ctx->cipher->flags & EVP_CIPH_MODE; - bits = ctx->key_len * 8; + mode = EVP_CIPHER_CTX_mode(ctx); + bits = EVP_CIPHER_CTX_key_length(ctx) * 8; cmll_t4_set_key(key, bits, &dat->ks); Thank a bunch, Rainer Am 16.01.2016 um 04:47 schrieb Rich Salz: > The branch master has been updated > via ecdd0ff733985fb573d687fe85fa533f62f6cfd8 (commit) > from 25be7a0feacdbd3326774f0da8aaeb966c1f57f8 (commit) > > > - Log ----------------------------------------------------------------- > commit ecdd0ff733985fb573d687fe85fa533f62f6cfd8 > Author: Rich Salz > Date: Fri Jan 15 22:37:11 2016 -0500 > > RT4247: Fix EVP_CIPHER_CTX opaque on sparc > > Via Rainer Jung > > Reviewed-by: Dr. Stephen Henson > > ----------------------------------------------------------------------- > > Summary of changes: > crypto/evp/e_des.c | 2 +- > crypto/evp/e_des3.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/crypto/evp/e_des.c b/crypto/evp/e_des.c > index 5536f62..929151c 100644 > --- a/crypto/evp/e_des.c > +++ b/crypto/evp/e_des.c > @@ -247,7 +247,7 @@ static int des_init_key(EVP_CIPHER_CTX *ctx, const unsigned char *key, > dat->stream.cbc = NULL; > # if defined(SPARC_DES_CAPABLE) > if (SPARC_DES_CAPABLE) { > - int mode = ctx->cipher->flags & EVP_CIPH_MODE; > + int mode = EVP_CIPHER_CTX_mode(ctx); > > if (mode == EVP_CIPH_CBC_MODE) { > des_t4_key_expand(key, &dat->ks.ks); > diff --git a/crypto/evp/e_des3.c b/crypto/evp/e_des3.c > index 16407e8..8b6c2b5 100644 > --- a/crypto/evp/e_des3.c > +++ b/crypto/evp/e_des3.c > @@ -270,7 +270,7 @@ static int des_ede_init_key(EVP_CIPHER_CTX *ctx, const unsigned char *key, > dat->stream.cbc = NULL; > # if defined(SPARC_DES_CAPABLE) > if (SPARC_DES_CAPABLE) { > - int mode = ctx->cipher->flags & EVP_CIPH_MODE; > + int mode = EVP_CIPHER_CTX_mode(ctx); > > if (mode == EVP_CIPH_CBC_MODE) { > des_t4_key_expand(&deskey[0], &dat->ks1); > @@ -297,7 +297,7 @@ static int des_ede3_init_key(EVP_CIPHER_CTX *ctx, const unsigned char *key, > dat->stream.cbc = NULL; > # if defined(SPARC_DES_CAPABLE) > if (SPARC_DES_CAPABLE) { > - int mode = ctx->cipher->flags & EVP_CIPH_MODE; > + int mode = EVP_CIPHER_CTX_mode(ctx); > > if (mode == EVP_CIPH_CBC_MODE) { > des_t4_key_expand(&deskey[0], &dat->ks1); From rt at openssl.org Sat Jan 16 10:39:39 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Sat, 16 Jan 2016 10:39:39 +0000 Subject: [openssl-dev] [openssl.org #4248] Link error under Windows In-Reply-To: References: <5698E644.1080209@approach.be> <5699E05E.3060508@dancingdragon.be> Message-ID: My new build system won't change much in this respect, it still relies on util/libeay.num. So the issue lies in util/mkdef.pl (at least for the TS_CONF symbols). I haven't checked the others you mentioned, but it may come down to them not being marked properly as deprecated in their respective headers. I'll try to have a look at this tomorrow. Vid Sat, 16 Jan 2016 kl. 06.17.13, skrev dragon at dancingdragon.be: > This appears to be the same issue as when building with no-engine: > > https://github.com/openssl/openssl/issues/536 > > Hopefully Richard Levitte's new build system will be able to handle > this. Presumably in the old system this would be handled by the last > lines of ms\do_win64a.bat: > > perl util\mkdef.pl 32 libeay > ms\libeay32.def > perl util\mkdef.pl 32 ssleay > ms\ssleay32.def > > > On 1/15/2016 7:14 PM, marc.stern at approach.be via RT wrote: > > On any version of Windows (32 or 64 bits), if using the "no-deprecated" > > configure flag, some functions (see list below) are not compiled but > > they are still referenced in LIBEAY32.DEF. This gives the following > > error: LIBEAY32.def : error LNK2001: unresolved external symbol ... > > > > List of functions: > > - BN_BLINDING_get_thread_id > > - BN_BLINDING_set_thread_id > > - BN_CTX_init > > - BN_generate_prime > > - BN_get_params > > - BN_is_prime > > - BN_is_prime_fasttest > > - BN_set_params > > - CRYPTO_get_id_callback > > - CRYPTO_set_id_callback > > - CRYPTO_thread_id > > - DH_generate_parameters > > - DSA_generate_parameters > > - ERR_remove_state > > - RSA_generate_key > > - bn_dup_expand > > > > > > _______________________________________________ > > openssl-dev mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > -- Richard Levitte levitte at openssl.org From gvanem at yahoo.no Sat Jan 16 10:42:52 2016 From: gvanem at yahoo.no (Gisle Vanem) Date: Sat, 16 Jan 2016 11:42:52 +0100 Subject: [openssl-dev] MSVC 2015 internal compiler error Message-ID: <569A1EAC.1000607@yahoo.no> While building OpenSSL from today's git-repo: ssl\d1_srtp.c : fatal error C1001: An internalerror has occurred in the compiler. (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 246) To work around this problem, try simplifying or changing the program near the locations listed above. Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information INTERNAL COMPILER ERROR in 'f:\gv\VC_2015\bin\cl.exe' Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information ----- Seems to be related to: typedef const char *OPENSSL_CSTRING; in safestack.h Changing this into: #ifdef _MSC_VER typedef char *OPENSSL_CSTRING; #else typedef const char *OPENSSL_CSTRING; #endif helps, but triggers the same internal compiler error later on. It suspect the compiler sees 'const const *x' in some places. So I assume that's the trigger for this fault. Details: Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23026 for x86 on Win-10 build 10240. -- --gv From levitte at openssl.org Sat Jan 16 10:45:16 2016 From: levitte at openssl.org (Richard Levitte) Date: Sat, 16 Jan 2016 11:45:16 +0100 (CET) Subject: [openssl-dev] Upcoming build system change In-Reply-To: <5699DF80.6030609@dancingdragon.be> References: <20160114.215903.813205413779228431.levitte@openssl.org> <5699DF80.6030609@dancingdragon.be> Message-ID: <20160116.114516.1554366612744539703.levitte@openssl.org> In message <5699DF80.6030609 at dancingdragon.be> on Fri, 15 Jan 2016 22:13:20 -0800, Joey Yandle said: dragon> I tried building your branch on windows, but the windows Configure dragon> targets appear to be missing: I haven't done anything specific with Windows yet... or, quite frankly, checked it very much... My focus has been mainly on Unix and VMS. I do have some start of a makefile for Windows as well, but it's just that, as start. dragon> c:\src\openssl>perl Configure VC-WIN64A dragon> Configuring OpenSSL version 1.1.0-pre3-dev (0x0x10100003L) dragon> ... dragon> Configuring for VC-WIN64A dragon> Warning! target VC-WIN64A doesn't exist! dragon> Can't use an undefined value as an ARRAY reference at Configure line dragon> 825. This surprises me a bit, but we've had some issues surrounding this very target in master as well... it came down to Configure being a bit petty and has been changed accordingly, but my branch hasn't been rebased on the freshest master yet, so the fix hasn't propagated to my branch yet. I'm going to deal with that tomorrow and will make sure to verify the usual Windows configs then. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Sat Jan 16 10:49:10 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Sat, 16 Jan 2016 10:49:10 +0000 Subject: [openssl-dev] [openssl.org #4243] 1.1.0-pre2: bug: EVP_CIPHER_CTX isn't completely opaque In-Reply-To: References: 15 Jan Message-ID: No problem, misunderstandings happen. Closing this ticket now. Cheers, Richard Vid Sat, 16 Jan 2016 kl. 08.16.57, skrev balducci at units.it: > > This is according to our interpretation of "type opacity", meaning > > that the > > type name is available but not its content. "Data hiding" is another > > way to p > ut > > it. This means that there will be a need to adapt, stack allocated > > EVP_CIPHER_CTX is no longer allowed, but there are functions to > > allocate and > > free them on/from the heap (EVP_CIPHER_CTX_new and > > EVP_CIPHER_CTX_free). > > > > What's your interpretation of type opacity? I'm not going to say that > > you're > > wrong and we're perfect, we're interested in feedback and > > constructive > > arguments. I just wanted to let you know our thinking so far. > > > > > > > > > apologies if I am missing something here. > > > > > ...it is evident that I was missing something! > > A simple search for "opaque type" brings me to, eg, wikipedia (yes, > that > popular!) where I find: > > "In computer science, an opaque data type is a data type > whose concrete data structure is not defined in an > interface." > > ie exactly what I naively called "inconsistency" (!) > > I'm sorry for the noise: I promise next time I'll double check before > disturbing > > thanks for your patience and politeness > > ciao > gabriele -- Richard Levitte levitte at openssl.org From rt at openssl.org Sat Jan 16 11:17:23 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Sat, 16 Jan 2016 11:17:23 +0000 Subject: [openssl-dev] [openssl.org #4248] Link error under Windows In-Reply-To: References: <5698E644.1080209@approach.be> <5699E05E.3060508@dancingdragon.be> Message-ID: For the TS_CONF issue, it was a simple matter of lacking marks in include/openssl/ts.h Fix coming up Vid Sat, 16 Jan 2016 kl. 10.39.39, skrev levitte: > My new build system won't change much in this respect, it still relies > on > util/libeay.num. So the issue lies in util/mkdef.pl (at least for the > TS_CONF > symbols). I haven't checked the others you mentioned, but it may come > down to > them not being marked properly as deprecated in their respective > headers. > > I'll try to have a look at this tomorrow. > > Vid Sat, 16 Jan 2016 kl. 06.17.13, skrev dragon at dancingdragon.be: > > This appears to be the same issue as when building with no-engine: > > > > https://github.com/openssl/openssl/issues/536 > > > > Hopefully Richard Levitte's new build system will be able to handle > > this. Presumably in the old system this would be handled by the last > > lines of ms\do_win64a.bat: > > > > perl util\mkdef.pl 32 libeay > ms\libeay32.def > > perl util\mkdef.pl 32 ssleay > ms\ssleay32.def > > > > > > On 1/15/2016 7:14 PM, marc.stern at approach.be via RT wrote: > > > On any version of Windows (32 or 64 bits), if using the "no- > > > deprecated" > > > configure flag, some functions (see list below) are not compiled > > > but > > > they are still referenced in LIBEAY32.DEF. This gives the following > > > error: LIBEAY32.def : error LNK2001: unresolved external symbol ... > > > > > > List of functions: > > > - BN_BLINDING_get_thread_id > > > - BN_BLINDING_set_thread_id > > > - BN_CTX_init > > > - BN_generate_prime > > > - BN_get_params > > > - BN_is_prime > > > - BN_is_prime_fasttest > > > - BN_set_params > > > - CRYPTO_get_id_callback > > > - CRYPTO_set_id_callback > > > - CRYPTO_thread_id > > > - DH_generate_parameters > > > - DSA_generate_parameters > > > - ERR_remove_state > > > - RSA_generate_key > > > - bn_dup_expand > > > > > > > > > _______________________________________________ > > > openssl-dev mailing list > > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl- > > > dev > > > > > > > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org From ca+ssl-dev at esmtp.org Sat Jan 16 12:30:26 2016 From: ca+ssl-dev at esmtp.org (Claus Assmann) Date: Sat, 16 Jan 2016 04:30:26 -0800 Subject: [openssl-dev] "SSL_dane_enable() may be called" Message-ID: <20160116123026.GA25768@x2.esmtp.org> SSL_CTX_dane_enable.pod states: SSL_dane_enable() may be called before the SSL handshake is initiated with L to enable DANE for that connection. "may" seems to be a bit confusing here: if you want "to enable DANE for that connection" then you "must" call the function, right? From gvanem at yahoo.no Sat Jan 16 12:51:28 2016 From: gvanem at yahoo.no (Gisle Vanem) Date: Sat, 16 Jan 2016 13:51:28 +0100 Subject: [openssl-dev] '-CIPHER_DEBUG' error on 'dh_dsa' Message-ID: <569A3CD0.9050300@yahoo.no> Having '-DCIPHER_DEBUG' in the CFLAGS causes this error in MingW (gcc 5.1): ssl/ssl_lib.c:2499:58: error: 'dh_dsa' undeclared (first use in this function) dh_tmp, rsa_enc, rsa_sign, dsa_sign, dh_rsa, dh_dsa); (+ a lot wore warnings). Time to retire/rewrite this 'CIPHER_DEBUG' part? Or patch ssl/ssl_lib.c: --- a/ssl/ssl_lib.c 2016-01-16 06:28:59 +++ b/ssl/ssl_lib.c 2016-01-16 13:40:51 @@ -2495,8 +2495,8 @@ #ifdef CIPHER_DEBUG fprintf(stderr, - "dht=%d re=%d rs=%d ds=%d dhr=%d dhd=%d\n", - dh_tmp, rsa_enc, rsa_sign, dsa_sign, dh_rsa, dh_dsa); + "dht=%d re=%d rs=%d ds=%d\n", + dh_tmp, rsa_enc, rsa_sign, dsa_sign); #endif -- --gv From rsalz at akamai.com Sat Jan 16 13:47:15 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 16 Jan 2016 13:47:15 +0000 Subject: [openssl-dev] [openssl-commits] [openssl] master update In-Reply-To: <569A178C.5000308@kippdata.de> References: <1452916037.569399.13452.nullmailer@dev.openssl.org> <569A178C.5000308@kippdata.de> Message-ID: <272a2e7c47bf4ab1910fb846172f78e9@usma1ex-dag1mb1.msg.corp.akamai.com> Oops, my mistake. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz > -----Original Message----- > From: Rainer Jung [mailto:rainer.jung at kippdata.de] > Sent: Saturday, January 16, 2016 5:12 AM > To: openssl-dev at openssl.org > Subject: Re: [openssl-dev] [openssl-commits] [openssl] master update > > Please note that the patch in RT4247 also contains a hunk for > crypto/evp/e_camellia.c. This was not committed here, but without it one > gets the same type of compilation error on SPARC. Since the RT is already > closed I thought I better ask. > > The missing part is: > > Index: crypto/evp/e_camellia.c > --- crypto/evp/e_camellia.c 2016-01-14 10:51:32.000000000 +0100 > +++ crypto/evp/e_camellia.c 2016-01-16 04:01:44.443269000 +0100 > @@ -119,10 +119,10 @@ > const unsigned char *iv, int enc) > { > int ret, mode, bits; > - EVP_CAMELLIA_KEY *dat = (EVP_CAMELLIA_KEY *) ctx->cipher_data; > + EVP_CAMELLIA_KEY *dat = (EVP_CAMELLIA_KEY *) > EVP_CIPHER_CTX_cipher_data(ctx); > > - mode = ctx->cipher->flags & EVP_CIPH_MODE; > - bits = ctx->key_len * 8; > + mode = EVP_CIPHER_CTX_mode(ctx); > + bits = EVP_CIPHER_CTX_key_length(ctx) * 8; > > cmll_t4_set_key(key, bits, &dat->ks); > > Thank a bunch, > > Rainer > > Am 16.01.2016 um 04:47 schrieb Rich Salz: > > The branch master has been updated > > via ecdd0ff733985fb573d687fe85fa533f62f6cfd8 (commit) > > from 25be7a0feacdbd3326774f0da8aaeb966c1f57f8 (commit) > > > > > > - Log > > ----------------------------------------------------------------- > > commit ecdd0ff733985fb573d687fe85fa533f62f6cfd8 > > Author: Rich Salz > > Date: Fri Jan 15 22:37:11 2016 -0500 > > > > RT4247: Fix EVP_CIPHER_CTX opaque on sparc > > > > Via Rainer Jung > > > > Reviewed-by: Dr. Stephen Henson > > > > ---------------------------------------------------------------------- > > - > > > > Summary of changes: > > crypto/evp/e_des.c | 2 +- > > crypto/evp/e_des3.c | 4 ++-- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/crypto/evp/e_des.c b/crypto/evp/e_des.c index > > 5536f62..929151c 100644 > > --- a/crypto/evp/e_des.c > > +++ b/crypto/evp/e_des.c > > @@ -247,7 +247,7 @@ static int des_init_key(EVP_CIPHER_CTX *ctx, const > unsigned char *key, > > dat->stream.cbc = NULL; > > # if defined(SPARC_DES_CAPABLE) > > if (SPARC_DES_CAPABLE) { > > - int mode = ctx->cipher->flags & EVP_CIPH_MODE; > > + int mode = EVP_CIPHER_CTX_mode(ctx); > > > > if (mode == EVP_CIPH_CBC_MODE) { > > des_t4_key_expand(key, &dat->ks.ks); diff --git > > a/crypto/evp/e_des3.c b/crypto/evp/e_des3.c index 16407e8..8b6c2b5 > > 100644 > > --- a/crypto/evp/e_des3.c > > +++ b/crypto/evp/e_des3.c > > @@ -270,7 +270,7 @@ static int des_ede_init_key(EVP_CIPHER_CTX *ctx, > const unsigned char *key, > > dat->stream.cbc = NULL; > > # if defined(SPARC_DES_CAPABLE) > > if (SPARC_DES_CAPABLE) { > > - int mode = ctx->cipher->flags & EVP_CIPH_MODE; > > + int mode = EVP_CIPHER_CTX_mode(ctx); > > > > if (mode == EVP_CIPH_CBC_MODE) { > > des_t4_key_expand(&deskey[0], &dat->ks1); @@ -297,7 > > +297,7 @@ static int des_ede3_init_key(EVP_CIPHER_CTX *ctx, const > unsigned char *key, > > dat->stream.cbc = NULL; > > # if defined(SPARC_DES_CAPABLE) > > if (SPARC_DES_CAPABLE) { > > - int mode = ctx->cipher->flags & EVP_CIPH_MODE; > > + int mode = EVP_CIPHER_CTX_mode(ctx); > > > > if (mode == EVP_CIPH_CBC_MODE) { > > des_t4_key_expand(&deskey[0], &dat->ks1); > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Sat Jan 16 13:55:04 2016 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 16 Jan 2016 13:55:04 +0000 Subject: [openssl-dev] [openssl.org #4054] [BUG] engine-provided ciphers are unavailable for command-line utility In-Reply-To: <20160116135448.GB14995@kronk.local> References: <20160116135448.GB14995@kronk.local> Message-ID: Seems that this works in master, so it can probably be closed. Cheers From rt at openssl.org Sat Jan 16 13:55:28 2016 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 16 Jan 2016 13:55:28 +0000 Subject: [openssl-dev] [openssl.org #4239] [PATCH] fixing wildcard matching on punycode domains In-Reply-To: <20160116135521.GC14995@kronk.local> References: <20160116135521.GC14995@kronk.local> Message-ID: On Fri, Jan 15, 2016 at 06:08:38pm +0000, Viktor Dukhovni via RT wrote: > > > On Jan 15, 2016, at 10:32 AM, Zi Lin via RT wrote: > > > > > > Yes, this will get fixed. Thanks. Patches merged, can be closed now. Cheers From rt at openssl.org Sat Jan 16 13:55:55 2016 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 16 Jan 2016 13:55:55 +0000 Subject: [openssl-dev] [openssl.org #4034] mkstack.pl does generate new safestack.h until release 1.0.1m In-Reply-To: <20160116135548.GD14995@kronk.local> References: <20160116135548.GD14995@kronk.local> Message-ID: The mkstack.pl script was removed in master so this can probably be closed (unless it needs fixing in older releases as well). Cheers From rt at openssl.org Sat Jan 16 13:56:15 2016 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 16 Jan 2016 13:56:15 +0000 Subject: [openssl-dev] [openssl.org #4157] Download Documentation In-Reply-To: <20160116135602.GE14995@kronk.local> References: <20160116135602.GE14995@kronk.local> Message-ID: Seems to me this can be closed now. Cheers From rt at openssl.org Sat Jan 16 13:56:31 2016 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 16 Jan 2016 13:56:31 +0000 Subject: [openssl-dev] [openssl.org #4026] patches to eliminate some warnings from clang In-Reply-To: <20160116135619.GF14995@kronk.local> References: <20160116135619.GF14995@kronk.local> Message-ID: Looks like some things are already fixed in master, does this needs any more actions? Cheers From rt at openssl.org Sat Jan 16 13:57:17 2016 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 16 Jan 2016 13:57:17 +0000 Subject: [openssl-dev] [openssl.org #4159] BUG ::: Null dereference in ssl3_free In-Reply-To: <20160116135704.GG14995@kronk.local> References: <20160116135704.GG14995@kronk.local> Message-ID: Kurt said this is fixed in git, can be closed I guess. Cheers From rt at openssl.org Sat Jan 16 13:57:29 2016 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 16 Jan 2016 13:57:29 +0000 Subject: [openssl-dev] [openssl.org #4112] GH458: Fix "primarility" typo In-Reply-To: <20160116135716.GH14995@kronk.local> References: <20160116135716.GH14995@kronk.local> Message-ID: PR merged, can be closed. Cheers From rt at openssl.org Sat Jan 16 13:57:46 2016 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 16 Jan 2016 13:57:46 +0000 Subject: [openssl-dev] [openssl.org #4140] GITHUB PULL REQUEST: do not load engines twice In-Reply-To: <20160116135740.GI14995@kronk.local> References: <20160116135740.GI14995@kronk.local> Message-ID: PR merged, can be closed. Cheers From rt at openssl.org Sat Jan 16 13:58:04 2016 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 16 Jan 2016 13:58:04 +0000 Subject: [openssl-dev] [openssl.org #4174] Support the TLS Feature (aka Must Staple) X.509v3 extension (RFC7633) In-Reply-To: <20160116135751.GJ14995@kronk.local> References: <20160116135751.GJ14995@kronk.local> Message-ID: PR merged, can be closed. Cheers From rt at openssl.org Sat Jan 16 13:58:17 2016 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 16 Jan 2016 13:58:17 +0000 Subject: [openssl-dev] [openssl.org #4183] No SSL_CIPHER_description() for ChaCha20/Poly1305 In-Reply-To: <20160116135804.GK14995@kronk.local> References: <20160116135804.GK14995@kronk.local> Message-ID: Looks fixed in master, can probably be closed. Cheers From rt at openssl.org Sat Jan 16 13:58:24 2016 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 16 Jan 2016 13:58:24 +0000 Subject: [openssl-dev] [openssl.org #4219] [typos] DANE related docs In-Reply-To: <20160116135817.GL14995@kronk.local> References: <20160116135817.GL14995@kronk.local> Message-ID: Seems fixed in master, so this can be closed. Cheers From rt at openssl.org Sat Jan 16 13:58:37 2016 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 16 Jan 2016 13:58:37 +0000 Subject: [openssl-dev] [openssl.org #4222] Wrong definition of the macro SSL_set1_sigalgs in ssl.h (PR #519) In-Reply-To: <20160116135831.GM14995@kronk.local> References: <20160116135831.GM14995@kronk.local> Message-ID: PR merged, can be closed now. Cheers From rt at openssl.org Sat Jan 16 13:58:52 2016 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 16 Jan 2016 13:58:52 +0000 Subject: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code In-Reply-To: <20160116135843.GN14995@kronk.local> References: <20160116135843.GN14995@kronk.local> Message-ID: This has been (partially) fixed, so it can probably be closed. From rt at openssl.org Sat Jan 16 14:16:42 2016 From: rt at openssl.org (Roumen Petrov via RT) Date: Sat, 16 Jan 2016 14:16:42 +0000 Subject: [openssl-dev] [openssl.org #4207] engine key format in 1.1 In-Reply-To: <569A50C1.9060203@roumenpetrov.info> References: <5682A73C.70305@roumenpetrov.info> <569A50C1.9060203@roumenpetrov.info> Message-ID: Also patches for commands: - pkey : "0017-pkey-cmd-restore-keys-from-engine.patch" - req : "0018-req-cmd-restore-keys-from-engine.patch" -------------- next part -------------- A non-text attachment was scrubbed... Name: 0017-pkey-cmd-restore-keys-from-engine.patch Type: text/x-diff Size: 1427 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0018-req-cmd-restore-keys-from-engine.patch Type: text/x-diff Size: 1654 bytes Desc: not available URL: From deengert at gmail.com Sat Jan 16 14:52:35 2016 From: deengert at gmail.com (Douglas E Engert) Date: Sat, 16 Jan 2016 08:52:35 -0600 Subject: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl req fails to use engine In-Reply-To: References: <20160115230320.17788998.66913.45627@ll.mit.edu> Message-ID: <569A5933.3020800@gmail.com> Yes, #458 is similar but for the pkeyutl.c I would have changed: {"keyform", OPT_KEYFORM, 'F', "Private key format - default PEM"}, to {"keyform", OPT_KEYFORM, 'f', "Private key format - default PEM"}, The patch also adds an additional parameter, {"engine_impl", OPT_ENGINE_IMPL, '-', "Also use engine given by -engine for crypto operations"}, I would ask the author about the engine_impl . It looks to me that to keep the previous behavior of the command one would need to add this option if an engine is used. IIt could also be an issue with the ordering of the parameters, or to try and not use the engine when the public key is used. (I could be wrong on this.) The author is also active on the OpenSC list trying to use EC with the OpenSC engine. On 1/15/2016 5:24 PM, Blumenthal, Uri - 0553 - MITLL via RT wrote: > Doug, could you please take a look at PR #548 (or is it #549)? It also addresses this KEY_FORM issue. > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > Original Message > From:deengert at gmail.com via RT > Sent: Friday, January 15, 2016 17:10 > Reply To:rt at openssl.org > Cc:openssl-dev at openssl.org > Subject: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl req fails to use engine > > req.c (and many of the other apps) appear to have lost the ability to use an engine. > The attached diff is against the github.com verison using Tag OpenSSL_1_1-pre2 > In the req_options[] table: > OPT_KEY is set to "S" so pre- checking of the parameters does not drop the string passed to the engine. > OPT_KEY_FORM is set to "f" so pre-checking will allow engine > > The engine is saved: > e = setup_engine(opt_arg(), 1); > > (I turned on debug, may want that off. ) > > to allow the theOPT_KEY_FORM to be an engine: > if (!opt_format(opt_arg(), OPT_FMT_PEMDER|OPT_FMT_ENGINE, &keyform)) > > This was tested with a modified version of OpenSC using ECDSA key on card to generate a self signed certificate. > > openssl req -config /tmp/genreq.6156.openssl.conf -engine pkcs11 -keyform e -sha256 -new -key slot_1-id_2 -out /tmp/selfsigned.pem -x509 -text > > > P.S. The EC_KEY_* functions appear to be working too (#4225) Have not tried the ECDH yet. > > -- Douglas E. Engert > > > > -- Douglas E. Engert From rt at openssl.org Sat Jan 16 15:00:28 2016 From: rt at openssl.org (deengert@gmail.com via RT) Date: Sat, 16 Jan 2016 15:00:28 +0000 Subject: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl req fails to use engine In-Reply-To: <569A5933.3020800@gmail.com> References: <20160115230320.17788998.66913.45627@ll.mit.edu> <569A5933.3020800@gmail.com> Message-ID: Yes, #458 is similar but for the pkeyutl.c I would have changed: {"keyform", OPT_KEYFORM, 'F', "Private key format - default PEM"}, to {"keyform", OPT_KEYFORM, 'f', "Private key format - default PEM"}, The patch also adds an additional parameter, {"engine_impl", OPT_ENGINE_IMPL, '-', "Also use engine given by -engine for crypto operations"}, I would ask the author about the engine_impl . It looks to me that to keep the previous behavior of the command one would need to add this option if an engine is used. IIt could also be an issue with the ordering of the parameters, or to try and not use the engine when the public key is used. (I could be wrong on this.) The author is also active on the OpenSC list trying to use EC with the OpenSC engine. On 1/15/2016 5:24 PM, Blumenthal, Uri - 0553 - MITLL via RT wrote: > Doug, could you please take a look at PR #548 (or is it #549)? It also addresses this KEY_FORM issue. > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > Original Message > From:deengert at gmail.com via RT > Sent: Friday, January 15, 2016 17:10 > Reply To:rt at openssl.org > Cc:openssl-dev at openssl.org > Subject: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl req fails to use engine > > req.c (and many of the other apps) appear to have lost the ability to use an engine. > The attached diff is against the github.com verison using Tag OpenSSL_1_1-pre2 > In the req_options[] table: > OPT_KEY is set to "S" so pre- checking of the parameters does not drop the string passed to the engine. > OPT_KEY_FORM is set to "f" so pre-checking will allow engine > > The engine is saved: > e = setup_engine(opt_arg(), 1); > > (I turned on debug, may want that off. ) > > to allow the theOPT_KEY_FORM to be an engine: > if (!opt_format(opt_arg(), OPT_FMT_PEMDER|OPT_FMT_ENGINE, &keyform)) > > This was tested with a modified version of OpenSC using ECDSA key on card to generate a self signed certificate. > > openssl req -config /tmp/genreq.6156.openssl.conf -engine pkcs11 -keyform e -sha256 -new -key slot_1-id_2 -out /tmp/selfsigned.pem -x509 -text > > > P.S. The EC_KEY_* functions appear to be working too (#4225) Have not tried the ECDH yet. > > -- Douglas E. Engert > > > > -- Douglas E. Engert From alessandro at ghedini.me Sat Jan 16 15:03:41 2016 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Sat, 16 Jan 2016 15:03:41 +0000 Subject: [openssl-dev] '-CIPHER_DEBUG' error on 'dh_dsa' In-Reply-To: <569A3CD0.9050300@yahoo.no> References: <569A3CD0.9050300@yahoo.no> Message-ID: <20160116150340.GA6496@kronk.local> On Sat, Jan 16, 2016 at 01:51:28pm +0100, Gisle Vanem wrote: > Having '-DCIPHER_DEBUG' in the CFLAGS causes this error in > MingW (gcc 5.1): > ssl/ssl_lib.c:2499:58: error: 'dh_dsa' undeclared (first use in this function) > dh_tmp, rsa_enc, rsa_sign, dsa_sign, dh_rsa, dh_dsa); > > (+ a lot wore warnings). Time to retire/rewrite this 'CIPHER_DEBUG' > part? Or patch ssl/ssl_lib.c: > > --- a/ssl/ssl_lib.c 2016-01-16 06:28:59 > +++ b/ssl/ssl_lib.c 2016-01-16 13:40:51 > @@ -2495,8 +2495,8 @@ > > #ifdef CIPHER_DEBUG > fprintf(stderr, > - "dht=%d re=%d rs=%d ds=%d dhr=%d dhd=%d\n", > - dh_tmp, rsa_enc, rsa_sign, dsa_sign, dh_rsa, dh_dsa); > + "dht=%d re=%d rs=%d ds=%d\n", > + dh_tmp, rsa_enc, rsa_sign, dsa_sign); > #endif IMO it's better to just remove it. It's unlikely anyone is using it since the build breaks. I opened a pull request (that includes another #if-related fix): https://github.com/openssl/openssl/pull/559 Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Sat Jan 16 15:37:39 2016 From: rt at openssl.org (Roumen Petrov via RT) Date: Sat, 16 Jan 2016 15:37:39 +0000 Subject: [openssl-dev] [openssl.org #4249] ECDSA method flags In-Reply-To: <569A63BE.8000409@roumenpetrov.info> References: <569A63BE.8000409@roumenpetrov.info> Message-ID: In 1.0.2 branch commit 94c2f77a62be7079ab1893ab14b18a30157c4532 add functions to set ECDSA_METHOD structure. One on functions is to set flags. Until now ECDSA flags are defined only in non-installed header. 1) "0003-move-some-ECDSA_METHOD-declarations-after-descriptio.patch" First patch is cosmetic correction of above mentioned commit - move some declarations after description. 2) "0004-public-flag-ECDSA_FLAG_FIPS_METHOD.patch" Actual patch that moves ECDSA flags to public header. 3) "0005-remove-unused-flag-EC_FLAG_FIPS_CHECKED.patch" OpenSSL describes flag EC_FLAG_FIPS_CHECKED but this flags is not used in fips enabled openssl build. It seems to me is enough to set flag ECDSA_FLAG_FIPS_METHOD to allow ECDSA method to work in fips mode. Regards, Roumen Petrov -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-move-some-ECDSA_METHOD-declarations-after-descriptio.patch Type: text/x-diff Size: 1389 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-public-flag-ECDSA_FLAG_FIPS_METHOD.patch Type: text/x-diff Size: 1739 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-remove-unused-flag-EC_FLAG_FIPS_CHECKED.patch Type: text/x-diff Size: 2842 bytes Desc: not available URL: From kurt at roeckx.be Sat Jan 16 16:13:13 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 16 Jan 2016 17:13:13 +0100 Subject: [openssl-dev] '-CIPHER_DEBUG' error on 'dh_dsa' In-Reply-To: <20160116150340.GA6496@kronk.local> References: <569A3CD0.9050300@yahoo.no> <20160116150340.GA6496@kronk.local> Message-ID: <20160116161313.GA12976@roeckx.be> On Sat, Jan 16, 2016 at 03:03:41PM +0000, Alessandro Ghedini wrote: > On Sat, Jan 16, 2016 at 01:51:28pm +0100, Gisle Vanem wrote: > > Having '-DCIPHER_DEBUG' in the CFLAGS causes this error in > > MingW (gcc 5.1): > > ssl/ssl_lib.c:2499:58: error: 'dh_dsa' undeclared (first use in this function) > > dh_tmp, rsa_enc, rsa_sign, dsa_sign, dh_rsa, dh_dsa); > > > > (+ a lot wore warnings). Time to retire/rewrite this 'CIPHER_DEBUG' > > part? Or patch ssl/ssl_lib.c: > > > > --- a/ssl/ssl_lib.c 2016-01-16 06:28:59 > > +++ b/ssl/ssl_lib.c 2016-01-16 13:40:51 > > @@ -2495,8 +2495,8 @@ > > > > #ifdef CIPHER_DEBUG > > fprintf(stderr, > > - "dht=%d re=%d rs=%d ds=%d dhr=%d dhd=%d\n", > > - dh_tmp, rsa_enc, rsa_sign, dsa_sign, dh_rsa, dh_dsa); > > + "dht=%d re=%d rs=%d ds=%d\n", > > + dh_tmp, rsa_enc, rsa_sign, dsa_sign); > > #endif > > IMO it's better to just remove it. It's unlikely anyone is using it since the > build breaks. I opened a pull request (that includes another #if-related fix): I've actually used this like last week, but it was in the 1.0.2 branch. Kurt From vinschen at redhat.com Sat Jan 16 16:46:53 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 16 Jan 2016 17:46:53 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160114.215903.813205413779228431.levitte@openssl.org> References: <20160114.215903.813205413779228431.levitte@openssl.org> Message-ID: <20160116164653.GH12431@calimero.vinschen.de> Hi Richard, On Jan 14 21:59, Richard Levitte wrote: > Hi, > > there's an effort going on to revamp the build system for future > OpenSSL, coining it as "unified". The intention is to have one and > the same base of information for all platforms, instead of having to > maintain one set of files for Unixly platforms, one makefile generator > for Windowsy platforms, and one pile of scripts with a serious case of > bit rot for VMS. > [...] > Config and build > ---------------- > > For Unix users, who are used to the usual generation of a top Makefile > from Makefile.org... that is, Makefile.in since recently, this it > still the default, but you can always use the unified build as an > alternative by adding the flag --unified, like so: > > ./config --unified I tried that and it doesn't work correctly for Cygwin on x86_64. Rather than choosing the "Cygwin-x86_64" configuration, it chooses the "Cygwin" configuration which is for the i686 based 32 bit version of Cygwin. Can this be recified easily. Btw., for the new unified configuration it might make sense to rename "Cygwin" to "Cygwin-i686". -march could then be set for i686 as well since 32 bit Cygwin won't run on older CPUs anyway. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From ca+ssl-dev at esmtp.org Sat Jan 16 17:42:18 2016 From: ca+ssl-dev at esmtp.org (Claus Assmann) Date: Sat, 16 Jan 2016 09:42:18 -0800 Subject: [openssl-dev] SSL_set_tlsext_host_name(ssl, "") Message-ID: <20160116174218.GA18704@x2.esmtp.org> While playing around with the DANE suppport in OpenSSL 1.1 I noticed that the TLS handshake will fail if I specify an empty name: SSL_dane_enable(ssl, "") (AFAICT no name is needed for DANE-TA(2) RRs). This can also be reproduced using openssl s_client -servername "" ... The error I'm getting is: SSL3 alert read:fatal:decode error SSL_connect:error in SSLv3/TLS write client hello 694985564:error:1409441A:SSL routines:ssl3_read_bytes:reason(1050):record/rec_layer_s3.c:1346:SSL alert number 50 It seems an empty name should not be allowed: RFC 3546 3.1: opaque HostName<1..2^16-1>; Maybe SSL_set_tlsext_host_name() should return an error if an empty name is passed? PS: SSL_CTX_dane_enable.pod: =head1 SEE ALSO ... L, but AFAICT that man page does not exist. From waywardgeek at google.com Sat Jan 16 18:34:25 2016 From: waywardgeek at google.com (Bill Cox) Date: Sat, 16 Jan 2016 10:34:25 -0800 Subject: [openssl-dev] Keyed hashing APIs for EVP? Message-ID: It is a yucky rainy 3-day weekend here in Marin, so at long last, I am working on integrating BLAKE2 into OpenSSL. Rich Salz has voiced support for including it, and I've got initial code over on github under waywardgeek/openssl. It is just the ref version, so there's nothing exciting there yet. I am working on the API calls now, and need some advice. BLAKE2 is very cool in many ways, especially to a speed-freak like me. BLAKE2 is a "keyed hash" that can be used as a MAC directly, without requiring the overhead of HMAC. I do not see any support in the EVP for keyed hash functions. Did I miss something in the EVP API? It would not be the first time. I'm not being too lazy to read the evp.h. I just don't see very well, and as can be seen from my emails, I really don't see what's in front of me very well. I looked at every line that contained "digest", but nothing looked compatible with keyed hashing. I feel keyed hashing is here to stay. Keccak also has this feature. Assuming I'm reading the EVP API correctly, should add support for keyed digests to EVP. What do you folks think? Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinschen at redhat.com Sat Jan 16 18:37:24 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 16 Jan 2016 19:37:24 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160114.154418.799119456171028604.levitte@openssl.org> References: <20160114.154418.799119456171028604.levitte@openssl.org> Message-ID: <20160116183724.GI12431@calimero.vinschen.de> On Jan 14 15:44, Richard Levitte wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > OpenSSL version 1.1.0 pre release 2 (alpha) > =========================================== I tried to build this for Cygwin and got some problems. First, with 1,0.2, we built the Cygwin package with the options enable-tlsext and no-krb5. The 1.1.0 notes mention that Kerberos ciphersuite support has been removed, so am I right that "no-krb5" just isn't required anymore? And what about "enable-tlsext"? Is that unchangable default now? Second, it doesn't build. I configured as usual for the Cygwin distro with the following set of options: shared zlib enable-camellia enable-seed enable-rfc3779 enable-cms \ enable-md2 no-idea no-rc5 [omitting enable-tlsext and no-krb5] The build bailed out with the following error: gcc [...] -c -o ct_lib.o ct_lib.c In file included from /usr/include/w32api/windows.h:95:0, from ../../include/openssl/async.h:60, from ../../ssl/ssl_locl.h:166, from ct_lib.c:63: ../../ssl/ssl_locl.h:1110:5: error: expected specifier-qualifier-list before '(' token X509_EXTENSIONS *tlsext_ocsp_exts; ^ : recipe for target 'ct_lib.o' failed Who had this funny idea to use the Windows definitions when building for Cygwin? Please, please, please, Cygwin is a *POSIX* layer. Please don't use Windows functions on Cygwin, use POSIX functions and POSIX methods, *unless* it's really necessary. And please, if you really think that Cygwin is lacking and you have to fall back to using Windows stuff, please *ask* first. It's really not helpful to use too much native Windows stuff because you're circumventing Cygwin's POSIX lauer and you might (i.e will) inadvertently break something in POSIX applications built for Cygwin. In this case, since Cygwin supports pthreads, why don't you use async_posix.h, which is the right thing to do on a POSIX system. While I was looking into this, I also found the snippet in apps/speed.c which completely breaks Cygwin POSIX-like signal handling by using native Win32 functions rather than POSIX signal functions. Please, please, don't. Additionally it turned out that the configury used two different macros to control a Cygwin build for no good reason, OPENSSL_SYS_CYGWIN and OPENSSL_SYS_WIN32_CYGWIN. Last but not least, we have a small build problem when building for the distro: To build the packages with additional debuginfo packages, the packages must not be built with the -s option, plus we have to induce a few options for the sake of creating the debuginfo information. Up to 1.0.2 we do this by tweaking openssl's build system. We add an expression $(OPT_CFLAGS) to the CFLAGS definition for that. If there's a better, easier way to do this, I'd be grateful for a hint. The attached patchset fixes all of the above. With this, openssl-1.1.0-pre2 builds fine for Cygwin. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- From ab1dba32d73a6c3df6bfebe68c9bd4440260b0d6 Mon Sep 17 00:00:00 2001 From: Corinna Vinschen Date: Sat, 16 Jan 2016 19:30:48 +0100 Subject: [PATCH 1/2] Use POSIX functions on Cygwin, not Win32 function Signed-off-by: Corinna Vinschen --- apps/speed.c | 10 +--------- crypto/async/arch/async_posix.h | 2 +- crypto/async/arch/async_win.h | 2 +- include/openssl/async.h | 2 +- test/asynctest.c | 4 ++-- 5 files changed, 6 insertions(+), 14 deletions(-) diff --git a/apps/speed.c b/apps/speed.c index d45a6f9..5bf1685 100644 --- a/apps/speed.c +++ b/apps/speed.c @@ -94,16 +94,8 @@ # include #endif -#if defined(_WIN32) || defined(__CYGWIN__) +#if defined(_WIN32) # include -# if defined(__CYGWIN__) && !defined(_WIN32) - /* - * should define _WIN32, which normally is mutually exclusive - * with __CYGWIN__, but if it didn't... - */ -# define _WIN32 - /* this is done because Cygwin alarm() fails sometimes. */ -# endif #endif #include diff --git a/crypto/async/arch/async_posix.h b/crypto/async/arch/async_posix.h index c247888..475b56f 100644 --- a/crypto/async/arch/async_posix.h +++ b/crypto/async/arch/async_posix.h @@ -54,7 +54,7 @@ #define OPENSSL_ASYNC_ARCH_ASYNC_POSIX_H #include -#if defined(OPENSSL_SYS_UNIX) && defined(OPENSSL_THREADS) +#if (defined(OPENSSL_SYS_UNIX) || defined(OPENSSL_SYS_CYGWIN)) && defined(OPENSSL_THREADS) # include diff --git a/crypto/async/arch/async_win.h b/crypto/async/arch/async_win.h index b247f59..31f2482 100644 --- a/crypto/async/arch/async_win.h +++ b/crypto/async/arch/async_win.h @@ -55,7 +55,7 @@ * This is the same detection used in cryptlib to set up the thread local * storage that we depend on, so just copy that */ -#if defined(_WIN32) || defined(__CYGWIN__) +#if defined(_WIN32) #include # define ASYNC_WIN # define ASYNC_ARCH diff --git a/include/openssl/async.h b/include/openssl/async.h index de5ef89..d130a36 100644 --- a/include/openssl/async.h +++ b/include/openssl/async.h @@ -56,7 +56,7 @@ #include -#if defined(_WIN32) || defined(__CYGWIN__) +#if defined(_WIN32) #include #define OSSL_ASYNC_FD HANDLE #else diff --git a/test/asynctest.c b/test/asynctest.c index 3e68b1d..ace52b9 100644 --- a/test/asynctest.c +++ b/test/asynctest.c @@ -62,12 +62,12 @@ #include #include <../apps/apps.h> -#if defined(OPENSSL_SYS_UNIX) && defined(OPENSSL_THREADS) +#if (defined(OPENSSL_SYS_UNIX) || defined(OPENSSL_SYS_CYGWIN)) && defined(OPENSSL_THREADS) # include # if _POSIX_VERSION >= 200112L # define ASYNC_POSIX # endif -#elif defined(_WIN32) || defined(__CYGWIN__) +#elif defined(_WIN32) # define ASYNC_WIN #endif -- 2.5.0 -------------- next part -------------- From 47e82daf9317a7d04650de2a6ea06eccbed3169c Mon Sep 17 00:00:00 2001 From: Corinna Vinschen Date: Sat, 16 Jan 2016 19:36:15 +0100 Subject: [PATCH 2/2] Don't strip object files on Cygwin Building for the Cygwin distro requires to be able to build debuginfo files. This in turn requires to build object files without stripping. The stripping is performed by the next step after building which creates the debuginfo files. This also requires to induce a few gcc options into the build process which this patch allows by adding a $(OPT_FLAGS) to cflags. Signed-off-by: Corinna Vinschen --- Configurations/10-main.conf | 4 ++-- Makefile.shared | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf index 2f5313e..d732a82 100644 --- a/Configurations/10-main.conf +++ b/Configurations/10-main.conf @@ -1224,7 +1224,7 @@ "Cygwin" => { inherit_from => [ asm("x86_asm") ], cc => "gcc", - cflags => "-DTERMIOS -DL_ENDIAN -march=i486 -Wall", + cflags => "\$(OPT_CFLAGS) -DTERMIOS -DL_ENDIAN -march=i486 -Wall", debug_cflags => "-g -O0", release_cflags => "-O3 -fomit-frame-pointer", sys_id => "CYGWIN", @@ -1239,7 +1239,7 @@ "Cygwin-x86_64" => { inherit_from => [ asm("x86_64_asm") ], cc => "gcc", - cflags => "-DTERMIOS -DL_ENDIAN -Wall", + cflags => "\$(OPT_CFLAGS) -DTERMIOS -DL_ENDIAN -Wall", debug_cflags => "-g -O0", release_cflags => "-O3", sys_id => "CYGWIN", diff --git a/Makefile.shared b/Makefile.shared index 208382e..0ff1a76 100644 --- a/Makefile.shared +++ b/Makefile.shared @@ -272,7 +272,7 @@ link_o.cygwin: SHLIB_SOVER=${LIBVERSION:+"-$(LIBVERSION)"}; \ ALLSYMSFLAGS='-Wl,--whole-archive'; \ NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \ - SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -shared $$base $$deffile -Wl,-s,-Bsymbolic"; \ + SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -shared $$base $$deffile -Wl,-Bsymbolic"; \ $(LINK_SO_O) #for mingw target if def-file is in use dll-name should match library-name link_a.cygwin: @@ -297,7 +297,7 @@ link_a.cygwin: extras="$$extras rc.o"; \ ALLSYMSFLAGS='-Wl,--whole-archive'; \ NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \ - SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -shared $$base -Wl,-s,-Bsymbolic -Wl,--out-implib,lib$(LIBNAME).dll.a $$extras"; \ + SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -shared $$base -Wl,-Bsymbolic -Wl,--out-implib,lib$(LIBNAME).dll.a $$extras"; \ [ -f apps/$$dll_name ] && rm apps/$$dll_name; \ [ -f test/$$dll_name ] && rm test/$$dll_name; \ $(LINK_SO_A) || exit 1; \ -- 2.5.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From openssl-users at dukhovni.org Sat Jan 16 18:41:43 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 16 Jan 2016 18:41:43 +0000 Subject: [openssl-dev] SSL_set_tlsext_host_name(ssl, "") In-Reply-To: <20160116174218.GA18704@x2.esmtp.org> References: <20160116174218.GA18704@x2.esmtp.org> Message-ID: <20160116184143.GP646@mournblade.imrryr.org> On Sat, Jan 16, 2016 at 09:42:18AM -0800, Claus Assmann wrote: > While playing around with the DANE suppport in OpenSSL 1.1 Thanks for the test drive. > I noticed that the TLS handshake will fail if I specify an empty name: > SSL_dane_enable(ssl, "") Good catch. > (AFAICT no name is needed for DANE-TA(2) RRs). DANE requires the client to send SNI in all cases. The server will often ignore the SNI name if it has just one certificate. > This can also be reproduced using > openssl s_client -servername "" ... Please try the two attached patches. -- Viktor. -------------- next part -------------- >From c9f8d6dc5c37988ec5c721356b3e287a6d491c55 Mon Sep 17 00:00:00 2001 From: Viktor Dukhovni Date: Sat, 16 Jan 2016 12:57:24 -0500 Subject: [PATCH 1/2] Empty SNI names are not valid While empty inputs to SSL_set1_host() clear the reference identifier list. --- crypto/x509/x509_vpm.c | 4 ++-- ssl/s3_lib.c | 5 ++++- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/crypto/x509/x509_vpm.c b/crypto/x509/x509_vpm.c index 827360d..b596d84 100644 --- a/crypto/x509/x509_vpm.c +++ b/crypto/x509/x509_vpm.c @@ -92,11 +92,11 @@ static int int_x509_param_set_hosts(X509_VERIFY_PARAM *vpm, int mode, * Refuse names with embedded NUL bytes, except perhaps as final byte. * XXX: Do we need to push an error onto the error stack? */ - if (namelen == 0) + if (namelen == 0 || name == NULL) namelen = name ? strlen(name) : 0; else if (name && memchr(name, '\0', namelen > 1 ? namelen - 1 : namelen)) return 0; - if (name && name[namelen - 1] == '\0') + if (name != NULL && name[namelen - 1] == '\0') --namelen; if (mode == SET_HOST) { diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c index de8dae2..54b8eba 100644 --- a/ssl/s3_lib.c +++ b/ssl/s3_lib.c @@ -3534,13 +3534,16 @@ long ssl3_ctrl(SSL *s, int cmd, long larg, void *parg) #endif /* !OPENSSL_NO_EC */ case SSL_CTRL_SET_TLSEXT_HOSTNAME: if (larg == TLSEXT_NAMETYPE_host_name) { + size_t len; + OPENSSL_free(s->tlsext_hostname); s->tlsext_hostname = NULL; ret = 1; if (parg == NULL) break; - if (strlen((char *)parg) > TLSEXT_MAXLEN_host_name) { + len = strlen((char *)parg); + if (len == 0 || len > TLSEXT_MAXLEN_host_name) { SSLerr(SSL_F_SSL3_CTRL, SSL_R_SSL3_EXT_INVALID_SERVERNAME); return 0; } -- 2.5.4 (Apple Git-61) -------------- next part -------------- >From 8fc1c14db18d000437664d81e4e250d44179bdc0 Mon Sep 17 00:00:00 2001 From: Viktor Dukhovni Date: Sat, 16 Jan 2016 13:25:17 -0500 Subject: [PATCH 2/2] Better invalid SNI name error handling Also report an SSL_dane_enable error when the basedomain is an invalid SNI name. Avoid side-effects when such a name is valid with X509_VERIFY_PARAM_set1_host(), as e.g. with an empty name, by setting the SNI name first. --- ssl/ssl_lib.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/ssl/ssl_lib.c b/ssl/ssl_lib.c index 90de747..e922e3f 100644 --- a/ssl/ssl_lib.c +++ b/ssl/ssl_lib.c @@ -872,18 +872,24 @@ int SSL_dane_enable(SSL *s, const char *basedomain) return 0; } + /* + * Default SNI name. This rejects empty names, while set1_host below + * accepts them and disables host name checks. To avoid side-effects with + * invalid input, set the SNI name first. + */ + if (s->tlsext_hostname == NULL) { + if (!SSL_set_tlsext_host_name(s, basedomain)) { + SSLerr(SSL_F_SSL_DANE_ENABLE, SSL_R_ERROR_SETTING_TLSA_BASE_DOMAIN); + return -1; + } + } + /* Primary RFC6125 reference identifier */ if (!X509_VERIFY_PARAM_set1_host(s->param, basedomain, 0)) { SSLerr(SSL_F_SSL_DANE_ENABLE, SSL_R_ERROR_SETTING_TLSA_BASE_DOMAIN); return -1; } - /* Default SNI name */ - if (s->tlsext_hostname == NULL) { - if (!SSL_set_tlsext_host_name(s, basedomain)) - return -1; - } - dane->mdpth = -1; dane->pdpth = -1; dane->dctx = &s->ctx->dane; -- 2.5.4 (Apple Git-61) From vinschen at redhat.com Sat Jan 16 18:42:50 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 16 Jan 2016 19:42:50 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160116183724.GI12431@calimero.vinschen.de> References: <20160114.154418.799119456171028604.levitte@openssl.org> <20160116183724.GI12431@calimero.vinschen.de> Message-ID: <20160116184250.GJ12431@calimero.vinschen.de> On Jan 16 19:37, Corinna Vinschen wrote: > On Jan 14 15:44, Richard Levitte wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > OpenSSL version 1.1.0 pre release 2 (alpha) > > =========================================== > > I tried to build this for Cygwin and got some problems. > [...] > The attached patchset fixes all of the above. With this, > openssl-1.1.0-pre2 builds fine for Cygwin. I added another patch to this mail which sets the default CPU for 32 bit Cygwin builds to i686, as outlined in another mail?. Cygwin won't run on older CPUs anyway. The path depends on the 2nd patch from my previous mail. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- From 3dca00f13e7ba3e798ef3f0cc059881056d1f43d Mon Sep 17 00:00:00 2001 From: Corinna Vinschen Date: Sat, 16 Jan 2016 19:39:37 +0100 Subject: [PATCH] On 32 bit Cygwin, build for 686 CPUs only Cygwin only supports at least i686 on 32 bit. Just build for this CPU type. Signed-off-by: Corinna Vinschen --- Configurations/10-main.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf index d732a82..02f9878 100644 --- a/Configurations/10-main.conf +++ b/Configurations/10-main.conf @@ -1224,7 +1224,7 @@ "Cygwin" => { inherit_from => [ asm("x86_asm") ], cc => "gcc", - cflags => "\$(OPT_CFLAGS) -DTERMIOS -DL_ENDIAN -march=i486 -Wall", + cflags => "\$(OPT_CFLAGS) -DTERMIOS -DL_ENDIAN -march=i686 -Wall", debug_cflags => "-g -O0", release_cflags => "-O3 -fomit-frame-pointer", sys_id => "CYGWIN", -- 2.5.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From openssl-users at dukhovni.org Sat Jan 16 18:57:35 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 16 Jan 2016 18:57:35 +0000 Subject: [openssl-dev] SSL_set_tlsext_host_name(ssl, "") In-Reply-To: <20160116184143.GP646@mournblade.imrryr.org> References: <20160116174218.GA18704@x2.esmtp.org> <20160116184143.GP646@mournblade.imrryr.org> Message-ID: <20160116185734.GQ646@mournblade.imrryr.org> On Sat, Jan 16, 2016 at 06:41:43PM +0000, Viktor Dukhovni wrote: > > This can also be reproduced using > > openssl s_client -servername "" ... > > Please try the two attached patches. Better version of the first patch. -- Viktor. -------------- next part -------------- >From 792fd81abdffd068162077bdb972baccfe09f280 Mon Sep 17 00:00:00 2001 From: Viktor Dukhovni Date: Sat, 16 Jan 2016 12:57:24 -0500 Subject: [PATCH 1/2] Empty SNI names are not valid While empty inputs to SSL_set1_host() clear the reference identifier list. --- crypto/x509/x509_vpm.c | 4 ++-- ssl/s3_lib.c | 5 ++++- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/crypto/x509/x509_vpm.c b/crypto/x509/x509_vpm.c index 827360d..8826fec 100644 --- a/crypto/x509/x509_vpm.c +++ b/crypto/x509/x509_vpm.c @@ -92,11 +92,11 @@ static int int_x509_param_set_hosts(X509_VERIFY_PARAM *vpm, int mode, * Refuse names with embedded NUL bytes, except perhaps as final byte. * XXX: Do we need to push an error onto the error stack? */ - if (namelen == 0) + if (namelen == 0 || name == NULL) namelen = name ? strlen(name) : 0; else if (name && memchr(name, '\0', namelen > 1 ? namelen - 1 : namelen)) return 0; - if (name && name[namelen - 1] == '\0') + if (namelen > 0 && name[namelen - 1] == '\0') --namelen; if (mode == SET_HOST) { diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c index de8dae2..54b8eba 100644 --- a/ssl/s3_lib.c +++ b/ssl/s3_lib.c @@ -3534,13 +3534,16 @@ long ssl3_ctrl(SSL *s, int cmd, long larg, void *parg) #endif /* !OPENSSL_NO_EC */ case SSL_CTRL_SET_TLSEXT_HOSTNAME: if (larg == TLSEXT_NAMETYPE_host_name) { + size_t len; + OPENSSL_free(s->tlsext_hostname); s->tlsext_hostname = NULL; ret = 1; if (parg == NULL) break; - if (strlen((char *)parg) > TLSEXT_MAXLEN_host_name) { + len = strlen((char *)parg); + if (len == 0 || len > TLSEXT_MAXLEN_host_name) { SSLerr(SSL_F_SSL3_CTRL, SSL_R_SSL3_EXT_INVALID_SERVERNAME); return 0; } -- 2.5.4 (Apple Git-61) From kurt at roeckx.be Sat Jan 16 18:59:34 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 16 Jan 2016 19:59:34 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160116184250.GJ12431@calimero.vinschen.de> References: <20160114.154418.799119456171028604.levitte@openssl.org> <20160116183724.GI12431@calimero.vinschen.de> <20160116184250.GJ12431@calimero.vinschen.de> Message-ID: <20160116185933.GA12641@roeckx.be> On Sat, Jan 16, 2016 at 07:42:50PM +0100, Corinna Vinschen wrote: > On Jan 16 19:37, Corinna Vinschen wrote: > > On Jan 14 15:44, Richard Levitte wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > > > > OpenSSL version 1.1.0 pre release 2 (alpha) > > > =========================================== > > > > I tried to build this for Cygwin and got some problems. > > [...] > > The attached patchset fixes all of the above. With this, > > openssl-1.1.0-pre2 builds fine for Cygwin. > > I added another patch to this mail which sets the default CPU for 32 bit > Cygwin builds to i686, as outlined in another mail. Cygwin won't run on > older CPUs anyway. The path depends on the 2nd patch from my previous > mail. Is gcc configure to only produce i686 code on cygwin, and so can we maybe drop the -march instead? Kurt From vinschen at redhat.com Sat Jan 16 19:01:59 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 16 Jan 2016 20:01:59 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160116185933.GA12641@roeckx.be> References: <20160114.154418.799119456171028604.levitte@openssl.org> <20160116183724.GI12431@calimero.vinschen.de> <20160116184250.GJ12431@calimero.vinschen.de> <20160116185933.GA12641@roeckx.be> Message-ID: <20160116190159.GA24307@calimero.vinschen.de> On Jan 16 19:59, Kurt Roeckx wrote: > On Sat, Jan 16, 2016 at 07:42:50PM +0100, Corinna Vinschen wrote: > > On Jan 16 19:37, Corinna Vinschen wrote: > > > On Jan 14 15:44, Richard Levitte wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > > > > > > > > > > OpenSSL version 1.1.0 pre release 2 (alpha) > > > > =========================================== > > > > > > I tried to build this for Cygwin and got some problems. > > > [...] > > > The attached patchset fixes all of the above. With this, > > > openssl-1.1.0-pre2 builds fine for Cygwin. > > > > I added another patch to this mail which sets the default CPU for 32 bit > > Cygwin builds to i686, as outlined in another mail. Cygwin won't run on > > older CPUs anyway. The path depends on the 2nd patch from my previous > > mail. > > Is gcc configure to only produce i686 code on cygwin, and so can > we maybe drop the -march instead? Oh yes, indeed. Sorry I missed that :} Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From openssl-users at dukhovni.org Sat Jan 16 19:20:40 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 16 Jan 2016 19:20:40 +0000 Subject: [openssl-dev] "SSL_dane_enable() may be called" In-Reply-To: <20160116123026.GA25768@x2.esmtp.org> References: <20160116123026.GA25768@x2.esmtp.org> Message-ID: <20160116192039.GR646@mournblade.imrryr.org> On Sat, Jan 16, 2016 at 04:30:26AM -0800, Claus Assmann wrote: > SSL_CTX_dane_enable.pod states: > > SSL_dane_enable() may be called before the SSL handshake is > initiated with L to enable DANE for that connection. > > "may" seems to be a bit confusing here: if you want "to enable DANE > for that connection" then you "must" call the function, right? Correct. And conversely must not be called, if the intention is to not enable DANE. Any suggested improvements of the text. -- Viktor. From ca+ssl-dev at esmtp.org Sat Jan 16 19:32:51 2016 From: ca+ssl-dev at esmtp.org (Claus Assmann) Date: Sat, 16 Jan 2016 11:32:51 -0800 Subject: [openssl-dev] "SSL_dane_enable() may be called" In-Reply-To: <20160116192039.GR646@mournblade.imrryr.org> References: <20160116123026.GA25768@x2.esmtp.org> <20160116192039.GR646@mournblade.imrryr.org> Message-ID: <20160116193251.GA2114@x2.esmtp.org> On Sat, Jan 16, 2016, Viktor Dukhovni wrote: > On Sat, Jan 16, 2016 at 04:30:26AM -0800, Claus Assmann wrote: > > SSL_dane_enable() may be called before the SSL handshake is > > initiated with L to enable DANE for that connection. > > "may" seems to be a bit confusing here: if you want "to enable DANE > > for that connection" then you "must" call the function, right? > Correct. And conversely must not be called, if the intention is > to not enable DANE. Any suggested improvements of the text. - simply replace "may" with "must"? SSL_dane_enable() must be called before the SSL handshake is initiated with L to enable DANE for that connection. - this might be better: To enable DANE for a connection SSL_dane_enable() must be called before the SSL handshake is initiated with L. - or very explicit: SSL_dane_enable() must be called before the SSL handshake is initiated with L if (and only if) you want to enable DANE for that connection. From waywardgeek at google.com Sat Jan 16 19:46:52 2016 From: waywardgeek at google.com (Bill Cox) Date: Sat, 16 Jan 2016 11:46:52 -0800 Subject: [openssl-dev] Keyed hashing APIs for EVP? In-Reply-To: References: Message-ID: Another question: BLAKE2 passes the output length to the Blake2b_Init and Blake2s_Init functions. It is used to force the resulting output hash to depend on the output length, which in general sounds like a reasonable security precaution. Also, it is an error for outlen to be greater than the block size (64 for BLAKE2b, 32 for BLAKE2s). The EVP digest functions do not seem to take an output length, which seems OK. If I am allowed to add a blake2.h under openssl/include/openssl, should the public API for the BLAKE2 Init functions take outlen as a parameter, or should I make them like the other digest functions? I worry that people will get confused if they pass the actual used output length to BLAKE2b_Init, and wind up with a different hash output than when using the EVP APIs instead. OTOH, I hate to leave out a feature that slightly improves security. Which wins in this case? Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinschen at redhat.com Sat Jan 16 19:54:50 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 16 Jan 2016 20:54:50 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160116190159.GA24307@calimero.vinschen.de> References: <20160114.154418.799119456171028604.levitte@openssl.org> <20160116183724.GI12431@calimero.vinschen.de> <20160116184250.GJ12431@calimero.vinschen.de> <20160116185933.GA12641@roeckx.be> <20160116190159.GA24307@calimero.vinschen.de> Message-ID: <20160116195450.GB24307@calimero.vinschen.de> On Jan 16 20:01, Corinna Vinschen wrote: > On Jan 16 19:59, Kurt Roeckx wrote: > > On Sat, Jan 16, 2016 at 07:42:50PM +0100, Corinna Vinschen wrote: > > > On Jan 16 19:37, Corinna Vinschen wrote: > > > > On Jan 14 15:44, Richard Levitte wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > Hash: SHA1 > > > > > > > > > > > > > > > OpenSSL version 1.1.0 pre release 2 (alpha) > > > > > =========================================== > > > > > > > > I tried to build this for Cygwin and got some problems. > > > > [...] > > > > The attached patchset fixes all of the above. With this, > > > > openssl-1.1.0-pre2 builds fine for Cygwin. > > > > > > I added another patch to this mail which sets the default CPU for 32 bit > > > Cygwin builds to i686, as outlined in another mail. Cygwin won't run on > > > older CPUs anyway. The path depends on the 2nd patch from my previous > > > mail. > > > > Is gcc configure to only produce i686 code on cygwin, and so can > > we maybe drop the -march instead? > > Oh yes, indeed. Sorry I missed that :} Here's the changed patch. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- From 544d74273588d8d3e887a2b0b32d2e5afb76d7d9 Mon Sep 17 00:00:00 2001 From: Corinna Vinschen Date: Sat, 16 Jan 2016 19:39:37 +0100 Subject: [PATCH] On 32 bit Cygwin, build for 686 CPUs only Cygwin only supports at least i686 on 32 bit. Just build for the default CPU type. Signed-off-by: Corinna Vinschen --- Configurations/10-main.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf index d732a82..14ed3a7 100644 --- a/Configurations/10-main.conf +++ b/Configurations/10-main.conf @@ -1224,7 +1224,7 @@ "Cygwin" => { inherit_from => [ asm("x86_asm") ], cc => "gcc", - cflags => "\$(OPT_CFLAGS) -DTERMIOS -DL_ENDIAN -march=i486 -Wall", + cflags => "\$(OPT_CFLAGS) -DTERMIOS -DL_ENDIAN -Wall", debug_cflags => "-g -O0", release_cflags => "-O3 -fomit-frame-pointer", sys_id => "CYGWIN", -- 2.5.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From michel.sales at free.fr Sat Jan 16 20:18:41 2016 From: michel.sales at free.fr (Michel) Date: Sat, 16 Jan 2016 21:18:41 +0100 Subject: [openssl-dev] MSVC 2015 internal compiler error In-Reply-To: <569A1EAC.1000607@yahoo.no> References: <569A1EAC.1000607@yahoo.no> Message-ID: <005401d1509b$17dbaa80$4792ff80$@sales@free.fr> Hi, FWIW I encountered the same problem last week with the statem_srvr.c. I undestood that it was a compiler bug, but suspected there was an underlying problem with the source code, as usually it is error in MY code that make the compiler crashes... :-( So I gave a try to Visual Studio Community 2013 SP 5, and it compiles even without a warning. Contrary at what I read, the update 1 of VS 2015 didn't fixed this. -----Message d'origine----- De?: openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Gisle Vanem Envoy??: samedi 16 janvier 2016 11:43 ??: OpenSSL-dev Objet?: [openssl-dev] MSVC 2015 internal compiler error While building OpenSSL from today's git-repo: ssl\d1_srtp.c : fatal error C1001: An internalerror has occurred in the compiler. (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 246) To work around this problem, try simplifying or changing the program near the locations listed above. Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information INTERNAL COMPILER ERROR in 'f:\gv\VC_2015\bin\cl.exe' Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information From rt at openssl.org Sat Jan 16 20:36:14 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 16 Jan 2016 20:36:14 +0000 Subject: [openssl-dev] [openssl.org #4239] [PATCH] fixing wildcard matching on punycode domains In-Reply-To: References: Message-ID: Viktor merged this in. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat Jan 16 20:45:12 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 16 Jan 2016 20:45:12 +0000 Subject: [openssl-dev] [openssl.org #4026] patches to eliminate some warnings from clang In-Reply-To: References: Message-ID: Compiler warnings in non-master aren't going to be addressed unless we see they are bugs. Clsoing this. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat Jan 16 20:46:42 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 16 Jan 2016 20:46:42 +0000 Subject: [openssl-dev] [openssl.org #4112] GH458: Fix "primarility" typo In-Reply-To: References: Message-ID: right, this was merged; closing. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From openssl-users at dukhovni.org Sat Jan 16 20:47:16 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 16 Jan 2016 15:47:16 -0500 Subject: [openssl-dev] "SSL_dane_enable() may be called" In-Reply-To: <20160116193251.GA2114@x2.esmtp.org> References: <20160116123026.GA25768@x2.esmtp.org> <20160116192039.GR646@mournblade.imrryr.org> <20160116193251.GA2114@x2.esmtp.org> Message-ID: <4429E225-5B35-47E5-AB78-3CE3DAEB4AB2@dukhovni.org> > On Jan 16, 2016, at 2:32 PM, Claus Assmann wrote: > > - or very explicit: > SSL_dane_enable() must be called before the SSL handshake is initiated > with L if (and only if) you want to enable DANE for > that connection. I'm going with this one. Thanks. -- Viktor. From rt at openssl.org Sat Jan 16 20:47:39 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 16 Jan 2016 20:47:39 +0000 Subject: [openssl-dev] [openssl.org #4140] GITHUB PULL REQUEST: do not load engines twice In-Reply-To: <20151114112920.GB29696@suse.de> References: <20151114112920.GB29696@suse.de> Message-ID: Merged, closing. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat Jan 16 20:48:17 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 16 Jan 2016 20:48:17 +0000 Subject: [openssl-dev] [openssl.org #4174] Support the TLS Feature (aka Must Staple) X.509v3 extension (RFC7633) In-Reply-To: <5665A835.1020206@comodo.com> References: <5665A835.1020206@comodo.com> Message-ID: Yes merged and closing this. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat Jan 16 20:50:44 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 16 Jan 2016 20:50:44 +0000 Subject: [openssl-dev] [openssl.org #4222] Wrong definition of the macro SSL_set1_sigalgs in ssl.h (PR #519) In-Reply-To: <478739725.1292081.1452146254823.JavaMail.yahoo@mail.yahoo.com> References: <478739725.1292081.1452146254823.JavaMail.yahoo.ref@mail.yahoo.com> <478739725.1292081.1452146254823.JavaMail.yahoo@mail.yahoo.com> Message-ID: merged, closing. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat Jan 16 20:51:35 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 16 Jan 2016 20:51:35 +0000 Subject: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code In-Reply-To: <20151031122641.GA11750@kronk.local> References: <20151031122641.GA11750@kronk.local> Message-ID: we did everything we want to do, closing this. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat Jan 16 20:52:15 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 16 Jan 2016 20:52:15 +0000 Subject: [openssl-dev] [openssl.org #4183] No SSL_CIPHER_description() for ChaCha20/Poly1305 In-Reply-To: <5671D73D.9040405@akamai.com> References: <5671D73D.9040405@akamai.com> Message-ID: yes, fixed. closing. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat Jan 16 20:53:09 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 16 Jan 2016 20:53:09 +0000 Subject: [openssl-dev] [openssl.org #4219] [typos] DANE related docs In-Reply-To: <20160106170432.GB29574@x2.esmtp.org> References: <20160106170432.GB29574@x2.esmtp.org> Message-ID: yes fixed; closing. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat Jan 16 20:56:09 2016 From: rt at openssl.org (Claus Assmann via RT) Date: Sat, 16 Jan 2016 20:56:09 +0000 Subject: [openssl-dev] [openssl.org #4250] [typos] doc/ssl/SSL_CTX_dane_enable.pod In-Reply-To: <20160116140853.GA4483@x2.esmtp.org> References: <20160116140853.GA4483@x2.esmtp.org> Message-ID: The example uses "s" in some places instead of "ssl": diff --git a/doc/ssl/SSL_CTX_dane_enable.pod b/doc/ssl/SSL_CTX_dane_enable.pod index c3c203e..21788ad 100644 --- a/doc/ssl/SSL_CTX_dane_enable.pod +++ b/doc/ssl/SSL_CTX_dane_enable.pod @@ -210,9 +210,9 @@ the lifetime of the SSL connection. const char *peername = SSL_get0_peername(ssl); EVP_PKEY *mspki = NULL; - int depth = SSL_get0_dane_authority(s, NULL, &mspki); + int depth = SSL_get0_dane_authority(ssl, NULL, &mspki); if (depth >= 0) { - (void) SSL_get0_dane_tlsa(s, &usage, &selector, &mtype, NULL, NULL); + (void) SSL_get0_dane_tlsa(ssl, &usage, &selector, &mtype, NULL, NULL); printf("DANE TLSA %d %d %d %s at depth %d\n", usage, selector, mtype, (mspki != NULL) ? "TA public key verified certificate" : depth ? "matched TA certificate" : "matched EE certificate", From rt at openssl.org Sat Jan 16 20:56:09 2016 From: rt at openssl.org (Lukas Tribus via RT) Date: Sat, 16 Jan 2016 20:56:09 +0000 Subject: [openssl-dev] [openssl.org #4251] PR request: Add OCSP_SINGLERESP_get0_id() accessor In-Reply-To: References: Message-ID: Since 1.1.0 API will be freezed soon, can you review the following pull-request Remi Gacogne posted: Add an OCSP_SINGLERESP_get0_id() accessor to the OCSP_CERTID of a OCSP_SINGLERESP https://github.com/openssl/openssl/pull/334 Thank you! From openssl-users at dukhovni.org Sat Jan 16 20:59:20 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 16 Jan 2016 15:59:20 -0500 Subject: [openssl-dev] [openssl.org #4250] [typos] doc/ssl/SSL_CTX_dane_enable.pod In-Reply-To: References: <20160116140853.GA4483@x2.esmtp.org> Message-ID: <1685471E-65AE-4823-9924-2E74A4942DA5@dukhovni.org> > On Jan 16, 2016, at 3:56 PM, Claus Assmann via RT wrote: > > - int depth = SSL_get0_dane_authority(s, NULL, &mspki); > + int depth = SSL_get0_dane_authority(ssl, NULL, &mspki); > - (void) SSL_get0_dane_tlsa(s, &usage, &selector, &mtype, NULL, NULL); > + (void) SSL_get0_dane_tlsa(ssl, &usage, &selector, &mtype, NULL, NULL); Merged. Thanks. -- Viktor. From rt at openssl.org Sat Jan 16 20:59:24 2016 From: rt at openssl.org (Viktor Dukhovni via RT) Date: Sat, 16 Jan 2016 20:59:24 +0000 Subject: [openssl-dev] [openssl.org #4250] [typos] doc/ssl/SSL_CTX_dane_enable.pod In-Reply-To: <1685471E-65AE-4823-9924-2E74A4942DA5@dukhovni.org> References: <20160116140853.GA4483@x2.esmtp.org> <1685471E-65AE-4823-9924-2E74A4942DA5@dukhovni.org> Message-ID: > On Jan 16, 2016, at 3:56 PM, Claus Assmann via RT wrote: > > - int depth = SSL_get0_dane_authority(s, NULL, &mspki); > + int depth = SSL_get0_dane_authority(ssl, NULL, &mspki); > - (void) SSL_get0_dane_tlsa(s, &usage, &selector, &mtype, NULL, NULL); > + (void) SSL_get0_dane_tlsa(ssl, &usage, &selector, &mtype, NULL, NULL); Merged. Thanks. -- Viktor. From steve at openssl.org Sat Jan 16 22:12:10 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Sat, 16 Jan 2016 22:12:10 +0000 Subject: [openssl-dev] Keyed hashing APIs for EVP? In-Reply-To: References: Message-ID: <20160116221210.GA31336@openssl.org> On Sat, Jan 16, 2016, Bill Cox wrote: > > I feel keyed hashing is here to stay. Keccak also has this feature. > Assuming I'm reading the EVP API correctly, should add support for keyed > digests to EVP. What do you folks think? > Support for MAC already exists in EVP. It's possible to access HMAC, CMAC and GOST MAC algorithms using EVP. The interface isn't very friendly however and could be tidied up a bit. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From ca+ssl-dev at esmtp.org Sat Jan 16 23:40:15 2016 From: ca+ssl-dev at esmtp.org (Claus Assmann) Date: Sat, 16 Jan 2016 15:40:15 -0800 Subject: [openssl-dev] SSL_set_tlsext_host_name(ssl, "") In-Reply-To: <20160116185734.GQ646@mournblade.imrryr.org> References: <20160116174218.GA18704@x2.esmtp.org> <20160116184143.GP646@mournblade.imrryr.org> <20160116185734.GQ646@mournblade.imrryr.org> Message-ID: <20160116234015.GA8123@x2.esmtp.org> On Sat, Jan 16, 2016, Viktor Dukhovni wrote: > > Please try the two attached patches. > Better version of the first patch. Those solve the problem for me. Thanks! From levitte at openssl.org Sun Jan 17 00:04:03 2016 From: levitte at openssl.org (Richard Levitte) Date: Sun, 17 Jan 2016 01:04:03 +0100 (CET) Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160116164653.GH12431@calimero.vinschen.de> References: <20160114.215903.813205413779228431.levitte@openssl.org> <20160116164653.GH12431@calimero.vinschen.de> Message-ID: <20160117.010403.1870902035842192354.levitte@openssl.org> In message <20160116164653.GH12431 at calimero.vinschen.de> on Sat, 16 Jan 2016 17:46:53 +0100, Corinna Vinschen said: vinschen> > ./config --unified vinschen> vinschen> I tried that and it doesn't work correctly for Cygwin on x86_64. vinschen> Rather than choosing the "Cygwin-x86_64" configuration, it chooses vinschen> the "Cygwin" configuration which is for the i686 based 32 bit vinschen> version of Cygwin. vinschen> vinschen> Can this be recified easily. vinschen> vinschen> Btw., for the new unified configuration it might make sense to vinschen> rename "Cygwin" to "Cygwin-i686". -march could then be set for vinschen> i686 as well since 32 bit Cygwin won't run on older CPUs anyway. Hey Corinna, This particular issue has nothing at all to do with with my build system changes, and everything to do with the "config" script. Its responsability is to figure out what the platform target should be and then call Configure with it. If you have a look in "config", it doesn't generate "Cygwin-x86_64" at all. Would you be willing to have a look at that script and modernise it regarding Cygwin? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sun Jan 17 00:14:14 2016 From: levitte at openssl.org (Richard Levitte) Date: Sun, 17 Jan 2016 01:14:14 +0100 (CET) Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160116183724.GI12431@calimero.vinschen.de> References: <20160114.154418.799119456171028604.levitte@openssl.org> <20160116183724.GI12431@calimero.vinschen.de> Message-ID: <20160117.011414.1456898108185780791.levitte@openssl.org> In message <20160116183724.GI12431 at calimero.vinschen.de> on Sat, 16 Jan 2016 19:37:24 +0100, Corinna Vinschen said: vinschen> Who had this funny idea to use the Windows definitions when building for vinschen> Cygwin? I'm afraid that is lost in the thin web of history ;-) vinschen> vinschen> vinschen> Please, please, please, Cygwin is a *POSIX* layer. Please don't use vinschen> Windows functions on Cygwin, use POSIX functions and POSIX methods, vinschen> *unless* it's really necessary. .... vinschen> I hear ya. vinschen> Last but not least, we have a small build problem when building for the vinschen> distro: To build the packages with additional debuginfo packages, the vinschen> packages must not be built with the -s option, plus we have to induce a vinschen> few options for the sake of creating the debuginfo information. Up to vinschen> 1.0.2 we do this by tweaking openssl's build system. We add an expression vinschen> $(OPT_CFLAGS) to the CFLAGS definition for that. If there's a better, vinschen> easier way to do this, I'd be grateful for a hint. OPT_FLAGS would be for optimizing, do I get that right? I suggest you have a look at Configurations/10-main.conf, you might notice configuration items like debug_cflags, release_cflags, debug_lflags and release_lflags. If you have a look at my refactor-build branch, you will see a fairly thorough Configurations/README. If you look the commit titled "Refactor config - move templates docs asm templates to Configurations", you'll find the documentation that's applicable to what Configure in the master branch supports... later editions are currently only supported in my branch. vinschen> The attached patchset fixes all of the above. With this, vinschen> openssl-1.1.0-pre2 builds fine for Cygwin. I'll have a closer look at all that tomorrow. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From gvanem at yahoo.no Sun Jan 17 08:50:55 2016 From: gvanem at yahoo.no (Gisle Vanem) Date: Sun, 17 Jan 2016 09:50:55 +0100 Subject: [openssl-dev] MSVC 2015 internal compiler error In-Reply-To: <005401d1509b$17dbaa80$4792ff80$@sales@free.fr> References: <569A1EAC.1000607@yahoo.no> <005401d1509b$17dbaa80$4792ff80$@sales@free.fr> Message-ID: <569B55EF.5050205@yahoo.no> Michel wrote: > FWIW I encountered the same problem last week with the statem_srvr.c. > I undestood that it was a compiler bug, but suspected there was an > underlying problem with the source code, as usually it is error in MY code > that make the compiler crashes... Nice to seem I'm not alone with such a problem. > So I gave a try to Visual Studio Community 2013 SP 5, and it compiles even > without a warning. > Contrary at what I read, the update 1 of VS 2015 didn't fixed this. I think I have this "update 1" from the cl version: Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23026 for x86 And did you have problems with the x86 compiler too? Did you try the x64 version also? -- --gv From rt at openssl.org Sun Jan 17 10:13:40 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Sun, 17 Jan 2016 10:13:40 +0000 Subject: [openssl-dev] [openssl.org #4248] Link error under Windows In-Reply-To: <5698E644.1080209@approach.be> References: <5698E644.1080209@approach.be> Message-ID: Hi Marc, is this still current? I've checked in as many ways as I can right now and I cannot make the build fail. Those functions look properly marked as deprecated, or in some cases, not existing at all. Since you didn't tell us the age of your source (was it 1.1.0 pre 1? 1.1.0 pre 2? Fresh pull of our master branch?), it's a bit difficult to help you further. All I can suggest is that you download 1.1.0 pre 2 (was release this Thursday) or make a fresh pull of our master branch and try again. In the mean time, I'm closing this ticket. Should you run into this issue anew, feel free to report again. Cheers, Richard Vid Sat, 16 Jan 2016 kl. 03.14.17, skrev marc.stern at approach.be: > On any version of Windows (32 or 64 bits), if using the "no-deprecated" > configure flag, some functions (see list below) are not compiled but > they are still referenced in LIBEAY32.DEF. This gives the following > error: LIBEAY32.def : error LNK2001: unresolved external symbol ... > > List of functions: > - BN_BLINDING_get_thread_id > - BN_BLINDING_set_thread_id > - BN_CTX_init > - BN_generate_prime > - BN_get_params > - BN_is_prime > - BN_is_prime_fasttest > - BN_set_params > - CRYPTO_get_id_callback > - CRYPTO_set_id_callback > - CRYPTO_thread_id > - DH_generate_parameters > - DSA_generate_parameters > - ERR_remove_state > - RSA_generate_key > - bn_dup_expand > -- Richard Levitte levitte at openssl.org From michel.sales at free.fr Sun Jan 17 10:21:34 2016 From: michel.sales at free.fr (Michel) Date: Sun, 17 Jan 2016 11:21:34 +0100 Subject: [openssl-dev] MSVC 2015 internal compiler error In-Reply-To: <569B55EF.5050205@yahoo.no> References: <569A1EAC.1000607@yahoo.no> <005401d1509b$17dbaa80$4792ff80$@sales@free.fr> <569B55EF.5050205@yahoo.no> Message-ID: <000301d15110$d78131f0$868395d0$@sales@free.fr> > And did you have problems with the x86 compiler too? Did you try the x64 version also? No, I didn't try the x64 version. From levitte at openssl.org Sun Jan 17 10:43:03 2016 From: levitte at openssl.org (Richard Levitte) Date: Sun, 17 Jan 2016 11:43:03 +0100 (CET) Subject: [openssl-dev] Personal configuration in 1.1.0 Message-ID: <20160117.114303.1596959756799309923.levitte@openssl.org> Hi, I think I've seen this question asked a few times, an it's time for an explanation. In upcoming OpenSSL 1.1.0, the old configuration strings supposed to be gone, completely and entirely. There are some traces left from the time when we still had some of them and were converting them to the new style configurations found in Configurations/, but those bits haven't been tried for some time. As a matter of fact, those last traces are completely removed in my my refactor-build branch. If you want to keep some personal configurations around, I'd suggest having a look at the personal ones some of us in the team are keeping around in Configurations/, and build your own using them as a model on how to do so. Unfortunately, the documentation isn't there yet, at least in master. (have a look at my refactor-build branch, it has a Configurations/README which I hope does a fair enough job... if there are enhancements needed, feedback is welcome!) The older configuration strings still work as usual in the 1.0.x releases. That won't change, of course. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Sun Jan 17 11:26:29 2016 From: rt at openssl.org (Roumen Petrov via RT) Date: Sun, 17 Jan 2016 11:26:29 +0000 Subject: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code In-Reply-To: <569B7A5D.4080503@roumenpetrov.info> References: <20151031122641.GA11750@kronk.local> <569B7A5D.4080503@roumenpetrov.info> Message-ID: Rich Salz via RT wrote: > we did everything we want to do, closing this. What about to remove declaration of FIPS_mode and FIPS_mode_set? Those functions could be used by external packages at configure time to detect that fips is not supported at all. Note 1.0.0 does not declare both functions. Regards Roumen Petrov From kurt at roeckx.be Sun Jan 17 13:16:04 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 17 Jan 2016 14:16:04 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160117.011414.1456898108185780791.levitte@openssl.org> References: <20160114.154418.799119456171028604.levitte@openssl.org> <20160116183724.GI12431@calimero.vinschen.de> <20160117.011414.1456898108185780791.levitte@openssl.org> Message-ID: <20160117131603.GA10909@roeckx.be> On Sun, Jan 17, 2016 at 01:14:14AM +0100, Richard Levitte wrote: > OPT_FLAGS would be for optimizing, do I get that right? I suggest you > have a look at Configurations/10-main.conf, you might notice > configuration items like debug_cflags, release_cflags, debug_lflags > and release_lflags. If you have a look at my refactor-build branch, > you will see a fairly thorough Configurations/README. If you look the > commit titled "Refactor config - move templates docs asm templates to > Configurations", you'll find the documentation that's applicable to > what Configure in the master branch supports... later editions are > currently only supported in my branch. In Debian we have a system that where you can override things like the CFLAGS, and I wonder how easy it will be to integrate that with your new system. We have a tool called dpkg-buildflags. By default it now returns: $ dpkg-buildflags CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security FCFLAGS=-g -O2 -fstack-protector-strong FFLAGS=-g -O2 -fstack-protector-strong GCJFLAGS=-g -O2 -fstack-protector-strong LDFLAGS=-Wl,-z,relro OBJCFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security OBJCXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security In the 1.0.2 branch I use this: my $debian_cflags = `dpkg-buildflags --get CFLAGS` . `dpkg-buildflags --get CPPFLAGS` . `dpkg-buildflags --get LDFLAGS` . "-Wa,--noexecstack -Wall"; And then use $debian_cflags in the targets. There were was no way to separate clfags/lfdlags, so I needed to combine it. dpkg-buildflags can return different things depending on environment variables. Some examples: $ DEB_BUILD_OPTIONS=noopt dpkg-buildflags --get CFLAGS -g -O0 -fstack-protector-strong -Wformat -Werror=format-security $ DEB_BUILD_OPTIONS=hardening=-all dpkg-buildflags --get CFLAGS -g -O2 $ DEB_CFLAGS_APPEND=-O3 dpkg-buildflags --get CFLAGS -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -O3 There are environment variables for both the maintainer to set the defaults and someone who then wants to build the package with different settings. (I should move the -Wa,--noexecstack -Wall to environment variables.) Is there an easy way to I can override the flags with dpkg-buildflags? Kurt From rt at openssl.org Sun Jan 17 14:17:16 2016 From: rt at openssl.org (Bheesham Persaud via RT) Date: Sun, 17 Jan 2016 14:17:16 +0000 Subject: [openssl-dev] [openssl.org #4252] [PATCH] Fix the inclusion of e_os2.h In-Reply-To: References: Message-ID: Hey all, `crypto/o_dir_test.c` was not using the correct path to `e_os2.h`. Link to pull request: https://github.com/openssl/openssl/pull/561 - Bhee -------------- next part -------------- A non-text attachment was scrubbed... Name: mydiffs.patch Type: text/x-patch Size: 681 bytes Desc: not available URL: From levitte at openssl.org Sun Jan 17 13:56:37 2016 From: levitte at openssl.org (Richard Levitte) Date: Sun, 17 Jan 2016 14:56:37 +0100 (CET) Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160117131603.GA10909@roeckx.be> References: <20160116183724.GI12431@calimero.vinschen.de> <20160117.011414.1456898108185780791.levitte@openssl.org> <20160117131603.GA10909@roeckx.be> Message-ID: <20160117.145637.791534577484004451.levitte@openssl.org> In message <20160117131603.GA10909 at roeckx.be> on Sun, 17 Jan 2016 14:16:04 +0100, Kurt Roeckx said: kurt> On Sun, Jan 17, 2016 at 01:14:14AM +0100, Richard Levitte wrote: kurt> > OPT_FLAGS would be for optimizing, do I get that right? I suggest you kurt> > have a look at Configurations/10-main.conf, you might notice kurt> > configuration items like debug_cflags, release_cflags, debug_lflags kurt> > and release_lflags. If you have a look at my refactor-build branch, kurt> > you will see a fairly thorough Configurations/README. If you look the kurt> > commit titled "Refactor config - move templates docs asm templates to kurt> > Configurations", you'll find the documentation that's applicable to kurt> > what Configure in the master branch supports... later editions are kurt> > currently only supported in my branch. kurt> kurt> In Debian we have a system that where you can override things like kurt> the CFLAGS, and I wonder how easy it will be to integrate that kurt> with your new system. kurt> kurt> We have a tool called dpkg-buildflags. By default it now returns: kurt> $ dpkg-buildflags kurt> CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security kurt> CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 kurt> CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security kurt> FCFLAGS=-g -O2 -fstack-protector-strong kurt> FFLAGS=-g -O2 -fstack-protector-strong kurt> GCJFLAGS=-g -O2 -fstack-protector-strong kurt> LDFLAGS=-Wl,-z,relro kurt> OBJCFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security kurt> OBJCXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security kurt> kurt> In the 1.0.2 branch I use this: kurt> my $debian_cflags = `dpkg-buildflags --get CFLAGS` . `dpkg-buildflags --get CPPFLAGS` . `dpkg-buildflags --get LDFLAGS` . "-Wa,--noexecstack -Wall"; kurt> kurt> And then use $debian_cflags in the targets. kurt> kurt> There were was no way to separate clfags/lfdlags, so I needed to kurt> combine it. kurt> kurt> dpkg-buildflags can return different things depending on environment variables. kurt> Some examples: kurt> $ DEB_BUILD_OPTIONS=noopt dpkg-buildflags --get CFLAGS kurt> -g -O0 -fstack-protector-strong -Wformat -Werror=format-security kurt> kurt> $ DEB_BUILD_OPTIONS=hardening=-all dpkg-buildflags --get CFLAGS kurt> -g -O2 kurt> kurt> $ DEB_CFLAGS_APPEND=-O3 dpkg-buildflags --get CFLAGS kurt> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -O3 kurt> kurt> kurt> There are environment variables for both the maintainer to set the kurt> defaults and someone who then wants to build the package with kurt> different settings. kurt> kurt> (I should move the -Wa,--noexecstack -Wall to environment kurt> variables.) kurt> kurt> Is there an easy way to I can override the flags with kurt> dpkg-buildflags? I see where you're going with this. As it is right now, there is no way to affect Configure via the environment, except for the names of certain commands. Personally, I'd say that using those should be done carefully. I have no plans to expand on the use of environment variables... However, there is always the possibility to quickly write up a small config target for yourself in Configurations, and have them inherit the items for an already existing target. For example: cflags=` ... dpkg-buildflags --get CFLAGS`; \ cat < Configurations/01-debian-tmp.conf %targets = ( "debian-linux-x86_64" => { inherit_from => [ "linux-x86_64" ], cflags => "$cflags", } ); 1; EOF If you want to just append or prepend your flags, you do this with the cflags item: cflags => sub { join(" ", $@, "$cflags"); }, In my refactor-build branch, I've added some lazy functions to do the same: cflags => add("$cflags"), or cflags => add_before("$cflags"), # to prepend Did that help? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Sun Jan 17 14:19:34 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 17 Jan 2016 14:19:34 +0000 Subject: [openssl-dev] [openssl-commits] [openssl] master update In-Reply-To: <569A178C.5000308@kippdata.de> References: <1452916037.569399.13452.nullmailer@dev.openssl.org> <569A178C.5000308@kippdata.de> Message-ID: <9a0c7159a70d4f7790b07e6a95178544@usma1ex-dag1mb1.msg.corp.akamai.com> > Please note that the patch in RT4247 also contains a hunk for > crypto/evp/e_camellia.c. This was not committed here, but without it one > gets the same type of compilation error on SPARC. Since the RT is already > closed I thought I better ask. Thanks for catching this. Fixed now. From rsalz at akamai.com Sun Jan 17 15:11:06 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 17 Jan 2016 15:11:06 +0000 Subject: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code In-Reply-To: References: <20151031122641.GA11750@kronk.local> <569B7A5D.4080503@roumenpetrov.info> Message-ID: <9dfc402d9f164092af1181420d9ab486@usma1ex-dag1mb1.msg.corp.akamai.com> > What about to remove declaration of FIPS_mode and FIPS_mode_set? > Those functions could be used by external packages at configure time to > detect that fips is not supported at all. > Note 1.0.0 does not declare both functions. For various reasons, the team wants them there. From rt at openssl.org Sun Jan 17 15:11:15 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Sun, 17 Jan 2016 15:11:15 +0000 Subject: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code In-Reply-To: <9dfc402d9f164092af1181420d9ab486@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20151031122641.GA11750@kronk.local> <569B7A5D.4080503@roumenpetrov.info> <9dfc402d9f164092af1181420d9ab486@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > What about to remove declaration of FIPS_mode and FIPS_mode_set? > Those functions could be used by external packages at configure time to > detect that fips is not supported at all. > Note 1.0.0 does not declare both functions. For various reasons, the team wants them there. From vinschen at redhat.com Sun Jan 17 15:26:01 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 17 Jan 2016 16:26:01 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160117.011414.1456898108185780791.levitte@openssl.org> References: <20160114.154418.799119456171028604.levitte@openssl.org> <20160116183724.GI12431@calimero.vinschen.de> <20160117.011414.1456898108185780791.levitte@openssl.org> Message-ID: <20160117152601.GA9897@calimero.vinschen.de> Hi Richard, On Jan 17 01:14, Richard Levitte wrote: > In message <20160116183724.GI12431 at calimero.vinschen.de> on Sat, 16 Jan 2016 19:37:24 +0100, Corinna Vinschen said: > > vinschen> Who had this funny idea to use the Windows definitions when building for > vinschen> Cygwin? > > I'm afraid that is lost in the thin web of history ;-) Heh :) > vinschen> > vinschen> > vinschen> Please, please, please, Cygwin is a *POSIX* layer. Please don't use > vinschen> Windows functions on Cygwin, use POSIX functions and POSIX methods, > vinschen> *unless* it's really necessary. > .... > vinschen> > > I hear ya. > > vinschen> Last but not least, we have a small build problem when building for the > vinschen> distro: To build the packages with additional debuginfo packages, the > vinschen> packages must not be built with the -s option, plus we have to induce a > vinschen> few options for the sake of creating the debuginfo information. Up to > vinschen> 1.0.2 we do this by tweaking openssl's build system. We add an expression > vinschen> $(OPT_CFLAGS) to the CFLAGS definition for that. If there's a better, > vinschen> easier way to do this, I'd be grateful for a hint. > > OPT_FLAGS would be for optimizing, do I get that right? Uh no, I think OPT stands for "optional" in this case. I didn't invent the name, actually :) > I suggest you > have a look at Configurations/10-main.conf, you might notice > configuration items like debug_cflags, release_cflags, debug_lflags > and release_lflags. If you have a look at my refactor-build branch, > you will see a fairly thorough Configurations/README. If you look the > commit titled "Refactor config - move templates docs asm templates to > Configurations", you'll find the documentation that's applicable to > what Configure in the master branch supports... later editions are > currently only supported in my branch. I did that, but I don't see that the new build system would allow that any better than the previous build system. There's still no way to induce optional build flags into a build, unless you manually override CFLAGS, which is quite a burdon. In our case the options in OPT_CFLAGS added by the build systems are something along the lines of -ggdb -O2 -pipe -Wimplicit-function-declaration \ -fdebug-prefix-map=${BUILDDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 \ -fdebug-prefix-map=${SOURCEDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 This is required to make sure that the debuginfo is created during the build at all, and to make sure the mapping in the debuginfo is not using the build paths, but rather the installation paths. Otherwise the debuginfo pointer in the object files will point to the wrong paths. The above is provided by the package build system and depends on the path the build is done in, as well as the version of the package. This info is added by the package build system for all packages built for the distro. However, what that means is, we need to have a way to induce variable content into the release_cflags from "outside". This is usually no problem at all for packages with, e.g., autotool-based configuration. It's also not a Cygwin-specific problem. I dare say that many distro package builders have certain requirements to add variable build options to a build to allow distro-specific build options. It would be really nice if the OpenSSL build systems would allow that by default. Otherwise distros will always have to patch the package before being able to build it in a distro-specific way. > vinschen> The attached patchset fixes all of the above. With this, > vinschen> openssl-1.1.0-pre2 builds fine for Cygwin. > > I'll have a closer look at all that tomorrow. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From vinschen at redhat.com Sun Jan 17 15:32:35 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 17 Jan 2016 16:32:35 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160117.145637.791534577484004451.levitte@openssl.org> References: <20160116183724.GI12431@calimero.vinschen.de> <20160117.011414.1456898108185780791.levitte@openssl.org> <20160117131603.GA10909@roeckx.be> <20160117.145637.791534577484004451.levitte@openssl.org> Message-ID: <20160117153235.GB9897@calimero.vinschen.de> On Jan 17 14:56, Richard Levitte wrote: > In message <20160117131603.GA10909 at roeckx.be> on Sun, 17 Jan 2016 14:16:04 +0100, Kurt Roeckx said: > > kurt> On Sun, Jan 17, 2016 at 01:14:14AM +0100, Richard Levitte wrote: > kurt> > OPT_FLAGS would be for optimizing, do I get that right? I suggest you > kurt> > have a look at Configurations/10-main.conf, you might notice > kurt> > configuration items like debug_cflags, release_cflags, debug_lflags > kurt> > and release_lflags. If you have a look at my refactor-build branch, > kurt> > you will see a fairly thorough Configurations/README. If you look the > kurt> > commit titled "Refactor config - move templates docs asm templates to > kurt> > Configurations", you'll find the documentation that's applicable to > kurt> > what Configure in the master branch supports... later editions are > kurt> > currently only supported in my branch. > kurt> > kurt> In Debian we have a system that where you can override things like > kurt> the CFLAGS, and I wonder how easy it will be to integrate that > kurt> with your new system. > kurt> [...] > kurt> Is there an easy way to I can override the flags with > kurt> dpkg-buildflags? > > I see where you're going with this. > > As it is right now, there is no way to affect Configure via the > environment, except for the names of certain commands. Personally, > I'd say that using those should be done carefully. I have no plans to > expand on the use of environment variables... > > However, there is always the possibility to quickly write up a small > config target for yourself in Configurations, and have them inherit > the items for an already existing target. For example: > > cflags=` ... dpkg-buildflags --get CFLAGS`; \ > cat < Configurations/01-debian-tmp.conf > %targets = ( > "debian-linux-x86_64" => { > inherit_from => [ "linux-x86_64" ], > cflags => "$cflags", > } > ); > 1; > EOF > > If you want to just append or prepend your flags, you do this with the > cflags item: > > cflags => sub { join(" ", $@, "$cflags"); }, > > In my refactor-build branch, I've added some lazy functions to do the > same: > > cflags => add("$cflags"), > > or > > cflags => add_before("$cflags"), # to prepend > > Did that help? This is pretty non-standard. By not allowing to extend CFLAGS from the environment, you require all distros to patch the OpenSSL package to fit their needs in terms of the build flags. Why is that necessary? It's no problem at all with autotool or cmake-based configurations, and it's really *needed* by distros. Ideally you simply define CFLAGS differently, along the lines of OPENSSL_CFLAGS= -D_WINDLL -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS[...etc...] CFLAGS+=$(OPENSSL_CFLAGS) This way, the package build system can simply set CFLAGS to the desired value, as is typical. Alternatively, you can support a specific variable, e.g. OPENSSL_CFLAGS= -D_WINDLL -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS[...etc...] CFLAGS="${BUILD_CFLAGS) $(OPENSSL_CFLAGS)" and the package build system has to set $BUILD_CFLAGS. That would be sufficient as well. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Sun Jan 17 15:42:07 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 17 Jan 2016 15:42:07 +0000 Subject: [openssl-dev] [openssl.org #4251] PR request: Add OCSP_SINGLERESP_get0_id() accessor In-Reply-To: References: Message-ID: done in commit 9e5cd4bac777e27ebcdc9aa411f0a63c27500468 thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From vinschen at redhat.com Sun Jan 17 15:43:53 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 17 Jan 2016 16:43:53 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160117.010403.1870902035842192354.levitte@openssl.org> References: <20160114.215903.813205413779228431.levitte@openssl.org> <20160116164653.GH12431@calimero.vinschen.de> <20160117.010403.1870902035842192354.levitte@openssl.org> Message-ID: <20160117154353.GC9897@calimero.vinschen.de> On Jan 17 01:04, Richard Levitte wrote: > In message <20160116164653.GH12431 at calimero.vinschen.de> on Sat, 16 Jan 2016 17:46:53 +0100, Corinna Vinschen said: > > vinschen> > ./config --unified > vinschen> > vinschen> I tried that and it doesn't work correctly for Cygwin on x86_64. > vinschen> Rather than choosing the "Cygwin-x86_64" configuration, it chooses > vinschen> the "Cygwin" configuration which is for the i686 based 32 bit > vinschen> version of Cygwin. > vinschen> > vinschen> Can this be recified easily. > vinschen> > vinschen> Btw., for the new unified configuration it might make sense to > vinschen> rename "Cygwin" to "Cygwin-i686". -march could then be set for > vinschen> i686 as well since 32 bit Cygwin won't run on older CPUs anyway. > > Hey Corinna, > > This particular issue has nothing at all to do with with my build > system changes, and everything to do with the "config" script. Its > responsability is to figure out what the platform target should be and > then call Configure with it. > > If you have a look in "config", it doesn't generate "Cygwin-x86_64" at > all. Would you be willing to have a look at that script and modernise > it regarding Cygwin? Like the attached? Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- From d8b509832d9e8cab2cb8e8fd3cf4d34ada792818 Mon Sep 17 00:00:00 2001 From: Corinna Vinschen Date: Sun, 17 Jan 2016 16:42:38 +0100 Subject: [PATCH] Fix configuration system to support different architectures on Cygwin. This patch allows to recognize the architectures supported by Cygwin and to choose the right configuration from there. Drop -march to use default architecture on 32 bit x86. Drop pre-Cygwin-1.3 recognition since it's long gone and there's no valid configuration for this anymore. Signed-off-by: Corinna Vinschen --- Configurations/10-main.conf | 4 ++-- config | 13 ++----------- 2 files changed, 4 insertions(+), 13 deletions(-) diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf index 4085e10..6315b2c 100644 --- a/Configurations/10-main.conf +++ b/Configurations/10-main.conf @@ -1232,10 +1232,10 @@ }, #### Cygwin - "Cygwin" => { + "Cygwin-i686" => { inherit_from => [ asm("x86_asm") ], cc => "gcc", - cflags => "-DTERMIOS -DL_ENDIAN -march=i486 -Wall", + cflags => "-DTERMIOS -DL_ENDIAN -Wall", debug_cflags => "-g -O0", release_cflags => "-O3 -fomit-frame-pointer", sys_id => "CYGWIN", diff --git a/config b/config index e805a84..a888fd8 100755 --- a/config +++ b/config @@ -324,15 +324,7 @@ case "${SYSTEM}:${RELEASE}:${VERSION}:${MACHINE}" in echo "${MACHINE}-whatever-mingw"; exit 0; ;; CYGWIN*) - case "$RELEASE" in - [bB]*|1.0|1.[12].*) - echo "${MACHINE}-whatever-cygwin_pre1.3" - ;; - *) - echo "${MACHINE}-whatever-cygwin" - ;; - esac - exit 0 + echo "${MACHINE}-pc-cygwin"; exit 0 ;; vxworks*) @@ -815,8 +807,7 @@ case "$GUESSOS" in fi ;; # these are all covered by the catchall below - *-*-cygwin_pre1.3) OUT="Cygwin-pre1.3" ;; - *-*-cygwin) OUT="Cygwin" ;; + *-*-cygwin) OUT="Cygwin-${MACHINE}" ;; x86pc-*-qnx6) OUT="QNX6-i386" ;; *-*-qnx6) OUT="QNX6" ;; x86-*-android|i?86-*-android) OUT="android-x86" ;; -- 2.5.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From levitte at openssl.org Sun Jan 17 16:30:54 2016 From: levitte at openssl.org (Richard Levitte) Date: Sun, 17 Jan 2016 17:30:54 +0100 (CET) Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160117153235.GB9897@calimero.vinschen.de> References: <20160117131603.GA10909@roeckx.be> <20160117.145637.791534577484004451.levitte@openssl.org> <20160117153235.GB9897@calimero.vinschen.de> Message-ID: <20160117.173054.301306272346272263.levitte@openssl.org> In message <20160117153235.GB9897 at calimero.vinschen.de> on Sun, 17 Jan 2016 16:32:35 +0100, Corinna Vinschen said: vinschen> On Jan 17 14:56, Richard Levitte wrote: vinschen> > In message <20160117131603.GA10909 at roeckx.be> on Sun, 17 Jan 2016 14:16:04 +0100, Kurt Roeckx said: vinschen> > vinschen> > kurt> On Sun, Jan 17, 2016 at 01:14:14AM +0100, Richard Levitte wrote: vinschen> > kurt> > OPT_FLAGS would be for optimizing, do I get that right? I suggest you vinschen> > kurt> > have a look at Configurations/10-main.conf, you might notice vinschen> > kurt> > configuration items like debug_cflags, release_cflags, debug_lflags vinschen> > kurt> > and release_lflags. If you have a look at my refactor-build branch, vinschen> > kurt> > you will see a fairly thorough Configurations/README. If you look the vinschen> > kurt> > commit titled "Refactor config - move templates docs asm templates to vinschen> > kurt> > Configurations", you'll find the documentation that's applicable to vinschen> > kurt> > what Configure in the master branch supports... later editions are vinschen> > kurt> > currently only supported in my branch. vinschen> > kurt> vinschen> > kurt> In Debian we have a system that where you can override things like vinschen> > kurt> the CFLAGS, and I wonder how easy it will be to integrate that vinschen> > kurt> with your new system. vinschen> > kurt> [...] vinschen> > kurt> Is there an easy way to I can override the flags with vinschen> > kurt> dpkg-buildflags? vinschen> > vinschen> > I see where you're going with this. vinschen> > vinschen> > As it is right now, there is no way to affect Configure via the vinschen> > environment, except for the names of certain commands. Personally, vinschen> > I'd say that using those should be done carefully. I have no plans to vinschen> > expand on the use of environment variables... vinschen> > vinschen> > However, there is always the possibility to quickly write up a small vinschen> > config target for yourself in Configurations, and have them inherit vinschen> > the items for an already existing target. For example: vinschen> > vinschen> > cflags=` ... dpkg-buildflags --get CFLAGS`; \ vinschen> > cat < Configurations/01-debian-tmp.conf vinschen> > %targets = ( vinschen> > "debian-linux-x86_64" => { vinschen> > inherit_from => [ "linux-x86_64" ], vinschen> > cflags => "$cflags", vinschen> > } vinschen> > ); vinschen> > 1; vinschen> > EOF vinschen> > vinschen> > If you want to just append or prepend your flags, you do this with the vinschen> > cflags item: vinschen> > vinschen> > cflags => sub { join(" ", $@, "$cflags"); }, vinschen> > vinschen> > In my refactor-build branch, I've added some lazy functions to do the vinschen> > same: vinschen> > vinschen> > cflags => add("$cflags"), vinschen> > vinschen> > or vinschen> > vinschen> > cflags => add_before("$cflags"), # to prepend vinschen> > vinschen> > Did that help? vinschen> vinschen> This is pretty non-standard. By not allowing to extend CFLAGS from the vinschen> environment, you require all distros to patch the OpenSSL package to fit vinschen> their needs in terms of the build flags. Actually, I forgot another possibility, to just pass them on the Configure / config command line, like so: ./config -ggdb -O2 -pipe -Wimplicit-function-declaration \ -fdebug-prefix-map=${BUILDDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 \ -fdebug-prefix-map=${SOURCEDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 Basically, anything start with a dash or plus that Configure doesn't recognise as its own, it will pass down: * if it starts with -l. -L or -Wl, into EX_LIBS, which is essentially flags to the linker. * otherwise, into CFLAG / CFLAGS. Can't believe I forgot to mention that, considering I use it all the time... vinschen> Why is that necessary? It's no problem at all with autotool vinschen> or cmake-based configurations, and it's really *needed* by vinschen> distros. Before we all go off on a tangent, I'd like to point out that I'm only stating how it works as it is right now. We're not strangers to making changes, even though carefully most of the times ;-) vinschen> CFLAGS+=$(OPENSSL_CFLAGS) += is a GNU make extension, and therefore a no can do. We need to stay with generic make. vinschen> OPENSSL_CFLAGS= -D_WINDLL -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS[...etc...] vinschen> CFLAGS="${BUILD_CFLAGS) $(OPENSSL_CFLAGS)" vinschen> vinschen> and the package build system has to set $BUILD_CFLAGS. That would vinschen> be sufficient as well. If my info about the Configure command line above wasn't good enough, I do have a fairly simple idea on how to allow for using environment variables to expand the diverse flag items, more or less directly into the target structure. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sun Jan 17 16:50:26 2016 From: levitte at openssl.org (Richard Levitte) Date: Sun, 17 Jan 2016 17:50:26 +0100 (CET) Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160117154353.GC9897@calimero.vinschen.de> References: <20160116164653.GH12431@calimero.vinschen.de> <20160117.010403.1870902035842192354.levitte@openssl.org> <20160117154353.GC9897@calimero.vinschen.de> Message-ID: <20160117.175026.1553736512917308940.levitte@openssl.org> In message <20160117154353.GC9897 at calimero.vinschen.de> on Sun, 17 Jan 2016 16:43:53 +0100, Corinna Vinschen said: vinschen> On Jan 17 01:04, Richard Levitte wrote: vinschen> > If you have a look in "config", it doesn't generate "Cygwin-x86_64" at vinschen> > all. Would you be willing to have a look at that script and modernise vinschen> > it regarding Cygwin? vinschen> vinschen> Like the attached? Thank you, that helped... it was less traumatic than I imagined ;-) I've attached a small fixup, your thoughts? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FIXUP-to-adjust-names-and-include-i-345-86.patch Type: text/x-patch Size: 1184 bytes Desc: not available URL: From vinschen at redhat.com Sun Jan 17 17:13:50 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 17 Jan 2016 18:13:50 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160117.175026.1553736512917308940.levitte@openssl.org> References: <20160116164653.GH12431@calimero.vinschen.de> <20160117.010403.1870902035842192354.levitte@openssl.org> <20160117154353.GC9897@calimero.vinschen.de> <20160117.175026.1553736512917308940.levitte@openssl.org> Message-ID: <20160117171350.GA16440@calimero.vinschen.de> On Jan 17 17:50, Richard Levitte wrote: > In message <20160117154353.GC9897 at calimero.vinschen.de> on Sun, 17 Jan 2016 16:43:53 +0100, Corinna Vinschen said: > > vinschen> On Jan 17 01:04, Richard Levitte wrote: > vinschen> > If you have a look in "config", it doesn't generate "Cygwin-x86_64" at > vinschen> > all. Would you be willing to have a look at that script and modernise > vinschen> > it regarding Cygwin? > vinschen> > vinschen> Like the attached? > > Thank you, that helped... it was less traumatic than I imagined ;-) > I've attached a small fixup, your thoughts? Well, that works, too. But if we ever support another architecture, we'd have to tweak two files, config and 10-main.conf, rather then just one, 10-main.conf. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From vinschen at redhat.com Sun Jan 17 17:17:38 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 17 Jan 2016 18:17:38 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160117.173054.301306272346272263.levitte@openssl.org> References: <20160117131603.GA10909@roeckx.be> <20160117.145637.791534577484004451.levitte@openssl.org> <20160117153235.GB9897@calimero.vinschen.de> <20160117.173054.301306272346272263.levitte@openssl.org> Message-ID: <20160117171738.GB16440@calimero.vinschen.de> On Jan 17 17:30, Richard Levitte wrote: > In message <20160117153235.GB9897 at calimero.vinschen.de> on Sun, 17 Jan 2016 16:32:35 +0100, Corinna Vinschen said: > [...] > vinschen> This is pretty non-standard. By not allowing to extend CFLAGS from the > vinschen> environment, you require all distros to patch the OpenSSL package to fit > vinschen> their needs in terms of the build flags. > > Actually, I forgot another possibility, to just pass them on the > Configure / config command line, like so: > > ./config -ggdb -O2 -pipe -Wimplicit-function-declaration \ > -fdebug-prefix-map=${BUILDDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 \ > -fdebug-prefix-map=${SOURCEDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 > > Basically, anything start with a dash or plus that Configure doesn't > recognise as its own, it will pass down: > > * if it starts with -l. -L or -Wl, into EX_LIBS, which is > essentially flags to the linker. > * otherwise, into CFLAG / CFLAGS. > > Can't believe I forgot to mention that, considering I use it all the > time... This works. I can't believe this worked so simple all the time. Is that documented somewhere? If not, it certainly should. > vinschen> CFLAGS+=$(OPENSSL_CFLAGS) > > += is a GNU make extension, and therefore a no can do. We need to > stay with generic make. I expected that but had to point it out ;) > vinschen> OPENSSL_CFLAGS= -D_WINDLL -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS[...etc...] > vinschen> CFLAGS="${BUILD_CFLAGS) $(OPENSSL_CFLAGS)" > vinschen> > vinschen> and the package build system has to set $BUILD_CFLAGS. That would > vinschen> be sufficient as well. > > If my info about the Configure command line above wasn't good enough, > I do have a fairly simple idea on how to allow for using environment > variables to expand the diverse flag items, more or less directly into > the target structure. I guess it's your choice then. The above seems to work nicely for us, so there's no pressure. It would be good to know if that helps for Debian as well, of course. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From vinschen at redhat.com Sun Jan 17 17:20:14 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 17 Jan 2016 18:20:14 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160117171350.GA16440@calimero.vinschen.de> References: <20160116164653.GH12431@calimero.vinschen.de> <20160117.010403.1870902035842192354.levitte@openssl.org> <20160117154353.GC9897@calimero.vinschen.de> <20160117.175026.1553736512917308940.levitte@openssl.org> <20160117171350.GA16440@calimero.vinschen.de> Message-ID: <20160117172014.GC16440@calimero.vinschen.de> On Jan 17 18:13, Corinna Vinschen wrote: > On Jan 17 17:50, Richard Levitte wrote: > > In message <20160117154353.GC9897 at calimero.vinschen.de> on Sun, 17 Jan 2016 16:43:53 +0100, Corinna Vinschen said: > > > > vinschen> On Jan 17 01:04, Richard Levitte wrote: > > vinschen> > If you have a look in "config", it doesn't generate "Cygwin-x86_64" at > > vinschen> > all. Would you be willing to have a look at that script and modernise > > vinschen> > it regarding Cygwin? > > vinschen> > > vinschen> Like the attached? > > > > Thank you, that helped... it was less traumatic than I imagined ;-) > > I've attached a small fixup, your thoughts? > > Well, that works, too. But if we ever support another architecture, > we'd have to tweak two files, config and 10-main.conf, rather then just > one, 10-main.conf. Btw., when calling Configure rather than config, i686 would be simpler for the package builder since it could just use the build variable ${ARCH}, rather than having to check and explicitely turn this to "x86". Just saying... Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From vinschen at redhat.com Sun Jan 17 17:23:21 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 17 Jan 2016 18:23:21 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160117171738.GB16440@calimero.vinschen.de> References: <20160117131603.GA10909@roeckx.be> <20160117.145637.791534577484004451.levitte@openssl.org> <20160117153235.GB9897@calimero.vinschen.de> <20160117.173054.301306272346272263.levitte@openssl.org> <20160117171738.GB16440@calimero.vinschen.de> Message-ID: <20160117172321.GD16440@calimero.vinschen.de> On Jan 17 18:17, Corinna Vinschen wrote: > On Jan 17 17:30, Richard Levitte wrote: > > In message <20160117153235.GB9897 at calimero.vinschen.de> on Sun, 17 Jan 2016 16:32:35 +0100, Corinna Vinschen said: > > [...] > > vinschen> This is pretty non-standard. By not allowing to extend CFLAGS from the > > vinschen> environment, you require all distros to patch the OpenSSL package to fit > > vinschen> their needs in terms of the build flags. > > > > Actually, I forgot another possibility, to just pass them on the > > Configure / config command line, like so: > > > > ./config -ggdb -O2 -pipe -Wimplicit-function-declaration \ > > -fdebug-prefix-map=${BUILDDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 \ > > -fdebug-prefix-map=${SOURCEDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 > > > > Basically, anything start with a dash or plus that Configure doesn't > > recognise as its own, it will pass down: > > > > * if it starts with -l. -L or -Wl, into EX_LIBS, which is > > essentially flags to the linker. > > * otherwise, into CFLAG / CFLAGS. > > > > Can't believe I forgot to mention that, considering I use it all the > > time... > > This works. I can't believe this worked so simple all the time. > [...] Just to be clear, this does not help unless the -s option is dropped from the linker command line. This part of my patch (or something along the lines) is still necessary, otherwise building the debuginfo files fails. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From levitte at openssl.org Sun Jan 17 17:27:13 2016 From: levitte at openssl.org (Richard Levitte) Date: Sun, 17 Jan 2016 18:27:13 +0100 (CET) Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160117171350.GA16440@calimero.vinschen.de> References: <20160117154353.GC9897@calimero.vinschen.de> <20160117.175026.1553736512917308940.levitte@openssl.org> <20160117171350.GA16440@calimero.vinschen.de> Message-ID: <20160117.182713.528425249515294593.levitte@openssl.org> In message <20160117171350.GA16440 at calimero.vinschen.de> on Sun, 17 Jan 2016 18:13:50 +0100, Corinna Vinschen said: vinschen> On Jan 17 17:50, Richard Levitte wrote: vinschen> > In message <20160117154353.GC9897 at calimero.vinschen.de> on Sun, 17 Jan 2016 16:43:53 +0100, Corinna Vinschen said: vinschen> > vinschen> > vinschen> On Jan 17 01:04, Richard Levitte wrote: vinschen> > vinschen> > If you have a look in "config", it doesn't generate "Cygwin-x86_64" at vinschen> > vinschen> > all. Would you be willing to have a look at that script and modernise vinschen> > vinschen> > it regarding Cygwin? vinschen> > vinschen> vinschen> > vinschen> Like the attached? vinschen> > vinschen> > Thank you, that helped... it was less traumatic than I imagined ;-) vinschen> > I've attached a small fixup, your thoughts? vinschen> vinschen> Well, that works, too. But if we ever support another architecture, vinschen> we'd have to tweak two files, config and 10-main.conf, rather then just vinschen> one, 10-main.conf. I can live with that. Or, well, that's actually just a slightly different fixup away. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FIXUP-to-adjust-names-and-include-i-345-86.patch Type: text/x-patch Size: 1140 bytes Desc: not available URL: From levitte at openssl.org Sun Jan 17 17:33:58 2016 From: levitte at openssl.org (Richard Levitte) Date: Sun, 17 Jan 2016 18:33:58 +0100 (CET) Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160117172014.GC16440@calimero.vinschen.de> References: <20160117.175026.1553736512917308940.levitte@openssl.org> <20160117171350.GA16440@calimero.vinschen.de> <20160117172014.GC16440@calimero.vinschen.de> Message-ID: <20160117.183358.1156122332350585290.levitte@openssl.org> In message <20160117172014.GC16440 at calimero.vinschen.de> on Sun, 17 Jan 2016 18:20:14 +0100, Corinna Vinschen said: vinschen> On Jan 17 18:13, Corinna Vinschen wrote: vinschen> > On Jan 17 17:50, Richard Levitte wrote: vinschen> > > In message <20160117154353.GC9897 at calimero.vinschen.de> on Sun, 17 Jan 2016 16:43:53 +0100, Corinna Vinschen said: vinschen> > > vinschen> > > vinschen> On Jan 17 01:04, Richard Levitte wrote: vinschen> > > vinschen> > If you have a look in "config", it doesn't generate "Cygwin-x86_64" at vinschen> > > vinschen> > all. Would you be willing to have a look at that script and modernise vinschen> > > vinschen> > it regarding Cygwin? vinschen> > > vinschen> vinschen> > > vinschen> Like the attached? vinschen> > > vinschen> > > Thank you, that helped... it was less traumatic than I imagined ;-) vinschen> > > I've attached a small fixup, your thoughts? vinschen> > vinschen> > Well, that works, too. But if we ever support another architecture, vinschen> > we'd have to tweak two files, config and 10-main.conf, rather then just vinschen> > one, 10-main.conf. vinschen> vinschen> Btw., when calling Configure rather than config, i686 would be simpler vinschen> for the package builder since it could just use the build variable vinschen> ${ARCH}, rather than having to check and explicitely turn this to "x86". vinschen> vinschen> vinschen> Just saying... I was just thinking of that, as well as a backward compatibility name Cygwin. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-some-extra-Cygwin-targets-as-aliases-for-Cygwin-.patch Type: text/x-patch Size: 1426 bytes Desc: not available URL: From levitte at openssl.org Sun Jan 17 17:38:46 2016 From: levitte at openssl.org (Richard Levitte) Date: Sun, 17 Jan 2016 18:38:46 +0100 (CET) Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160117171738.GB16440@calimero.vinschen.de> References: <20160117153235.GB9897@calimero.vinschen.de> <20160117.173054.301306272346272263.levitte@openssl.org> <20160117171738.GB16440@calimero.vinschen.de> Message-ID: <20160117.183846.1442194888012860123.levitte@openssl.org> In message <20160117171738.GB16440 at calimero.vinschen.de> on Sun, 17 Jan 2016 18:17:38 +0100, Corinna Vinschen said: vinschen> On Jan 17 17:30, Richard Levitte wrote: vinschen> > In message <20160117153235.GB9897 at calimero.vinschen.de> on Sun, 17 Jan 2016 16:32:35 +0100, Corinna Vinschen said: vinschen> > [...] vinschen> > vinschen> This is pretty non-standard. By not allowing to extend CFLAGS from the vinschen> > vinschen> environment, you require all distros to patch the OpenSSL package to fit vinschen> > vinschen> their needs in terms of the build flags. vinschen> > vinschen> > Actually, I forgot another possibility, to just pass them on the vinschen> > Configure / config command line, like so: vinschen> > vinschen> > ./config -ggdb -O2 -pipe -Wimplicit-function-declaration \ vinschen> > -fdebug-prefix-map=${BUILDDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 \ vinschen> > -fdebug-prefix-map=${SOURCEDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 vinschen> > vinschen> > Basically, anything start with a dash or plus that Configure doesn't vinschen> > recognise as its own, it will pass down: vinschen> > vinschen> > * if it starts with -l. -L or -Wl, into EX_LIBS, which is vinschen> > essentially flags to the linker. vinschen> > * otherwise, into CFLAG / CFLAGS. vinschen> > vinschen> > Can't believe I forgot to mention that, considering I use it all the vinschen> > time... vinschen> vinschen> This works. I can't believe this worked so simple all the time. Is vinschen> that documented somewhere? If not, it certainly should. Badly, I have to admit. Looks like this in the big wall of commenting at the beginning of Configure: # - + compiler options are passed through vinschen> > If my info about the Configure command line above wasn't good enough, vinschen> > I do have a fairly simple idea on how to allow for using environment vinschen> > variables to expand the diverse flag items, more or less directly into vinschen> > the target structure. vinschen> vinschen> I guess it's your choice then. The above seems to work vinschen> nicely for us, so there's no pressure. Well, the path of least resistance and all that ;-) Seriously, it'll stay on my mind, but unless someone screams bloody murder, it's not gonna be on my top ten priority list. I'm sure you understand. Of course, if someone else in the team feels compelled, by all means! vinschen> It would be good to know if that helps for Debian as well, vinschen> of course. Yup, agreed. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sun Jan 17 17:44:54 2016 From: levitte at openssl.org (Richard Levitte) Date: Sun, 17 Jan 2016 18:44:54 +0100 (CET) Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published In-Reply-To: <20160117172321.GD16440@calimero.vinschen.de> References: <20160117.173054.301306272346272263.levitte@openssl.org> <20160117171738.GB16440@calimero.vinschen.de> <20160117172321.GD16440@calimero.vinschen.de> Message-ID: <20160117.184454.1930098959177898564.levitte@openssl.org> In message <20160117172321.GD16440 at calimero.vinschen.de> on Sun, 17 Jan 2016 18:23:21 +0100, Corinna Vinschen said: vinschen> Just to be clear, this does not help unless the -s option is dropped vinschen> from the linker command line. This part of my patch (or something along vinschen> the lines) is still necessary, otherwise building the debuginfo files vinschen> fails. No worries, those previous patches are on my todo list Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From erik at efca.com Sun Jan 17 18:39:31 2016 From: erik at efca.com (Erik Forsberg) Date: Sun, 17 Jan 2016 10:39:31 -0800 Subject: [openssl-dev] Personal configuration in 1.1.0 In-Reply-To: <20160117.114303.1596959756799309923.levitte@openssl.org> References: <20160117.114303.1596959756799309923.levitte@openssl.org> Message-ID: Just wanted to mention that I like the new configuration style a lot better than the old, much easier to automate a custom build now. Thanks. >-- Original Message -- > >Hi, > >I think I've seen this question asked a few times, an it's time for an >explanation. > >In upcoming OpenSSL 1.1.0, the old configuration strings supposed to >be gone, completely and entirely. There are some traces left from the >time when we still had some of them and were converting them to the >new style configurations found in Configurations/, but those bits >haven't been tried for some time. As a matter of fact, those last >traces are completely removed in my my refactor-build branch. > >If you want to keep some personal configurations around, I'd suggest >having a look at the personal ones some of us in the team are keeping >around in Configurations/, and build your own using them as a model on >how to do so. > >Unfortunately, the documentation isn't there yet, at least in master. >(have a look at my refactor-build branch, it has a Configurations/README >which I hope does a fair enough job... if there are enhancements >needed, feedback is welcome!) > >The older configuration strings still work as usual in the 1.0.x >releases. That won't change, of course. > >Cheers, >Richard > >-- >Richard Levitte levitte at openssl.org >OpenSSL Project http://www.openssl.org/~levitte/ >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From levitte at openssl.org Sun Jan 17 19:12:46 2016 From: levitte at openssl.org (Richard Levitte) Date: Sun, 17 Jan 2016 20:12:46 +0100 (CET) Subject: [openssl-dev] Personal configuration in 1.1.0 In-Reply-To: References: <20160117.114303.1596959756799309923.levitte@openssl.org> Message-ID: <20160117.201246.2019150544116220694.levitte@openssl.org> In message on Sun, 17 Jan 2016 10:39:31 -0800, "Erik Forsberg" said: erik> Just wanted to mention that I like the new configuration style erik> a lot better than the old, much easier to automate a custom build now. erik> erik> Thanks. Heh, you're welcome. Let me tell you, making that move was quite a self gratifying move, exactly for the reason you state! :-) Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From vinschen at redhat.com Sun Jan 17 19:33:30 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 17 Jan 2016 20:33:30 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160117.183358.1156122332350585290.levitte@openssl.org> References: <20160117.175026.1553736512917308940.levitte@openssl.org> <20160117171350.GA16440@calimero.vinschen.de> <20160117172014.GC16440@calimero.vinschen.de> <20160117.183358.1156122332350585290.levitte@openssl.org> Message-ID: <20160117193330.GE16440@calimero.vinschen.de> On Jan 17 18:33, Richard Levitte wrote: > In message <20160117172014.GC16440 at calimero.vinschen.de> on Sun, 17 Jan 2016 18:20:14 +0100, Corinna Vinschen said: > > vinschen> On Jan 17 18:13, Corinna Vinschen wrote: > vinschen> > On Jan 17 17:50, Richard Levitte wrote: > vinschen> > > In message <20160117154353.GC9897 at calimero.vinschen.de> on Sun, 17 Jan 2016 16:43:53 +0100, Corinna Vinschen said: > vinschen> > > > vinschen> > > vinschen> On Jan 17 01:04, Richard Levitte wrote: > vinschen> > > vinschen> > If you have a look in "config", it doesn't generate "Cygwin-x86_64" at > vinschen> > > vinschen> > all. Would you be willing to have a look at that script and modernise > vinschen> > > vinschen> > it regarding Cygwin? > vinschen> > > vinschen> > vinschen> > > vinschen> Like the attached? > vinschen> > > > vinschen> > > Thank you, that helped... it was less traumatic than I imagined ;-) > vinschen> > > I've attached a small fixup, your thoughts? > vinschen> > > vinschen> > Well, that works, too. But if we ever support another architecture, > vinschen> > we'd have to tweak two files, config and 10-main.conf, rather then just > vinschen> > one, 10-main.conf. > vinschen> > vinschen> Btw., when calling Configure rather than config, i686 would be simpler > vinschen> for the package builder since it could just use the build variable > vinschen> ${ARCH}, rather than having to check and explicitely turn this to "x86". > vinschen> > vinschen> > vinschen> Just saying... > > I was just thinking of that, as well as a backward compatibility name > Cygwin. Looks good to me, as discussed in PM. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Mon Jan 18 00:17:22 2016 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Mon, 18 Jan 2016 00:17:22 +0000 Subject: [openssl-dev] [openssl.org #4253] [PATCH] Build system fixes for GCC In-Reply-To: <20160118001706.GB974@kronk.local> References: <20160118001706.GB974@kronk.local> Message-ID: Hello, I opened two pull request regarding fixes for builds using GCC: * Fix versioned GCC detection https://github.com/openssl/openssl/pull/552 * Support link time optimization with GCC https://github.com/openssl/openssl/pull/553 Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Mon Jan 18 08:51:51 2016 From: rt at openssl.org (marc.stern@approach.be via RT) Date: Mon, 18 Jan 2016 08:51:51 +0000 Subject: [openssl-dev] [openssl.org #4248] Link error under Windows In-Reply-To: <569C9FB5.9060504@approach.be> References: <5698E644.1080209@approach.be> <5699E05E.3060508@dancingdragon.be> <569C9FB5.9060504@approach.be> Message-ID: Indeed, and the same with "no-deprecated". So I asssume it's solved in the trunk. Thanks On 16-01-2016 07:17, Joey Yandle via RT wrote: > This appears to be the same issue as when building with no-engine: > > https://github.com/openssl/openssl/issues/536 > > Hopefully Richard Levitte's new build system will be able to handle > this. Presumably in the old system this would be handled by the last > lines of ms\do_win64a.bat: > > perl util\mkdef.pl 32 libeay > ms\libeay32.def > perl util\mkdef.pl 32 ssleay > ms\ssleay32.def > > > On 1/15/2016 7:14 PM, marc.stern at approach.be via RT wrote: >> On any version of Windows (32 or 64 bits), if using the "no-deprecated" >> configure flag, some functions (see list below) are not compiled but >> they are still referenced in LIBEAY32.DEF. This gives the following >> error: LIBEAY32.def : error LNK2001: unresolved external symbol ... >> >> List of functions: >> - BN_BLINDING_get_thread_id >> - BN_BLINDING_set_thread_id >> - BN_CTX_init >> - BN_generate_prime >> - BN_get_params >> - BN_is_prime >> - BN_is_prime_fasttest >> - BN_set_params >> - CRYPTO_get_id_callback >> - CRYPTO_set_id_callback >> - CRYPTO_thread_id >> - DH_generate_parameters >> - DSA_generate_parameters >> - ERR_remove_state >> - RSA_generate_key >> - bn_dup_expand >> >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> > From hkario at redhat.com Mon Jan 18 11:23:30 2016 From: hkario at redhat.com (Hubert Kario) Date: Mon, 18 Jan 2016 12:23:30 +0100 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: <20160115000243.GB5911@openssl.org> References: <20160114144128.17780804.28529.45238@ll.mit.edu> <20160115000243.GB5911@openssl.org> Message-ID: <5571806.YmRtfAv59r@pintsize.usersys.redhat.com> On Friday 15 January 2016 00:02:43 Dr. Stephen Henson wrote: > On Thu, Jan 14, 2016, Blumenthal, Uri - 0553 - MITLL wrote: > > On 1/14/16, 16:51 , "openssl-dev on behalf of Dr. Stephen Henson" > > > > wrote: > > >On Thu, Jan 14, 2016, Salz, Rich wrote: > > >> Okay, how about this. First, remove the NOTES subhead. Add this > > >> to > > >> > > >>the end of the first paragraph: > > >> This program does not hash the input data and requires the input > > >> data > > >> to be of the proper size, and must not be greater than the size > > >> of > > >> the public key field or modulus. See dgst(1) for a unified > > >> Interace. > > > > > >The comment about the public key field or modulus is only true for > > >some public > > >key algorithms (e.g. RSA). > > > > Public key modulus would be true for RSA and DSA. Field would be > > true for ECDSA (and I daresay EdDSA). What other signatures do we > > have? > For RSA the maximum size depends on the padding mode and is typically > less than the modulus. > > For ECDSA it can be exceed the field size: it is truncated in that > case. True, but what should we put in the man page? Explain the above exactly, or just not mention the limit at all? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From kristian.amlie at cfengine.com Mon Jan 18 14:28:00 2016 From: kristian.amlie at cfengine.com (Kristian Amlie) Date: Mon, 18 Jan 2016 15:28:00 +0100 Subject: [openssl-dev] Patch for grep on Solaris Message-ID: <569CF670.3020309@cfengine.com> Simple build fix for Solaris. See commit message in the patch for details. I hope this can make it into the openssl repository. -- Kristian -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Don-t-use-grep-q-q-is-not-POSIX-and-fails-on-Solaris.patch Type: text/x-patch Size: 839 bytes Desc: not available URL: From levitte at openssl.org Mon Jan 18 14:34:56 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 18 Jan 2016 15:34:56 +0100 (CET) Subject: [openssl-dev] Patch for grep on Solaris In-Reply-To: <569CF670.3020309@cfengine.com> References: <569CF670.3020309@cfengine.com> Message-ID: <20160118.153456.434057517693509069.levitte@openssl.org> In message <569CF670.3020309 at cfengine.com> on Mon, 18 Jan 2016 15:28:00 +0100, Kristian Amlie said: kristian.amlie> Simple build fix for Solaris. See commit message in the patch for details. kristian.amlie> kristian.amlie> I hope this can make it into the openssl repository. On it. It will hopefully appear fairly soon in our repo. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From andrewponomarenko at yandex.ru Mon Jan 18 16:02:12 2016 From: andrewponomarenko at yandex.ru (Ponomarenko Andrey) Date: Mon, 18 Jan 2016 19:02:12 +0300 Subject: [openssl-dev] ABI structure in detail for OpenSSL 1.0.2e Message-ID: <3186311453132932@web20g.yandex.ru> Hello, I'm developing a new tool for visualization of the ABI (App. Binary Interface) structure and high-detailed binary compatibility analysis of C/C++ libraries (in addition to the abi-compliance-checker tool). And I've recently tested it on the latest release of the OpenSSL. I think that the results might be interesting for some of you: libssl.so: http://abi-laboratory.pro/tracker/abi_view/openssl/1.0.2e/a2cf7/symbols.html libcrypto.so: http://abi-laboratory.pro/tracker/abi_view/openssl/1.0.2e/c93f7/symbols.html You can find detailed information on the calling conventions and used registers for each function and memory layout for each data type in the ABI. I can share this report as tarball if you are interested to host it somewhere in the infrastructure of the OpenSSL. Thank you. From rsalz at akamai.com Mon Jan 18 16:55:50 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 18 Jan 2016 16:55:50 +0000 Subject: [openssl-dev] ABI structure in detail for OpenSSL 1.0.2e In-Reply-To: <3186311453132932@web20g.yandex.ru> References: <3186311453132932@web20g.yandex.ru> Message-ID: <85192c83c528447b9f2ff29ab7a2e0bb@usma1ex-dag1mb1.msg.corp.akamai.com> This is interesting, thanks. I am not sure how to read the charts; I'm probably being dumb. I wonder how master compares? -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From uri at ll.mit.edu Mon Jan 18 19:22:19 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 18 Jan 2016 19:22:19 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? Message-ID: <20160118192227.17788998.21663.45907@ll.mit.edu> My preference would be to explain exactly - to avoid confusion and problems arising from possible misunderstanding. As I said, however, I can live with either - as by now *I* at least understand what this code does. ;-) But it doesn't seem fair for those who did not benefit from studying the piles of openssl-users and openssl-dev archives. Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Hubert Kario Sent: Monday, January 18, 2016 06:23 To: openssl-dev at openssl.org Reply To: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? On Friday 15 January 2016 00:02:43 Dr. Stephen Henson wrote: > On Thu, Jan 14, 2016, Blumenthal, Uri - 0553 - MITLL wrote: > > On 1/14/16, 16:51 , "openssl-dev on behalf of Dr. Stephen Henson" > > > > wrote: > > >On Thu, Jan 14, 2016, Salz, Rich wrote: > > >> Okay, how about this. First, remove the NOTES subhead. Add this > > >> to > > >> > > >>the end of the first paragraph: > > >> This program does not hash the input data and requires the input > > >> data > > >> to be of the proper size, and must not be greater than the size > > >> of > > >> the public key field or modulus. See dgst(1) for a unified > > >> Interace. > > > > > >The comment about the public key field or modulus is only true for > > >some public > > >key algorithms (e.g. RSA). > > > > Public key modulus would be true for RSA and DSA. Field would be > > true for ECDSA (and I daresay EdDSA). What other signatures do we > > have? > For RSA the maximum size depends on the padding mode and is typically > less than the modulus. > > For ECDSA it can be exceed the field size: it is truncated in that > case. True, but what should we put in the man page? Explain the above exactly, or just not mention the limit at all? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From uri at ll.mit.edu Mon Jan 18 21:45:39 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 18 Jan 2016 21:45:39 +0000 Subject: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl req fails to use engine In-Reply-To: <569A5933.3020800@gmail.com> References: <20160115230320.17788998.66913.45627@ll.mit.edu> <569A5933.3020800@gmail.com> Message-ID: On 1/16/16, 09:52, "openssl-dev on behalf of Douglas E Engert" wrote: >Yes, #548 is similar but for the pkeyutl.c > >I would have changed: > >{"keyform", OPT_KEYFORM, 'F', "Private key format - default PEM"}, >to >{"keyform", OPT_KEYFORM, 'f', "Private key format - default PEM"}, Will do, thanks. >The patch also adds an additional parameter, >{"engine_impl", OPT_ENGINE_IMPL, '-', "Also use engine given by -engine >for crypto operations"}, > >I would ask the author about the engine_impl . I?m not sure I understand. I?m the author of this addition (including addition of ?-engine_impl? option, which was added exclusively to make sure the previous/original behavior is available if somebody would want it), and it?s made upon suggestion by Steve Henson. Or do you mean the author of the original pkeyutl.c? He can?t know anything about the flag I?m adding. Also note that this patch is a copy (as close as the difference in the source base allowed) of the one accepted for OpenSSL_1_0_2-stable. >It looks to me that to keep the previous behavior of the command >one would need to add this option if an engine is used. IMHO it (the previous behavior) could never work with real keys on a real hardware token the way it was written (perhaps it could work with other kinds of engines). As always, I?d be happy to learn any evidence to the contrary. :-) And I?ve accumulated plenty of experience using OpenSSL with a few different PIV tokens (PKCS11-accessible via OpenSC). So far I?ve done plenty of RSA signing/verifying and encrypting/decrypting, and ECDSA signing. ECDH derivation works only when the public key is on the token - because engine_pkcs11 doesn?t support ec_derive yet. >IIt could also be an issue with the ordering >of the parameters, or to try and not use the engine when the public key >is used. >(I could be wrong on this.) Yes, parameter ordering is strict at the moment. I don?t want to mess with the code too much to make the it work regardless of the parameter order. For right now I?d be happy if the mainstream code would just work - and this patch accomplishes exactly that. >The author is also active on the OpenSC list trying to use EC with the >OpenSC engine. Are we talking about Michael? BTW, on a separate issue - I?m rather concerned about the apparent circular dependency between OpenSSL and OpenSC. This makes it problematic to use OpenSC with another software library like Botan or Crypto++. But that?s for a different message thread. >On 1/15/2016 5:24 PM, Blumenthal, Uri - 0553 - MITLL via RT wrote: >> Doug, could you please take a look at PR #548 (or is it #549)? It also >>addresses this KEY_FORM issue. >> >> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE >>network. >> Original Message >> From:deengert at gmail.com via RT >> Sent: Friday, January 15, 2016 17:10 >> Reply To:rt at openssl.org >> Cc:openssl-dev at openssl.org >> Subject: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl >>req fails to use engine >> >> req.c (and many of the other apps) appear to have lost the ability to >>use an engine. >> The attached diff is against the github.com verison using Tag >>OpenSSL_1_1-pre2 >> In the req_options[] table: >> OPT_KEY is set to "S" so pre- checking of the parameters does not drop >>the string passed to the engine. >> OPT_KEY_FORM is set to "f" so pre-checking will allow engine >> >> The engine is saved: >> e = setup_engine(opt_arg(), 1); >> >> (I turned on debug, may want that off. ) >> >> to allow the theOPT_KEY_FORM to be an engine: >> if (!opt_format(opt_arg(), OPT_FMT_PEMDER|OPT_FMT_ENGINE, &keyform)) >> >> This was tested with a modified version of OpenSC using ECDSA key on >>card to generate a self signed certificate. >> >> openssl req -config /tmp/genreq.6156.openssl.conf -engine pkcs11 >>-keyform e -sha256 -new -key slot_1-id_2 -out /tmp/selfsigned.pem -x509 >>-text >> >> >> P.S. The EC_KEY_* functions appear to be working too (#4225) Have not >>tried the ECDH yet. >> >> -- Douglas E. Engert >> >> >> >> > >-- > > Douglas E. Engert > > >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Mon Jan 18 21:45:48 2016 From: rt at openssl.org (Blumenthal, Uri - 0553 - MITLL via RT) Date: Mon, 18 Jan 2016 21:45:48 +0000 Subject: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl req fails to use engine In-Reply-To: References: <20160115230320.17788998.66913.45627@ll.mit.edu> <569A5933.3020800@gmail.com> Message-ID: On 1/16/16, 09:52, "openssl-dev on behalf of Douglas E Engert" wrote: >Yes, #548 is similar but for the pkeyutl.c > >I would have changed: > >{"keyform", OPT_KEYFORM, 'F', "Private key format - default PEM"}, >to >{"keyform", OPT_KEYFORM, 'f', "Private key format - default PEM"}, Will do, thanks. >The patch also adds an additional parameter, >{"engine_impl", OPT_ENGINE_IMPL, '-', "Also use engine given by -engine >for crypto operations"}, > >I would ask the author about the engine_impl . I?m not sure I understand. I?m the author of this addition (including addition of ?-engine_impl? option, which was added exclusively to make sure the previous/original behavior is available if somebody would want it), and it?s made upon suggestion by Steve Henson. Or do you mean the author of the original pkeyutl.c? He can?t know anything about the flag I?m adding. Also note that this patch is a copy (as close as the difference in the source base allowed) of the one accepted for OpenSSL_1_0_2-stable. >It looks to me that to keep the previous behavior of the command >one would need to add this option if an engine is used. IMHO it (the previous behavior) could never work with real keys on a real hardware token the way it was written (perhaps it could work with other kinds of engines). As always, I?d be happy to learn any evidence to the contrary. :-) And I?ve accumulated plenty of experience using OpenSSL with a few different PIV tokens (PKCS11-accessible via OpenSC). So far I?ve done plenty of RSA signing/verifying and encrypting/decrypting, and ECDSA signing. ECDH derivation works only when the public key is on the token - because engine_pkcs11 doesn?t support ec_derive yet. >IIt could also be an issue with the ordering >of the parameters, or to try and not use the engine when the public key >is used. >(I could be wrong on this.) Yes, parameter ordering is strict at the moment. I don?t want to mess with the code too much to make the it work regardless of the parameter order. For right now I?d be happy if the mainstream code would just work - and this patch accomplishes exactly that. >The author is also active on the OpenSC list trying to use EC with the >OpenSC engine. Are we talking about Michael? BTW, on a separate issue - I?m rather concerned about the apparent circular dependency between OpenSSL and OpenSC. This makes it problematic to use OpenSC with another software library like Botan or Crypto++. But that?s for a different message thread. >On 1/15/2016 5:24 PM, Blumenthal, Uri - 0553 - MITLL via RT wrote: >> Doug, could you please take a look at PR #548 (or is it #549)? It also >>addresses this KEY_FORM issue. >> >> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE >>network. >> Original Message >> From:deengert at gmail.com via RT >> Sent: Friday, January 15, 2016 17:10 >> Reply To:rt at openssl.org >> Cc:openssl-dev at openssl.org >> Subject: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl >>req fails to use engine >> >> req.c (and many of the other apps) appear to have lost the ability to >>use an engine. >> The attached diff is against the github.com verison using Tag >>OpenSSL_1_1-pre2 >> In the req_options[] table: >> OPT_KEY is set to "S" so pre- checking of the parameters does not drop >>the string passed to the engine. >> OPT_KEY_FORM is set to "f" so pre-checking will allow engine >> >> The engine is saved: >> e = setup_engine(opt_arg(), 1); >> >> (I turned on debug, may want that off. ) >> >> to allow the theOPT_KEY_FORM to be an engine: >> if (!opt_format(opt_arg(), OPT_FMT_PEMDER|OPT_FMT_ENGINE, &keyform)) >> >> This was tested with a modified version of OpenSC using ECDSA key on >>card to generate a self signed certificate. >> >> openssl req -config /tmp/genreq.6156.openssl.conf -engine pkcs11 >>-keyform e -sha256 -new -key slot_1-id_2 -out /tmp/selfsigned.pem -x509 >>-text >> >> >> P.S. The EC_KEY_* functions appear to be working too (#4225) Have not >>tried the ECDH yet. >> >> -- Douglas E. Engert >> >> >> >> > >-- > > Douglas E. Engert > > >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From phpdev at ehrhardt.nl Mon Jan 18 22:22:13 2016 From: phpdev at ehrhardt.nl (Jan Ehrhardt) Date: Mon, 18 Jan 2016 23:22:13 +0100 Subject: [openssl-dev] MSVC 2015 internal compiler error References: <569A1EAC.1000607@yahoo.no> <005401d1509b$17dbaa80$4792ff80$@sales@free.fr> <569B55EF.5050205@yahoo.no> Message-ID: Gisle Vanem in gmane.comp.encryption.openssl.devel (Sun, 17 Jan 2016 09:50:55 +0100): >I think I have this "update 1" from the cl version: > Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23026 for x86 There is a newer one: Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506 for x86 Did you install SP1 manually? It was not included in the normal Windows Update. https://www.visualstudio.com/en-us/news/vs2015-update1-vs.aspx Jan From anthony.chow at al-enterprise.com Mon Jan 18 21:50:44 2016 From: anthony.chow at al-enterprise.com (Anthony T CHOW) Date: Mon, 18 Jan 2016 21:50:44 +0000 Subject: [openssl-dev] Manually created CRL for OpenSSL In-Reply-To: References: <20160115230320.17788998.66913.45627@ll.mit.edu> <569A5933.3020800@gmail.com> Message-ID: I am looking around the OpenSSL code and is trying to figure out where I can specify the location of a manually created CRL. My device at this time does not support OCSP. I am looking at the .../crypto/X509 directory. Any suggestion that can help me look into this faster? Another question: Is OCSP support built-in for OpenSSL? Thanks for the help, Anthony. From levitte at openssl.org Mon Jan 18 22:50:12 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 18 Jan 2016 23:50:12 +0100 (CET) Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160114.215903.813205413779228431.levitte@openssl.org> References: <20160114.215903.813205413779228431.levitte@openssl.org> Message-ID: <20160118.235012.1388704382358841060.levitte@openssl.org> FYI, The branch has been updated, the Makfile template now has install targets as well, and I did the mods I could see would be necessary for Cygwin and Mingw. I would appreciate it if someone could help me try those out. Remember to configure with --unified. Next thing coming up is install targets on VMS. And with that, I have to rethink the defaults for the installation directories. Cheers, Richard In message <20160114.215903.813205413779228431.levitte at openssl.org> on Thu, 14 Jan 2016 21:59:03 +0100 (CET), Richard Levitte said: levitte> Hi, levitte> levitte> there's an effort going on to revamp the build system for future levitte> OpenSSL, coining it as "unified". The intention is to have one and levitte> the same base of information for all platforms, instead of having to levitte> maintain one set of files for Unixly platforms, one makefile generator levitte> for Windowsy platforms, and one pile of scripts with a serious case of levitte> bit rot for VMS. levitte> levitte> In particular, this is of interest for the VMS folks, as it's the only levitte> currently workable build system for upcoming version 1.1. levitte> levitte> levitte> Finding it levitte> ========== levitte> levitte> For now, this change is available on here: levitte> levitte> https://github.com/levitte/openssl/tree/refactor-build levitte> levitte> which is git repo https://github.com/levitte/openssl.git, branch levitte> refactor-build. levitte> levitte> levitte> Using it levitte> ======== levitte> levitte> Requirements levitte> ------------ levitte> levitte> On all platforms, it requires levitte> levitte> - Perl! Reports tell me that version 5.10.1 works fine but might need levitte> some extra perl modules (Test::More and possibly others. Feedback levitte> welcome!). Unix usually has it installed or easy to find. For VMS, levitte> there's an install kit on sourceforge levitte> (https://sourceforge.net/projects/vmsperlkit/files/Archive/), and levitte> Windows, we've always recommended ActiveState Perl levitte> (http://www.activestate.com/ActivePerl). levitte> - The Perl module Text::Template, which is the driver behind the levitte> generation Makefile and other files. This branch relies quite levitte> heavily on templates. levitte> levitte> On Unix, it requires levitte> levitte> - the usual developmemt stuff. cc, as and make would be the really levitte> bare minimum, and maybe I'm forgetting something, but what is levitte> usually considered the normal tool chain should work out. levitte> levitte> On VMS, it requires levitte> levitte> - DEC C... It's called HP C these days and might be called something levitte> else again when VSI starts shipping. It needs to be recent enough levitte> to support the qualifiers /NAMES=(AS_IS,SHORTENED) and /REPOSITORY levitte> (I welcome feedback on which the minimum version for this is!) levitte> - DECset, at the very least MMS. Alternatively, MMK can be used if levitte> you can find it (if anyone knows of a place that has it for sure, levitte> feedback is welcome!) levitte> - Of course, the rest of the tool chain, but that comes with the levitte> operating system, no worries there. levitte> levitte> [I certainly hope I didn't forget anything, but if I did, feedback is levitte> welcome!] levitte> levitte> Config and build levitte> ---------------- levitte> levitte> For Unix users, who are used to the usual generation of a top Makefile levitte> from Makefile.org... that is, Makefile.in since recently, this it levitte> still the default, but you can always use the unified build as an levitte> alternative by adding the flag --unified, like so: levitte> levitte> ./config --unified levitte> make levitte> make test levitte> # There is no install target yet, it's coming up! levitte> levitte> You will get One Top Makefile that does everything. It will not touch levitte> any other Makefile. levitte> levitte> levitte> For VMS users, the unified build is the only one available in this levitte> branch, the old scripts are simply gone. Instead, you configure just levitte> like you would on any other platform (well, almost, there isn't any levitte> config.com yet, so you'll have to jump directly to the Configure levitte> script), and that will generate a descrip.mms: levitte> levitte> perl Configure vms-alpha ! or vms-ia64 levitte> mms levitte> mms test levitte> ! There is no install target yet. levitte> ! As a matter of fact, I'd like to talk about exactly where it levitte> ! should install. Let's talk! levitte> levitte> levitte> Features levitte> ======== levitte> levitte> There are a few features in the unified build that are worth testing: levitte> levitte> 1. Out of source tree builds! It's perfectly possible to do this: levitte> levitte> mkdir ../build levitte> cd ../build levitte> perl ../openssl-src/config levitte> make levitte> make test levitte> levitte> (and yes, on VMS as well) levitte> levitte> 2. The generated Makefile supports parallell make: levitte> levitte> make -j9 levitte> levitte> (carefull, though, don't try the silliness I tried: make -j9 clean all) levitte> levitte> levitte> Future levitte> ====== levitte> levitte> I plan on making the generated Makefile / descrip.mms full featured, levitte> which means at least adding install targets. Then, on to a template levitte> for a Windows makefile. levitte> levitte> levitte> ================= levitte> Feedback welcome! levitte> ================= levitte> levitte> levitte> Cheers, levitte> Richard levitte> levitte> -- levitte> Richard Levitte levitte at openssl.org levitte> OpenSSL Project http://www.openssl.org/~levitte/ From gvanem at yahoo.no Tue Jan 19 02:25:52 2016 From: gvanem at yahoo.no (Gisle Vanem) Date: Tue, 19 Jan 2016 03:25:52 +0100 Subject: [openssl-dev] "openssl s_client" memory leak Message-ID: <569D9EB0.7030400@yahoo.no> There seems to be some memory leak(s) somewhere during the life of 's_client_main()'. Example from a client.bat here: set OPENSSL_DEBUG_MEMORY=on echo -e GET /ssltest/viewMyClient.html\r\n | openssl.exe s_client ^ -connect www.ssllabs.com:443 ('echo -e' is from Cygwin32). All .html output gets produced correctly; ends with: read:errno=0 and dumped okay in Lynx. But the mem-tracker reports: [12:06:07] 6930 file=crypto/bio/bio_lib.c, line=68, thread=1092, number=72, address=0x284ef78 72 bytes leaked in 1 chunks And adding other options show additional leaks. E.g. '-nbio_test -reconnect' results in 12 leaks: [12:15:17] 13704 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, address=0x2ccf468 [12:15:15] 13016 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, address=0x2ccedb0 [12:15:18] 14345 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, address=0x2ccf238 [12:15:14] 6906 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, address=0x2c7e618 [12:15:17] 13705 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, address=0x2ccf2a8 [12:15:15] 13017 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, address=0x2ccee20 [12:15:16] 13363 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, address=0x2ccf078 [12:15:14] 6907 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, address=0x2c7e688 [12:15:18] 14344 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, address=0x2ccf0e8 [12:15:17] 14022 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, address=0x2cceeb8 [12:15:16] 13364 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, address=0x2ccef28 [12:15:17] 14021 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, address=0x2ccf628 864 bytes leaked in 12 chunks line 68 in bio_lib.c is inside BIO_new() which gives me no clue as to the caller(s). And these order-values in column 2, what exactly are they? All this is with a ver 0x10100003L, MingW + gcc 5.1 build on Win-10. Maybe someone can verify this happening on other OSes too? BTW. 'memleaktest.exe freeit' reports nothing. So the mem-dbg seems okay in this memtleaktest program. But maybe not in the 'big-picture'? -- --gv From gmadkat1 at gmail.com Tue Jan 19 04:18:30 2016 From: gmadkat1 at gmail.com (Gowri V) Date: Mon, 18 Jan 2016 23:18:30 -0500 Subject: [openssl-dev] Usage of the enable-capieng Message-ID: Hello, I am attempting to use the Microsoft Windows CA trust store for openssl using Mingw32, Do you have any samples/tests for the new interfaces in engines/e_capi.c that I can refer to? I also found one minor issue below in the openssl s_client implementation: The openssl s_client for TLS hostname validation parameter is -verify_host in the help usage, but it should be -verify_hostname. Thanks! Gowri -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.amlie at cfengine.com Tue Jan 19 07:04:57 2016 From: kristian.amlie at cfengine.com (Kristian Amlie) Date: Tue, 19 Jan 2016 08:04:57 +0100 Subject: [openssl-dev] Patch for grep on Solaris In-Reply-To: <20160118.153456.434057517693509069.levitte@openssl.org> References: <569CF670.3020309@cfengine.com> <20160118.153456.434057517693509069.levitte@openssl.org> Message-ID: <569DE019.1060403@cfengine.com> On 18/01/16 15:34, Richard Levitte wrote: > In message <569CF670.3020309 at cfengine.com> on Mon, 18 Jan 2016 15:28:00 +0100, Kristian Amlie said: > > kristian.amlie> Simple build fix for Solaris. See commit message in the patch for details. > kristian.amlie> > kristian.amlie> I hope this can make it into the openssl repository. > > On it. It will hopefully appear fairly soon in our repo. I see it's in now. Thanks! -- Kristian From doctor at doctor.nl2k.ab.ca Tue Jan 19 09:33:27 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 19 Jan 2016 02:33:27 -0700 Subject: [openssl-dev] Couple of pointers Message-ID: <20160119093327.GA7568@doctor.nl2k.ab.ca> 1) For backwards compability do we have in I think openssl/rsa.h #define SSLeay_add_ssl_algorithms OpenSSL_add_ssl_algorithms #define SSLv23_server_method TLS_server_method ?? 2) Running the old BSD/OS I get rm -f openssl shlib_target=; if [ -n "libcrypto.so.1.1 libssl.so.1.1" ]; then shlib_target="bsd-gcc-shared"; fi; LIBRARIES="-L.. -lssl -L.. -lcrypto" ; make -f ../Makefile.shared -e APPNAME=openssl OBJECTS="openssl.o asn1pars.o ca.o ciphers.o cms.o crl.o crl2p7.o dgst.o dhparam.o dsa.o dsaparam.o ec.o ecparam.o enc.o engine.o errstr.o gendsa.o genpkey.o genrsa.o nseq.o ocsp.o passwd.o pkcs12.o pkcs7.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o prime.o rand.o req.o rsa.o rsautl.o s_client.o s_server.o s_time.o sess_id.o smime.o speed.o spkac.o srp.o ts.o verify.o version.o x509.o rehash.o apps.o opt.o s_cb.o s_socket.o app_rand.o" LIBDEPS=" $LIBRARIES -ldl -lgmp -lm -lc -lz" link_app.${shlib_target} TOP=.. PERL=/usr/bin/perl5 /usr/bin/perl5 run_tests.pl alltests ../test/recipes/00-check_testexes.t ....... ok ../test/recipes/01-test_ordinals.t ........ ok ../test/recipes/05-test_bf.t .............. ok ../test/recipes/05-test_cast.t ............ ok ../test/recipes/05-test_des.t ............. ok ../test/recipes/05-test_hmac.t ............ ok ../test/recipes/05-test_idea.t ............ ok ../test/recipes/05-test_md2.t ............. skipped: md2 is not supported by this OpenSSL build ../test/recipes/05-test_md4.t ............. ok ../test/recipes/05-test_md5.t ............. ok ../test/recipes/05-test_mdc2.t ............ ok ../test/recipes/05-test_rand.t ............ 1/1 # Failed test 'running randtest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 64. # Looks like you failed 1 test of 1. ../test/recipes/05-test_rand.t ............ Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_rc2.t ............. ok ../test/recipes/05-test_rc4.t ............. ok ../test/recipes/05-test_rc5.t ............. ok ../test/recipes/05-test_rmd.t ............. ok ../test/recipes/05-test_sha1.t ............ ok ../test/recipes/05-test_sha256.t .......... ok ../test/recipes/05-test_sha512.t .......... ok ../test/recipes/05-test_wp.t .............. ok ../test/recipes/10-test_bn.t .............. ok ../test/recipes/10-test_exp.t ............. ok ../test/recipes/15-test_dh.t .............. ok ../test/recipes/15-test_dsa.t ............. ok ../test/recipes/15-test_ec.t .............. ok ../test/recipes/15-test_ecdh.t ............ ok ../test/recipes/15-test_ecdsa.t ........... ok ../test/recipes/15-test_rsa.t ............. ok ../test/recipes/20-test_enc.t ............. 2/129 # Failed test 'aes-128-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'aes-128-cbc base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 4/129 # Failed test 'aes-128-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'aes-128-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'aes-192-cbc' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 7/129 # Failed test 'aes-192-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'aes-192-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'aes-192-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'aes-256-cbc' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 11/129 # Failed test 'aes-256-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'aes-256-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'aes-256-ecb base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 16/129 # Failed test 'bf' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'bf base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 18/129 # Failed test 'bf-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'bf-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'bf-cfb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 21/129 # Failed test 'bf-cfb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'bf-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'bf-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'bf-ofb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 25/129 # Failed test 'bf-ofb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'camellia-128-cbc' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 27/129 # Failed test 'camellia-128-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'camellia-128-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'camellia-128-ecb base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 30/129 # Failed test 'camellia-192-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'camellia-192-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'camellia-192-ecb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 33/129 # Failed test 'camellia-192-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'camellia-256-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'camellia-256-cbc base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 36/129 # Failed test 'camellia-256-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'camellia-256-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'cast' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 39/129 # Failed test 'cast base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'cast-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'cast-cbc base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 42/129 # Failed test 'cast5-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'cast5-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'cast5-cfb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 45/129 # Failed test 'cast5-cfb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'cast5-ecb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 47/129 # Failed test 'cast5-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'cast5-ofb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'cast5-ofb base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 50/129 # Failed test 'des' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-cbc' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 53/129 # Failed test 'des-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-cfb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-cfb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ecb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 57/129 # Failed test 'des-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 60/129 # Failed test 'des-ede-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede-cbc base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 62/129 # Failed test 'des-ede-cfb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede-cfb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede-ofb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 65/129 # Failed test 'des-ede-ofb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede3' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede3 base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 68/129 # Failed test 'des-ede3-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede3-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede3-cfb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 71/129 # Failed test 'des-ede3-cfb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede3-ofb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede3-ofb base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 74/129 # Failed test 'des-ofb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ofb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des3' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 77/129 # Failed test 'des3 base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'desx' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'desx base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'idea' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 81/129 # Failed test 'idea base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'idea-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'idea-cbc base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 84/129 # Failed test 'idea-cfb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'idea-cfb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'idea-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'idea-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'idea-ofb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 89/129 # Failed test 'idea-ofb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2 base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 92/129 # Failed test 'rc2-40-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2-40-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2-64-cbc' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 95/129 # Failed test 'rc2-64-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2-cbc base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 98/129 # Failed test 'rc2-cfb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2-cfb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2-ecb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 101/129 # Failed test 'rc2-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2-ofb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2-ofb base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 104/129 # Failed test 'rc4' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc4 base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc4-40' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 107/129 # Failed test 'rc4-40 base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc5' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc5 base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 110/129 # Failed test 'rc5-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc5-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc5-cfb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 113/129 # Failed test 'rc5-cfb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc5-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc5-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc5-ofb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 117/129 # Failed test 'rc5-ofb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'seed' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'seed base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 120/129 # Failed test 'seed-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'seed-cbc base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 122/129 # Failed test 'seed-cfb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'seed-cfb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'seed-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'seed-ecb base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 126/129 # Failed test 'seed-ofb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'seed-ofb base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 128/129 # Looks like you failed 124 tests of 129. ../test/recipes/20-test_enc.t ............. Dubious, test returned 124 (wstat 31744, 0x7c00) Failed 124/129 subtests ../test/recipes/25-test_crl.t ............. ok ../test/recipes/25-test_gen.t ............. ok ../test/recipes/25-test_pkcs7.t ........... ok ../test/recipes/25-test_req.t ............. ok ../test/recipes/25-test_sid.t ............. ok ../test/recipes/25-test_verify.t .......... ok ../test/recipes/25-test_x509.t ............ ok ../test/recipes/30-test_engine.t .......... ok ../test/recipes/30-test_evp.t ............. 1/1 # Failed test 'running evp_test evptests.txt' # at ../test/recipes/30-test_evp.t line 11. # Looks like you failed 1 test of 1. ../test/recipes/30-test_evp.t ............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/30-test_evp_extra.t ....... 1/1 # Failed test 'running evp_extra_test' # at ../test/recipes/30-test_evp_extra.t line 11. # Looks like you failed 1 test of 1. ../test/recipes/30-test_evp_extra.t ....... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/30-test_pbelu.t ........... ok ../test/recipes/40-test_rehash.t .......... 4/5 # Failed test 'Testing that we aren't running as a priviledged user, such as root' # at ../test/recipes/40-test_rehash.t line 41. # Looks like you failed 1 test of 5. ../test/recipes/40-test_rehash.t .......... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/5 subtests (less 1 skipped subtest: 3 okay) ../test/recipes/70-test_clienthello.t ..... 1/1 # Failed test 'running clienthellotest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 64. # Looks like you failed 1 test of 1. ../test/recipes/70-test_clienthello.t ..... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/70-test_packet.t .......... 1/1 # Failed test 'running packettest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 64. # Looks like you failed 1 test of 1. ../test/recipes/70-test_packet.t .......... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/70-test_sslcertstatus.t ... ok ../test/recipes/70-test_sslextension.t .... ok ../test/recipes/70-test_sslsessiontick.t .. ok ../test/recipes/70-test_sslskewith0p.t .... ok ../test/recipes/70-test_sslvertol.t ....... ok ../test/recipes/70-test_tlsextms.t ........ ok ../test/recipes/70-test_verify_extra.t .... ok ../test/recipes/80-test_ca.t .............. ok ../test/recipes/80-test_cms.t ............. # Failed test 'enveloped content test streaming S/MIME format, 3 recipients' # at ../test/recipes/80-test_cms.t line 376. # Failed test 'enveloped content test streaming S/MIME format, 3 recipients, 3rd used' # at ../test/recipes/80-test_cms.t line 376. # Failed test 'enveloped content test streaming S/MIME format, 3 recipients, key only used' # at ../test/recipes/80-test_cms.t line 376. # Failed test 'enveloped content test streaming S/MIME format, AES-256 cipher, 3 recipients' # at ../test/recipes/80-test_cms.t line 376. # Looks like you failed 4 tests of 15. ../test/recipes/80-test_cms.t ............. 1/4 # Failed test 'CMS => PKCS\#7 compatibility tests # ' # at ../test/recipes/80-test_cms.t line 381. # Failed test 'enveloped content test streaming S/MIME format, 3 recipients' # at ../test/recipes/80-test_cms.t line 391. # Failed test 'enveloped content test streaming S/MIME format, 3 recipients, 3rd used' # at ../test/recipes/80-test_cms.t line 391. # Failed test 'enveloped content test streaming S/MIME format, 3 recipients, key only used' # at ../test/recipes/80-test_cms.t line 391. # Failed test 'enveloped content test streaming S/MIME format, AES-256 cipher, 3 recipients' # at ../test/recipes/80-test_cms.t line 391. # Looks like you failed 4 tests of 15. ../test/recipes/80-test_cms.t ............. 2/4 # Failed test 'CMS <= PKCS\#7 compatibility tests # ' # at ../test/recipes/80-test_cms.t line 396. # Failed test 'enveloped content test streaming S/MIME format, 3 recipients' # at ../test/recipes/80-test_cms.t line 407. # Failed test 'enveloped content test streaming S/MIME format, 3 recipients, 3rd used' # at ../test/recipes/80-test_cms.t line 407. # Failed test 'enveloped content test streaming S/MIME format, 3 recipients, key only used' # at ../test/recipes/80-test_cms.t line 407. # Failed test 'enveloped content test streaming S/MIME format, AES-256 cipher, 3 recipients' # at ../test/recipes/80-test_cms.t line 407. # Failed test 'signed receipt MIME format, RSA key' # at ../test/recipes/80-test_cms.t line 418. # Failed test 'enveloped content test streaming S/MIME format, 3 recipients, keyid' # at ../test/recipes/80-test_cms.t line 418. # Failed test 'enveloped content test streaming PEM format, KEK' # at ../test/recipes/80-test_cms.t line 418. # Failed test 'enveloped content test streaming PEM format, KEK, key only' # at ../test/recipes/80-test_cms.t line 418. # Failed test 'encrypted content test streaming PEM format, 128 bit RC2 key' # at ../test/recipes/80-test_cms.t line 418. # Failed test 'encrypted content test streaming PEM format, 40 bit RC2 key' # at ../test/recipes/80-test_cms.t line 418. # Failed test 'encrypted content test streaming PEM format, triple DES key' # at ../test/recipes/80-test_cms.t line 418. # Failed test 'encrypted content test streaming PEM format, 128 bit AES key' # at ../test/recipes/80-test_cms.t line 418. # Looks like you failed 12 tests of 27. ../test/recipes/80-test_cms.t ............. 3/4 # Failed test 'CMS <=> CMS consistency tests # ' # at ../test/recipes/80-test_cms.t line 423. # Failed test 'enveloped content test streaming S/MIME format, OAEP default parameters' # at ../test/recipes/80-test_cms.t line 435. # Failed test 'enveloped content test streaming S/MIME format, OAEP SHA256' # at ../test/recipes/80-test_cms.t line 435. # Failed test 'enveloped content test streaming S/MIME format, ECDH' # at ../test/recipes/80-test_cms.t line 435. # Failed test 'enveloped content test streaming S/MIME format, ECDH, key identifier' # at ../test/recipes/80-test_cms.t line 435. # Failed test 'enveloped content test streaming S/MIME format, ECDH, AES128, SHA256 KDF' # at ../test/recipes/80-test_cms.t line 435. # Failed test 'enveloped content test streaming S/MIME format, ECDH, K-283, cofactor DH' # at ../test/recipes/80-test_cms.t line 435. # Failed test 'enveloped content test streaming S/MIME format, X9.42 DH' # at ../test/recipes/80-test_cms.t line 435. # Looks like you failed 7 tests of 11. ../test/recipes/80-test_cms.t ............. 4/4 # Failed test 'CMS <=> CMS consistency tests, modified key parameters # ' # at ../test/recipes/80-test_cms.t line 458. # Looks like you failed 4 tests of 4. ../test/recipes/80-test_cms.t ............. Dubious, test returned 4 (wstat 1024, 0x400) Failed 4/4 subtests ../test/recipes/80-test_dane.t ............ ok ../test/recipes/80-test_ocsp.t ............ ok ../test/recipes/80-test_ssl.t ............. ok ../test/recipes/80-test_tsa.t ............. 1/20 # Failed test 'creating a new CA for the TSA tests' # at ../test/recipes/80-test_tsa.t line 84. # Looks like you failed 1 test of 20. ../test/recipes/80-test_tsa.t ............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/20 subtests (less 19 skipped subtests: 0 okay) ../test/recipes/90-test_async.t ........... ok ../test/recipes/90-test_constant_time.t ... ok ../test/recipes/90-test_gmdiff.t .......... ok ../test/recipes/90-test_gost2814789.t ..... # Failed test 'running gost2814789test' # at ../test/recipes/90-test_gost2814789.t line 13. # Looks like you failed 1 test of 1. ../test/recipes/90-test_gost2814789.t ..... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/90-test_heartbeat.t ....... 1/1 # Failed test 'running heartbeat_test' # at ../test/testlib/OpenSSL/Test/Simple.pm line 64. # Looks like you failed 1 test of 1. ../test/recipes/90-test_heartbeat.t ....... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/90-test_ige.t ............. ok ../test/recipes/90-test_jpake.t ........... ok ../test/recipes/90-test_memleak.t ......... ok ../test/recipes/90-test_np.t .............. ok ../test/recipes/90-test_p5_crpt2.t ........ ok ../test/recipes/90-test_secmem.t .......... ok ../test/recipes/90-test_srp.t ............. 1/1 # Failed test 'running srptest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 64. # Looks like you failed 1 test of 1. ../test/recipes/90-test_srp.t ............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/90-test_v3name.t .......... ok Test Summary Report ------------------- ../test/recipes/05-test_rand.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 ../test/recipes/20-test_enc.t (Wstat: 31744 Tests: 129 Failed: 124) Failed tests: 2-13, 16-127 Non-zero exit status: 124 ../test/recipes/30-test_evp.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 ../test/recipes/30-test_evp_extra.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) Failed test: 4 Non-zero exit status: 1 ../test/recipes/70-test_clienthello.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 ../test/recipes/70-test_packet.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 ../test/recipes/80-test_cms.t (Wstat: 1024 Tests: 4 Failed: 4) Failed tests: 1-4 Non-zero exit status: 4 ../test/recipes/80-test_tsa.t (Wstat: 256 Tests: 20 Failed: 1) Failed test: 1 Non-zero exit status: 1 ../test/recipes/90-test_gost2814789.t (Wstat: 256 Tests: 0 Failed: 0) Non-zero exit status: 1 Parse errors: Bad plan. You planned 1 tests but ran 0. ../test/recipes/90-test_heartbeat.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 ../test/recipes/90-test_srp.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=69, Tests=364, 496 wallclock secs ( 3.18 usr 3.97 sys + 224.77 cusr 140.63 csys = 372.55 CPU) Result: FAIL Failed 12/69 test programs. 137/364 subtests failed. *** Error code 255 Stop. *** Error code 1 Stop. Any concerns? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From levitte at openssl.org Tue Jan 19 10:04:38 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 19 Jan 2016 11:04:38 +0100 (CET) Subject: [openssl-dev] Couple of pointers In-Reply-To: <20160119093327.GA7568@doctor.nl2k.ab.ca> References: <20160119093327.GA7568@doctor.nl2k.ab.ca> Message-ID: <20160119.110438.2235903368500073175.levitte@openssl.org> In message <20160119093327.GA7568 at doctor.nl2k.ab.ca> on Tue, 19 Jan 2016 02:33:27 -0700, The Doctor said: doctor> 1) doctor> doctor> For backwards compability do we have in I think openssl/rsa.h doctor> doctor> #define SSLeay_add_ssl_algorithms OpenSSL_add_ssl_algorithms doctor> #define SSLv23_server_method TLS_server_method That would be openssl/ssl.h rather than openssl/rsa.h... doctor> 2) doctor> doctor> Running the old BSD/OS doctor> doctor> I get doctor> doctor> rm -f openssl doctor> shlib_target=; if [ -n "libcrypto.so.1.1 libssl.so.1.1" ]; then shlib_target="bsd-gcc-shared"; fi; LIBRARIES="-L.. -lssl -L.. -lcrypto" ; make -f ../Makefile.shared -e APPNAME=openssl OBJECTS="openssl.o asn1pars.o ca.o ciphers.o cms.o crl.o crl2p7.o dgst.o dhparam.o dsa.o dsaparam.o ec.o ecparam.o enc.o engine.o errstr.o gendsa.o genpkey.o genrsa.o nseq.o ocsp.o passwd.o pkcs12.o pkcs7.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o prime.o rand.o req.o rsa.o rsautl.o s_client.o s_server.o s_time.o sess_id.o smime.o speed.o spkac.o srp.o ts.o verify.o version.o x509.o rehash.o apps.o opt.o s_cb.o s_socket.o app_rand.o" LIBDEPS=" $LIBRARIES -ldl -lgmp -lm -lc -lz" link_app.${shlib_target} doctor> TOP=.. PERL=/usr/bin/perl5 /usr/bin/perl5 run_tests.pl alltests doctor> ../test/recipes/00-check_testexes.t ....... ok doctor> ../test/recipes/01-test_ordinals.t ........ ok doctor> ../test/recipes/05-test_bf.t .............. ok doctor> ../test/recipes/05-test_cast.t ............ ok doctor> ../test/recipes/05-test_des.t ............. ok doctor> ../test/recipes/05-test_hmac.t ............ ok doctor> ../test/recipes/05-test_idea.t ............ ok doctor> ../test/recipes/05-test_md2.t ............. skipped: md2 is not supported by this OpenSSL build doctor> ../test/recipes/05-test_md4.t ............. ok doctor> ../test/recipes/05-test_md5.t ............. ok doctor> ../test/recipes/05-test_mdc2.t ............ ok doctor> ../test/recipes/05-test_rand.t ............ 1/1 doctor> # Failed test 'running randtest' doctor> # at ../test/testlib/OpenSSL/Test/Simple.pm line 64. doctor> # Looks like you failed 1 test of 1. doctor> ../test/recipes/05-test_rand.t ............ Dubious, test returned 1 (wstat 256, 0x100) doctor> Failed 1/1 subtests doctor> ../test/recipes/05-test_rc2.t ............. ok doctor> ../test/recipes/05-test_rc4.t ............. ok doctor> ../test/recipes/05-test_rc5.t ............. ok doctor> ../test/recipes/05-test_rmd.t ............. ok doctor> ../test/recipes/05-test_sha1.t ............ ok doctor> ../test/recipes/05-test_sha256.t .......... ok doctor> ../test/recipes/05-test_sha512.t .......... ok doctor> ../test/recipes/05-test_wp.t .............. ok doctor> ../test/recipes/10-test_bn.t .............. ok doctor> ../test/recipes/10-test_exp.t ............. ok doctor> ../test/recipes/15-test_dh.t .............. ok doctor> ../test/recipes/15-test_dsa.t ............. ok doctor> ../test/recipes/15-test_ec.t .............. ok doctor> ../test/recipes/15-test_ecdh.t ............ ok doctor> ../test/recipes/15-test_ecdsa.t ........... ok doctor> ../test/recipes/15-test_rsa.t ............. ok doctor> ../test/recipes/20-test_enc.t ............. 2/129 doctor> # Failed test 'aes-128-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'aes-128-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 4/129 doctor> # Failed test 'aes-128-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'aes-128-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'aes-192-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 7/129 doctor> # Failed test 'aes-192-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'aes-192-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'aes-192-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'aes-256-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 11/129 doctor> # Failed test 'aes-256-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'aes-256-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'aes-256-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 16/129 doctor> # Failed test 'bf' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'bf base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 18/129 doctor> # Failed test 'bf-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'bf-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'bf-cfb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 21/129 doctor> # Failed test 'bf-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'bf-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'bf-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'bf-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 25/129 doctor> # Failed test 'bf-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'camellia-128-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 27/129 doctor> # Failed test 'camellia-128-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'camellia-128-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'camellia-128-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 30/129 doctor> # Failed test 'camellia-192-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'camellia-192-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'camellia-192-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 33/129 doctor> # Failed test 'camellia-192-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'camellia-256-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'camellia-256-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 36/129 doctor> # Failed test 'camellia-256-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'camellia-256-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'cast' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 39/129 doctor> # Failed test 'cast base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'cast-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'cast-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 42/129 doctor> # Failed test 'cast5-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'cast5-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'cast5-cfb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 45/129 doctor> # Failed test 'cast5-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'cast5-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 47/129 doctor> # Failed test 'cast5-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'cast5-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'cast5-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 50/129 doctor> # Failed test 'des' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 53/129 doctor> # Failed test 'des-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-cfb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 57/129 doctor> # Failed test 'des-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 60/129 doctor> # Failed test 'des-ede-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 62/129 doctor> # Failed test 'des-ede-cfb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 65/129 doctor> # Failed test 'des-ede-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede3' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede3 base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 68/129 doctor> # Failed test 'des-ede3-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede3-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede3-cfb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 71/129 doctor> # Failed test 'des-ede3-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede3-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede3-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 74/129 doctor> # Failed test 'des-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des3' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 77/129 doctor> # Failed test 'des3 base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'desx' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'desx base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'idea' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 81/129 doctor> # Failed test 'idea base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'idea-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'idea-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 84/129 doctor> # Failed test 'idea-cfb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'idea-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'idea-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'idea-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'idea-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 89/129 doctor> # Failed test 'idea-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2 base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 92/129 doctor> # Failed test 'rc2-40-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2-40-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2-64-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 95/129 doctor> # Failed test 'rc2-64-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 98/129 doctor> # Failed test 'rc2-cfb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 101/129 doctor> # Failed test 'rc2-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 104/129 doctor> # Failed test 'rc4' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc4 base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc4-40' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 107/129 doctor> # Failed test 'rc4-40 base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc5' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc5 base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 110/129 doctor> # Failed test 'rc5-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc5-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc5-cfb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 113/129 doctor> # Failed test 'rc5-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc5-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc5-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc5-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 117/129 doctor> # Failed test 'rc5-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'seed' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'seed base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 120/129 doctor> # Failed test 'seed-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'seed-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 122/129 doctor> # Failed test 'seed-cfb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'seed-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'seed-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'seed-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 126/129 doctor> # Failed test 'seed-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'seed-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 128/129 # Looks like you failed 124 tests of 129. doctor> ../test/recipes/20-test_enc.t ............. Dubious, test returned 124 (wstat 31744, 0x7c00) doctor> Failed 124/129 subtests doctor> ../test/recipes/25-test_crl.t ............. ok doctor> ../test/recipes/25-test_gen.t ............. ok doctor> ../test/recipes/25-test_pkcs7.t ........... ok doctor> ../test/recipes/25-test_req.t ............. ok doctor> ../test/recipes/25-test_sid.t ............. ok doctor> ../test/recipes/25-test_verify.t .......... ok doctor> ../test/recipes/25-test_x509.t ............ ok doctor> ../test/recipes/30-test_engine.t .......... ok doctor> ../test/recipes/30-test_evp.t ............. 1/1 doctor> # Failed test 'running evp_test evptests.txt' doctor> # at ../test/recipes/30-test_evp.t line 11. doctor> # Looks like you failed 1 test of 1. doctor> ../test/recipes/30-test_evp.t ............. Dubious, test returned 1 (wstat 256, 0x100) doctor> Failed 1/1 subtests doctor> ../test/recipes/30-test_evp_extra.t ....... 1/1 doctor> # Failed test 'running evp_extra_test' doctor> # at ../test/recipes/30-test_evp_extra.t line 11. doctor> # Looks like you failed 1 test of 1. doctor> ../test/recipes/30-test_evp_extra.t ....... Dubious, test returned 1 (wstat 256, 0x100) doctor> Failed 1/1 subtests doctor> ../test/recipes/30-test_pbelu.t ........... ok doctor> ../test/recipes/40-test_rehash.t .......... 4/5 doctor> # Failed test 'Testing that we aren't running as a priviledged user, such as root' doctor> # at ../test/recipes/40-test_rehash.t line 41. doctor> # Looks like you failed 1 test of 5. doctor> ../test/recipes/40-test_rehash.t .......... Dubious, test returned 1 (wstat 256, 0x100) doctor> Failed 1/5 subtests doctor> (less 1 skipped subtest: 3 okay) doctor> ../test/recipes/70-test_clienthello.t ..... 1/1 doctor> # Failed test 'running clienthellotest' doctor> # at ../test/testlib/OpenSSL/Test/Simple.pm line 64. doctor> # Looks like you failed 1 test of 1. doctor> ../test/recipes/70-test_clienthello.t ..... Dubious, test returned 1 (wstat 256, 0x100) doctor> Failed 1/1 subtests doctor> ../test/recipes/70-test_packet.t .......... 1/1 doctor> # Failed test 'running packettest' doctor> # at ../test/testlib/OpenSSL/Test/Simple.pm line 64. doctor> # Looks like you failed 1 test of 1. doctor> ../test/recipes/70-test_packet.t .......... Dubious, test returned 1 (wstat 256, 0x100) doctor> Failed 1/1 subtests doctor> ../test/recipes/70-test_sslcertstatus.t ... ok doctor> ../test/recipes/70-test_sslextension.t .... ok doctor> ../test/recipes/70-test_sslsessiontick.t .. ok doctor> ../test/recipes/70-test_sslskewith0p.t .... ok doctor> ../test/recipes/70-test_sslvertol.t ....... ok doctor> ../test/recipes/70-test_tlsextms.t ........ ok doctor> ../test/recipes/70-test_verify_extra.t .... ok doctor> ../test/recipes/80-test_ca.t .............. ok doctor> ../test/recipes/80-test_cms.t ............. doctor> # Failed test 'enveloped content test streaming S/MIME format, 3 recipients' doctor> # at ../test/recipes/80-test_cms.t line 376. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, 3 recipients, 3rd used' doctor> # at ../test/recipes/80-test_cms.t line 376. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, 3 recipients, key only used' doctor> # at ../test/recipes/80-test_cms.t line 376. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, AES-256 cipher, 3 recipients' doctor> # at ../test/recipes/80-test_cms.t line 376. doctor> # Looks like you failed 4 tests of 15. doctor> ../test/recipes/80-test_cms.t ............. 1/4 doctor> # Failed test 'CMS => PKCS\#7 compatibility tests doctor> # ' doctor> # at ../test/recipes/80-test_cms.t line 381. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, 3 recipients' doctor> # at ../test/recipes/80-test_cms.t line 391. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, 3 recipients, 3rd used' doctor> # at ../test/recipes/80-test_cms.t line 391. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, 3 recipients, key only used' doctor> # at ../test/recipes/80-test_cms.t line 391. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, AES-256 cipher, 3 recipients' doctor> # at ../test/recipes/80-test_cms.t line 391. doctor> # Looks like you failed 4 tests of 15. doctor> ../test/recipes/80-test_cms.t ............. 2/4 doctor> # Failed test 'CMS <= PKCS\#7 compatibility tests doctor> # ' doctor> # at ../test/recipes/80-test_cms.t line 396. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, 3 recipients' doctor> # at ../test/recipes/80-test_cms.t line 407. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, 3 recipients, 3rd used' doctor> # at ../test/recipes/80-test_cms.t line 407. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, 3 recipients, key only used' doctor> # at ../test/recipes/80-test_cms.t line 407. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, AES-256 cipher, 3 recipients' doctor> # at ../test/recipes/80-test_cms.t line 407. doctor> doctor> # Failed test 'signed receipt MIME format, RSA key' doctor> # at ../test/recipes/80-test_cms.t line 418. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, 3 recipients, keyid' doctor> # at ../test/recipes/80-test_cms.t line 418. doctor> doctor> # Failed test 'enveloped content test streaming PEM format, KEK' doctor> # at ../test/recipes/80-test_cms.t line 418. doctor> doctor> # Failed test 'enveloped content test streaming PEM format, KEK, key only' doctor> # at ../test/recipes/80-test_cms.t line 418. doctor> doctor> # Failed test 'encrypted content test streaming PEM format, 128 bit RC2 key' doctor> # at ../test/recipes/80-test_cms.t line 418. doctor> doctor> # Failed test 'encrypted content test streaming PEM format, 40 bit RC2 key' doctor> # at ../test/recipes/80-test_cms.t line 418. doctor> doctor> # Failed test 'encrypted content test streaming PEM format, triple DES key' doctor> # at ../test/recipes/80-test_cms.t line 418. doctor> doctor> # Failed test 'encrypted content test streaming PEM format, 128 bit AES key' doctor> # at ../test/recipes/80-test_cms.t line 418. doctor> # Looks like you failed 12 tests of 27. doctor> ../test/recipes/80-test_cms.t ............. 3/4 doctor> # Failed test 'CMS <=> CMS consistency tests doctor> # ' doctor> # at ../test/recipes/80-test_cms.t line 423. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, OAEP default parameters' doctor> # at ../test/recipes/80-test_cms.t line 435. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, OAEP SHA256' doctor> # at ../test/recipes/80-test_cms.t line 435. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, ECDH' doctor> # at ../test/recipes/80-test_cms.t line 435. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, ECDH, key identifier' doctor> # at ../test/recipes/80-test_cms.t line 435. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, ECDH, AES128, SHA256 KDF' doctor> # at ../test/recipes/80-test_cms.t line 435. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, ECDH, K-283, cofactor DH' doctor> # at ../test/recipes/80-test_cms.t line 435. doctor> doctor> # Failed test 'enveloped content test streaming S/MIME format, X9.42 DH' doctor> # at ../test/recipes/80-test_cms.t line 435. doctor> # Looks like you failed 7 tests of 11. doctor> ../test/recipes/80-test_cms.t ............. 4/4 doctor> # Failed test 'CMS <=> CMS consistency tests, modified key parameters doctor> # ' doctor> # at ../test/recipes/80-test_cms.t line 458. doctor> # Looks like you failed 4 tests of 4. doctor> ../test/recipes/80-test_cms.t ............. Dubious, test returned 4 (wstat 1024, 0x400) doctor> Failed 4/4 subtests doctor> ../test/recipes/80-test_dane.t ............ ok doctor> ../test/recipes/80-test_ocsp.t ............ ok doctor> ../test/recipes/80-test_ssl.t ............. ok doctor> ../test/recipes/80-test_tsa.t ............. 1/20 doctor> # Failed test 'creating a new CA for the TSA tests' doctor> # at ../test/recipes/80-test_tsa.t line 84. doctor> # Looks like you failed 1 test of 20. doctor> ../test/recipes/80-test_tsa.t ............. Dubious, test returned 1 (wstat 256, 0x100) doctor> Failed 1/20 subtests doctor> (less 19 skipped subtests: 0 okay) doctor> ../test/recipes/90-test_async.t ........... ok doctor> ../test/recipes/90-test_constant_time.t ... ok doctor> ../test/recipes/90-test_gmdiff.t .......... ok doctor> ../test/recipes/90-test_gost2814789.t ..... doctor> # Failed test 'running gost2814789test' doctor> # at ../test/recipes/90-test_gost2814789.t line 13. doctor> # Looks like you failed 1 test of 1. doctor> ../test/recipes/90-test_gost2814789.t ..... Dubious, test returned 1 (wstat 256, 0x100) doctor> Failed 1/1 subtests doctor> ../test/recipes/90-test_heartbeat.t ....... 1/1 doctor> # Failed test 'running heartbeat_test' doctor> # at ../test/testlib/OpenSSL/Test/Simple.pm line 64. doctor> # Looks like you failed 1 test of 1. doctor> ../test/recipes/90-test_heartbeat.t ....... Dubious, test returned 1 (wstat 256, 0x100) doctor> Failed 1/1 subtests doctor> ../test/recipes/90-test_ige.t ............. ok doctor> ../test/recipes/90-test_jpake.t ........... ok doctor> ../test/recipes/90-test_memleak.t ......... ok doctor> ../test/recipes/90-test_np.t .............. ok doctor> ../test/recipes/90-test_p5_crpt2.t ........ ok doctor> ../test/recipes/90-test_secmem.t .......... ok doctor> ../test/recipes/90-test_srp.t ............. 1/1 doctor> # Failed test 'running srptest' doctor> # at ../test/testlib/OpenSSL/Test/Simple.pm line 64. doctor> # Looks like you failed 1 test of 1. doctor> ../test/recipes/90-test_srp.t ............. Dubious, test returned 1 (wstat 256, 0x100) doctor> Failed 1/1 subtests doctor> ../test/recipes/90-test_v3name.t .......... ok doctor> doctor> Test Summary Report doctor> ------------------- doctor> ../test/recipes/05-test_rand.t (Wstat: 256 Tests: 1 Failed: 1) doctor> Failed test: 1 doctor> Non-zero exit status: 1 doctor> ../test/recipes/20-test_enc.t (Wstat: 31744 Tests: 129 Failed: 124) doctor> Failed tests: 2-13, 16-127 doctor> Non-zero exit status: 124 doctor> ../test/recipes/30-test_evp.t (Wstat: 256 Tests: 1 Failed: 1) doctor> Failed test: 1 doctor> Non-zero exit status: 1 doctor> ../test/recipes/30-test_evp_extra.t (Wstat: 256 Tests: 1 Failed: 1) doctor> Failed test: 1 doctor> Non-zero exit status: 1 doctor> ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) doctor> Failed test: 4 doctor> Non-zero exit status: 1 doctor> ../test/recipes/70-test_clienthello.t (Wstat: 256 Tests: 1 Failed: 1) doctor> Failed test: 1 doctor> Non-zero exit status: 1 doctor> ../test/recipes/70-test_packet.t (Wstat: 256 Tests: 1 Failed: 1) doctor> Failed test: 1 doctor> Non-zero exit status: 1 doctor> ../test/recipes/80-test_cms.t (Wstat: 1024 Tests: 4 Failed: 4) doctor> Failed tests: 1-4 doctor> Non-zero exit status: 4 doctor> ../test/recipes/80-test_tsa.t (Wstat: 256 Tests: 20 Failed: 1) doctor> Failed test: 1 doctor> Non-zero exit status: 1 doctor> ../test/recipes/90-test_gost2814789.t (Wstat: 256 Tests: 0 Failed: 0) doctor> Non-zero exit status: 1 doctor> Parse errors: Bad plan. You planned 1 tests but ran 0. doctor> ../test/recipes/90-test_heartbeat.t (Wstat: 256 Tests: 1 Failed: 1) doctor> Failed test: 1 doctor> Non-zero exit status: 1 doctor> ../test/recipes/90-test_srp.t (Wstat: 256 Tests: 1 Failed: 1) doctor> Failed test: 1 doctor> Non-zero exit status: 1 doctor> Files=69, Tests=364, 496 wallclock secs ( 3.18 usr 3.97 sys + 224.77 cusr 140.63 csys = 372.55 CPU) doctor> Result: FAIL doctor> Failed 12/69 test programs. 137/364 subtests failed. doctor> *** Error code 255 doctor> doctor> Stop. doctor> *** Error code 1 doctor> doctor> Stop. doctor> doctor> Any concerns? Not sure what the team's stand is on BSD/OS, but that looks like a lot. A tip here, most of the tests generates log files, you'll find them all in test/, named like the tests themselves but without the indexing number, so for example, test/recipes/20-test_enc.t generates test/test_enc.log. They might shed some light on what's going on. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Tue Jan 19 11:34:01 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 19 Jan 2016 11:34:01 +0000 Subject: [openssl-dev] [openssl.org #4141] GOST ciphersuites In-Reply-To: References: Message-ID: This one was fixed a while ago. Closing. Matt From rt at openssl.org Tue Jan 19 11:47:22 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 19 Jan 2016 11:47:22 +0000 Subject: [openssl-dev] [openssl.org #4213] Error defining ciphersuite 0x0300ff87 In-Reply-To: References: Message-ID: Patch applied - thanks. Closing ticket. Matt From hkario at redhat.com Tue Jan 19 12:15:32 2016 From: hkario at redhat.com (Hubert Kario) Date: Tue, 19 Jan 2016 13:15:32 +0100 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: <20160118192227.17788998.21663.45907@ll.mit.edu> References: <20160118192227.17788998.21663.45907@ll.mit.edu> Message-ID: <2613183.d0DnLrUqE4@pintsize.usersys.redhat.com> On Monday 18 January 2016 19:22:19 Blumenthal, Uri - 0553 - MITLL wrote: > My preference would be to explain exactly - to avoid confusion and > problems arising from possible misunderstanding. > > As I said, however, I can live with either - as by now *I* at least > understand what this code does. ;-) > > But it doesn't seem fair for those who did not benefit from studying > the piles of openssl-users and openssl-dev archives. OK, I've updated the PR: https://github.com/openssl/openssl/pull/554 https://github.com/tomato42/openssl/commit/f37b5e639e57c2d4c3b404c24ecb11b8ec627e9b > Sent from my BlackBerry 10 smartphone on the > Verizon Wireless 4G LTE network. Original Message > From: Hubert Kario > Sent: Monday, January 18, 2016 06:23 > To: openssl-dev at openssl.org > Reply To: openssl-dev at openssl.org > Subject: Re: [openssl-dev] [openssl-users] pkeyutl does not invoke > hash? > On Friday 15 January 2016 00:02:43 Dr. Stephen Henson wrote: > > On Thu, Jan 14, 2016, Blumenthal, Uri - 0553 - MITLL wrote: > > > On 1/14/16, 16:51 , "openssl-dev on behalf of Dr. Stephen Henson" > > > > > > > > wrote: > > > >On Thu, Jan 14, 2016, Salz, Rich wrote: > > > >> Okay, how about this. First, remove the NOTES subhead. Add this > > > >> to > > > >> > > > >>the end of the first paragraph: > > > >> This program does not hash the input data and requires the > > > >> input > > > >> data > > > >> to be of the proper size, and must not be greater than the size > > > >> of > > > >> the public key field or modulus. See dgst(1) for a unified > > > >> Interace. > > > > > > > >The comment about the public key field or modulus is only true > > > >for > > > >some public > > > >key algorithms (e.g. RSA). > > > > > > Public key modulus would be true for RSA and DSA. Field would be > > > true for ECDSA (and I daresay EdDSA). What other signatures do we > > > have? > > > > For RSA the maximum size depends on the padding mode and is > > typically > > less than the modulus. > > > > For ECDSA it can be exceed the field size: it is truncated in that > > case. > > True, but what should we put in the man page? Explain the above > exactly, or just not mention the limit at all? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rt at openssl.org Tue Jan 19 14:22:30 2016 From: rt at openssl.org (Bill Cox via RT) Date: Tue, 19 Jan 2016 14:22:30 +0000 Subject: [openssl-dev] [openssl.org #4254] PR for BLAKE2 support In-Reply-To: References: Message-ID: This PR is on github at: https://github.com/openssl/openssl/pull/566 This set of changes adds initial BLAKE2 support to OpenSSL. The BLAKE2s is a 32-bit friendly 256-bit hash, while BLAKE2d is a 64-bit friendly 512-bit hash. The point of BLAKE2 is extremely fast secure hashing, even faster than MD5 on modern desktop CPUs with SSE instructions, as well as on ARM NEON processors. This PR integrates, with the authors' permission, the portable reference code from blake2.net, licensed under the OpenSSL license. EVP support is included, and test vectors for BLAKE2b and BLAKE2s have been added to tests/evptests.txt. Thanks, Bill From rt at openssl.org Tue Jan 19 14:22:31 2016 From: rt at openssl.org (sav_ix@ukr.net via RT) Date: Tue, 19 Jan 2016 14:22:31 +0000 Subject: [openssl-dev] [openssl.org #4255] OpenSSL-1.1.0-pre2 failures using MinGW-W64 In-Reply-To: <1453060954.186021958.y9vnrjtk@frv39.fwdcdn.com> References: <1453060954.186021958.y9vnrjtk@frv39.fwdcdn.com> Message-ID: ??? Hi everyone, Got few questions concerning OpenSSL builds using MinGW-W64. Used stuff: - Windows 10, - MinGW-W64 (v5.3.0, -posix-sjlj-rev0), - MSYS2 x64 (msys2-x86_64-20150916.exe), - OpenSSL-1.1.0-pre2. 1. If add parameter '-std=C11' (or '-std=C89') to 'cflags' variable in 'mingw' and 'mingw64' sections of file 'OpenSSL/Configurations/10-main.conf', and built OpenSSL with commands: ./Configure --prefix="$PWD/GCC32" mingw && make depend && make or ./Configure --prefix="$PWD/GCC64" mingw64 && make depend && make got error: =============================== : recipe for target 'md4_dgst.o]' failed make[2]: *** [md4_dgst.o] Error 1 =============================== Is it a flaw, or standard behavior? (e rror inherent to OpenSSL-1.0.2e too) 2. Command 'make test' finishes with errors for + configurations (logs added in attachment). While shared builds freeze on some step and should be terminated manually. Is it a flaw, or standard behavior on Windows? Regards, Alexander -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl_build_using_mingw-w64_logs.zip Type: application/x-zip-compressed Size: 12879 bytes Desc: not available URL: From rt at openssl.org Tue Jan 19 14:37:33 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Tue, 19 Jan 2016 14:37:33 +0000 Subject: [openssl-dev] [openssl.org #4255] OpenSSL-1.1.0-pre2 failures using MinGW-W64 In-Reply-To: <20160119.153731.780239351938967227.levitte@openssl.org> References: <1453060954.186021958.y9vnrjtk@frv39.fwdcdn.com> <20160119.153731.780239351938967227.levitte@openssl.org> Message-ID: In message on Tue, 19 Jan 2016 14:22:31 +0000, "sav_ix at ukr.net via RT" said: > 1. If add parameter '-std=C11' (or '-std=C89') to 'cflags' variable in 'mingw' and 'mingw64' sections of file 'OpenSSL/Configurations/10-main.conf', and built OpenSSL with commands: Do you know that you can do that on the configuration command line as well? Like this: ./Configure ming2 -std=C11 rt> got error: rt> =============================== rt> : recipe for target 'md4_dgst.o]' failed rt> make[2]: *** [md4_dgst.o] Error 1 rt> =============================== rt> rt> Is it a flaw, or standard behavior? (e rror inherent to OpenSSL-1.0.2e too) That means you need to look above, at the output from the compile line of md4_dgst.o. Those line that you show is are from make, basically complaining that the compiler (or whatever program that reports an error) was complaining. rt> 2. Command 'make test' finishes with errors for + configurations (logs added in attachment). While shared builds freeze on some step and should be terminated manually. rt> Is it a flaw, or standard behavior on Windows? You can find more logs in test/*.log, one file for each test. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Tue Jan 19 15:59:27 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 19 Jan 2016 15:59:27 +0000 Subject: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length) In-Reply-To: <3339734.5GVbOz5xNp@pintsize.usersys.redhat.com> References: <3339734.5GVbOz5xNp@pintsize.usersys.redhat.com> Message-ID: Alessandro's patch has now been applied (thanks). Closing this ticket. Matt From openssl-users at dukhovni.org Tue Jan 19 17:46:14 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 19 Jan 2016 12:46:14 -0500 Subject: [openssl-dev] Couple of pointers In-Reply-To: <20160119093327.GA7568@doctor.nl2k.ab.ca> References: <20160119093327.GA7568@doctor.nl2k.ab.ca> Message-ID: <7B2DDD6D-7B31-4820-97C4-7914AEAB3524@dukhovni.org> > On Jan 19, 2016, at 4:33 AM, The Doctor wrote: > > For backwards compability do we have in I think openssl/rsa.h > > #define SSLeay_add_ssl_algorithms OpenSSL_add_ssl_algorithms > #define SSLv23_server_method TLS_server_method The second is already present: include/openssl/ssl.h:#define SSLv23_server_method TLS_server_method I'll try to get the first restored, but that's been obsolete for quite some time. Even with the compatibility restored, take the opportunity to fix everything that fails with -DOPENSSL_API_COMPAT=0x10100000L -- Viktor. -- Viktor. From levitte at openssl.org Tue Jan 19 18:06:06 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 19 Jan 2016 19:06:06 +0100 (CET) Subject: [openssl-dev] Configure --prefix and --openssldir Message-ID: <20160119.190606.1029140769596300252.levitte@openssl.org> Hi, I'd like to ask developers and packagers out there, how are the configuration options --prefix and --openssldir working out for you? When I look at them today, they look... well, a bit aged, and could use a refreshment. But before doing anything with these options, I'd like to know how you guys are using them, and how they could be better. As a recap, here's how they work today (*): --prefix unset, --openssldir unset => INSTALLTOP=/usr/local/ssl , OPENSSLDIR=/usr/local/ssl --prefix unset, --openssldir set to "/bar" (absolute path) => INSTALLTOP=/bar , OPENSSLDIR=/bar --prefix unset, --openssldir set to "bar" (relative path) => INSTALLTOP=bar , OPENSSLDIR=bar/bar --prefix set to "/foo", --openssldir unset => INSTALLTOP=/foo , OPENSSLDIR=/foo/ssl --prefix set to "/foo", --openssldir set to "/bar" (absolute path) => INSTALLTOP=/foo , OPENSSLDIR=/bar --prefix set to "/foo", --openssldir set to "bar" (relative path) => INSTALLTOP=/foo , OPENSSLDIR=/foo/bar Installation currrntly uses $(INSTALLTOP) to install 'openssl' and 'c_rehash' (in $(INSTALLTOP)/bin), libraries & pkgconfig files (in $(INSTALLTOP)/lib and $(INSTALLTOP)/lib/pkgconfig), engines (in $(INSTALLTOP)/lib/engines) and include files (in $(INSTALLTOP)/include/openssl). Installation also currently uses $(OPENSSLDIR) to install scripts (in $(OPENSSLDIR)/misc) except for 'c_rehash', and manuals, both in man form (in $(OPENSSLDIR)/man/man$n) and html form (in $(OPENSSLDIR)/html/{apps|crypto|ssl}). Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From quanah at zimbra.com Tue Jan 19 18:33:01 2016 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Tue, 19 Jan 2016 10:33:01 -0800 Subject: [openssl-dev] Configure --prefix and --openssldir In-Reply-To: <20160119.190606.1029140769596300252.levitte@openssl.org> References: <20160119.190606.1029140769596300252.levitte@openssl.org> Message-ID: <51593E1E6154C9BAABEB9BC8@[192.168.1.9]> --On Tuesday, January 19, 2016 7:06 PM +0100 Richard Levitte wrote: > Hi, > > I'd like to ask developers and packagers out there, how are the > configuration options --prefix and --openssldir working out for you? > > When I look at them today, they look... well, a bit aged, and could > use a refreshment. But before doing anything with these options, I'd > like to know how you guys are using them, and how they could be > better. For Zimbra 8.7, we are doing: ./Configure no-idea enable-ec_nistp_64_gcc_128 no-mdc2 no-rc5 no-ssl2 \ no-hw --prefix=/opt/zimbra/common --libdir=lib --openssldir=/opt/zimbra/common/etc/ssl \ shared linux-x86_64 -g -O2 -DOPENSSL_NO_HEARTBEATS For previous versions of Zimbra, we did: ./Configure no-idea enable-ec_nistp_64_gcc_128 no-mdc2 no-rc5 no-ssl2 no-hw --prefix=/opt/zimbra/openssl-$(OPENSSL_VERSION) --libdir=lib \ shared $(PLAT) -g -O2 -DOPENSSL_NO_HEARTBEATS; \ So we've only just recently started using openssldir, but it does exactly what we want it to do. ;) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From openssl-users at dukhovni.org Tue Jan 19 18:37:42 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 19 Jan 2016 18:37:42 +0000 Subject: [openssl-dev] Configure --prefix and --openssldir In-Reply-To: <20160119.190606.1029140769596300252.levitte@openssl.org> References: <20160119.190606.1029140769596300252.levitte@openssl.org> Message-ID: <20160119183742.GP646@mournblade.imrryr.org> On Tue, Jan 19, 2016 at 07:06:06PM +0100, Richard Levitte wrote: > When I look at them today, they look... well, a bit aged, and could > use a refreshment. But before doing anything with these options, I'd > like to know how you guys are using them, and how they could be > better. > > As a recap, here's how they work today (*): > > --prefix unset, --openssldir unset > => INSTALLTOP=/usr/local/ssl , OPENSSLDIR=/usr/local/ssl > ... I only use "--prefix". There seems to be some code in Configure to support BSD platforms by adding "-rpath" when --prefix is not /usr, but it does not seem to work (the flag does not actually make it into the link command for libssl.so). I have to explicitly tweak the BSD definition in Configurations/. Fixing that might be useful. -- Viktor. From dragon at dancingdragon.be Tue Jan 19 18:48:58 2016 From: dragon at dancingdragon.be (Joey Yandle) Date: Tue, 19 Jan 2016 10:48:58 -0800 Subject: [openssl-dev] Configure --prefix and --openssldir In-Reply-To: <20160119.190606.1029140769596300252.levitte@openssl.org> References: <20160119.190606.1029140769596300252.levitte@openssl.org> Message-ID: <569E851A.9030607@dancingdragon.be> > --prefix unset, --openssldir set to "bar" (relative path) > => INSTALLTOP=bar , OPENSSLDIR=bar/bar > This one was sufficiently opaque that I stopped using --openssldir and started just using --prefix. For a multi-level relative path, this gives very strange results... From levitte at openssl.org Tue Jan 19 18:52:30 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 19 Jan 2016 19:52:30 +0100 (CET) Subject: [openssl-dev] Configure --prefix and --openssldir In-Reply-To: <20160119183742.GP646@mournblade.imrryr.org> References: <20160119.190606.1029140769596300252.levitte@openssl.org> <20160119183742.GP646@mournblade.imrryr.org> Message-ID: <20160119.195230.377900997894025834.levitte@openssl.org> In message <20160119183742.GP646 at mournblade.imrryr.org> on Tue, 19 Jan 2016 18:37:42 +0000, Viktor Dukhovni said: openssl-users> On Tue, Jan 19, 2016 at 07:06:06PM +0100, Richard Levitte wrote: openssl-users> openssl-users> > When I look at them today, they look... well, a bit aged, and could openssl-users> > use a refreshment. But before doing anything with these options, I'd openssl-users> > like to know how you guys are using them, and how they could be openssl-users> > better. openssl-users> > openssl-users> > As a recap, here's how they work today (*): openssl-users> > openssl-users> > --prefix unset, --openssldir unset openssl-users> > => INSTALLTOP=/usr/local/ssl , OPENSSLDIR=/usr/local/ssl openssl-users> > ... openssl-users> openssl-users> I only use "--prefix". There seems to be some code in Configure openssl-users> to support BSD platforms by adding "-rpath" when --prefix is not openssl-users> /usr, but it does not seem to work (the flag does not actually make openssl-users> it into the link command for libssl.so). I have to explicitly openssl-users> tweak the BSD definition in Configurations/. openssl-users> openssl-users> Fixing that might be useful. Check if this litte patch helps: openssl base64 -d < References: <569E8D8A.7030608@akamai.com> Message-ID: Part of the patch submitted to RT #844 includes a patch to the usage message of CA.pl. Although the functionality itself of CA.pl was rewritten for 1.1 (so that #844 was closed), the usage message remains incomplete, and Debian continues to apply a local patch to add the usage. So, as mentioned in the closing message of #844, this is a new ticket for this lingering issue. -Ben From openssl-users at dukhovni.org Tue Jan 19 19:26:27 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 19 Jan 2016 19:26:27 +0000 Subject: [openssl-dev] Configure --prefix and --openssldir In-Reply-To: <20160119.195230.377900997894025834.levitte@openssl.org> References: <20160119.190606.1029140769596300252.levitte@openssl.org> <20160119183742.GP646@mournblade.imrryr.org> <20160119.195230.377900997894025834.levitte@openssl.org> Message-ID: <20160119192627.GQ646@mournblade.imrryr.org> On Tue, Jan 19, 2016 at 07:52:30PM +0100, Richard Levitte wrote: > openssl-users> I only use "--prefix". There seems to be some code in Configure > openssl-users> to support BSD platforms by adding "-rpath" when --prefix is not > openssl-users> /usr, but it does not seem to work (the flag does not actually make > openssl-users> it into the link command for libssl.so). I have to explicitly > openssl-users> tweak the BSD definition in Configurations/. > openssl-users> > openssl-users> Fixing that might be useful. > > Check if this litte patch helps: > > openssl base64 -d < H4sIAHWFnlYAA5WOzUrDQACEz9mnGNMcGpNNUmKJIoXaerDgQVTwYG3Jz26yuN2E > zRZbrH12KwZUPIinGQbmmykE56C0FAZpOK0VF+VaM2RfnghVsA3iiJ1FWRIEcRwl > J6cZBlGUDIeEUvq9STzP+9Eej0EHSZz4CbxOD5Hg6Dsm1SUzGO0RzqnIcyd0rR5m > yjCJKfJ61QjJNEEPUqhnplErucVLxdThcaMZFxuIFqo2CNetDsgv7GJydzmnoUtg > vRJqOW2ValYsZcFlWgYjG/RB+lQ3qan8udO/nk1uby7ur1z7k9RtHO2x2i0+Jh7D > p2Nn554T7y/Wv2iw3gi69+22XYoCisG2XfIOdTfeR58BAAA= > EOF Yes, that seems to work: $ ./Configure --prefix=$HOME/install shared BSD-x86_64 $ make $ readelf -d libssl.so | grep RPATH 0x000000000000000f (RPATH) Library rpath: [/u/viktor/install/lib] Thanks. -- Viktor. From rt at openssl.org Tue Jan 19 19:33:21 2016 From: rt at openssl.org (=?UTF-8?B?SmFuIMW9w6Fr?= via RT) Date: Tue, 19 Jan 2016 19:33:21 +0000 Subject: [openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format In-Reply-To: References: Message-ID: I have updated Judson's patch to match with master branch. See GitHub PR https://github.com/openssl/openssl/pull/570 Jan On Mon, Jan 11, 2016 at 12:34 PM, Judson Wilson via RT wrote: > Here is an OpenSSL port of a patch in BoringSSL. It requires a call from > the application to set a file BIO. You could probably do this from within > SSL_CTX_new or something like that if you want a solution that doesn't > change the application. > > > https://github.com/JudsonWilson/openssl/commit/20e035a293756976b519ce028d5bcfe95544794b > > > > On Mon, Jan 11, 2016 at 2:08 AM, Matt Caswell via RT > wrote: > > > On Mon Dec 28 23:53:02 2015, matt wrote: > > > On Mon Dec 28 22:01:04 2015, rsalz at akamai.com wrote: > > > > Yes we would be interested in this but someone would almost > > > > definitely > > > > have to be provided as a complete patch because it seems unlikely > > > > anyone on the team will get around to doing it by 1.1 release. > > > > > > > > > > Actually I think this capability is already in 1.1.0...or rather it > > > *was* but > > > now seems to be broken. > > > > > > See commit 189ae368d91 and RT ticket 3352. > > > > > > I suspect the big apps cleanup broke it. > > > > This is now fixed. Keeping this ticket open for now because of the > request > > for > > support beyond just the apps. > > > > Matt > > > > _______________________________________________ > > openssl-dev mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From levitte at openssl.org Tue Jan 19 18:54:28 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 19 Jan 2016 19:54:28 +0100 (CET) Subject: [openssl-dev] Configure --prefix and --openssldir In-Reply-To: <569E851A.9030607@dancingdragon.be> References: <20160119.190606.1029140769596300252.levitte@openssl.org> <569E851A.9030607@dancingdragon.be> Message-ID: <20160119.195428.1248871089955981019.levitte@openssl.org> In message <569E851A.9030607 at dancingdragon.be> on Tue, 19 Jan 2016 10:48:58 -0800, Joey Yandle said: dragon> > --prefix unset, --openssldir set to "bar" (relative path) dragon> > => INSTALLTOP=bar , OPENSSLDIR=bar/bar dragon> > dragon> dragon> This one was sufficiently opaque that I stopped using --openssldir and dragon> started just using --prefix. For a multi-level relative path, this dragon> gives very strange results... That particular combination is really a bug, something I think we didn't think of back in the days, or shrugged at, can't recall which. But yes, it's quite the odd thing! Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From uri at ll.mit.edu Tue Jan 19 19:44:20 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 19 Jan 2016 19:44:20 +0000 Subject: [openssl-dev] Configure --prefix and --openssldir Message-ID: <20160119194429.17788998.35196.46280@ll.mit.edu> These ?arguments work quite well for me.? I use them to install openssl over Macports default installation, and having --prefix and --openssldir turns out to be sufficient for the job. Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Richard Levitte Sent: Tuesday, January 19, 2016 13:06 To: openssl-dev at openssl.org Reply To: openssl-dev at openssl.org Subject: [openssl-dev] Configure --prefix and --openssldir ? Hi, I'd like to ask developers and packagers out there, how are the configuration options --prefix and --openssldir working out for you? When I look at them today, they look... well, a bit aged, and could use a refreshment. But before doing anything with these options, I'd like to know how you guys are using them, and how they could be better. As a recap, here's how they work today (*): --prefix unset, --openssldir unset => INSTALLTOP=/usr/local/ssl , OPENSSLDIR=/usr/local/ssl --prefix unset, --openssldir set to "/bar" (absolute path) => INSTALLTOP=/bar , OPENSSLDIR=/bar --prefix unset, --openssldir set to "bar" (relative path) => INSTALLTOP=bar , OPENSSLDIR=bar/bar --prefix set to "/foo", --openssldir unset => INSTALLTOP=/foo , OPENSSLDIR=/foo/ssl --prefix set to "/foo", --openssldir set to "/bar" (absolute path) => INSTALLTOP=/foo , OPENSSLDIR=/bar --prefix set to "/foo", --openssldir set to "bar" (relative path) => INSTALLTOP=/foo , OPENSSLDIR=/foo/bar Installation currrntly uses $(INSTALLTOP) to install 'openssl' and 'c_rehash' (in $(INSTALLTOP)/bin), libraries & pkgconfig files (in $(INSTALLTOP)/lib and $(INSTALLTOP)/lib/pkgconfig), engines (in $(INSTALLTOP)/lib/engines) and include files (in $(INSTALLTOP)/include/openssl). Installation also currently uses $(OPENSSLDIR) to install scripts (in $(OPENSSLDIR)/misc) except for 'c_rehash', and manuals, both in man form (in $(OPENSSLDIR)/man/man$n) and html form (in $(OPENSSLDIR)/html/{apps|crypto|ssl}). Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From rt at openssl.org Tue Jan 19 19:55:32 2016 From: rt at openssl.org (=?UTF-8?B?SmFuIMW9w6Fr?= via RT) Date: Tue, 19 Jan 2016 19:55:32 +0000 Subject: [openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format In-Reply-To: References: Message-ID: It automatically opens a BIO for the keylogfile. Also if this patch is merged, RT 3352 can be reverted because it covers only a special case in the s_client app. On Tue, Jan 19, 2016 at 8:33 PM, Jan ??k wrote: > I have updated Judson's patch to match with master branch. See GitHub PR > https://github.com/openssl/openssl/pull/570 > > Jan > > On Mon, Jan 11, 2016 at 12:34 PM, Judson Wilson via RT > wrote: > > > Here is an OpenSSL port of a patch in BoringSSL. It requires a call from > > the application to set a file BIO. You could probably do this from > within > > SSL_CTX_new or something like that if you want a solution that doesn't > > change the application. > > > > > > > https://github.com/JudsonWilson/openssl/commit/20e035a293756976b519ce028d5bcfe95544794b > > > > > > > > On Mon, Jan 11, 2016 at 2:08 AM, Matt Caswell via RT > > wrote: > > > > > On Mon Dec 28 23:53:02 2015, matt wrote: > > > > On Mon Dec 28 22:01:04 2015, rsalz at akamai.com wrote: > > > > > Yes we would be interested in this but someone would almost > > > > > definitely > > > > > have to be provided as a complete patch because it seems unlikely > > > > > anyone on the team will get around to doing it by 1.1 release. > > > > > > > > > > > > > Actually I think this capability is already in 1.1.0...or rather it > > > > *was* but > > > > now seems to be broken. > > > > > > > > See commit 189ae368d91 and RT ticket 3352. > > > > > > > > I suspect the big apps cleanup broke it. > > > > > > This is now fixed. Keeping this ticket open for now because of the > > request > > > for > > > support beyond just the apps. > > > > > > Matt > > > > > > _______________________________________________ > > > openssl-dev mailing list > > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > > > > _______________________________________________ > > openssl-dev mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From uri at ll.mit.edu Tue Jan 19 22:16:23 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 19 Jan 2016 22:16:23 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: <2613183.d0DnLrUqE4@pintsize.usersys.redhat.com> References: <20160118192227.17788998.21663.45907@ll.mit.edu> <2613183.d0DnLrUqE4@pintsize.usersys.redhat.com> Message-ID: Looks good. I might add an *explicit* statement ?pkeyutl does not invoke the specified digest function?. Yes I realize it could be seen as repetitive. I?d much rather be repetitive than risk misunderstanding. And there are no praises for the shortest man page. :-) -- Regards, Uri Blumenthal On 1/19/16, 7:15 , "Hubert Kario" wrote: >On Monday 18 January 2016 19:22:19 Blumenthal, Uri - 0553 - MITLL wrote: >> My preference would be to explain exactly - to avoid confusion and >> problems arising from possible misunderstanding. >> >> As I said, however, I can live with either - as by now *I* at least >> understand what this code does. ;-) >> >> But it doesn't seem fair for those who did not benefit from studying >> the piles of openssl-users and openssl-dev archives. > >OK, I've updated the PR: https://github.com/openssl/openssl/pull/554 >https://github.com/tomato42/openssl/commit/f37b5e639e57c2d4c3b404c24ecb11b >8ec627e9b > >> Sent from my BlackBerry 10 smartphone on the >> Verizon Wireless 4G LTE network. Original Message >> From: Hubert Kario >> Sent: Monday, January 18, 2016 06:23 >> To: openssl-dev at openssl.org >> Reply To: openssl-dev at openssl.org >> Subject: Re: [openssl-dev] [openssl-users] pkeyutl does not invoke >> hash? >> On Friday 15 January 2016 00:02:43 Dr. Stephen Henson wrote: >> > On Thu, Jan 14, 2016, Blumenthal, Uri - 0553 - MITLL wrote: >> > > On 1/14/16, 16:51 , "openssl-dev on behalf of Dr. Stephen Henson" >> > > >> > > >> >> wrote: >> > > >On Thu, Jan 14, 2016, Salz, Rich wrote: >> > > >> Okay, how about this. First, remove the NOTES subhead. Add this >> > > >> to >> > > >> >> > > >>the end of the first paragraph: >> > > >> This program does not hash the input data and requires the >> > > >> input >> > > >> data >> > > >> to be of the proper size, and must not be greater than the size >> > > >> of >> > > >> the public key field or modulus. See dgst(1) for a unified >> > > >> Interace. >> > > > >> > > >The comment about the public key field or modulus is only true >> > > >for >> > > >some public >> > > >key algorithms (e.g. RSA). >> > > >> > > Public key modulus would be true for RSA and DSA. Field would be >> > > true for ECDSA (and I daresay EdDSA). What other signatures do we >> > > have? >> > >> > For RSA the maximum size depends on the padding mode and is >> > typically >> > less than the modulus. >> > >> > For ECDSA it can be exceed the field size: it is truncated in that >> > case. >> >> True, but what should we put in the man page? Explain the above >> exactly, or just not mention the limit at all? > >-- >Regards, >Hubert Kario >Senior Quality Engineer, QE BaseOS Security team >Web: www.cz.redhat.com >Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From uri at ll.mit.edu Tue Jan 19 22:23:09 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 19 Jan 2016 22:23:09 +0000 Subject: [openssl-dev] Bug and PR: pkeyutl.c fails -derive with token (1.0.2-stable) Message-ID: Currently pkeyutl.c fails to derive a shared symmetric key when the peer public key is on a hardware token. PR https://github.com/openssl/openssl/pull/557 fixes this issue. Review and merge would be appreciated. It applies to OpenSSL_1_0_2-stable. (Will be a separate one for 1.1.) -- Regards, Uri Blumenthal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From uri at ll.mit.edu Tue Jan 19 22:39:18 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 19 Jan 2016 22:39:18 +0000 Subject: [openssl-dev] Bug and PR: pkeyutl.c fails to work with keys that reside on a token (fix against master) Message-ID: This fix is for a problem that existed in all the OpenSSL branches. For 1_0_2-stable it has been already fixed by the approved and merged PR #523. This PR https://github.com/openssl/openssl/pull/548 is a port of it to the master branch (and has been sitting there for a while :). I?d appreciate a review and (hopefully) a merge. Thanks! -- Regards, Uri Blumenthal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From doctor at doctor.nl2k.ab.ca Tue Jan 19 23:37:24 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 19 Jan 2016 16:37:24 -0700 Subject: [openssl-dev] Openssl 1.1 and Bind 9.6 ESV R11 Message-ID: <20160119233724.GA9102@doctor.nl2k.ab.ca> Tried to compile an old bind and ran into /bin/bash /usr/source/bind-9.6-ESV-R11/libtool --mode=compile /usr/bin/gcc -I/usr/source/bind-9.6-ESV-R11 -I. -Iinclude -I/usr/source/bind-9.6-ESV-R11/lib/dns/include -I../../lib/dns/include -I/usr/source/bind-9.6-ESV-R11/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/nothreads/include -I../../lib/isc/x86_32/include -I/usr/contrib/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_MD5 -DOPENSSL -g -O2 -Wall -I/usr/contrib/include/libxml2 -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -c openssldh_link.c libtool: compile: /usr/bin/gcc -I/usr/source/bind-9.6-ESV-R11 -I. -Iinclude -I/usr/source/bind-9.6-ESV-R11/lib/dns/include -I../../lib/dns/include -I/usr/source/bind-9.6-ESV-R11/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/nothreads/include -I../../lib/isc/x86_32/include -I/usr/contrib/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_MD5 -DOPENSSL -g -O2 -Wall -I/usr/contrib/include/libxml2 -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -c openssldh_link.c -o openssldh_link.o openssldh_link.c: In function `openssldh_generate': openssldh_link.c:155: storage size of `cb' isn't known openssldh_link.c:155: warning: unused variable `cb' openssldh_link.c: In function `dst__openssldh_init': openssldh_link.c:623: warning: implicit declaration of function `BN_init' /usr/contrib/include/openssl/conf.h: At top level: openssldh_link.c:73: storage size of `bn2' isn't known openssldh_link.c:73: storage size of `bn768' isn't known openssldh_link.c:73: storage size of `bn1024' isn't known openssldh_link.c:73: storage size of `bn1536' isn't known *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Line 73 reads static BIGNUM bn2, bn768, bn1024, bn1536; line 155 reads #if OPENSSL_VERSION_NUMBER > 0x00908000L BN_GENCB cb; #endif and line 623 reads isc_result_t dst__openssldh_init(dst_func_t **funcp) { REQUIRE(funcp != NULL); if (*funcp == NULL) { BN_init(&bn2); BN_init(&bn768); BN_init(&bn1024); BN_init(&bn1536); BN_set_word(&bn2, 2); BN_fromhex(&bn768, PRIME768); BN_fromhex(&bn1024, PRIME1024); BN_fromhex(&bn1536, PRIME1536); *funcp = &openssldh_functions; } return (ISC_R_SUCCESS); } What needs to be adjusted? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From rsalz at akamai.com Wed Jan 20 02:43:48 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 20 Jan 2016 02:43:48 +0000 Subject: [openssl-dev] Openssl 1.1 and Bind 9.6 ESV R11 In-Reply-To: <20160119233724.GA9102@doctor.nl2k.ab.ca> References: <20160119233724.GA9102@doctor.nl2k.ab.ca> Message-ID: > static BIGNUM bn2, bn768, bn1024, bn1536; The BIGNUM structure is now opaque. These must be pointers. > BN_init(&bn2); BN_new() > BN_init(&bn768); > BN_init(&bn1024); > BN_init(&bn1536); > BN_set_word(&bn2, 2); > BN_fromhex(&bn768, PRIME768); > BN_fromhex(&bn1024, PRIME1024); > BN_fromhex(&bn1536, PRIME1536); Pointers. From bkaduk at akamai.com Wed Jan 20 02:53:49 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 19 Jan 2016 20:53:49 -0600 Subject: [openssl-dev] Openssl 1.1 and Bind 9.6 ESV R11 In-Reply-To: <20160119233724.GA9102@doctor.nl2k.ab.ca> References: <20160119233724.GA9102@doctor.nl2k.ab.ca> Message-ID: <569EF6BD.9000804@akamai.com> On 01/19/2016 05:37 PM, The Doctor wrote: > Tried to compile an old bind and ran into Why? > What needs to be adjusted? > > The bind code is what needs to be adjusted, given that openssl 1.1 is intentionally introducing API changes and removing direct access to many structures. It seems quite unlikely that an EoL version of a third-party software is going to magically receive a new release allowing it to build against a version of openssl that did not exist when it was released. -Ben From hkario at redhat.com Wed Jan 20 10:10:27 2016 From: hkario at redhat.com (Hubert Kario) Date: Wed, 20 Jan 2016 11:10:27 +0100 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: References: <20160118192227.17788998.21663.45907@ll.mit.edu> <2613183.d0DnLrUqE4@pintsize.usersys.redhat.com> Message-ID: <4181799.NJm4JpuZrY@pintsize.usersys.redhat.com> On Tuesday 19 January 2016 22:16:23 Blumenthal, Uri - 0553 - MITLL wrote: > Looks good. I might add an *explicit* statement ?pkeyutl does not > invoke the specified digest function?. > > Yes I realize it could be seen as repetitive. I?d much rather be > repetitive than risk misunderstanding. And there are no praises for > the shortest man page. :-) I don't want to do that because AFAIK, for Ed25519 and Ed448 the hash *is* integral part of the signature process and you pass *the whole* message-to-be-signed to the signature function, not its hash. So, unless the above is false, I'd rather not add such absolute statements. But please correct me if I'm wrong. > >On Monday 18 January 2016 19:22:19 Blumenthal, Uri - 0553 - MITLL wrote: > >> My preference would be to explain exactly - to avoid confusion and > >> problems arising from possible misunderstanding. > >> > >> As I said, however, I can live with either - as by now *I* at least > >> understand what this code does. ;-) > >> > >> But it doesn't seem fair for those who did not benefit from > >> studying > >> the piles of openssl-users and openssl-dev archives. > > > >OK, I've updated the PR: https://github.com/openssl/openssl/pull/554 > >https://github.com/tomato42/openssl/commit/f37b5e639e57c2d4c3b404c24e > >cb11b 8ec627e9b > > > >> Sent from my BlackBerry 10 smartphone on the > >> Verizon Wireless 4G LTE network. Original Message > >> From: Hubert Kario > >> Sent: Monday, January 18, 2016 06:23 > >> To: openssl-dev at openssl.org > >> Reply To: openssl-dev at openssl.org > >> Subject: Re: [openssl-dev] [openssl-users] pkeyutl does not invoke > >> hash? > >> > >> On Friday 15 January 2016 00:02:43 Dr. Stephen Henson wrote: > >> > On Thu, Jan 14, 2016, Blumenthal, Uri - 0553 - MITLL wrote: > >> > > On 1/14/16, 16:51 , "openssl-dev on behalf of Dr. Stephen > >> > > Henson" > >> > > > >> > > >> > > steve at openssl.org> > >> > >> wrote: > >> > > >On Thu, Jan 14, 2016, Salz, Rich wrote: > >> > > >> Okay, how about this. First, remove the NOTES subhead. Add > >> > > >> this > >> > > >> to > >> > > >> > >> > > >>the end of the first paragraph: > >> > > >> This program does not hash the input data and requires the > >> > > >> input > >> > > >> data > >> > > >> to be of the proper size, and must not be greater than the > >> > > >> size > >> > > >> of > >> > > >> the public key field or modulus. See dgst(1) for a unified > >> > > >> Interace. > >> > > > > >> > > >The comment about the public key field or modulus is only true > >> > > >for > >> > > >some public > >> > > >key algorithms (e.g. RSA). > >> > > > >> > > Public key modulus would be true for RSA and DSA. Field would > >> > > be > >> > > true for ECDSA (and I daresay EdDSA). What other signatures do > >> > > we > >> > > have? > >> > > >> > For RSA the maximum size depends on the padding mode and is > >> > typically > >> > less than the modulus. > >> > > >> > For ECDSA it can be exceed the field size: it is truncated in > >> > that > >> > case. > >> > >> True, but what should we put in the man page? Explain the above > >> exactly, or just not mention the limit at all? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From andrewponomarenko at yandex.ru Wed Jan 20 12:36:59 2016 From: andrewponomarenko at yandex.ru (Ponomarenko Andrey) Date: Wed, 20 Jan 2016 15:36:59 +0300 Subject: [openssl-dev] ABI structure in detail for OpenSSL 1.0.2e In-Reply-To: <85192c83c528447b9f2ff29ab7a2e0bb@usma1ex-dag1mb1.msg.corp.akamai.com> References: <3186311453132932@web20g.yandex.ru> <85192c83c528447b9f2ff29ab7a2e0bb@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <3693771453293419@web17o.yandex.ru> 18.01.2016, 19:56, "Salz, Rich" : > This is interesting, thanks. > > I am not sure how to read the charts; I'm probably being dumb. > > I wonder how master compares? You can find comparison results for master and latest pre-releases on this page: http://abi-laboratory.pro/tracker/timeline/openssl/ More info: https://wiki.openssl.org/index.php/Binary_Compatibility Thank you. From uri at ll.mit.edu Wed Jan 20 13:34:42 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 20 Jan 2016 13:34:42 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: <4181799.NJm4JpuZrY@pintsize.usersys.redhat.com> References: <20160118192227.17788998.21663.45907@ll.mit.edu> <2613183.d0DnLrUqE4@pintsize.usersys.redhat.com> <4181799.NJm4JpuZrY@pintsize.usersys.redhat.com> Message-ID: On 1/20/16, 5:10 , "Hubert Kario" wrote: >On Tuesday 19 January 2016 22:16:23 Blumenthal, Uri - 0553 - MITLL wrote: >> Looks good. I might add an *explicit* statement ?pkeyutl does not >> invoke the specified digest function?. >> >> Yes I realize it could be seen as repetitive. I?d much rather be >> repetitive than risk misunderstanding. And there are no praises for >> the shortest man page. :-) > >I don't want to do that because AFAIK, for Ed25519 and Ed448 the hash >*is* integral part of the signature process and you pass *the whole* >message-to-be-signed to the signature function, not its hash. I think the above confuses (mixes together) two different things: signature *function* and signature *implementation*. In practice (IMHO, based on my experience with such things) the *implementation* on tokens (such as smart cards) will always be split, so the hashing is done in software while the actual ECC operation is performed on the token. It appears to me that pkeyutl is more an instrument to access those primitive operations, unlike dgst that provides access to the ?true? (complete) signature function that includes hashing. So no matter what draft-josefsson-eddsa-ed25519-02 says, the hashing would have to be done in software, and the result passed to the token for the actual signing. >So, unless the above is false, I'd rather not add such absolute >statements. I see your point. Would leave the decision to you, in light of the above. Because the exact purpose of pkeyutl is unclear to me, I can?t insist. Assuming pkeyutl does provide access to the ?complete EdDSA function? as specified in the draft above, one possibility is to add even more words, and explicitly state where the digest for sure is NOT invoked (RSA, DSA, ECDSA), and maybe where it is (EdDSA, maybe other future schemes)... >But please correct me if I'm wrong. Likewise. :-) >>>On Monday 18 January 2016 19:22:19 Blumenthal, Uri - 0553 - MITLL >wrote: >> >> My preference would be to explain exactly - to avoid confusion and >> >> problems arising from possible misunderstanding. >> >> >> >> As I said, however, I can live with either - as by now *I* at least >> >> understand what this code does. ;-) >> >> >> >> But it doesn't seem fair for those who did not benefit from >> >> studying >> >> the piles of openssl-users and openssl-dev archives. >> > >> >OK, I've updated the PR: https://github.com/openssl/openssl/pull/554 >> >https://github.com/tomato42/openssl/commit/f37b5e639e57c2d4c3b404c24e >> >cb11b 8ec627e9b >> > >> >> Sent from my BlackBerry 10 smartphone on the >> >> Verizon Wireless 4G LTE network. Original Message >> >> From: Hubert Kario >> >> Sent: Monday, January 18, 2016 06:23 >> >> To: openssl-dev at openssl.org >> >> Reply To: openssl-dev at openssl.org >> >> Subject: Re: [openssl-dev] [openssl-users] pkeyutl does not invoke >> >> hash? >> >> >> >> On Friday 15 January 2016 00:02:43 Dr. Stephen Henson wrote: >> >> > On Thu, Jan 14, 2016, Blumenthal, Uri - 0553 - MITLL wrote: >> >> > > On 1/14/16, 16:51 , "openssl-dev on behalf of Dr. Stephen >> >> > > Henson" >> >> > > >> >> > > > >> > > steve at openssl.org> >> >> >> >> wrote: >> >> > > >On Thu, Jan 14, 2016, Salz, Rich wrote: >> >> > > >> Okay, how about this. First, remove the NOTES subhead. Add >> >> > > >> this >> >> > > >> to >> >> > > >> >> >> > > >>the end of the first paragraph: >> >> > > >> This program does not hash the input data and requires the >> >> > > >> input >> >> > > >> data >> >> > > >> to be of the proper size, and must not be greater than the >> >> > > >> size >> >> > > >> of >> >> > > >> the public key field or modulus. See dgst(1) for a unified >> >> > > >> Interace. >> >> > > > >> >> > > >The comment about the public key field or modulus is only true >> >> > > >for >> >> > > >some public >> >> > > >key algorithms (e.g. RSA). >> >> > > >> >> > > Public key modulus would be true for RSA and DSA. Field would >> >> > > be >> >> > > true for ECDSA (and I daresay EdDSA). What other signatures do >> >> > > we >> >> > > have? >> >> > >> >> > For RSA the maximum size depends on the padding mode and is >> >> > typically >> >> > less than the modulus. >> >> > >> >> > For ECDSA it can be exceed the field size: it is truncated in >> >> > that >> >> > case. >> >> >> >> True, but what should we put in the man page? Explain the above >> >> exactly, or just not mention the limit at all? > >-- >Regards, >Hubert Kario >Senior Quality Engineer, QE BaseOS Security team >Web: www.cz.redhat.com >Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From matt at openssl.org Wed Jan 20 14:04:57 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 20 Jan 2016 14:04:57 +0000 Subject: [openssl-dev] renegotiation failure causes SSL_shutdown to return 1? In-Reply-To: References: Message-ID: <569F9409.4050206@openssl.org> On 05/12/15 09:42, Judson Wilson wrote: > I am noticing the following sequence of events: > > 1) SSL_renegotiate(...), followed by SSL_write(..., 0) fails when a web > server rejects it by sending a TCP FIN > 2) SSL_get_error returns SSL_ERROR_SSL > 3) SSL_in_init(...) is true > 4) SSL_shutdown returns 1 <-- this seems strange. > > I'm not sure that this is the right behavior. Shutting down in a > handshake without sending/receiving close_notify shouldn't give the > "everything shutdown gracefully" signal. Perhaps it would be better to > return -1 and signal SSL_ERROR_SSL? This is fixed now (in master and 1.0.2). Matt From rt at openssl.org Wed Jan 20 15:01:28 2016 From: rt at openssl.org (Billy Brumley via RT) Date: Wed, 20 Jan 2016 15:01:28 +0000 Subject: [openssl-dev] [openssl.org #4257] Fix BN_gcd errors for curves with even order that do not play nicely with Montgomery arithmetic In-Reply-To: References: Message-ID: https://github.com/openssl/openssl/pull/571 I was getting errors for curves with even order. This patch squelches the errors. 139858767824544:error:0306E06C:lib(3):func(110):reason(108):bn_gcd.c:233: 139858767824544:error:0306E06C:lib(3):func(110):reason(108):bn_gcd.c:233: From gvanem at yahoo.no Wed Jan 20 15:24:25 2016 From: gvanem at yahoo.no (Gisle Vanem) Date: Wed, 20 Jan 2016 16:24:25 +0100 Subject: [openssl-dev] "openssl s_client" memory leak In-Reply-To: <569D9EB0.7030400@yahoo.no> References: <569D9EB0.7030400@yahoo.no> Message-ID: <569FA6A9.3090601@yahoo.no> Gisle Vanem wrote: > And adding other options show additional leaks. > E.g. '-nbio_test -reconnect' results in 12 leaks: > > [12:15:17] 13704 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, address=0x2ccf468 > [12:15:15] 13016 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, address=0x2ccedb0 ... > [12:15:17] 14021 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, address=0x2ccf628 > 864 bytes leaked in 12 chunks I was curious to fix + understand why this leak happens. AFAICS the execution-flow with the options '-reconnect' and '-nbio_test' seems a bit funny. Because, in a brief of 's_client_main()' is: re_start: ... if (nbio_test) { BIO *test; test = BIO_new(BIO_f_nbio_test()); << ! leaks here AFAICS sbio = BIO_push(test, sbio); } ... if (reconnect) { reconnect--; ... goto re_start; } ------------- According to 'man s_client', a reconnect should be performed 5 times: -reconnect reconnects to the same server 5 times using the same session ID, this can be used as a test that session caching is working. But where is 'test' bio-freed? Does it hurt the "session ID" that one does 'sbio = BIO_pop(sbio)'? Or could the 're_start' label be moved *after* the BIO_new()? You experts should take a look at this. -- --gv From rsalz at akamai.com Wed Jan 20 15:28:16 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 20 Jan 2016 15:28:16 +0000 Subject: [openssl-dev] "openssl s_client" memory leak In-Reply-To: <569FA6A9.3090601@yahoo.no> References: <569D9EB0.7030400@yahoo.no> <569FA6A9.3090601@yahoo.no> Message-ID: Thanks for looking into this. I don't think it's gonna be on anyone's high priority list to fix in the next release, so feel free to keep at it :) From agostrer at gmail.com Wed Jan 20 15:46:59 2016 From: agostrer at gmail.com (Alexander Gostrer) Date: Wed, 20 Jan 2016 07:46:59 -0800 Subject: [openssl-dev] ECDH engine In-Reply-To: <20151219204917.GA1814@openssl.org> References: <20151219204917.GA1814@openssl.org> Message-ID: Hi Steve, And here is the ENGINE implementation for Atmel ATECC508A with few small patches to OpenSSL_1_0_2-stable: https://github.com/AtmelCSO/cryptoauth-openssl-engine Your comments are welcome. Regards, Alex. On Sat, Dec 19, 2015 at 12:49 PM, Dr. Stephen Henson wrote: > On Fri, Dec 18, 2015, Alexander Gostrer wrote: > > > Hi Steve, > > > > John and I completed writing an ECDH engine based on the > > OpenSSL_1_0_2-stable branch. We were planning to expand it to the master > > but found some major changes made by you recently. What is the status of > > this task? Is it stable enough to follow it? Are you planning another > > changes? Is there a design document that we can use in our work? > > > > The version in master shouldn't change much any more. Documentation will be > available in the near future. The changes were meant to remove some of the > weird "quirks" of ECC compared to other algortihms and to permit future > expansion to a wider range of curves. > > In the meantime it shouldn't be too hard to follow how the new code works. > Instead of separate ECDH/ECDSA methods with weird locking and ex_data and > minimal ENGINE support everything is combined into a single EC_KEY_METHOD > which can contain ECDSA, ECDH and key generation (something which was > impossible with the old code) and be tied directly to an ENGINE. > > Most of the primary APIs such as ECDH_compute_key can be redirected > directly > through an engine supplied function in EC_KEY_METHOD. > > Having said that the code is very new and may have the odd bug that needs > to > be fixed. If you have any problems let me know and I'll look into them. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Wed Jan 20 16:11:23 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 20 Jan 2016 16:11:23 +0000 Subject: [openssl-dev] ECDH engine Message-ID: <20160120161132.17788998.39388.46447@ll.mit.edu> What is this Atmel x508x? Is it a chip? Is it a token/smartcard? Is it accessible via PKCS#11 at all? Is it accessible by/via OpenSC? I am trying to figure why such a generic and useful set of ECC operations (Sign, Derive) is implementation-limited to one single .? A much better solution to me would be adding EC-DERIVE to engine_pkcs11, and automatically get all the tokens covered. Since I'm probably? missing something, could you please educate me? Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. From: Alexander Gostrer? Sent: Wednesday, January 20, 2016 10:47 To: Dr. Stephen Henson Reply To: openssl-dev at openssl.org Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] ECDH engine ? Hi Steve, ? And here is the ENGINE implementation for Atmel ATECC508A with few small patches to OpenSSL_1_0_2-stable: https://github.com/AtmelCSO/cryptoauth-openssl-engine Your comments are welcome. Regards, Alex. On Sat, Dec 19, 2015 at 12:49 PM, Dr. Stephen Henson wrote: On Fri, Dec 18, 2015, Alexander Gostrer wrote: > Hi Steve, > > John and I completed writing an ECDH engine based on the > OpenSSL_1_0_2-stable branch. We were planning to expand it to the master > but found some major changes made by you recently. What is the status of > this task? Is it stable enough to follow it? Are you planning another > changes? Is there a design document that we can use in our work? > The version in master shouldn't change much any more. Documentation will be available in the near future. The changes were meant to remove some of the weird "quirks" of ECC compared to other algortihms and to permit future expansion to a wider range of curves. In the meantime it shouldn't be too hard to follow how the new code works. Instead of separate ECDH/ECDSA methods with weird locking and ex_data and minimal ENGINE support everything is combined into a single EC_KEY_METHOD which can contain ECDSA, ECDH and key generation (something which was impossible with the old code) and be tied directly to an ENGINE. Most of the primary APIs such as ECDH_compute_key can be redirected directly through an engine supplied function in EC_KEY_METHOD. Having said that the code is very new and may have the odd bug that needs to be fixed. If you have any problems let me know and I'll look into them. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From steve at openssl.org Wed Jan 20 16:37:43 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 20 Jan 2016 16:37:43 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: References: <20160118192227.17788998.21663.45907@ll.mit.edu> <2613183.d0DnLrUqE4@pintsize.usersys.redhat.com> <4181799.NJm4JpuZrY@pintsize.usersys.redhat.com> Message-ID: <20160120163743.GA18335@openssl.org> On Wed, Jan 20, 2016, Blumenthal, Uri - 0553 - MITLL wrote: > On 1/20/16, 5:10 , "Hubert Kario" wrote: > > It appears to me that pkeyutl is more an instrument to access those > primitive operations, unlike dgst that provides access to the ???true??? > (complete) signature function that includes hashing. So no matter what > draft-josefsson-eddsa-ed25519-02 says, the hashing would have to be done > in software, and the result passed to the token for the actual signing. > > >So, unless the above is false, I'd rather not add such absolute > >statements. > > I see your point. Would leave the decision to you, in light of the above. > Because the exact purpose of pkeyutl is unclear to me, I can???t insist. > > Assuming pkeyutl does provide access to the ???complete EdDSA function??? as > specified in the draft above, one possibility is to add even more words, > and explicitly state where the digest for sure is NOT invoked (RSA, DSA, > ECDSA), and maybe where it is (EdDSA, maybe other future schemes)... > > >But please correct me if I'm wrong. > > Likewise. :-) > Well pkeyutl along with pkey and genpkey are algorithm neutral versions of rsautl, rsa, genrsa. Underneath they access the EVP_PKEY APIs so what pkeyutl does is largely governed by how those behave. So while there is some common behaviour (e.g. if a digest is specified the input will be a raw digest with length sanity checks) what happens in detail is determined by the algortihms themselves. Support for EdDSA isn't in OpenSSL yet (there are some issues to resolve in order to decide how the API will work) so how that will precisely behave is not yet defined. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From uri at ll.mit.edu Wed Jan 20 17:17:47 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 20 Jan 2016 17:17:47 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: <20160120163743.GA18335@openssl.org> References: <20160118192227.17788998.21663.45907@ll.mit.edu> <2613183.d0DnLrUqE4@pintsize.usersys.redhat.com> <4181799.NJm4JpuZrY@pintsize.usersys.redhat.com> <20160120163743.GA18335@openssl.org> Message-ID: I see. Steve, what would you suggest to add to the man page, in view of what we?ve been discussing for the last few days here? -- Regards, Uri Blumenthal On 1/20/16, 11:37 , "openssl-dev on behalf of Dr. Stephen Henson" wrote: >On Wed, Jan 20, 2016, Blumenthal, Uri - 0553 - MITLL wrote: > >> On 1/20/16, 5:10 , "Hubert Kario" wrote: >> >> It appears to me that pkeyutl is more an instrument to access those >> primitive operations, unlike dgst that provides access to the ???true??? >> (complete) signature function that includes hashing. So no matter what >> draft-josefsson-eddsa-ed25519-02 says, the hashing would have to be done >> in software, and the result passed to the token for the actual signing. >> >> >So, unless the above is false, I'd rather not add such absolute >> >statements. >> >> I see your point. Would leave the decision to you, in light of the >>above. >> Because the exact purpose of pkeyutl is unclear to me, I can???t insist. >> >> Assuming pkeyutl does provide access to the ???complete EdDSA >>function??? as >> specified in the draft above, one possibility is to add even more words, >> and explicitly state where the digest for sure is NOT invoked (RSA, DSA, >> ECDSA), and maybe where it is (EdDSA, maybe other future schemes)... >> >> >But please correct me if I'm wrong. >> >> Likewise. :-) >> > >Well pkeyutl along with pkey and genpkey are algorithm neutral versions of >rsautl, rsa, genrsa. Underneath they access the EVP_PKEY APIs so what >pkeyutl >does is largely governed by how those behave. So while there is some >common >behaviour (e.g. if a digest is specified the input will be a raw digest >with >length sanity checks) what happens in detail is determined by the >algortihms >themselves. > >Support for EdDSA isn't in OpenSSL yet (there are some issues to resolve >in >order to decide how the API will work) so how that will precisely behave >is >not yet defined. > >Steve. >-- >Dr Stephen N. Henson. OpenSSL project core developer. >Commercial tech support now available see: http://www.openssl.org >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From agostrer at gmail.com Wed Jan 20 17:28:36 2016 From: agostrer at gmail.com (Alexander Gostrer) Date: Wed, 20 Jan 2016 09:28:36 -0800 Subject: [openssl-dev] ECDH engine In-Reply-To: <20160120161132.17788998.39388.46447@ll.mit.edu> References: <20160120161132.17788998.39388.46447@ll.mit.edu> Message-ID: <91E408CB-504C-4FFE-8208-0DF2C6FD3158@gmail.com> Hi Uri, The ATECC508A is a chip. There are few USB devices built by Atmel on its base. Or you can use the chip directly over I2C (that many people like to do). You can follow the links that we posted on the ATECCX08 Engine repository WiKi to learn about the chip. Well, our first indent was to use the pksc11 library. But it didn't go to well for many reasons. I should go back for several months to collect these reasons but I think the main reason was that ATECC508A hardware is based on ECC-256 algorithms while pkcs11 is originally written for RSA - the overhead was looking too high (many ATECC508 customers are using limited hardware and want direct I2C connection to the chip). But let's talk about pkcs11. Can you point me to the set of documentation for EC-DERIVE? It may be a good time now to add the ATECC508 support to there. Regards, Alex Sent from my iPhone > On Jan 20, 2016, at 8:11 AM, Blumenthal, Uri - 0553 - MITLL wrote: > > What is this Atmel x508x? Is it a chip? Is it a token/smartcard? Is it accessible via PKCS#11 at all? Is it accessible by/via OpenSC? > > I am trying to figure why such a generic and useful set of ECC operations (Sign, Derive) is implementation-limited to one single . > > A much better solution to me would be adding EC-DERIVE to engine_pkcs11, and automatically get all the tokens covered. > > Since I'm probably? missing something, could you please educate me? > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > From: Alexander Gostrer? > Sent: Wednesday, January 20, 2016 10:47 > To: Dr. Stephen Henson > Reply To: openssl-dev at openssl.org > Cc: openssl-dev at openssl.org > Subject: Re: [openssl-dev] ECDH engine > ? > Hi Steve, > ? > And here is the ENGINE implementation for Atmel ATECC508A with few small patches to OpenSSL_1_0_2-stable: > https://github.com/AtmelCSO/cryptoauth-openssl-engine > > Your comments are welcome. > > Regards, > Alex. > >> On Sat, Dec 19, 2015 at 12:49 PM, Dr. Stephen Henson wrote: >> On Fri, Dec 18, 2015, Alexander Gostrer wrote: >> >> > Hi Steve, >> > >> > John and I completed writing an ECDH engine based on the >> > OpenSSL_1_0_2-stable branch. We were planning to expand it to the master >> > but found some major changes made by you recently. What is the status of >> > this task? Is it stable enough to follow it? Are you planning another >> > changes? Is there a design document that we can use in our work? >> > >> >> The version in master shouldn't change much any more. Documentation will be >> available in the near future. The changes were meant to remove some of the >> weird "quirks" of ECC compared to other algortihms and to permit future >> expansion to a wider range of curves. >> >> In the meantime it shouldn't be too hard to follow how the new code works. >> Instead of separate ECDH/ECDSA methods with weird locking and ex_data and >> minimal ENGINE support everything is combined into a single EC_KEY_METHOD >> which can contain ECDSA, ECDH and key generation (something which was >> impossible with the old code) and be tied directly to an ENGINE. >> >> Most of the primary APIs such as ECDH_compute_key can be redirected directly >> through an engine supplied function in EC_KEY_METHOD. >> >> Having said that the code is very new and may have the odd bug that needs to >> be fixed. If you have any problems let me know and I'll look into them. >> >> Steve. >> -- >> Dr Stephen N. Henson. OpenSSL project core developer. >> Commercial tech support now available see: http://www.openssl.org > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Wed Jan 20 17:46:14 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 20 Jan 2016 17:46:14 +0000 Subject: [openssl-dev] ECDH engine In-Reply-To: <91E408CB-504C-4FFE-8208-0DF2C6FD3158@gmail.com> References: <20160120161132.17788998.39388.46447@ll.mit.edu> <91E408CB-504C-4FFE-8208-0DF2C6FD3158@gmail.com> Message-ID: > The ATECC508A is a chip. There are few USB devices built by Atmel on its base. > Or you can use the chip directly over I2C (that many people like to do). You > can follow the links that we posted on the ATECCX08 Engine repository WiKi to > learn about the chip. I see, thanks. > Well, our first indent was to use the pksc11 library. But it didn't go to well > for many reasons. I should go back for several months to collect these reasons > but I think the main reason was that ATECC508A hardware is based on ECC-256 > algorithms while pkcs11 is originally written for RSA - the overhead was > looking too high (many ATECC508 customers are using limited hardware and want > direct I2C connection to the chip). There are a few hardware tokens (USB-pluggable), e.g. Yubikey, that support ECC256 and (in case of Yubikey 4) ECC384. > But let's talk about pkcs11. Can you point me to the set of documentation for > EC-DERIVE? It may be a good time now to add the ATECC508 support to there. Honestly, I?m more interested in adding ECDH support ? assuming that it would also serve ATECC508, rather than working on ATECC508B and hoping that perhaps it would be usable for other ECC-capable tokens. Here?s the PKCS#11 spec http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf, which covers ECDH including ECDH1_DERIVE and ECDH1_COFACTOR_DERIVE. I think older versions (like v2.20) have more content, but this is the current one. Hope it helps. P.S. At this time I?m standing by my original opinion ? that a better way is incorporating ECDH1_*DERIVE in libp11 and engine_pkcs11, rather than creating an engine specifically for one chip that add uncertainly of non-interoperability with other chips/tokens. > On Jan 20, 2016, at 8:11 AM, Blumenthal, Uri - 0553 - MITLL > wrote: > >> What is this Atmel x508x? Is it a chip? Is it a token/smartcard? Is it >> accessible via PKCS#11 at all? Is it accessible by/via OpenSC? >> >> I am trying to figure why such a generic and useful set of ECC operations >> (Sign, Derive) is implementation-limited to one single . >> >> A much better solution to me would be adding EC-DERIVE to engine_pkcs11, and >> automatically get all the tokens covered. >> >> Since I'm probably? missing something, could you please educate me? >> >> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. >> From: Alexander Gostrer? >> Sent: Wednesday, January 20, 2016 10:47 >> To: Dr. Stephen Henson >> Reply To: openssl-dev at openssl.org >> Cc: openssl-dev at openssl.org >> Subject: Re: [openssl-dev] ECDH engine >> ? >> Hi Steve, >> ? >> And here is the ENGINE implementation for Atmel ATECC508A with few small >> patches to OpenSSL_1_0_2-stable: >> https://github.com/AtmelCSO/cryptoauth-openssl-engine >> >> Your comments are welcome. >> >> Regards, >> Alex. >> >> On Sat, Dec 19, 2015 at 12:49 PM, Dr. Stephen Henson >> wrote: >>> On Fri, Dec 18, 2015, Alexander Gostrer wrote: >>> >>>> > Hi Steve, >>>> > >>>> > John and I completed writing an ECDH engine based on the >>>> > OpenSSL_1_0_2-stable branch. We were planning to expand it to the master >>>> > but found some major changes made by you recently. What is the status of >>>> > this task? Is it stable enough to follow it? Are you planning another >>>> > changes? Is there a design document that we can use in our work? >>>> > >>> >>> The version in master shouldn't change much any more. Documentation will be >>> available in the near future. The changes were meant to remove some of the >>> weird "quirks" of ECC compared to other algortihms and to permit future >>> expansion to a wider range of curves. >>> >>> In the meantime it shouldn't be too hard to follow how the new code works. >>> Instead of separate ECDH/ECDSA methods with weird locking and ex_data and >>> minimal ENGINE support everything is combined into a single EC_KEY_METHOD >>> which can contain ECDSA, ECDH and key generation (something which was >>> impossible with the old code) and be tied directly to an ENGINE. >>> >>> Most of the primary APIs such as ECDH_compute_key can be redirected directly >>> through an engine supplied function in EC_KEY_METHOD. >>> >>> Having said that the code is very new and may have the odd bug that needs to >>> be fixed. If you have any problems let me know and I'll look into them. >>> >>> Steve. >>> -- >>> Dr Stephen N. Henson. OpenSSL project core developer. >>> Commercial tech support now available see: http://www.openssl.org >> >> >>> _______________________________________________ >>> openssl-dev mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From uri at ll.mit.edu Wed Jan 20 18:02:18 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 20 Jan 2016 18:02:18 +0000 Subject: [openssl-dev] ECDH engine Message-ID: <20160120180227.17788998.72846.46496@ll.mit.edu> I forgot to add that ?OpenSSL-1_0-2-stable with the current (Github master) engine-pkcs11, libp11, and OpenSC successfully does ECDSA with keys on the token (tested for ECC256 and ECC384). OpenSC tools successfully derive (i.e., implement ECDH1_DERIVE). I'm waiting for libp11 and engine_pkcs11 to add this capability. Ideally this is where your code would plug in, and complete the circle. As it currently is, a separate Atmel-specific ECC-specific engine is of a limited usefulness. Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. From: Blumenthal, Uri - 0553 - MITLL Sent: Wednesday, January 20, 2016 12:46 To: openssl-dev at openssl.org Reply To: openssl-dev at openssl.org Subject: Re: [openssl-dev] ECDH engine The ATECC508A is a chip. There are few USB devices built by Atmel on its base. Or you can use the chip directly over I2C (that many people like to do). You can follow the links that we posted on the ATECCX08 Engine repository WiKi to learn about the chip.? I see, thanks. Well, our first indent was to use the pksc11 library. But it didn't go to well for many reasons. I should go back for several months to collect these reasons but I think the main reason was that ATECC508A hardware is based on ECC-256 algorithms while pkcs11 is originally written for RSA - the overhead was looking too high (many ATECC508 customers are using limited hardware and want direct I2C connection to the chip).? There are a few hardware tokens (USB-pluggable), e.g. Yubikey, that support ECC256 and (in case of Yubikey 4) ECC384. But let's talk about pkcs11. Can you point me to the set of documentation for EC-DERIVE? It may be a good time now to add the ATECC508 support to there. Honestly, I?m more interested in adding ECDH support ? assuming that it would also serve ATECC508, rather than working on ATECC508B and hoping that perhaps it would be usable for other ECC-capable tokens. Here?s the PKCS#11 spec?http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf, which covers ECDH including ECDH1_DERIVE and ECDH1_COFACTOR_DERIVE. I think older versions (like v2.20) have more content, but this is the current one. Hope it helps. P.S. At this time I?m standing by my original opinion ? that a better way is incorporating ECDH1_*DERIVE in libp11 and engine_pkcs11, rather than creating an engine specifically for one chip that add uncertainly of non-interoperability with other chips/tokens. On Jan 20, 2016, at 8:11 AM, Blumenthal, Uri - 0553 - MITLL wrote: What is this Atmel x508x? Is it a chip? Is it a token/smartcard? Is it accessible via PKCS#11 at all? Is it accessible by/via OpenSC? I am trying to figure why such a generic and useful set of ECC operations (Sign, Derive) is implementation-limited to one single .? A much better solution to me would be adding EC-DERIVE to engine_pkcs11, and automatically get all the tokens covered. Since I'm probably? missing something, could you please educate me? Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. From: Alexander Gostrer? Sent: Wednesday, January 20, 2016 10:47 To: Dr. Stephen Henson Reply To: openssl-dev at openssl.org Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] ECDH engine ? Hi Steve, ? And here is the ENGINE implementation for Atmel ATECC508A with few small patches to OpenSSL_1_0_2-stable: https://github.com/AtmelCSO/cryptoauth-openssl-engine Your comments are welcome. Regards, Alex. On Sat, Dec 19, 2015 at 12:49 PM, Dr. Stephen Henson wrote: On Fri, Dec 18, 2015, Alexander Gostrer wrote: > Hi Steve, > > John and I completed writing an ECDH engine based on the > OpenSSL_1_0_2-stable branch. We were planning to expand it to the master > but found some major changes made by you recently. What is the status of > this task? Is it stable enough to follow it? Are you planning another > changes? Is there a design document that we can use in our work? > The version in master shouldn't change much any more. Documentation will be available in the near future. The changes were meant to remove some of the weird "quirks" of ECC compared to other algortihms and to permit future expansion to a wider range of curves. In the meantime it shouldn't be too hard to follow how the new code works. Instead of separate ECDH/ECDSA methods with weird locking and ex_data and minimal ENGINE support everything is combined into a single EC_KEY_METHOD which can contain ECDSA, ECDH and key generation (something which was impossible with the old code) and be tied directly to an ENGINE. Most of the primary APIs such as ECDH_compute_key can be redirected directly through an engine supplied function in EC_KEY_METHOD. Having said that the code is very new and may have the odd bug that needs to be fixed. If you have any problems let me know and I'll look into them. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From doctor at doctor.nl2k.ab.ca Wed Jan 20 18:05:58 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 20 Jan 2016 11:05:58 -0700 Subject: [openssl-dev] Openssl 1.1 and Bind 9.6 ESV R11 In-Reply-To: <569EF6BD.9000804@akamai.com> References: <20160119233724.GA9102@doctor.nl2k.ab.ca> <569EF6BD.9000804@akamai.com> Message-ID: <20160120180558.GB13198@doctor.nl2k.ab.ca> On Tue, Jan 19, 2016 at 08:53:49PM -0600, Benjamin Kaduk wrote: > On 01/19/2016 05:37 PM, The Doctor wrote: > > Tried to compile an old bind and ran into > > Why? > > > What needs to be adjusted? > > > > > > The bind code is what needs to be adjusted, given that openssl 1.1 is > intentionally introducing API changes and removing direct access to many > structures. It seems quite unlikely that an EoL version of a > third-party software is going to magically receive a new release > allowing it to build against a version of openssl that did not exist > when it was released. That's my issue. I cannot get a more recent bind version to stay to stable on one box. > > -Ben > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From doctor at doctor.nl2k.ab.ca Wed Jan 20 18:04:47 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 20 Jan 2016 11:04:47 -0700 Subject: [openssl-dev] Openssl 1.1 and Bind 9.6 ESV R11 In-Reply-To: References: <20160119233724.GA9102@doctor.nl2k.ab.ca> Message-ID: <20160120180447.GA13198@doctor.nl2k.ab.ca> On Wed, Jan 20, 2016 at 02:43:48AM +0000, Salz, Rich wrote: > > > static BIGNUM bn2, bn768, bn1024, bn1536; > > The BIGNUM structure is now opaque. These must be pointers. > > > BN_init(&bn2); > > BN_new() > > > BN_init(&bn768); > > BN_init(&bn1024); > > BN_init(&bn1536); > > BN_set_word(&bn2, 2); > > BN_fromhex(&bn768, PRIME768); > > BN_fromhex(&bn1024, PRIME1024); > > BN_fromhex(&bn1536, PRIME1536); > > Pointers. > Fun to reprogramme. > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From rsalz at akamai.com Wed Jan 20 18:11:16 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 20 Jan 2016 18:11:16 +0000 Subject: [openssl-dev] Openssl 1.1 and Bind 9.6 ESV R11 In-Reply-To: <20160120180558.GB13198@doctor.nl2k.ab.ca> References: <20160119233724.GA9102@doctor.nl2k.ab.ca> <569EF6BD.9000804@akamai.com> <20160120180558.GB13198@doctor.nl2k.ab.ca> Message-ID: <79e519af478e4b32abe06f2f65480c42@usma1ex-dag1mb1.msg.corp.akamai.com> > That's my issue. I cannot get a more recent bind version to stay to stable on > one box. Then I think that's going to be a tough issue, and you'll either have to modify that source or stay at 1.0.2 From openssl-users at dukhovni.org Wed Jan 20 18:20:07 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 20 Jan 2016 18:20:07 +0000 Subject: [openssl-dev] Openssl 1.1 and Bind 9.6 ESV R11 In-Reply-To: <20160120180558.GB13198@doctor.nl2k.ab.ca> References: <20160119233724.GA9102@doctor.nl2k.ab.ca> <569EF6BD.9000804@akamai.com> <20160120180558.GB13198@doctor.nl2k.ab.ca> Message-ID: <20160120182007.GU646@mournblade.imrryr.org> On Wed, Jan 20, 2016 at 11:05:58AM -0700, The Doctor wrote: > > The bind code is what needs to be adjusted, given that openssl 1.1 is > > intentionally introducing API changes and removing direct access to many > > structures. It seems quite unlikely that an EoL version of a > > third-party software is going to magically receive a new release > > allowing it to build against a version of openssl that did not exist > > when it was released. > > That's my issue. I cannot get a more recent bind version to stay > to stable on one box. Bind 9.10 works fine for me, but I use it only as an authoritative server. My recursive resolver is "unbound". And I make sure to build both without GOST support. If BIND is not reliable enough for you, consider some combination "unbound" and/or "nsd". -- Viktor. From deengert at gmail.com Wed Jan 20 18:59:36 2016 From: deengert at gmail.com (Douglas E Engert) Date: Wed, 20 Jan 2016 12:59:36 -0600 Subject: [openssl-dev] ECDH engine In-Reply-To: <20160120180227.17788998.72846.46496@ll.mit.edu> References: <20160120180227.17788998.72846.46496@ll.mit.edu> Message-ID: <569FD918.5060204@gmail.com> An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Wed Jan 20 19:10:05 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 20 Jan 2016 19:10:05 +0000 Subject: [openssl-dev] ECDH engine Message-ID: <20160120191014.17788998.97457.46531@ll.mit.edu> Are you saying it won't work on OpenSSL_1_0_2-stable?! Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. From: Douglas E Engert Sent: Wednesday, January 20, 2016 14:07 To: openssl-dev at openssl.org Reply To: openssl-dev at openssl.org Subject: Re: [openssl-dev] ECDH engine Patches are underdevelopment for OpenSC's libp11 and engine_pkcs11 to support ECDH. There are waiting for OpenSSL-1.1 to be come stable and some minor bug? fixes. Testing is proceeding using OpenSSL-1.1-pre2 today.? OpenSSL-1.1 is needed because it exposes the functions needed to use ECDH from an external engine i.e.? the OPenSC engine_pkcs11. ? ? https://github.com/OpenSC/libp11/issues/52 ? https://github.com/dengert/libp11/tree/prep-openssl-1.1 ? https://github.com/dengert/engine_pkcs11/tree/prep-openssl-1.1 In addition to a major rewrite of combining the ECDSA_METHOD and ECDH_METHOD into an C_KEY_METHOD, OpenSSL-1.1? introduces a lot of changes, mainly because it hides many of the structures that have been exposed in the past. This causes a major rewrite of code to use functions to access these structures.? Although OpenSC could still use an older version of OpenSSL, there is also underway changes for OpenSC to use OpenSSL-1.1: https://github.com/OpenSC/OpenSC/pull/654 https://github.com/dengert/OpenSC/tree/prep-openssl-1.1 On 1/20/2016 12:02 PM, Blumenthal, Uri - 0553 - MITLL wrote: I forgot to add that ?OpenSSL-1_0-2-stable with the current (Github master) engine-pkcs11, libp11, and OpenSC successfully does ECDSA with keys on the token (tested for ECC256 and ECC384). OpenSC tools successfully derive (i.e., implement ECDH1_DERIVE). I'm waiting for libp11 and engine_pkcs11 to add this capability. ? Ideally this is where your code would plug in, and complete the circle. As it currently is, a separate Atmel-specific ECC-specific engine is of a limited usefulness. Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. From: Blumenthal, Uri - 0553 - MITLL Sent: Wednesday, January 20, 2016 12:46 To: openssl-dev at openssl.org Reply To: openssl-dev at openssl.org Subject: Re: [openssl-dev] ECDH engine The ATECC508A is a chip. There are few USB devices built by Atmel on its base. Or you can use the chip directly over I2C (that many people like to do). You can follow the links that we posted on the ATECCX08 Engine repository WiKi to learn about the chip.? I see, thanks. Well, our first indent was to use the pksc11 library. But it didn't go to well for many reasons. I should go back for several months to collect these reasons but I think the main reason was that ATECC508A hardware is based on ECC-256 algorithms while pkcs11 is originally written for RSA - the overhead was looking too high (many ATECC508 customers are using limited hardware and want direct I2C connection to the chip).? There are a few hardware tokens (USB-pluggable), e.g. Yubikey, that support ECC256 and (in case of Yubikey 4) ECC384. But let's talk about pkcs11. Can you point me to the set of documentation for EC-DERIVE? It may be a good time now to add the ATECC508 support to there. Honestly, I?m more interested in adding ECDH support ? assuming that it would also serve ATECC508, rather than working on ATECC508B and hoping that perhaps it would be usable for other ECC-capable tokens. Here?s the PKCS#11 spec?http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf, which covers ECDH including ECDH1_DERIVE and ECDH1_COFACTOR_DERIVE. I think older versions (like v2.20) have more content, but this is the current one. Hope it helps. P.S. At this time I?m standing by my original opinion ? that a better way is incorporating ECDH1_*DERIVE in libp11 and engine_pkcs11, rather than creating an engine specifically for one chip that add uncertainly of non-interoperability with other chips/tokens. On Jan 20, 2016, at 8:11 AM, Blumenthal, Uri - 0553 - MITLL wrote: What is this Atmel x508x? Is it a chip? Is it a token/smartcard? Is it accessible via PKCS#11 at all? Is it accessible by/via OpenSC? I am trying to figure why such a generic and useful set of ECC operations (Sign, Derive) is implementation-limited to one single .? A much better solution to me would be adding EC-DERIVE to engine_pkcs11, and automatically get all the tokens covered. Since I'm probably? missing something, could you please educate me? Sent?from?my?BlackBerry?10?smartphone?on the?Verizon?Wireless?4G?LTE?network. From: Alexander Gostrer? Sent: Wednesday, January 20, 2016 10:47 To: Dr. Stephen Henson Reply To: openssl-dev at openssl.org Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] ECDH engine ? Hi Steve, ? And here is the ENGINE implementation for Atmel ATECC508A with few small patches to OpenSSL_1_0_2-stable: https://github.com/AtmelCSO/cryptoauth-openssl-engine Your comments are welcome. Regards, Alex. On Sat, Dec 19, 2015 at 12:49 PM, Dr. Stephen Henson wrote: On Fri, Dec 18, 2015, Alexander Gostrer wrote: > Hi Steve, > > John and I completed writing an ECDH engine based on the > OpenSSL_1_0_2-stable branch. We were planning to expand it to the master > but found some major changes made by you recently. What is the status of > this task? Is it stable enough to follow it? Are you planning another > changes? Is there a design document that we can use in our work? > The version in master shouldn't change much any more. Documentation will be available in the near future. The changes were meant to remove some of the weird "quirks" of ECC compared to other algortihms and to permit future expansion to a wider range of curves. In the meantime it shouldn't be too hard to follow how the new code works. Instead of separate ECDH/ECDSA methods with weird locking and ex_data and minimal ENGINE support everything is combined into a single EC_KEY_METHOD which can contain ECDSA, ECDH and key generation (something which was impossible with the old code) and be tied directly to an ENGINE. Most of the primary APIs such as ECDH_compute_key can be redirected directly through an engine supplied function in EC_KEY_METHOD. Having said that the code is very new and may have the odd bug that needs to be fixed. If you have any problems let me know and I'll look into them. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Douglas E. Engert -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From agostrer at gmail.com Wed Jan 20 19:17:09 2016 From: agostrer at gmail.com (Alexander Gostrer) Date: Wed, 20 Jan 2016 11:17:09 -0800 Subject: [openssl-dev] ECDH engine In-Reply-To: References: <20160120161132.17788998.39388.46447@ll.mit.edu> <91E408CB-504C-4FFE-8208-0DF2C6FD3158@gmail.com> Message-ID: On Wed, Jan 20, 2016 at 9:46 AM, Blumenthal, Uri - 0553 - MITLL < uri at ll.mit.edu> wrote: > The ATECC508A is a chip. There are few USB devices built by Atmel on its > base. Or you can use the chip directly over I2C (that many people like to > do). You can follow the links that we posted on the ATECCX08 Engine > repository WiKi to learn about the chip. > > > I see, thanks. > Direct link: https://github.com/AtmelCSO/cryptoauth-openssl-engine/wiki > > Well, our first indent was to use the pksc11 library. But it didn't go to > well for many reasons. I should go back for several months to collect these > reasons but I think the main reason was that ATECC508A hardware is based on > ECC-256 algorithms while pkcs11 is originally written for RSA - the > overhead was looking too high (many ATECC508 customers are using limited > hardware and want direct I2C connection to the chip). > > > There are a few hardware tokens (USB-pluggable), e.g. Yubikey, that > support ECC256 and (in case of Yubikey 4) ECC384. > Thanks > > But let's talk about pkcs11. Can you point me to the set of documentation > for EC-DERIVE? It may be a good time now to add the ATECC508 support to > there. > > > Honestly, I?m more interested in adding ECDH support ? assuming that it > would also serve ATECC508, rather than working on ATECC508B and hoping that > perhaps it would be usable for other ECC-capable tokens. > Check our patches here: https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches. It is non-official openssl patches and probably will never go into but they are enabling ECDH enginee in stable-1.0.2. Limited use of course. > > Here?s the PKCS#11 spec > http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf, > which covers ECDH including ECDH1_DERIVE and ECDH1_COFACTOR_DERIVE. I > think older versions (like v2.20) have more content, but this is the > current one. > > Hope it helps. > > P.S. At this time I?m standing by my original opinion ? that a better way > is incorporating ECDH1_*DERIVE in libp11 and engine_pkcs11, rather than > creating an engine specifically for one chip that add uncertainly of > non-interoperability with other chips/tokens. > I see your point. We'll look into it Thank you, Alex. > > > On Jan 20, 2016, at 8:11 AM, Blumenthal, Uri - 0553 - MITLL < > uri at ll.mit.edu> wrote: > > What is this Atmel x508x? Is it a chip? Is it a token/smartcard? Is it > accessible via PKCS#11 at all? Is it accessible by/via OpenSC? > > I am trying to figure why such a generic and useful set of ECC operations > (Sign, Derive) is implementation-limited to one single . > > A much better solution to me would be adding EC-DERIVE to engine_pkcs11, > and automatically get all the tokens covered. > > Since I'm probably? missing something, could you please educate me? > > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > *From: *Alexander Gostrer? > *Sent: *Wednesday, January 20, 2016 10:47 > *To: *Dr. Stephen Henson > *Reply To: *openssl-dev at openssl.org > *Cc: *openssl-dev at openssl.org > *Subject: *Re: [openssl-dev] ECDH engine > ? > Hi Steve, > ? > And here is the ENGINE implementation for Atmel ATECC508A with few small > patches to OpenSSL_1_0_2-stable: > https://github.com/AtmelCSO/cryptoauth-openssl-engine > > Your comments are welcome. > > Regards, > Alex. > > On Sat, Dec 19, 2015 at 12:49 PM, Dr. Stephen Henson > wrote: > >> On Fri, Dec 18, 2015, Alexander Gostrer wrote: >> >> > Hi Steve, >> > >> > John and I completed writing an ECDH engine based on the >> > OpenSSL_1_0_2-stable branch. We were planning to expand it to the master >> > but found some major changes made by you recently. What is the status of >> > this task? Is it stable enough to follow it? Are you planning another >> > changes? Is there a design document that we can use in our work? >> > >> >> The version in master shouldn't change much any more. Documentation will >> be >> available in the near future. The changes were meant to remove some of the >> weird "quirks" of ECC compared to other algortihms and to permit future >> expansion to a wider range of curves. >> >> In the meantime it shouldn't be too hard to follow how the new code works. >> Instead of separate ECDH/ECDSA methods with weird locking and ex_data and >> minimal ENGINE support everything is combined into a single EC_KEY_METHOD >> which can contain ECDSA, ECDH and key generation (something which was >> impossible with the old code) and be tied directly to an ENGINE. >> >> Most of the primary APIs such as ECDH_compute_key can be redirected >> directly >> through an engine supplied function in EC_KEY_METHOD. >> >> Having said that the code is very new and may have the odd bug that needs >> to >> be fixed. If you have any problems let me know and I'll look into them. >> >> Steve. >> -- >> Dr Stephen N. Henson. OpenSSL project core developer. >> Commercial tech support now available see: http://www.openssl.org >> > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From agostrer at gmail.com Wed Jan 20 19:19:17 2016 From: agostrer at gmail.com (Alexander Gostrer) Date: Wed, 20 Jan 2016 11:19:17 -0800 Subject: [openssl-dev] ECDH engine In-Reply-To: <20160120191014.17788998.97457.46531@ll.mit.edu> References: <20160120191014.17788998.97457.46531@ll.mit.edu> Message-ID: Probably it was one of the main reasons why we didn't use pkcs11 for ATECC508A and wrote an engine instead Regards, Alex. On Wed, Jan 20, 2016 at 11:10 AM, Blumenthal, Uri - 0553 - MITLL < uri at ll.mit.edu> wrote: > Are you saying it won't work on OpenSSL_1_0_2-stable?! > > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > *From: *Douglas E Engert > *Sent: *Wednesday, January 20, 2016 14:07 > *To: *openssl-dev at openssl.org > *Reply To: *openssl-dev at openssl.org > *Subject: *Re: [openssl-dev] ECDH engine > > Patches are underdevelopment for OpenSC's libp11 and engine_pkcs11 to > support ECDH. There are waiting for OpenSSL-1.1 to be come stable > and some minor bug fixes. Testing is proceeding using OpenSSL-1.1-pre2 > today. OpenSSL-1.1 is needed because it exposes the functions needed > to use ECDH from an external engine i.e. the OPenSC engine_pkcs11. > ? > https://github.com/OpenSC/libp11/issues/52 > https://github.com/dengert/libp11/tree/prep-openssl-1.1 > https://github.com/dengert/engine_pkcs11/tree/prep-openssl-1.1 > > In addition to a major rewrite of combining the ECDSA_METHOD and > ECDH_METHOD into an C_KEY_METHOD, OpenSSL-1.1 introduces a lot of changes, > mainly because it hides many of the structures that have been exposed in > the past. This causes a major rewrite of code to use functions to access > these structures. > > Although OpenSC could still use an older version of OpenSSL, there is also > underway changes for OpenSC to use OpenSSL-1.1: > https://github.com/OpenSC/OpenSC/pull/654 > https://github.com/dengert/OpenSC/tree/prep-openssl-1.1 > > > On 1/20/2016 12:02 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > I forgot to add that ?OpenSSL-1_0-2-stable with the current (Github > master) engine-pkcs11, libp11, and OpenSC successfully does ECDSA with keys > on the token (tested for ECC256 and ECC384). > > OpenSC tools successfully derive (i.e., implement ECDH1_DERIVE). I'm > waiting for libp11 and engine_pkcs11 to add this capability. > ? > Ideally this is where your code would plug in, and complete the circle. > > As it currently is, a separate Atmel-specific ECC-specific engine is of a > limited usefulness. > > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > *From: *Blumenthal, Uri - 0553 - MITLL > *Sent: *Wednesday, January 20, 2016 12:46 > *To: *openssl-dev at openssl.org > *Reply To: *openssl-dev at openssl.org > *Subject: *Re: [openssl-dev] ECDH engine > > The ATECC508A is a chip. There are few USB devices built by Atmel on its > base. Or you can use the chip directly over I2C (that many people like to > do). You can follow the links that we posted on the ATECCX08 Engine > repository WiKi to learn about the chip. > > > I see, thanks. > > Well, our first indent was to use the pksc11 library. But it didn't go to > well for many reasons. I should go back for several months to collect these > reasons but I think the main reason was that ATECC508A hardware is based on > ECC-256 algorithms while pkcs11 is originally written for RSA - the > overhead was looking too high (many ATECC508 customers are using limited > hardware and want direct I2C connection to the chip). > > > There are a few hardware tokens (USB-pluggable), e.g. Yubikey, that > support ECC256 and (in case of Yubikey 4) ECC384. > > But let's talk about pkcs11. Can you point me to the set of documentation > for EC-DERIVE? It may be a good time now to add the ATECC508 support to > there. > > > Honestly, I?m more interested in adding ECDH support ? assuming that it > would also serve ATECC508, rather than working on ATECC508B and hoping that > perhaps it would be usable for other ECC-capable tokens. > > Here?s the PKCS#11 spec > http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf, > which covers ECDH including ECDH1_DERIVE and ECDH1_COFACTOR_DERIVE. I > think older versions (like v2.20) have more content, but this is the > current one. > > Hope it helps. > > P.S. At this time I?m standing by my original opinion ? that a better way > is incorporating ECDH1_*DERIVE in libp11 and engine_pkcs11, rather than > creating an engine specifically for one chip that add uncertainly of > non-interoperability with other chips/tokens. > > > On Jan 20, 2016, at 8:11 AM, Blumenthal, Uri - 0553 - MITLL < > uri at ll.mit.edu> wrote: > > What is this Atmel x508x? Is it a chip? Is it a token/smartcard? Is it > accessible via PKCS#11 at all? Is it accessible by/via OpenSC? > > I am trying to figure why such a generic and useful set of ECC operations > (Sign, Derive) is implementation-limited to one single . > > A much better solution to me would be adding EC-DERIVE to engine_pkcs11, > and automatically get all the tokens covered. > > Since I'm probably? missing something, could you please educate me? > > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > *From: *Alexander Gostrer? > *Sent: *Wednesday, January 20, 2016 10:47 > *To: *Dr. Stephen Henson > *Reply To: * openssl-dev at openssl.org > *Cc: *openssl-dev at openssl.org > *Subject: *Re: [openssl-dev] ECDH engine > ? > Hi Steve, > ? > And here is the ENGINE implementation for Atmel ATECC508A with few small > patches to OpenSSL_1_0_2-stable: > https://github.com/AtmelCSO/cryptoauth-openssl-engine > > Your comments are welcome. > > Regards, > Alex. > > On Sat, Dec 19, 2015 at 12:49 PM, Dr. Stephen Henson > wrote: > >> On Fri, Dec 18, 2015, Alexander Gostrer wrote: >> >> > Hi Steve, >> > >> > John and I completed writing an ECDH engine based on the >> > OpenSSL_1_0_2-stable branch. We were planning to expand it to the master >> > but found some major changes made by you recently. What is the status of >> > this task? Is it stable enough to follow it? Are you planning another >> > changes? Is there a design document that we can use in our work? >> > >> >> The version in master shouldn't change much any more. Documentation will >> be >> available in the near future. The changes were meant to remove some of the >> weird "quirks" of ECC compared to other algortihms and to permit future >> expansion to a wider range of curves. >> >> In the meantime it shouldn't be too hard to follow how the new code works. >> Instead of separate ECDH/ECDSA methods with weird locking and ex_data and >> minimal ENGINE support everything is combined into a single EC_KEY_METHOD >> which can contain ECDSA, ECDH and key generation (something which was >> impossible with the old code) and be tied directly to an ENGINE. >> >> Most of the primary APIs such as ECDH_compute_key can be redirected >> directly >> through an engine supplied function in EC_KEY_METHOD. >> >> Having said that the code is very new and may have the odd bug that needs >> to >> be fixed. If you have any problems let me know and I'll look into them. >> >> Steve. >> -- >> Dr Stephen N. Henson. OpenSSL project core developer. >> Commercial tech support now available see: http://www.openssl.org >> > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > -- > > Douglas E. Engert > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Wed Jan 20 19:34:07 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 20 Jan 2016 19:34:07 +0000 Subject: [openssl-dev] ECDH engine In-Reply-To: References: <20160120191014.17788998.97457.46531@ll.mit.edu> Message-ID: > Probably it was one of the main reasons why we didn't use pkcs11 for ATECC508A > and wrote an engine instead I still argue with the approach (IMHO nobody needs yet another limited engine), but constraining ECC additions to 1.1 does not make any sense to me. 1.0.2 is going to be around for a quite a while. A lot of applications won?t migrate to 1.1 quickly ? a few years would be a good/reasonable/safe bet. To restrict this work to 1.1 means pushing this basic capability off by (realistically) several years. Most people can?t/won't deploy openssl-1.1 as long as it interferes with the majority of the applications they or their OS is using, is not good. I for one won?t be able to use 1.1 in practice until it becomes the embraced standard and software such as Macports port set is moved to support it. I?m 100% sure there are many more of us in this bus, on different OS (e.g., it looks like Ubuntu is even worse off than Macports). > On Wed, Jan 20, 2016 at 11:10 AM, Blumenthal, Uri - 0553 - MITLL > wrote: >> Are you saying it won't work on OpenSSL_1_0_2-stable?! >> >> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. >> From: Douglas E Engert >> Sent: Wednesday, January 20, 2016 14:07 >> To: openssl-dev at openssl.org >> Reply To: openssl-dev at openssl.org >> Subject: Re: [openssl-dev] ECDH engine >> >> Patches are underdevelopment for OpenSC's libp11 and engine_pkcs11 to support >> ECDH. There are waiting for OpenSSL-1.1 to be come stable >> and some minor bug fixes. Testing is proceeding using OpenSSL-1.1-pre2 >> today. OpenSSL-1.1 is needed because it exposes the functions needed >> to use ECDH from an external engine i.e. the OPenSC engine_pkcs11. >> ? >> https://github.com/OpenSC/libp11/issues/52 >> https://github.com/dengert/libp11/tree/prep-openssl-1.1 >> https://github.com/dengert/engine_pkcs11/tree/prep-openssl-1.1 >> >> In addition to a major rewrite of combining the ECDSA_METHOD and ECDH_METHOD >> into an C_KEY_METHOD, OpenSSL-1.1 introduces a lot of changes, >> mainly because it hides many of the structures that have been exposed in the >> past. This causes a major rewrite of code to use functions to access these >> structures. >> >> Although OpenSC could still use an older version of OpenSSL, there is also >> underway changes for OpenSC to use OpenSSL-1.1: >> https://github.com/OpenSC/OpenSC/pull/654 >> https://github.com/dengert/OpenSC/tree/prep-openssl-1.1 >> >> >> On 1/20/2016 12:02 PM, Blumenthal, Uri - 0553 - MITLL wrote: >>> I forgot to add that ?OpenSSL-1_0-2-stable with the current (Github master) >>> engine-pkcs11, libp11, and OpenSC successfully does ECDSA with keys on the >>> token (tested for ECC256 and ECC384). >>> >>> OpenSC tools successfully derive (i.e., implement ECDH1_DERIVE). I'm waiting >>> for libp11 and engine_pkcs11 to add this capability. >>> ? >>> Ideally this is where your code would plug in, and complete the circle. >>> >>> As it currently is, a separate Atmel-specific ECC-specific engine is of a >>> limited usefulness. >>> >>> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE >>> network. >>> From: Blumenthal, Uri - 0553 - MITLL >>> Sent: Wednesday, January 20, 2016 12:46 >>> To: openssl-dev at openssl.org >>> Reply To: openssl-dev at openssl.org >>> Subject: Re: [openssl-dev] ECDH engine >>> >>>> The ATECC508A is a chip. There are few USB devices built by Atmel on its >>>> base. Or you can use the chip directly over I2C (that many people like to >>>> do). You can follow the links that we posted on the ATECCX08 Engine >>>> repository WiKi to learn about the chip. >>> >>> I see, thanks. >>> >>>> Well, our first indent was to use the pksc11 library. But it didn't go to >>>> well for many reasons. I should go back for several months to collect these >>>> reasons but I think the main reason was that ATECC508A hardware is based on >>>> ECC-256 algorithms while pkcs11 is originally written for RSA - the >>>> overhead was looking too high (many ATECC508 customers are using limited >>>> hardware and want direct I2C connection to the chip). >>> >>> There are a few hardware tokens (USB-pluggable), e.g. Yubikey, that support >>> ECC256 and (in case of Yubikey 4) ECC384. >>> >>>> But let's talk about pkcs11. Can you point me to the set of documentation >>>> for EC-DERIVE? It may be a good time now to add the ATECC508 support to >>>> there. >>> >>> Honestly, I?m more interested in adding ECDH support ? assuming that it >>> would also serve ATECC508, rather than working on ATECC508B and hoping that >>> perhaps it would be usable for other ECC-capable tokens. >>> >>> Here?s the PKCS#11 spec >>> http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf, >>> which covers ECDH including ECDH1_DERIVE and ECDH1_COFACTOR_DERIVE. I think >>> older versions (like v2.20) have more content, but this is the current one. >>> >>> Hope it helps. >>> >>> P.S. At this time I?m standing by my original opinion ? that a better way is >>> incorporating ECDH1_*DERIVE in libp11 and engine_pkcs11, rather than >>> creating an engine specifically for one chip that add uncertainly of >>> non-interoperability with other chips/tokens. >>> >>> >>>> On Jan 20, 2016, at 8:11 AM, Blumenthal, Uri - 0553 - MITLL >>>> wrote: >>>> >>>>> What is this Atmel x508x? Is it a chip? Is it a token/smartcard? Is it >>>>> accessible via PKCS#11 at all? Is it accessible by/via OpenSC? >>>>> >>>>> I am trying to figure why such a generic and useful set of ECC operations >>>>> (Sign, Derive) is implementation-limited to one single . >>>>> >>>>> A much better solution to me would be adding EC-DERIVE to engine_pkcs11, >>>>> and automatically get all the tokens covered. >>>>> >>>>> Since I'm probably? missing something, could you please educate me? >>>>> >>>>> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE >>>>> network. >>>>> From: Alexander Gostrer? >>>>> Sent: Wednesday, January 20, 2016 10:47 >>>>> To: Dr. Stephen Henson >>>>> Reply To: openssl-dev at openssl.org >>>>> Cc: openssl-dev at openssl.org >>>>> Subject: Re: [openssl-dev] ECDH engine >>>>> ? >>>>> Hi Steve, >>>>> ? >>>>> And here is the ENGINE implementation for Atmel ATECC508A with few small >>>>> patches to OpenSSL_1_0_2-stable: >>>>> https://github.com/AtmelCSO/cryptoauth-openssl-engine >>>>> >>>>> Your comments are welcome. >>>>> >>>>> Regards, >>>>> Alex. >>>>> >>>>> On Sat, Dec 19, 2015 at 12:49 PM, Dr. Stephen Henson >>>>> wrote: >>>>>> On Fri, Dec 18, 2015, Alexander Gostrer wrote: >>>>>> >>>>>>> > Hi Steve, >>>>>>> > >>>>>>> > John and I completed writing an ECDH engine based on the >>>>>>> > OpenSSL_1_0_2-stable branch. We were planning to expand it to the >>>>>>> master >>>>>>> > but found some major changes made by you recently. What is the status >>>>>>> of >>>>>>> > this task? Is it stable enough to follow it? Are you planning another >>>>>>> > changes? Is there a design document that we can use in our work? >>>>>>> > >>>>>> >>>>>> The version in master shouldn't change much any more. Documentation will >>>>>> be >>>>>> available in the near future. The changes were meant to remove some of >>>>>> the >>>>>> weird "quirks" of ECC compared to other algortihms and to permit future >>>>>> expansion to a wider range of curves. >>>>>> >>>>>> In the meantime it shouldn't be too hard to follow how the new code >>>>>> works. >>>>>> Instead of separate ECDH/ECDSA methods with weird locking and ex_data and >>>>>> minimal ENGINE support everything is combined into a single EC_KEY_METHOD >>>>>> which can contain ECDSA, ECDH and key generation (something which was >>>>>> impossible with the old code) and be tied directly to an ENGINE. >>>>>> >>>>>> Most of the primary APIs such as ECDH_compute_key can be redirected >>>>>> directly >>>>>> through an engine supplied function in EC_KEY_METHOD. >>>>>> >>>>>> Having said that the code is very new and may have the odd bug that needs >>>>>> to >>>>>> be fixed. If you have any problems let me know and I'll look into them. >>>>>> >>>>>> Steve. >>>>>> -- >>>>>> Dr Stephen N. Henson. OpenSSL project core developer. >>>>>> Commercial tech support now available see: http://www.openssl.org >>>>> >>>>> >>>>>> _______________________________________________ >>>>>> openssl-dev mailing list >>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >>> >>> >>> >>> _______________________________________________ >>> openssl-dev mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >>> >>> -- >>> >>> Douglas E. Engert >>> >>> >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From deengert at gmail.com Wed Jan 20 19:41:36 2016 From: deengert at gmail.com (Douglas E Engert) Date: Wed, 20 Jan 2016 13:41:36 -0600 Subject: [openssl-dev] ECDH engine In-Reply-To: <20160120191014.17788998.97457.46531@ll.mit.edu> References: <20160120191014.17788998.97457.46531@ll.mit.edu> Message-ID: <569FE2F0.7090205@gmail.com> An HTML attachment was scrubbed... URL: From deengert at gmail.com Wed Jan 20 19:51:12 2016 From: deengert at gmail.com (Douglas E Engert) Date: Wed, 20 Jan 2016 13:51:12 -0600 Subject: [openssl-dev] ECDH engine In-Reply-To: References: <20160120191014.17788998.97457.46531@ll.mit.edu> Message-ID: <569FE530.4050603@gmail.com> An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Jan 20 20:07:04 2016 From: rt at openssl.org (Markus Wernig via RT) Date: Wed, 20 Jan 2016 20:07:04 +0000 Subject: [openssl-dev] [openssl.org #4258] bug: s_client -connect option fails on IPv6 addresses In-Reply-To: <569FA389.2040902@wernig.net> References: <569FA389.2040902@wernig.net> Message-ID: Hi all When an IPv6 address:port tuple is given to s_client's -connect option, the internal parsing of the address/port seems to fail. The port is taken to be a part of the IP address, and the IP address is shortened by the first 2 bytes: # openssl s_client -connect 2a00:c38:10a::1:0:71:443 getservbyname failure for c38:10a::1:0:71:443 Leaving the port empty, results in the same error: openssl s_client -connect 2a00:c38:10a::1:0:71 getservbyname failure for c38:10a::1:0:71 Verified with OpenSSL 1.0.2e 3 Dec 2015 (Gentoo) and OpenSSL 1.0.1f 6 Jan 2014 (Ubuntu). Both systems do have IPv6 connectivity. Kind regards /markus -- Markus Wernig Unix/Network Security Engineer PGP: 8E82E4DC SIP/XMPP: markus at wernig.net Furch D25-SR Cut - Ovation CE C2078AX-5 ----------------------------------------- http://xfer.ch - http://markus.wernig.net ----------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4100 bytes Desc: not available URL: From rt at openssl.org Wed Jan 20 20:07:04 2016 From: rt at openssl.org (Highland, Glenn via RT) Date: Wed, 20 Jan 2016 20:07:04 +0000 Subject: [openssl-dev] [openssl.org #4259] Bug: Apparent memory leak in kssl.c In-Reply-To: <0D659A5A3F184B459470CC3DFE7A4CE12FDAFA40@MTK-SMS-XCH02.digi.com> References: <0D659A5A3F184B459470CC3DFE7A4CE12FDAFA40@MTK-SMS-XCH02.digi.com> Message-ID: Hello - I ran OpenSSL v1.0.2e through static analysis (Cppcheck v1.62) and there was one apparent memory leak identified as follows: openssl-1.0.2e\ssl\kssl.c error line: 2234 Memory leak: p_data (new_p is freed in the error return condition, but its data field references a buffer addressed by p_data and that is not freed first) This is not impacting our use of OpenSSL. It was found during a preparatory step to porting v1.0.2e in the near future. Glenn Highland Lead Software Engineer Digi International(c) Wireless Design Services Inc. 11001 Bren Road East, Minnetonka, MN 55343 Direct: 612-524-7153 Main: 612-435-0789 Email: Glenn.Highland at digi.com http://www.digi.com/wireless-design-services/ "Exite de medio eorum et separamini." From uri at ll.mit.edu Wed Jan 20 20:19:16 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 20 Jan 2016 20:19:16 +0000 Subject: [openssl-dev] ECDH engine Message-ID: <20160120201925.17788998.82513.46556@ll.mit.edu> Very possible that I'm missing the point here. Still, since openssl-1_0_2 does ECDH, and it exposes ?ECDSA to external engine(s), how difficult would it be to add ECDH exposure? I suspect - a good deal easier than getting 1.1 replace 1.0.x as the de-facto deployment standard. Plus, by this time there already are (and reasonably common) tokens that support ECDH, other packages that do ECDH, and people (like myself :-) willing to test it and offer minor enhancements. Another point I seem to be missing - if what's necessary to implement ECDH in an external engine is missing from 1_0_2 - how could ?Alexander write a (presumably) working ECDH engine for 1_0_2? If he could do it, ?why can't engine_pkcs11 be extended to do the same? Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. From: Douglas E Engert Sent: Wednesday, January 20, 2016 14:59 To: openssl-dev at openssl.org? Reply To: openssl-dev at openssl.org Subject: Re: [openssl-dev] ECDH engine ? You are missing the point. OpenSSL-1.0.2 only exposed ECDSA, not ECDH to external engines.? It took years to even get ECDSA exposed. OpenSSL approach to support this is OpenSSL-1.1? that does a lot of other things. But that was there approach. Its their package. From working package to distribution always takes several years... ? On 1/20/2016 1:34 PM, Blumenthal, Uri - 0553 - MITLL wrote: Probably it was one of the main reasons why we didn't use pkcs11 for ATECC508A and wrote an engine instead I still argue with the approach (IMHO nobody needs yet another limited engine), but constraining ECC additions to 1.1 does not make any sense to me. 1.0.2 is going to be around for a quite a while. A lot of applications won?t migrate to 1.1 quickly ? a few years would be a good/reasonable/safe bet.? To restrict this work to 1.1 means pushing this basic capability off by (realistically) several years. Most people can?t/won't deploy openssl-1.1 as long as it interferes with the majority of the applications they or their OS is using, is not good. I for one won?t be able to use 1.1 in practice until it becomes the embraced standard and software such as Macports port set is moved to support it. I?m 100% sure there are many?more of us in this bus, on different OS (e.g., it looks like Ubuntu is even worse off than Macports). On Wed, Jan 20, 2016 at 11:10 AM, Blumenthal, Uri - 0553 - MITLL wrote: Are you saying it won't work on OpenSSL_1_0_2-stable?! Sent?from?my?BlackBerry?10?smartphone?on the?Verizon?Wireless?4G?LTE?network. From: Douglas E Engert Sent: Wednesday, January 20, 2016 14:07 To: openssl-dev at openssl.org Reply To: openssl-dev at openssl.org Subject: Re: [openssl-dev] ECDH engine Patches are underdevelopment for OpenSC's libp11 and engine_pkcs11 to support ECDH. There are waiting for OpenSSL-1.1 to be come stable and some minor bug? fixes. Testing is proceeding using OpenSSL-1.1-pre2 today.? OpenSSL-1.1 is needed because it exposes the functions needed to use ECDH from an external engine i.e.? the OPenSC engine_pkcs11. ? ? https://github.com/OpenSC/libp11/issues/52 ? https://github.com/dengert/libp11/tree/prep-openssl-1.1 ? https://github.com/dengert/engine_pkcs11/tree/prep-openssl-1.1 In addition to a major rewrite of combining the ECDSA_METHOD and ECDH_METHOD into an C_KEY_METHOD, OpenSSL-1.1? introduces a lot of changes, mainly because it hides many of the structures that have been exposed in the past. This causes a major rewrite of code to use functions to access these structures.? Although OpenSC could still use an older version of OpenSSL, there is also underway changes for OpenSC to use OpenSSL-1.1: https://github.com/OpenSC/OpenSC/pull/654 https://github.com/dengert/OpenSC/tree/prep-openssl-1.1 On 1/20/2016 12:02 PM, Blumenthal, Uri - 0553 - MITLL wrote: I forgot to add that ?OpenSSL-1_0-2-stable with the current (Github master) engine-pkcs11, libp11, and OpenSC successfully does ECDSA with keys on the token (tested for ECC256 and ECC384). OpenSC tools successfully derive (i.e., implement ECDH1_DERIVE). I'm waiting for libp11 and engine_pkcs11 to add this capability. ? Ideally this is where your code would plug in, and complete the circle. As it currently is, a separate Atmel-specific ECC-specific engine is of a limited usefulness. Sent?from?my?BlackBerry?10?smartphone?on the?Verizon?Wireless?4G?LTE?network. From: Blumenthal, Uri - 0553 - MITLL Sent: Wednesday, January 20, 2016 12:46 To: openssl-dev at openssl.org Reply To: openssl-dev at openssl.org Subject: Re: [openssl-dev] ECDH engine The ATECC508A is a chip. There are few USB devices built by Atmel on its base. Or you can use the chip directly over I2C (that many people like to do). You can follow the links that we posted on the ATECCX08 Engine repository WiKi to learn about the chip.? I see, thanks. Well, our first indent was to use the pksc11 library. But it didn't go to well for many reasons. I should go back for several months to collect these reasons but I think the main reason was that ATECC508A hardware is based on ECC-256 algorithms while pkcs11 is originally written for RSA - the overhead was looking too high (many ATECC508 customers are using limited hardware and want direct I2C connection to the chip).? There are a few hardware tokens (USB-pluggable), e.g. Yubikey, that support ECC256 and (in case of Yubikey 4) ECC384. But let's talk about pkcs11. Can you point me to the set of documentation for EC-DERIVE? It may be a good time now to add the ATECC508 support to there. Honestly, I?m more interested in adding ECDH support ? assuming that it would also serve ATECC508, rather than working on ATECC508B and hoping that perhaps it would be usable for other ECC-capable tokens. Here?s the PKCS#11 spec?http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf, which covers ECDH including ECDH1_DERIVE and ECDH1_COFACTOR_DERIVE. I think older versions (like v2.20) have more content, but this is the current one. Hope it helps. P.S. At this time I?m standing by my original opinion ? that a better way is incorporating ECDH1_*DERIVE in libp11 and engine_pkcs11, rather than creating an engine specifically for one chip that add uncertainly of non-interoperability with other chips/tokens. On Jan 20, 2016, at 8:11 AM, Blumenthal, Uri - 0553 - MITLL wrote: What is this Atmel x508x? Is it a chip? Is it a token/smartcard? Is it accessible via PKCS#11 at all? Is it accessible by/via OpenSC? I am trying to figure why such a generic and useful set of ECC operations (Sign, Derive) is implementation-limited to one single .? A much better solution to me would be adding EC-DERIVE to engine_pkcs11, and automatically get all the tokens covered. Since I'm probably? missing something, could you please educate me? Sent?from?my?BlackBerry?10 smartphone?on?the?Verizon?Wireless?4G LTE?network. From: Alexander Gostrer? Sent: Wednesday, January 20, 2016 10:47 To: Dr. Stephen Henson Reply To: openssl-dev at openssl.org Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] ECDH engine ? Hi Steve, ? And here is the ENGINE implementation for Atmel ATECC508A with few small patches to OpenSSL_1_0_2-stable: https://github.com/AtmelCSO/cryptoauth-openssl-engine Your comments are welcome. Regards, Alex. On Sat, Dec 19, 2015 at 12:49 PM, Dr. Stephen Henson wrote: On Fri, Dec 18, 2015, Alexander Gostrer wrote: > Hi Steve, > > John and I completed writing an ECDH engine based on the > OpenSSL_1_0_2-stable branch. We were planning to expand it to the master > but found some major changes made by you recently. What is the status of > this task? Is it stable enough to follow it? Are you planning another > changes? Is there a design document that we can use in our work? > The version in master shouldn't change much any more. Documentation will be available in the near future. The changes were meant to remove some of the weird "quirks" of ECC compared to other algortihms and to permit future expansion to a wider range of curves. In the meantime it shouldn't be too hard to follow how the new code works. Instead of separate ECDH/ECDSA methods with weird locking and ex_data and minimal ENGINE support everything is combined into a single EC_KEY_METHOD which can contain ECDSA, ECDH and key generation (something which was impossible with the old code) and be tied directly to an ENGINE. Most of the primary APIs such as ECDH_compute_key can be redirected directly through an engine supplied function in EC_KEY_METHOD. Having said that the code is very new and may have the odd bug that needs to be fixed. If you have any problems let me know and I'll look into them. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Douglas E. Engert _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Douglas E. Engert -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From agostrer at gmail.com Wed Jan 20 20:27:07 2016 From: agostrer at gmail.com (Alexander Gostrer) Date: Wed, 20 Jan 2016 12:27:07 -0800 Subject: [openssl-dev] ECDH engine In-Reply-To: <20160120201925.17788998.82513.46556@ll.mit.edu> References: <20160120201925.17788998.82513.46556@ll.mit.edu> Message-ID: On Wed, Jan 20, 2016 at 12:19 PM, Blumenthal, Uri - 0553 - MITLL < uri at ll.mit.edu> wrote: > Very possible that I'm missing the point here. > > Still, since openssl-1_0_2 does ECDH, and it exposes ?ECDSA to external > engine(s), how difficult would it be to add ECDH exposure? I suspect - a > good deal easier than getting 1.1 replace 1.0.x as the de-facto deployment > standard. > > Plus, by this time there already are (and reasonably common) tokens that > support ECDH, other packages that do ECDH, and people (like myself :-) > willing to test it and offer minor enhancements. > > Another point I seem to be missing - if what's necessary to implement ECDH > in an external engine is missing from 1_0_2 - how could ?Alexander write a > (presumably) working ECDH engine for 1_0_2? If he could do it, why can't > engine_pkcs11 be extended to do the same? > As I said, we were needed to patch 1_0_2 to make it working (see patches here: https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches). Changes are pretty minor. We will be more than happy if the openssl community will agree to apply these patches to the 1_0_2 branch. But I was said that it is unlikely to happen because it is more feature than bug. Also we tested them for TLS-1.2 only. > > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > *From: *Douglas E Engert > *Sent: *Wednesday, January 20, 2016 14:59 > *To: *openssl-dev at openssl.org? > *Reply To: *openssl-dev at openssl.org > *Subject: *Re: [openssl-dev] ECDH engine > ? > You are missing the point. OpenSSL-1.0.2 only exposed ECDSA, not ECDH to > external engines. It took years to even get ECDSA exposed. > OpenSSL approach to support this is OpenSSL-1.1 that does a lot of other > things. But that was there approach. Its their package. > From working package to distribution always takes several years... > > > > ? > On 1/20/2016 1:34 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > Probably it was one of the main reasons why we didn't use pkcs11 for > ATECC508A and wrote an engine instead > > > I still argue with the approach (IMHO nobody needs yet another limited > engine), but constraining ECC additions to 1.1 does not make any sense to > me. 1.0.2 is going to be around for a quite a while. A lot of applications > won?t migrate to 1.1 quickly ? a few years would be a good/reasonable/safe > bet. > > To restrict this work to 1.1 means pushing this basic capability off by > (realistically) several years. Most people can?t/won't deploy openssl-1.1 > as long as it interferes with the majority of the applications they or > their OS is using, is not good. I for one won?t be able to use 1.1 in > practice until it becomes the embraced standard and software such as > Macports port set is moved to support it. I?m 100% sure there are many more > of us in this bus, on different OS (e.g., it looks like Ubuntu is even > worse off than Macports). > > > On Wed, Jan 20, 2016 at 11:10 AM, Blumenthal, Uri - 0553 - MITLL < > uri at ll.mit.edu> wrote: > >> Are you saying it won't work on OpenSSL_1_0_2-stable?! >> >> >> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. >> *From: *Douglas E Engert >> *Sent: *Wednesday, January 20, 2016 14:07 >> *To: * openssl-dev at openssl.org >> *Reply To: * openssl-dev at openssl.org >> *Subject: *Re: [openssl-dev] ECDH engine >> >> Patches are underdevelopment for OpenSC's libp11 and engine_pkcs11 to >> support ECDH. There are waiting for OpenSSL-1.1 to be come stable >> and some minor bug fixes. Testing is proceeding using OpenSSL-1.1-pre2 >> today. OpenSSL-1.1 is needed because it exposes the functions needed >> to use ECDH from an external engine i.e. the OPenSC engine_pkcs11. >> ? >> https://github.com/OpenSC/libp11/issues/52 >> https://github.com/dengert/libp11/tree/prep-openssl-1.1 >> https://github.com/dengert/engine_pkcs11/tree/prep-openssl-1.1 >> >> In addition to a major rewrite of combining the ECDSA_METHOD and >> ECDH_METHOD into an C_KEY_METHOD, OpenSSL-1.1 introduces a lot of changes, >> mainly because it hides many of the structures that have been exposed in >> the past. This causes a major rewrite of code to use functions to access >> these structures. >> >> Although OpenSC could still use an older version of OpenSSL, there is >> also underway changes for OpenSC to use OpenSSL-1.1: >> https://github.com/OpenSC/OpenSC/pull/654 >> https://github.com/dengert/OpenSC/tree/prep-openssl-1.1 >> >> >> On 1/20/2016 12:02 PM, Blumenthal, Uri - 0553 - MITLL wrote: >> >> I forgot to add that ?OpenSSL-1_0-2-stable with the current (Github >> master) engine-pkcs11, libp11, and OpenSC successfully does ECDSA with keys >> on the token (tested for ECC256 and ECC384). >> >> OpenSC tools successfully derive (i.e., implement ECDH1_DERIVE). I'm >> waiting for libp11 and engine_pkcs11 to add this capability. >> ? >> Ideally this is where your code would plug in, and complete the circle. >> >> As it currently is, a separate Atmel-specific ECC-specific engine is of a >> limited usefulness. >> >> >> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. >> *From: *Blumenthal, Uri - 0553 - MITLL >> *Sent: *Wednesday, January 20, 2016 12:46 >> *To: * openssl-dev at openssl.org >> *Reply To: * openssl-dev at openssl.org >> *Subject: *Re: [openssl-dev] ECDH engine >> >> The ATECC508A is a chip. There are few USB devices built by Atmel on its >> base. Or you can use the chip directly over I2C (that many people like to >> do). You can follow the links that we posted on the ATECCX08 Engine >> repository WiKi to learn about the chip. >> >> >> I see, thanks. >> >> Well, our first indent was to use the pksc11 library. But it didn't go to >> well for many reasons. I should go back for several months to collect these >> reasons but I think the main reason was that ATECC508A hardware is based on >> ECC-256 algorithms while pkcs11 is originally written for RSA - the >> overhead was looking too high (many ATECC508 customers are using limited >> hardware and want direct I2C connection to the chip). >> >> >> There are a few hardware tokens (USB-pluggable), e.g. Yubikey, that >> support ECC256 and (in case of Yubikey 4) ECC384. >> >> But let's talk about pkcs11. Can you point me to the set of documentation >> for EC-DERIVE? It may be a good time now to add the ATECC508 support to >> there. >> >> >> Honestly, I?m more interested in adding ECDH support ? assuming that it >> would also serve ATECC508, rather than working on ATECC508B and hoping that >> perhaps it would be usable for other ECC-capable tokens. >> >> Here?s the PKCS#11 spec >> >> http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf, >> which covers ECDH including ECDH1_DERIVE and ECDH1_COFACTOR_DERIVE. I >> think older versions (like v2.20) have more content, but this is the >> current one. >> >> Hope it helps. >> >> P.S. At this time I?m standing by my original opinion ? that a better way >> is incorporating ECDH1_*DERIVE in libp11 and engine_pkcs11, rather than >> creating an engine specifically for one chip that add uncertainly of >> non-interoperability with other chips/tokens. >> >> >> On Jan 20, 2016, at 8:11 AM, Blumenthal, Uri - 0553 - MITLL < >> uri at ll.mit.edu> wrote: >> >> What is this Atmel x508x? Is it a chip? Is it a token/smartcard? Is it >> accessible via PKCS#11 at all? Is it accessible by/via OpenSC? >> >> I am trying to figure why such a generic and useful set of ECC operations >> (Sign, Derive) is implementation-limited to one single . >> >> A much better solution to me would be adding EC-DERIVE to engine_pkcs11, >> and automatically get all the tokens covered. >> >> Since I'm probably? missing something, could you please educate me? >> >> >> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. >> *From: *Alexander Gostrer? >> *Sent: *Wednesday, January 20, 2016 10:47 >> *To: *Dr. Stephen Henson >> *Reply To: * openssl-dev at openssl.org >> *Cc: * openssl-dev at openssl.org >> *Subject: *Re: [openssl-dev] ECDH engine >> ? >> Hi Steve, >> ? >> And here is the ENGINE implementation for Atmel ATECC508A with few small >> patches to OpenSSL_1_0_2-stable: >> >> https://github.com/AtmelCSO/cryptoauth-openssl-engine >> >> Your comments are welcome. >> >> Regards, >> Alex. >> >> On Sat, Dec 19, 2015 at 12:49 PM, Dr. Stephen Henson < >> steve at openssl.org> wrote: >> >>> On Fri, Dec 18, 2015, Alexander Gostrer wrote: >>> >>> > Hi Steve, >>> > >>> > John and I completed writing an ECDH engine based on the >>> > OpenSSL_1_0_2-stable branch. We were planning to expand it to the >>> master >>> > but found some major changes made by you recently. What is the status >>> of >>> > this task? Is it stable enough to follow it? Are you planning another >>> > changes? Is there a design document that we can use in our work? >>> > >>> >>> The version in master shouldn't change much any more. Documentation will >>> be >>> available in the near future. The changes were meant to remove some of >>> the >>> weird "quirks" of ECC compared to other algortihms and to permit future >>> expansion to a wider range of curves. >>> >>> In the meantime it shouldn't be too hard to follow how the new code >>> works. >>> Instead of separate ECDH/ECDSA methods with weird locking and ex_data and >>> minimal ENGINE support everything is combined into a single EC_KEY_METHOD >>> which can contain ECDSA, ECDH and key generation (something which was >>> impossible with the old code) and be tied directly to an ENGINE. >>> >>> Most of the primary APIs such as ECDH_compute_key can be redirected >>> directly >>> through an engine supplied function in EC_KEY_METHOD. >>> >>> Having said that the code is very new and may have the odd bug that >>> needs to >>> be fixed. If you have any problems let me know and I'll look into them. >>> >>> Steve. >>> -- >>> Dr Stephen N. Henson. OpenSSL project core developer. >>> Commercial tech support now available see: >>> http://www.openssl.org >>> >> >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: >> https://mta.openssl.org/mailman/listinfo/openssl-dev >> >> >> >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> >> >> -- >> >> Douglas E. Engert >> >> >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> >> > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > -- > > Douglas E. Engert > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From agostrer at gmail.com Wed Jan 20 20:29:04 2016 From: agostrer at gmail.com (Alexander Gostrer) Date: Wed, 20 Jan 2016 12:29:04 -0800 Subject: [openssl-dev] ECDH engine In-Reply-To: References: <20160120191014.17788998.97457.46531@ll.mit.edu> Message-ID: On Wed, Jan 20, 2016 at 11:34 AM, Blumenthal, Uri - 0553 - MITLL < uri at ll.mit.edu> wrote: > Probably it was one of the main reasons why we didn't use pkcs11 for > ATECC508A and wrote an engine instead > > > I still argue with the approach (IMHO nobody needs yet another limited > engine > Limited? - yes. Useless? - Probably, not. We will see it very soon. > ), but constraining ECC additions to 1.1 does not make any sense to me. > 1.0.2 is going to be around for a quite a while. A lot of applications > won?t migrate to 1.1 quickly ? a few years would be a good/reasonable/safe > bet. > > To restrict this work to 1.1 means pushing this basic capability off by > (realistically) several years. Most people can?t/won't deploy openssl-1.1 > as long as it interferes with the majority of the applications they or > their OS is using, is not good. I for one won?t be able to use 1.1 in > practice until it becomes the embraced standard and software such as > Macports port set is moved to support it. I?m 100% sure there are many more > of us in this bus, on different OS (e.g., it looks like Ubuntu is even > worse off than Macports). > > > On Wed, Jan 20, 2016 at 11:10 AM, Blumenthal, Uri - 0553 - MITLL < > uri at ll.mit.edu> wrote: > >> Are you saying it won't work on OpenSSL_1_0_2-stable?! >> >> >> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. >> *From: *Douglas E Engert >> *Sent: *Wednesday, January 20, 2016 14:07 >> *To: *openssl-dev at openssl.org >> *Reply To: *openssl-dev at openssl.org >> *Subject: *Re: [openssl-dev] ECDH engine >> >> Patches are underdevelopment for OpenSC's libp11 and engine_pkcs11 to >> support ECDH. There are waiting for OpenSSL-1.1 to be come stable >> and some minor bug fixes. Testing is proceeding using OpenSSL-1.1-pre2 >> today. OpenSSL-1.1 is needed because it exposes the functions needed >> to use ECDH from an external engine i.e. the OPenSC engine_pkcs11. >> ? >> https://github.com/OpenSC/libp11/issues/52 >> https://github.com/dengert/libp11/tree/prep-openssl-1.1 >> https://github.com/dengert/engine_pkcs11/tree/prep-openssl-1.1 >> >> In addition to a major rewrite of combining the ECDSA_METHOD and >> ECDH_METHOD into an C_KEY_METHOD, OpenSSL-1.1 introduces a lot of changes, >> mainly because it hides many of the structures that have been exposed in >> the past. This causes a major rewrite of code to use functions to access >> these structures. >> >> Although OpenSC could still use an older version of OpenSSL, there is >> also underway changes for OpenSC to use OpenSSL-1.1: >> https://github.com/OpenSC/OpenSC/pull/654 >> https://github.com/dengert/OpenSC/tree/prep-openssl-1.1 >> >> >> On 1/20/2016 12:02 PM, Blumenthal, Uri - 0553 - MITLL wrote: >> >> I forgot to add that ?OpenSSL-1_0-2-stable with the current (Github >> master) engine-pkcs11, libp11, and OpenSC successfully does ECDSA with keys >> on the token (tested for ECC256 and ECC384). >> >> OpenSC tools successfully derive (i.e., implement ECDH1_DERIVE). I'm >> waiting for libp11 and engine_pkcs11 to add this capability. >> ? >> Ideally this is where your code would plug in, and complete the circle. >> >> As it currently is, a separate Atmel-specific ECC-specific engine is of a >> limited usefulness. >> >> >> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. >> *From: *Blumenthal, Uri - 0553 - MITLL >> *Sent: *Wednesday, January 20, 2016 12:46 >> *To: *openssl-dev at openssl.org >> *Reply To: *openssl-dev at openssl.org >> *Subject: *Re: [openssl-dev] ECDH engine >> >> The ATECC508A is a chip. There are few USB devices built by Atmel on its >> base. Or you can use the chip directly over I2C (that many people like to >> do). You can follow the links that we posted on the ATECCX08 Engine >> repository WiKi to learn about the chip. >> >> >> I see, thanks. >> >> Well, our first indent was to use the pksc11 library. But it didn't go to >> well for many reasons. I should go back for several months to collect these >> reasons but I think the main reason was that ATECC508A hardware is based on >> ECC-256 algorithms while pkcs11 is originally written for RSA - the >> overhead was looking too high (many ATECC508 customers are using limited >> hardware and want direct I2C connection to the chip). >> >> >> There are a few hardware tokens (USB-pluggable), e.g. Yubikey, that >> support ECC256 and (in case of Yubikey 4) ECC384. >> >> But let's talk about pkcs11. Can you point me to the set of documentation >> for EC-DERIVE? It may be a good time now to add the ATECC508 support to >> there. >> >> >> Honestly, I?m more interested in adding ECDH support ? assuming that it >> would also serve ATECC508, rather than working on ATECC508B and hoping that >> perhaps it would be usable for other ECC-capable tokens. >> >> Here?s the PKCS#11 spec >> http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf, >> which covers ECDH including ECDH1_DERIVE and ECDH1_COFACTOR_DERIVE. I >> think older versions (like v2.20) have more content, but this is the >> current one. >> >> Hope it helps. >> >> P.S. At this time I?m standing by my original opinion ? that a better way >> is incorporating ECDH1_*DERIVE in libp11 and engine_pkcs11, rather than >> creating an engine specifically for one chip that add uncertainly of >> non-interoperability with other chips/tokens. >> >> >> On Jan 20, 2016, at 8:11 AM, Blumenthal, Uri - 0553 - MITLL < >> uri at ll.mit.edu> wrote: >> >> What is this Atmel x508x? Is it a chip? Is it a token/smartcard? Is it >> accessible via PKCS#11 at all? Is it accessible by/via OpenSC? >> >> I am trying to figure why such a generic and useful set of ECC operations >> (Sign, Derive) is implementation-limited to one single . >> >> A much better solution to me would be adding EC-DERIVE to engine_pkcs11, >> and automatically get all the tokens covered. >> >> Since I'm probably? missing something, could you please educate me? >> >> >> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. >> *From: *Alexander Gostrer? >> *Sent: *Wednesday, January 20, 2016 10:47 >> *To: *Dr. Stephen Henson >> *Reply To: * openssl-dev at openssl.org >> *Cc: *openssl-dev at openssl.org >> *Subject: *Re: [openssl-dev] ECDH engine >> ? >> Hi Steve, >> ? >> And here is the ENGINE implementation for Atmel ATECC508A with few small >> patches to OpenSSL_1_0_2-stable: >> https://github.com/AtmelCSO/cryptoauth-openssl-engine >> >> Your comments are welcome. >> >> Regards, >> Alex. >> >> On Sat, Dec 19, 2015 at 12:49 PM, Dr. Stephen Henson >> wrote: >> >>> On Fri, Dec 18, 2015, Alexander Gostrer wrote: >>> >>> > Hi Steve, >>> > >>> > John and I completed writing an ECDH engine based on the >>> > OpenSSL_1_0_2-stable branch. We were planning to expand it to the >>> master >>> > but found some major changes made by you recently. What is the status >>> of >>> > this task? Is it stable enough to follow it? Are you planning another >>> > changes? Is there a design document that we can use in our work? >>> > >>> >>> The version in master shouldn't change much any more. Documentation will >>> be >>> available in the near future. The changes were meant to remove some of >>> the >>> weird "quirks" of ECC compared to other algortihms and to permit future >>> expansion to a wider range of curves. >>> >>> In the meantime it shouldn't be too hard to follow how the new code >>> works. >>> Instead of separate ECDH/ECDSA methods with weird locking and ex_data and >>> minimal ENGINE support everything is combined into a single EC_KEY_METHOD >>> which can contain ECDSA, ECDH and key generation (something which was >>> impossible with the old code) and be tied directly to an ENGINE. >>> >>> Most of the primary APIs such as ECDH_compute_key can be redirected >>> directly >>> through an engine supplied function in EC_KEY_METHOD. >>> >>> Having said that the code is very new and may have the odd bug that >>> needs to >>> be fixed. If you have any problems let me know and I'll look into them. >>> >>> Steve. >>> -- >>> Dr Stephen N. Henson. OpenSSL project core developer. >>> Commercial tech support now available see: http://www.openssl.org >>> >> >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> >> >> >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> >> >> -- >> >> Douglas E. Engert >> >> >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> >> > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jan 20 20:31:13 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 20 Jan 2016 20:31:13 +0000 Subject: [openssl-dev] ECDH engine In-Reply-To: <20160120201925.17788998.82513.46556@ll.mit.edu> References: <20160120201925.17788998.82513.46556@ll.mit.edu> Message-ID: <75648fc72a70419abf039245134c1f1f@usma1ex-dag1mb1.msg.corp.akamai.com> ? Still, since openssl-1_0_2 does ECDH, and it exposes ?ECDSA to external engine(s), how difficult would it be to add ECDH exposure? I suspect - a good deal easier than getting 1.1 replace 1.0.x as the de-facto deployment standard. It?s a new feature, so it won?t come from OpenSSL. Don?t know if that?s an issue or not. Only fixes go into released branches. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Wed Jan 20 21:22:01 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 20 Jan 2016 21:22:01 +0000 Subject: [openssl-dev] ECDH engine In-Reply-To: <75648fc72a70419abf039245134c1f1f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160120201925.17788998.82513.46556@ll.mit.edu> <75648fc72a70419abf039245134c1f1f@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > ? Still, since openssl-1_0_2 does ECDH, and it exposes ?ECDSA to external > engine(s), how difficult would it be to add ECDH exposure? I suspect - a good > deal easier than getting 1.1 replace 1.0.x as the de-facto deployment > standard. > > > It?s a new feature, so it won?t come from OpenSSL. Don?t know if that?s an > issue or not. Only fixes go into released branches. I see several lines of reasoning in favor of my approach: 1. It is more of a bug than of a new feature: OpenSSL-1.0 has been supporting ECC for quite a while. It also has been supporting engines (such as engine_pkcs11), and has mechanisms to specify that the keys are on the engine-accessible token. The fact that these mechanisms are half-done means to be that it?s a bug in need of fixing. As examples of new feature I?d consider EdDSA, or (if somebody decides to contribute it) Grasshopper for symmetric crypto library. 2. OpenSSL_1_0_2-stable (1.0.2f) has not yet been released. So even if you?re inclined to consider this a ?feature? (even though it merely repairs previous undocumented deficiency), perhaps it can go in. Nobody is talking about fitting this fix into 1.0.2e or earlier (?really released? versions). I urge OpenSSL developers to consider this. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From rsalz at akamai.com Wed Jan 20 21:25:42 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 20 Jan 2016 21:25:42 +0000 Subject: [openssl-dev] ECDH engine In-Reply-To: References: <20160120201925.17788998.82513.46556@ll.mit.edu> <75648fc72a70419abf039245134c1f1f@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > The fact that these mechanisms are half-done means to be that it?s a bug in need of fixing. I doubt that anyone else on the team will find this argument compelling. From uri at ll.mit.edu Wed Jan 20 21:35:59 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 20 Jan 2016 21:35:59 +0000 Subject: [openssl-dev] ECDH engine In-Reply-To: References: <20160120201925.17788998.82513.46556@ll.mit.edu> <75648fc72a70419abf039245134c1f1f@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: On 1/20/16, 16:25 , "openssl-dev on behalf of Salz, Rich" wrote: >> The fact that these mechanisms are half-done means to be that it?s a >>bug in need of fixing. > >I doubt that anyone else on the team will find this argument compelling. I don?t know. ?pkeyutl -engine pkcs11 -keyform engine -derive -inkey id_03" does not work the way it?s supposed to. To me it usually means a bug. Another supporting reason - no interface or parameters/arguments would change, only the internal behavior would be adjusted, resulting in actually succeeding with a crypto operation rather than returning an error. But regardless, I hope the team would consider the complexity (or simplicity :) of the proposed change and the benefits from it. After all, we?re not lawyers, and (hopefully :) we all want to make/keep this tool as useful as possible to as many users as feasible (as far as we can :). So since this change doesn?t require moving heaven and earth (AFAICT), perhaps the team would consider it. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From doctor at doctor.nl2k.ab.ca Wed Jan 20 21:52:47 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 20 Jan 2016 14:52:47 -0700 Subject: [openssl-dev] [openssl-users] Openssl 1.1 and Bind 9.6 ESV R11 In-Reply-To: <79e519af478e4b32abe06f2f65480c42@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160119233724.GA9102@doctor.nl2k.ab.ca> <569EF6BD.9000804@akamai.com> <20160120180558.GB13198@doctor.nl2k.ab.ca> <79e519af478e4b32abe06f2f65480c42@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160120215246.GA18819@doctor.nl2k.ab.ca> On Wed, Jan 20, 2016 at 06:11:16PM +0000, Salz, Rich wrote: > > That's my issue. I cannot get a more recent bind version to stay to stable on > > one box. > > Then I think that's going to be a tough issue, and you'll either have to modify that source or stay at 1.0.2 > Source modification it is. BTW we are more interested in Bind 9.9 and Bind 9.10 ? > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From agostrer at gmail.com Wed Jan 20 22:09:56 2016 From: agostrer at gmail.com (Alexander Gostrer) Date: Wed, 20 Jan 2016 14:09:56 -0800 Subject: [openssl-dev] ECDH engine In-Reply-To: References: <20160120201925.17788998.82513.46556@ll.mit.edu> <75648fc72a70419abf039245134c1f1f@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: I vote "for" :) Let me know what should I do if openssl will decide to move forward Regards, Alex. On Wed, Jan 20, 2016 at 1:35 PM, Blumenthal, Uri - 0553 - MITLL < uri at ll.mit.edu> wrote: > On 1/20/16, 16:25 , "openssl-dev on behalf of Salz, Rich" > wrote: > > >> The fact that these mechanisms are half-done means to be that it?s a > >>bug in need of fixing. > > > >I doubt that anyone else on the team will find this argument compelling. > > I don?t know. ?pkeyutl -engine pkcs11 -keyform engine -derive -inkey > id_03" does not work the way it?s supposed to. To me it usually means a > bug. Another supporting reason - no interface or parameters/arguments > would change, only the internal behavior would be adjusted, resulting in > actually succeeding with a crypto operation rather than returning an error. > > But regardless, I hope the team would consider the complexity (or > simplicity :) of the proposed change and the benefits from it. After all, > we?re not lawyers, and (hopefully :) we all want to make/keep this tool as > useful as possible to as many users as feasible (as far as we can :). So > since this change doesn?t require moving heaven and earth (AFAICT), > perhaps the team would consider it. > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Jan 20 23:25:35 2016 From: rt at openssl.org (Laetitia Baudoin via RT) Date: Wed, 20 Jan 2016 23:25:35 +0000 Subject: [openssl-dev] [openssl.org #4260] [PATCH] Update the return value documented for X509_REQ_sign and X509_sign In-Reply-To: References: Message-ID: X509_REQ_sign, X509_sign and similar functions return the signature length instead '1' as documented. Justification: Both function return whatever ASN1_item_sign returns: https://github.com/openssl/openssl/blob/master/crypto/x509/x_all.c#L95 https://github.com/openssl/openssl/blob/master/crypto/x509/x_all.c#L117 And ASN1_item_sign returns the output length: https://github.com/openssl/openssl/blob/master/crypto/asn1/a_sign.c#L321 -------------- next part -------------- A non-text attachment was scrubbed... Name: x509_sign_doc.patch Type: text/x-patch Size: 658 bytes Desc: not available URL: From erik at efca.com Thu Jan 21 00:49:04 2016 From: erik at efca.com (Erik Forsberg) Date: Wed, 20 Jan 2016 16:49:04 -0800 Subject: [openssl-dev] OpenSSL-1.1 make depend Message-ID: seems util/clean-depend.pl is now broken if using Solaris cc compiler. Looks like its working if gcc is used, the difference seems to be that if gcc is used the input to clean-depend.pl looks like object.o: dep1.h dep2.h \ dep3.h dep4.h if Solaris cc is used it looks like object.o: dep1.h object.o: dep2.h object.o: dep3.h object.o: dep4.h I get gazillions of 'Use of uninitialized variable in ....' when running and the net result is that all dependencies generated in the Makefile looks like : ../openssl/header.h the make target printed before the colon is undefined. This block from clean-depend.pl is the faulty part (seems to be added in 1.1, 1.0.2 was working fine) # Time to clean out possible system directories and normalise quirks # from different makedepend methods foreach $file (sort keys %files) { # This gets around a quirk with gcc, which removes all directory # information from the original file my $tmpfile=$file; $tmpfile=~s/\.o$/.c/; (my $origfile)=grep(/(^|\/)${tmpfile}$/,@{$files{$file}}); my $newfile=$origfile; $newfile=~s/\.c$/.o/; if ($newfile ne $file) { $files{$newfile} = $files{$file}; delete $files{$file}; $file = $newfile; } @{$files{$file}} = grep(!/^\//, grep(!/^$origfile$/, @{$files{$file}})); } Commenting out the entire block makes it work properly Adding a test like if (defined $origfile) { } around everything after the first grep call also fixes it but it doesnt for example ignore system directory dependencies. I use latest perl 5.22 if it matters but this looks like generic failure to me. From ca+ssl-dev at esmtp.org Thu Jan 21 01:50:28 2016 From: ca+ssl-dev at esmtp.org (Claus Assmann) Date: Wed, 20 Jan 2016 17:50:28 -0800 Subject: [openssl-dev] OpenSSL-1.1 make depend In-Reply-To: References: Message-ID: <20160121015028.GA22959@x2.esmtp.org> On Wed, Jan 20, 2016, Erik Forsberg wrote: > seems util/clean-depend.pl is now broken if using Solaris cc compiler. Just a confirmation that this isn't specific to that setup: the same happens on OpenBSD (e.g., 5.3) with gcc. > I get gazillions of 'Use of uninitialized variable in ....' when running making depend in crypto... Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 418. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 418. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 418. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 418. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 418. > I use latest perl 5.22 if it matters > but this looks like generic failure to me. Agreed (perl 5.12 here) From rsalz at akamai.com Thu Jan 21 01:55:24 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 21 Jan 2016 01:55:24 +0000 Subject: [openssl-dev] OpenSSL-1.1 make depend In-Reply-To: <20160121015028.GA22959@x2.esmtp.org> References: <20160121015028.GA22959@x2.esmtp.org> Message-ID: > Just a confirmation that this isn't specific to that setup: > the same happens on OpenBSD (e.g., 5.3) with gcc. Does something like this fix it? ; g diff util/clean-depend.pl diff --git a/util/clean-depend.pl b/util/clean-depend.pl index f29192f..1ace994 100755 --- a/util/clean-depend.pl +++ b/util/clean-depend.pl @@ -18,8 +18,9 @@ my %files; # Fetch all the dependency output first my $thisfile=""; -while() { - my ($dummy, $file,$deps)=/^((.*):)? (.*)$/; +while(my $line = ) { + while ($line =~ /\\$/) { chop($line); chop($line); $line .= ; } + my ($dummy, $file,$deps)=$line =~ m/^((.*):)? (.*)$/; $thisfile=$file if defined $file; next if !defined $deps; my @deps=split ' ',$deps; ; From ca+ssl-dev at esmtp.org Thu Jan 21 02:09:23 2016 From: ca+ssl-dev at esmtp.org (Claus Assmann) Date: Wed, 20 Jan 2016 18:09:23 -0800 Subject: [openssl-dev] OpenSSL-1.1 make depend In-Reply-To: References: <20160121015028.GA22959@x2.esmtp.org> Message-ID: <20160121020923.GB22959@x2.esmtp.org> On Thu, Jan 21, 2016, Salz, Rich wrote: > --- a/util/clean-depend.pl > -while() { > - my ($dummy, $file,$deps)=/^((.*):)? (.*)$/; > +while(my $line = ) { > + while ($line =~ /\\$/) { chop($line); chop($line); $line .= ; } > + my ($dummy, $file,$deps)=$line =~ m/^((.*):)? (.*)$/; Not for me: making depend in crypto... Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 42, line 418. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 43, line 418. ... [[37705 lines of such error messages]] From rsalz at akamai.com Thu Jan 21 02:14:30 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 21 Jan 2016 02:14:30 +0000 Subject: [openssl-dev] OpenSSL-1.1 make depend In-Reply-To: <20160121020923.GB22959@x2.esmtp.org> References: <20160121015028.GA22959@x2.esmtp.org> <20160121020923.GB22959@x2.esmtp.org> Message-ID: <0989d010a4574279962effe6a28b4def@usma1ex-dag1mb1.msg.corp.akamai.com> > Not for me: Oh well. That script has way too much perl magic in it for me to try more. :( From erik at efca.com Thu Jan 21 03:11:00 2016 From: erik at efca.com (Erik Forsberg) Date: Wed, 20 Jan 2016 19:11:00 -0800 Subject: [openssl-dev] OpenSSL-1.1 make depend In-Reply-To: References: Message-ID: No, doesnt help. Still no valid dependencies. The warnings can of course be silenced by inserting a no warnings "uninitialized"; but that doesnt fix the absence if valid dependencies in the generated Makefile >-- Original Message -- > > >> Just a confirmation that this isn't specific to that setup: >> the same happens on OpenBSD (e.g., 5.3) with gcc. > >Does something like this fix it? > >; g diff util/clean-depend.pl >diff --git a/util/clean-depend.pl b/util/clean-depend.pl >index f29192f..1ace994 100755 >--- a/util/clean-depend.pl >+++ b/util/clean-depend.pl >@@ -18,8 +18,9 @@ my %files; > > # Fetch all the dependency output first > my $thisfile=""; >-while() { >- my ($dummy, $file,$deps)=/^((.*):)? (.*)$/; >+while(my $line = ) { >+ while ($line =~ /\\$/) { chop($line); chop($line); $line .= ; } >+ my ($dummy, $file,$deps)=$line =~ m/^((.*):)? (.*)$/; > $thisfile=$file if defined $file; > next if !defined $deps; > my @deps=split ' ',$deps; >; >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From erik at efca.com Thu Jan 21 07:45:01 2016 From: erik at efca.com (Erik Forsberg) Date: Wed, 20 Jan 2016 23:45:01 -0800 Subject: [openssl-dev] OpenSSL-1.1 make depend In-Reply-To: References: Message-ID: In case its not clear, the difference in the input to clean-depend.pl is that when using Solaris cc, /usr/openwin/bin/makedepend is used instead of gcc -M Still, considering that, the problem is elsewhere, as I tried various styles of input and could not see any correlation >-- Original Message -- > > >seems util/clean-depend.pl is now broken if using Solaris cc compiler. >Looks like its working if gcc is used, the difference seems to be that if >gcc is used the input to clean-depend.pl looks like > >object.o: dep1.h dep2.h \ > dep3.h dep4.h > >if Solaris cc is used it looks like > >object.o: dep1.h >object.o: dep2.h >object.o: dep3.h >object.o: dep4.h > >I get gazillions of 'Use of uninitialized variable in ....' when running >and the net result is that all dependencies generated in the Makefile >looks like > > : ../openssl/header.h > >the make target printed before the colon is undefined. > >This block from clean-depend.pl is the faulty part (seems >to be added in 1.1, 1.0.2 was working fine) > ># Time to clean out possible system directories and normalise quirks ># from different makedepend methods >foreach $file (sort keys %files) { > # This gets around a quirk with gcc, which removes all directory > # information from the original file > my $tmpfile=$file; > $tmpfile=~s/\.o$/.c/; > (my $origfile)=grep(/(^|\/)${tmpfile}$/,@{$files{$file}}); > my $newfile=$origfile; > $newfile=~s/\.c$/.o/; > if ($newfile ne $file) { > $files{$newfile} = $files{$file}; > delete $files{$file}; > $file = $newfile; > } > > @{$files{$file}} = > grep(!/^\//, > grep(!/^$origfile$/, @{$files{$file}})); >} > >Commenting out the entire block makes it work properly >Adding a test like >if (defined $origfile) { >} > >around everything after the first grep call also fixes it >but it doesnt for example ignore system directory dependencies. > >I use latest perl 5.22 if it matters >but this looks like generic failure to me. >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From openssl-users at dukhovni.org Thu Jan 21 07:55:24 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 21 Jan 2016 02:55:24 -0500 Subject: [openssl-dev] OpenSSL-1.1 make depend In-Reply-To: References: Message-ID: <4218E2C4-B97D-43E3-A918-E57FA8E93E9D@dukhovni.org> > On Jan 21, 2016, at 2:45 AM, Erik Forsberg wrote: > > In case its not clear, the difference in the input to clean-depend.pl > is that when using Solaris cc, /usr/openwin/bin/makedepend is used > instead of gcc -M > > Still, considering that, the problem is elsewhere, as I tried > various styles of input and could not see any correlation Thing is, almost nobody actually needs "make depend", despite what Configure might say (we'll fix that soonish). It is really only of any use to the dev team, and any users who rebuild after editing header files while keeping the same Configuration. If all you do is reconfigure and build, the right thing to do is "make clean; make" NOT "make depend; make". Even for me "make depend" is rarely useful, I switch between release branches and configurations a lot more often than I do incremental builds after editing headers. And the build takes around 1 minute on my laptop, so there's really little benefit from "make depend". By far the biggest impediment to quick code/build/test loops is the "test" part, "make depend" does not speed up the tests. So my advice is to forget about "make depend". The git version of "master" has Makefiles with empty initial header dependencies, and it is simplest to just leave it that way. We'll probably have some kind of working "make depend" by the time 1.1.0 ships, but you're quite unlikely to need it. -- Viktor. From wilson.judson at gmail.com Thu Jan 21 08:03:21 2016 From: wilson.judson at gmail.com (Judson Wilson) Date: Thu, 21 Jan 2016 00:03:21 -0800 Subject: [openssl-dev] renegotiation failure causes SSL_shutdown to return 1? In-Reply-To: <569F9409.4050206@openssl.org> References: <569F9409.4050206@openssl.org> Message-ID: Cool! Thanks for doing that :) On Wed, Jan 20, 2016 at 6:04 AM, Matt Caswell wrote: > > > On 05/12/15 09:42, Judson Wilson wrote: > > I am noticing the following sequence of events: > > > > 1) SSL_renegotiate(...), followed by SSL_write(..., 0) fails when a web > > server rejects it by sending a TCP FIN > > 2) SSL_get_error returns SSL_ERROR_SSL > > 3) SSL_in_init(...) is true > > 4) SSL_shutdown returns 1 <-- this seems strange. > > > > I'm not sure that this is the right behavior. Shutting down in a > > handshake without sending/receiving close_notify shouldn't give the > > "everything shutdown gracefully" signal. Perhaps it would be better to > > return -1 and signal SSL_ERROR_SSL? > > This is fixed now (in master and 1.0.2). > > Matt > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu Jan 21 10:19:56 2016 From: levitte at openssl.org (Richard Levitte) Date: Thu, 21 Jan 2016 11:19:56 +0100 (CET) Subject: [openssl-dev] OpenSSL-1.1 make depend In-Reply-To: References: Message-ID: <20160121.111956.1367674790719557989.levitte@openssl.org> Actually, we can now throw away clean-depend.pl and make a much simpler variant. Its intent was to make sure that the list of dependencies would look the same for everyone, regardless of program used, to avoid commit wars. That isn't necessary any more. Something like this should suffice sed -e 's# /\(\\.\|[^ ]\)*##g' -e '/: *$/d' -e '/^\(#.*\| *\)$/d' Cheers, Richard In message on Wed, 20 Jan 2016 23:45:01 -0800, "Erik Forsberg" said: erik> In case its not clear, the difference in the input to clean-depend.pl erik> is that when using Solaris cc, /usr/openwin/bin/makedepend is used erik> instead of gcc -M erik> erik> Still, considering that, the problem is elsewhere, as I tried erik> various styles of input and could not see any correlation erik> erik> >-- Original Message -- erik> > erik> > erik> >seems util/clean-depend.pl is now broken if using Solaris cc compiler. erik> >Looks like its working if gcc is used, the difference seems to be that if erik> >gcc is used the input to clean-depend.pl looks like erik> > erik> >object.o: dep1.h dep2.h \ erik> > dep3.h dep4.h erik> > erik> >if Solaris cc is used it looks like erik> > erik> >object.o: dep1.h erik> >object.o: dep2.h erik> >object.o: dep3.h erik> >object.o: dep4.h erik> > erik> >I get gazillions of 'Use of uninitialized variable in ....' when running erik> >and the net result is that all dependencies generated in the Makefile erik> >looks like erik> > erik> > : ../openssl/header.h erik> > erik> >the make target printed before the colon is undefined. erik> > erik> >This block from clean-depend.pl is the faulty part (seems erik> >to be added in 1.1, 1.0.2 was working fine) erik> > erik> ># Time to clean out possible system directories and normalise quirks erik> ># from different makedepend methods erik> >foreach $file (sort keys %files) { erik> > # This gets around a quirk with gcc, which removes all directory erik> > # information from the original file erik> > my $tmpfile=$file; erik> > $tmpfile=~s/\.o$/.c/; erik> > (my $origfile)=grep(/(^|\/)${tmpfile}$/,@{$files{$file}}); erik> > my $newfile=$origfile; erik> > $newfile=~s/\.c$/.o/; erik> > if ($newfile ne $file) { erik> > $files{$newfile} = $files{$file}; erik> > delete $files{$file}; erik> > $file = $newfile; erik> > } erik> > erik> > @{$files{$file}} = erik> > grep(!/^\//, erik> > grep(!/^$origfile$/, @{$files{$file}})); erik> >} erik> > erik> >Commenting out the entire block makes it work properly erik> >Adding a test like erik> >if (defined $origfile) { erik> >} erik> > erik> >around everything after the first grep call also fixes it erik> >but it doesnt for example ignore system directory dependencies. erik> > erik> >I use latest perl 5.22 if it matters erik> >but this looks like generic failure to me. erik> >_______________________________________________ erik> >openssl-dev mailing list erik> >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev erik> erik> _______________________________________________ erik> openssl-dev mailing list erik> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev erik> From bbrumley at gmail.com Thu Jan 21 12:10:32 2016 From: bbrumley at gmail.com (Billy Brumley) Date: Thu, 21 Jan 2016 14:10:32 +0200 Subject: [openssl-dev] [openssl.org #3863] [PATCH] ECC: Add missing NULL check. Set a flag. In-Reply-To: References: Message-ID: https://github.com/openssl/openssl/pull/575 On Tue, May 26, 2015 at 9:06 PM, Billy Brumley via RT wrote: > Set point->Z_is_one flag after setting point->Z to one. Also check > BIGNUM for NULL before passing it to get_affine_coordinates. > > BBB > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From rt at openssl.org Thu Jan 21 12:10:44 2016 From: rt at openssl.org (Billy Brumley via RT) Date: Thu, 21 Jan 2016 12:10:44 +0000 Subject: [openssl-dev] [openssl.org #3863] [PATCH] ECC: Add missing NULL check. Set a flag. In-Reply-To: References: Message-ID: https://github.com/openssl/openssl/pull/575 On Tue, May 26, 2015 at 9:06 PM, Billy Brumley via RT wrote: > Set point->Z_is_one flag after setting point->Z to one. Also check > BIGNUM for NULL before passing it to get_affine_coordinates. > > BBB > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From cata.vasile at nxp.com Thu Jan 21 10:57:19 2016 From: cata.vasile at nxp.com (Catalin Vasile) Date: Thu, 21 Jan 2016 10:57:19 +0000 Subject: [openssl-dev] [eng_rdrand] alloc and free Message-ID: ENGINE_load_rdrand() creates a new engine, it adds it/registers it and then frees it. Looking further into these functions, the registration does NOT create a new object and then copy the data into it, so the registration is based on an object that it's later released. Based on this[1] tutorial on using RNG engines, after ENGINE_load_rdrand(),?ENGINE_by_id() is called, which looks in the registration list, which has a reference to a freed object. Am I missing something? Is there an actual logic error, or is there something I did not understand? Best regards, Cata ? [1]?https://wiki.openssl.org/index.php/Random_Numbers#Hardware From doctor at doctor.nl2k.ab.ca Thu Jan 21 13:56:02 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Thu, 21 Jan 2016 06:56:02 -0700 Subject: [openssl-dev] openssl-SNAP-20160121 issues Message-ID: <20160121135602.GA6020@doctor.nl2k.ab.ca> All right gcc -I.. -I../.. -I../modes -I../include -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=i486 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c str_lib.c str_lib.c: In function `STORE_generate_key': str_lib.c:423: dereferencing pointer to incomplete type str_lib.c: In function `STORE_get_private_key': str_lib.c:447: dereferencing pointer to incomplete type str_lib.c: In function `STORE_store_private_key': str_lib.c:477: dereferencing pointer to incomplete type str_lib.c: In function `STORE_list_private_key_next': str_lib.c:581: dereferencing pointer to incomplete type str_lib.c: In function `STORE_get_public_key': str_lib.c:631: dereferencing pointer to incomplete type str_lib.c: In function `STORE_store_public_key': str_lib.c:661: dereferencing pointer to incomplete type str_lib.c: In function `STORE_list_public_key_next': str_lib.c:765: dereferencing pointer to incomplete type Please fix. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From rsalz at akamai.com Thu Jan 21 14:05:16 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 21 Jan 2016 14:05:16 +0000 Subject: [openssl-dev] OpenSSL-1.1 make depend In-Reply-To: References: Message-ID: <5528a3b4d3c142a092816e7777cef99a@usma1ex-dag1mb1.msg.corp.akamai.com> > In case its not clear, the difference in the input to clean-depend.pl is that > when using Solaris cc, /usr/openwin/bin/makedepend is used instead of gcc Yup, got it. Thanks. From rsalz at akamai.com Thu Jan 21 14:16:15 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 21 Jan 2016 14:16:15 +0000 Subject: [openssl-dev] OpenSSL-1.1 make depend In-Reply-To: <20160121.111956.1367674790719557989.levitte@openssl.org> References: <20160121.111956.1367674790719557989.levitte@openssl.org> Message-ID: <1d3dadf8b4f74a70a3d7ddef56ccb8f5@usma1ex-dag1mb1.msg.corp.akamai.com> Try this patch do util/domd ; g diff util/domd diff --git a/util/domd b/util/domd index 16de5c7..f0532ad 100755 --- a/util/domd +++ b/util/domd @@ -26,12 +26,13 @@ if ${MAKEDEPEND} --version 2>&1 | grep "clang" > /dev/null || sed -e '/^# DO NOT DELETE.*/,$d' < Makefile > Makefile.tmp echo '# DO NOT DELETE THIS LINE -- make depend depends on it.' >> Makefile.tmp ${MAKEDEPEND} -Werror -D OPENSSL_DOING_MAKEDEPEND -M $args >> Makefile.tmp || exit 1 - ${PERL} $TOP/util/clean-depend.pl < Makefile.tmp > Makefile.new - RC=$? + sed -e 's# /\(\\.\|[^ ]\)*##g' -e '/: *$/d' -e '/^\(#.*\| *\)$/d' \ + Makefile.new rm -f Makefile.tmp else ${MAKEDEPEND} -D OPENSSL_DOING_MAKEDEPEND $@ && \ - ${PERL} $TOP/util/clean-depend.pl < Makefile > Makefile.new + sed -e 's# /\(\\.\|[^ ]\)*##g' -e '/: *$/d' -e '/^\(#.*\| *\)$/d' \ + >Makefile.new RC=$? fi mv Makefile.new Makefile From rt at openssl.org Thu Jan 21 14:19:06 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 21 Jan 2016 14:19:06 +0000 Subject: [openssl-dev] [openssl.org #3863] [PATCH] ECC: Add missing NULL check. Set a flag. In-Reply-To: References: Message-ID: Patch applied. Thanks Matt From ca+ssl-dev at esmtp.org Thu Jan 21 14:29:57 2016 From: ca+ssl-dev at esmtp.org (Claus Assmann) Date: Thu, 21 Jan 2016 06:29:57 -0800 Subject: [openssl-dev] OpenSSL-1.1 make depend In-Reply-To: <1d3dadf8b4f74a70a3d7ddef56ccb8f5@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160121.111956.1367674790719557989.levitte@openssl.org> <1d3dadf8b4f74a70a3d7ddef56ccb8f5@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160121142957.GA18239@x2.esmtp.org> On Thu, Jan 21, 2016, Salz, Rich wrote: > Try this patch do util/domd ... > else > ${MAKEDEPEND} -D OPENSSL_DOING_MAKEDEPEND $@ && \ > - ${PERL} $TOP/util/clean-depend.pl < Makefile > Makefile.new > + sed -e 's# /\(\\.\|[^ ]\)*##g' -e '/: *$/d' -e '/^\(#.*\| *\)$/d' \ > + >Makefile.new Isn't that missing some input file? With just that patch make depend "hangs". This one seems to be better, i.e., it generates Makefile(s) on my system: diff --git a/util/domd b/util/domd index 16de5c7..4240594 100755 --- a/util/domd +++ b/util/domd @@ -26,12 +26,13 @@ if ${MAKEDEPEND} --version 2>&1 | grep "clang" > /dev/null || sed -e '/^# DO NOT DELETE.*/,$d' < Makefile > Makefile.tmp echo '# DO NOT DELETE THIS LINE -- make depend depends on it.' >> Makefile.tmp ${MAKEDEPEND} -Werror -D OPENSSL_DOING_MAKEDEPEND -M $args >> Makefile.tmp || exit 1 - ${PERL} $TOP/util/clean-depend.pl < Makefile.tmp > Makefile.new - RC=$? + sed -e 's# /\(\\.\|[^ ]\)*##g' -e '/: *$/d' -e '/^\(#.*\| *\)$/d' \ + Makefile.new rm -f Makefile.tmp else ${MAKEDEPEND} -D OPENSSL_DOING_MAKEDEPEND $@ && \ - ${PERL} $TOP/util/clean-depend.pl < Makefile > Makefile.new + sed -e 's# /\(\\.\|[^ ]\)*##g' -e '/: *$/d' -e '/^\(#.*\| *\)$/d' \ + Makefile.new RC=$? fi mv Makefile.new Makefile From openssl-users at dukhovni.org Thu Jan 21 15:05:59 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 21 Jan 2016 10:05:59 -0500 Subject: [openssl-dev] openssl-SNAP-20160121 issues In-Reply-To: <20160121135602.GA6020@doctor.nl2k.ab.ca> References: <20160121135602.GA6020@doctor.nl2k.ab.ca> Message-ID: <45B46BF9-FA4D-470C-B64D-8243FD7CB6B9@dukhovni.org> > On Jan 21, 2016, at 8:56 AM, The Doctor wrote: > > > All right > > gcc -I.. -I../.. -I../modes -I../include -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=i486 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c str_lib.c > str_lib.c: In function `STORE_generate_key': > str_lib.c:423: dereferencing pointer to incomplete type > str_lib.c: In function `STORE_get_private_key': > str_lib.c:447: dereferencing pointer to incomplete type > str_lib.c: In function `STORE_store_private_key': > str_lib.c:477: dereferencing pointer to incomplete type > str_lib.c: In function `STORE_list_private_key_next': > str_lib.c:581: dereferencing pointer to incomplete type > str_lib.c: In function `STORE_get_public_key': > str_lib.c:631: dereferencing pointer to incomplete type > str_lib.c: In function `STORE_store_public_key': > str_lib.c:661: dereferencing pointer to incomplete type > str_lib.c: In function `STORE_list_public_key_next': > str_lib.c:765: dereferencing pointer to incomplete type The fix for now is to not build the store code, it is not ready. -- Viktor. From rt at openssl.org Thu Jan 21 15:50:28 2016 From: rt at openssl.org (Alan Bocutt via RT) Date: Thu, 21 Jan 2016 15:50:28 +0000 Subject: [openssl-dev] [openssl.org #4261] BUG unable to connect to Mysql via ssl connection. In-Reply-To: References: Message-ID: I am currently running Ubuntu with Mysql and am unable to connect via an ssl connection to the database getting following error. error 2026 (hy000): ssl connection error: protocol version mismatch My installation details are as follows Ubuntu version Linux ubuntu-365sussex 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Installed Version info for OpenSSL OpenSSL 1.0.1f 6 Jan 2014 built on: Fri Dec 4 13:55:16 UTC 2015 platform: debian-amd64 options: bn(64,64) rc4(8x,int) des(idx,cisc,16,int) blowfish(idx) compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: "/usr/lib/ssl" Mysql version mysql> show variables like "%version%" -> ; +-------------------------+-------------------------+ | Variable_name | Value | +-------------------------+-------------------------+ | innodb_version | 5.6.27 | | protocol_version | 10 | | slave_type_conversions | | | version | 5.6.27-0ubuntu0.14.04.1 | | version_comment | (Ubuntu) | | version_compile_machine | x86_64 | | version_compile_os | debian-linux-gnu | +-------------------------+-------------------------+ 7 rows in set (0.00 sec) Mysql SSL info mysql> show variables Like "%ssl%"; +---------------+-------------------------------------+ | Variable_name | Value | +---------------+-------------------------------------+ | have_openssl | YES | | have_ssl | YES | | ssl_ca | /etc/mysql/newcerst/ca.pem | | ssl_capath | | | ssl_cert | /etc/mysql/newcerts/server-cert.pem | | ssl_cipher | | | ssl_crl | | | ssl_crlpath | | | ssl_key | /etc/mysql/newcerts/server-key.pem | +---------------+-------------------------------------+ 9 rows in set (0.00 sec) mysql> notee; Not sure what more info you need or want please ask.. Regards Alan Bocutt 365Sussex Limited From rt at openssl.org Thu Jan 21 16:13:39 2016 From: rt at openssl.org (Alan Bocutt via RT) Date: Thu, 21 Jan 2016 16:13:39 +0000 Subject: [openssl-dev] [openssl.org #4261] AutoReply: BUG unable to connect to Mysql via ssl connection. In-Reply-To: References: Message-ID: Apologies, spotted my own error when reading you notification error path incorrect for ssl_ca certificate file.. Many Thanks Alan -----Original Message----- From: The default queue via RT [mailto:rt at openssl.org] Sent: 21 January 2016 15:50 To: alan.bocutt at outlook.com Subject: [openssl.org #4261] AutoReply: BUG unable to connect to Mysql via ssl connection. Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "BUG unable to connect to Mysql via ssl connection.", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [openssl.org #4261]. Please include the string: [openssl.org #4261] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, rt at openssl.org ------------------------------------------------------------------------- I am currently running Ubuntu with Mysql and am unable to connect via an ssl connection to the database getting following error. error 2026 (hy000): ssl connection error: protocol version mismatch My installation details are as follows Ubuntu version Linux ubuntu-365sussex 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Installed Version info for OpenSSL OpenSSL 1.0.1f 6 Jan 2014 built on: Fri Dec 4 13:55:16 UTC 2015 platform: debian-amd64 options: bn(64,64) rc4(8x,int) des(idx,cisc,16,int) blowfish(idx) compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: "/usr/lib/ssl" Mysql version mysql> show variables like "%version%" -> ; +-------------------------+-------------------------+ | Variable_name | Value | +-------------------------+-------------------------+ | innodb_version | 5.6.27 | | protocol_version | 10 | | slave_type_conversions | | | version | 5.6.27-0ubuntu0.14.04.1 | | version_comment | (Ubuntu) | | version_compile_machine | x86_64 | | version_compile_os | debian-linux-gnu | +-------------------------+-------------------------+ 7 rows in set (0.00 sec) Mysql SSL info mysql> show variables Like "%ssl%"; +---------------+-------------------------------------+ | Variable_name | Value | +---------------+-------------------------------------+ | have_openssl | YES | | have_ssl | YES | | ssl_ca | /etc/mysql/newcerst/ca.pem | | ssl_capath | | | ssl_cert | /etc/mysql/newcerts/server-cert.pem | | ssl_cipher | | | ssl_crl | | | ssl_crlpath | | | ssl_key | /etc/mysql/newcerts/server-key.pem | +---------------+-------------------------------------+ 9 rows in set (0.00 sec) mysql> notee; Not sure what more info you need or want please ask.. Regards Alan Bocutt 365Sussex Limited From rt at openssl.org Thu Jan 21 16:15:57 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 21 Jan 2016 16:15:57 +0000 Subject: [openssl-dev] [openssl.org #4261] BUG unable to connect to Mysql via ssl connection. In-Reply-To: References: Message-ID: closing per request of original submitter. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Jan 21 16:24:06 2016 From: rt at openssl.org (Daniel Kahn Gillmor via RT) Date: Thu, 21 Jan 2016 16:24:06 +0000 Subject: [openssl-dev] [openssl.org #4261] BUG unable to connect to Mysql via ssl connection. In-Reply-To: <87zivy52aw.fsf@alice.fifthhorseman.net> References: <87zivy52aw.fsf@alice.fifthhorseman.net> Message-ID: On Thu 2016-01-21 10:50:28 -0500, Alan Bocutt via RT wrote: > I am currently running Ubuntu with Mysql and am unable to connect via an ssl > connection to the database getting following error. > > error 2026 (hy000): ssl connection error: protocol version mismatch > > My installation details are as follows > > Ubuntu version > > Linux ubuntu-365sussex 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 > 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > Installed Version info for OpenSSL > > OpenSSL 1.0.1f 6 Jan 2014 iirc, mysql doesn't use openssl at all, due to licensing incompatibilities. It uses a separate TLS implementation entirely, but i don't recall whether it's an embedded copy of CYAssl these days or something else. I think this question belongs in a MySQL forum, not an OpenSSL forum. --dkg From dkg at fifthhorseman.net Thu Jan 21 16:23:51 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 21 Jan 2016 11:23:51 -0500 Subject: [openssl-dev] [openssl.org #4261] BUG unable to connect to Mysql via ssl connection. In-Reply-To: References: Message-ID: <87zivy52aw.fsf@alice.fifthhorseman.net> On Thu 2016-01-21 10:50:28 -0500, Alan Bocutt via RT wrote: > I am currently running Ubuntu with Mysql and am unable to connect via an ssl > connection to the database getting following error. > > error 2026 (hy000): ssl connection error: protocol version mismatch > > My installation details are as follows > > Ubuntu version > > Linux ubuntu-365sussex 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 > 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > Installed Version info for OpenSSL > > OpenSSL 1.0.1f 6 Jan 2014 iirc, mysql doesn't use openssl at all, due to licensing incompatibilities. It uses a separate TLS implementation entirely, but i don't recall whether it's an embedded copy of CYAssl these days or something else. I think this question belongs in a MySQL forum, not an OpenSSL forum. --dkg From todd.farmer at oracle.com Thu Jan 21 16:50:17 2016 From: todd.farmer at oracle.com (Todd Farmer) Date: Thu, 21 Jan 2016 09:50:17 -0700 Subject: [openssl-dev] [openssl.org #4261] BUG unable to connect to Mysql via ssl connection. In-Reply-To: <87zivy52aw.fsf@alice.fifthhorseman.net> References: <87zivy52aw.fsf@alice.fifthhorseman.net> Message-ID: <56A10C49.8000400@oracle.com> Hi, On 1/21/2016 9:23 AM, Daniel Kahn Gillmor wrote: > On Thu 2016-01-21 10:50:28 -0500, Alan Bocutt via RT wrote: >> I am currently running Ubuntu with Mysql and am unable to connect via an ssl >> connection to the database getting following error. >> >> error 2026 (hy000): ssl connection error: protocol version mismatch >> >> My installation details are as follows >> >> Ubuntu version >> >> Linux ubuntu-365sussex 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 >> 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> >> Installed Version info for OpenSSL >> >> OpenSSL 1.0.1f 6 Jan 2014 > > iirc, mysql doesn't use openssl at all, due to licensing > incompatibilities. It uses a separate TLS implementation entirely, but > i don't recall whether it's an embedded copy of CYAssl these days or > something else. I think this question belongs in a MySQL forum, not an > OpenSSL forum. Commercial-licensed MySQL binaries use OpenSSL; GPL-licensed MySQL binaries use yaSSL. Some downstream forks and/or distros may be less concerned with license incompatibilities between GPL and OpenSSL. I agree that this is a MySQL-focused question rather than OpenSSL-specific issue - help can be found on forums.mysql.com, or email me directly. Thanks, -- Todd Farmer Director, Technical Product Management, MySQL MySQL @ Oracle From ca+ssl-dev at esmtp.org Thu Jan 21 16:52:16 2016 From: ca+ssl-dev at esmtp.org (Claus Assmann) Date: Thu, 21 Jan 2016 08:52:16 -0800 Subject: [openssl-dev] OpenSSL-1.1 make depend In-Reply-To: <20160121142957.GA18239@x2.esmtp.org> References: <20160121.111956.1367674790719557989.levitte@openssl.org> <1d3dadf8b4f74a70a3d7ddef56ccb8f5@usma1ex-dag1mb1.msg.corp.akamai.com> <20160121142957.GA18239@x2.esmtp.org> Message-ID: <20160121165216.GA18920@x2.esmtp.org> Hmm, something is wrong with this new approach (or just on my machine?) Several targets have been removed from Makefile and hence broke it: --- crypto/Makefile- Thu Jan 21 08:48:08 2016 +++ crypto/Makefile Thu Jan 21 08:48:14 2016 @@ -1,4 +1,3 @@ -# Generated from Makefile.in, do not edit # # OpenSSL/crypto/Makefile # @@ -48,7 +47,6 @@ ALL= $(GENERAL) $(SRC) $(HEADER) -top: @(cd ..; $(MAKE) DIRS=$(DIR) all) all: shared @@ -86,10 +84,8 @@ arm64cpuid.S: arm64cpuid.pl; $(PERL) arm64cpuid.pl $(PERLASM_SCHEME) > $@ armv4cpuid.S: armv4cpuid.pl; $(PERL) armv4cpuid.pl $(PERLASM_SCHEME) > $@ -subdirs: @target=all; $(RECURSIVE_MAKE) -files: $(PERL) $(TOP)/util/files.pl "CPUID_OBJ=$(CPUID_OBJ)" Makefile >> $(TOP)/MINFO @target=files; $(RECURSIVE_MAKE) @@ -105,17 +101,297 @@ (cd ..; $(MAKE) $(SHARED_LIB)); \ fi -libs: @target=lib; $(RECURSIVE_MAKE) -depend: @[ -z "$(THIS)" -o -f buildinf.h ] || touch buildinf.h # fake buildinf.h if it does not exist @[ -z "$(THIS)" ] || $(MAKEDEPEND) -- $(CFLAG) $(INCLUDE) $(DEPFLAG) -- $(PROGS) $(LIBSRC) @[ -z "$(THIS)" -o -s buildinf.h ] || rm buildinf.h @[ -z "$(THIS)" ] || (set -e; target=depend; $(RECURSIVE_MAKE) ) @if [ -z "$(THIS)" ]; then $(MAKE) -f $(TOP)/Makefile reflect THIS=$@; fi -clean: rm -f buildinf.h *.s *.o */*.o *.obj lib tags core .pure .nfs* *.old *.bak fluff @target=clean; $(RECURSIVE_MAKE) # DO NOT DELETE THIS LINE -- make depend depends on it. + +cryptlib.o: include/internal/cryptlib.husr/include/stdlib.h .... From tom.kacvinsky at vectorcast.com Thu Jan 21 16:53:19 2016 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Thu, 21 Jan 2016 11:53:19 -0500 Subject: [openssl-dev] version script patch from Debian Message-ID: I ran into this problem with the OpenSSL 1.0.1e I built from source on a Debian based system (Ubuntu): libssl.so.1.0.0: no version information available (required by python) Found this page: http://ubuntuforums.org/showthread.php?t=1905963 to work around the issue, but the question is, is the version script they provide good enough for 1.0.1e? Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Jan 21 17:11:27 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 21 Jan 2016 17:11:27 +0000 Subject: [openssl-dev] OpenSSL-1.1 make depend In-Reply-To: <20160121165216.GA18920@x2.esmtp.org> References: <20160121.111956.1367674790719557989.levitte@openssl.org> <1d3dadf8b4f74a70a3d7ddef56ccb8f5@usma1ex-dag1mb1.msg.corp.akamai.com> <20160121142957.GA18239@x2.esmtp.org> <20160121165216.GA18920@x2.esmtp.org> Message-ID: <0dc934d5a71442c69ced471203a990b1@usma1ex-dag1mb1.msg.corp.akamai.com> Yes the script is wrong. Thanks for trying. Working on a real fix :( From matt at openssl.org Thu Jan 21 17:14:32 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 21 Jan 2016 17:14:32 +0000 Subject: [openssl-dev] version script patch from Debian In-Reply-To: References: Message-ID: <56A111F8.7050005@openssl.org> On 21/01/16 16:53, Tom Kacvinsky wrote: > I ran into this problem with the OpenSSL 1.0.1e I built from source on a > Debian based system (Ubuntu): > > libssl.so.1.0.0: no version information available (required by python) > > Found this page: > > http://ubuntuforums.org/showthread.php?t=1905963 > > to work around the issue, but the question is, is the version script > they provide good enough for 1.0.1e? A few things spring to mind here. Firstly 1.0.1e is really old (pre-heartbleed) and really shouldn't be used. I'd suggest you upgrade to 1.0.2e if you can (or 1.0.1q if it has to be 1.0.1). The simplest fix for this is to ensure that system installed applications always pick up the system installed libraries, and only use your locally compiled version for applications that need it. The version script that debian provide should be fine generally, but there is always the risk of a mismatch, i.e. if there are symbols defined in your local version not in the version script. The link in the above thread is for precise which was based on 1.0.1 (not 1.0.1e) so if there were any symbols added between 1.0.1 and 1.0.1e then you would be missing those (generally new symbols are avoided in letter releases so there may not be any). Finally, I'd point out that I recently added symbol version information (for linux) into the forthcoming 1.1.0, so in the future this (hopefully) won't be a problem. Matt From hyc at highlandsun.com Thu Jan 21 17:33:51 2016 From: hyc at highlandsun.com (Howard Chu) Date: Thu, 21 Jan 2016 17:33:51 +0000 Subject: [openssl-dev] OpenSSL 1.1 SSL_CTX issues Message-ID: <56A1167F.2050700@highlandsun.com> In OpenLDAP we've been using CRYPTO_add(&ctx->references, 1, CRYPTO_LOCK_SSL_CTX) to manage our own SSL_CTXs but this is not possible with current 1.1. Making the structures opaque is a good move, but please provide methods to manipulate refcounts. Currently ssl_lib.c appears to bump the ctx refcount twice, in SSL_new. Why is that? https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L670 https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L681 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From erik at efca.com Thu Jan 21 17:57:22 2016 From: erik at efca.com (Erik Forsberg) Date: Thu, 21 Jan 2016 09:57:22 -0800 Subject: [openssl-dev] OpenSSL-1.1 make depend In-Reply-To: <20160121165216.GA18920@x2.esmtp.org> References: <20160121165216.GA18920@x2.esmtp.org> Message-ID: <-dz8YLsQJ0ktS-0@srv.efca.com> No, same thing happens here too >-- Original Message -- > >Hmm, something is wrong with this new approach (or just on my machine?) >Several targets have been removed from Makefile and hence broke it: > >--- crypto/Makefile- Thu Jan 21 08:48:08 2016 >+++ crypto/Makefile Thu Jan 21 08:48:14 2016 >@@ -1,4 +1,3 @@ >-# Generated from Makefile.in, do not edit > # > # OpenSSL/crypto/Makefile > # >@@ -48,7 +47,6 @@ > > ALL= $(GENERAL) $(SRC) $(HEADER) > >-top: > @(cd ..; $(MAKE) DIRS=$(DIR) all) > > all: shared >@@ -86,10 +84,8 @@ > arm64cpuid.S: arm64cpuid.pl; $(PERL) arm64cpuid.pl $(PERLASM_SCHEME) > $@ > armv4cpuid.S: armv4cpuid.pl; $(PERL) armv4cpuid.pl $(PERLASM_SCHEME) > $@ > >-subdirs: > @target=all; $(RECURSIVE_MAKE) > >-files: > $(PERL) $(TOP)/util/files.pl "CPUID_OBJ=$(CPUID_OBJ)" Makefile >> $(TOP)/MINFO > @target=files; $(RECURSIVE_MAKE) > >@@ -105,17 +101,297 @@ > (cd ..; $(MAKE) $(SHARED_LIB)); \ > fi > >-libs: > @target=lib; $(RECURSIVE_MAKE) > >-depend: > @[ -z "$(THIS)" -o -f buildinf.h ] || touch buildinf.h # fake buildinf.h if it does not exist > @[ -z "$(THIS)" ] || $(MAKEDEPEND) -- $(CFLAG) $(INCLUDE) $(DEPFLAG) -- $(PROGS) $(LIBSRC) > @[ -z "$(THIS)" -o -s buildinf.h ] || rm buildinf.h > @[ -z "$(THIS)" ] || (set -e; target=depend; $(RECURSIVE_MAKE) ) > @if [ -z "$(THIS)" ]; then $(MAKE) -f $(TOP)/Makefile reflect THIS=$@; fi >-clean: > rm -f buildinf.h *.s *.o */*.o *.obj lib tags core .pure .nfs* *.old *.bak fluff > @target=clean; $(RECURSIVE_MAKE) > > # DO NOT DELETE THIS LINE -- make depend depends on it. >+ >+cryptlib.o: include/internal/cryptlib.husr/include/stdlib.h > >.... >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From openssl-users at dukhovni.org Thu Jan 21 17:57:43 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 21 Jan 2016 17:57:43 +0000 Subject: [openssl-dev] OpenSSL 1.1 SSL_CTX issues In-Reply-To: <56A1167F.2050700@highlandsun.com> References: <56A1167F.2050700@highlandsun.com> Message-ID: <20160121175743.GB25513@mournblade.imrryr.org> On Thu, Jan 21, 2016 at 05:33:51PM +0000, Howard Chu wrote: > In OpenLDAP we've been using > CRYPTO_add(&ctx->references, 1, CRYPTO_LOCK_SSL_CTX) > to manage our own SSL_CTXs but this is not possible with current 1.1. Making > the structures opaque is a good move, but please provide methods to > manipulate refcounts. > > Currently ssl_lib.c appears to bump the ctx refcount twice, in SSL_new. Why > is that? Because the SSL handle has two references to the SSL_CTX. ssl->ctx ssl->initial_ctx they are initially the same, but may diverge. These are freed independently. Indeed there are at present no SSL_up_ref() or SSL_CTX_up_ref() functions. The up_ref functions are at present: include/openssl/rsa.h:int RSA_up_ref(RSA *r); include/openssl/ec.h:int EC_KEY_up_ref(EC_KEY *key); include/openssl/dh.h:int DH_up_ref(DH *dh); include/openssl/dsa.h:int DSA_up_ref(DSA *r); include/openssl/evp.h:void EVP_PKEY_up_ref(EVP_PKEY *pkey); include/openssl/x509.h:void X509_up_ref(X509 *x); include/openssl/x509.h:void X509_CRL_up_ref(X509_CRL *crl); include/openssl/x509.h:STACK_OF(X509) *X509_chain_up_ref(STACK_OF(X509) *chain); include/openssl/x509_vfy.h:void X509_OBJECT_up_ref_count(X509_OBJECT *a); include/openssl/dso.h:int DSO_up_ref(DSO *dso); include/openssl/engine.h:int ENGINE_up_ref(ENGINE *e); -- Viktor. From hyc at highlandsun.com Thu Jan 21 17:58:01 2016 From: hyc at highlandsun.com (Howard Chu) Date: Thu, 21 Jan 2016 17:58:01 +0000 Subject: [openssl-dev] OpenSSL 1.1 X509_NAME issues Message-ID: <56A11C29.4070907@highlandsun.com> In OpenLDAP we reference X509_NAME->bytes->data directly, we want the DER bytes which we then pass thru our own DN validator/formatter. This no longer works with OpenSSL 1.1 and I don't see any provided method to return the DER bytes. I don't want a malloc'd copy, I just want read-only access to the bytes already cached inside the X509_NAME structure. for reference: https://github.com/openldap/openldap/blob/master/libraries/libldap/tls_o.c#L448 https://github.com/openldap/openldap/blob/master/libraries/libldap/tls_o.c#L475 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From tom.kacvinsky at vectorcast.com Thu Jan 21 18:51:16 2016 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Thu, 21 Jan 2016 13:51:16 -0500 Subject: [openssl-dev] version script patch from Debian In-Reply-To: <56A111F8.7050005@openssl.org> References: <56A111F8.7050005@openssl.org> Message-ID: On Thu, Jan 21, 2016 at 12:14 PM, Matt Caswell wrote: > > > > On 21/01/16 16:53, Tom Kacvinsky wrote: > > I ran into this problem with the OpenSSL 1.0.1e I built from source on a > > Debian based system (Ubuntu): > > > > libssl.so.1.0.0: no version information available (required by python) > > > > Found this page: > > > > http://ubuntuforums.org/showthread.php?t=1905963 > > > > to work around the issue, but the question is, is the version script > > they provide good enough for 1.0.1e? > > A few things spring to mind here. Firstly 1.0.1e is really old > (pre-heartbleed) and really shouldn't be used. I'd suggest you upgrade > to 1.0.2e if you can (or 1.0.1q if it has to be 1.0.1). Unforuntately, this is a no can do right now. We are using OpenSSL for client code only (OpenSSL support in Qt) and are not in a position to change right now. > > > The simplest fix for this is to ensure that system installed > applications always pick up the system installed libraries, and only use > your locally compiled version for applications that need it. > Using locally compiled version for only our applications. > The version script that debian provide should be fine generally, but > there is always the risk of a mismatch, i.e. if there are symbols > defined in your local version not in the version script. The link in the > above thread is for precise which was based on 1.0.1 (not 1.0.1e) so if > there were any symbols added between 1.0.1 and 1.0.1e then you would be > missing those (generally new symbols are avoided in letter releases so > there may not be any). Only one missing symbol, the memcmp symbol. > > Finally, I'd point out that I recently added symbol version information > (for linux) into the forthcoming 1.1.0, so in the future this > (hopefully) won't be a problem. Nice! I bet Linux distribution maintainers will love this. From rt at openssl.org Thu Jan 21 19:43:47 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 21 Jan 2016 19:43:47 +0000 Subject: [openssl-dev] [openssl.org #3248] Bug - OpenSSL 0.9.8 crashes randomly at the call to BIO_test_flags() In-Reply-To: <45A8CAC130F2FA498F127CD09DD4EFF8045F92A7@XMBC3083.northgrum.com> References: <45A8CAC130F2FA498F127CD09DD4EFF8045F92A7@XMBC3083.northgrum.com> Message-ID: looks like user error; don't pass a NULL pointer. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Jan 21 21:11:13 2016 From: rt at openssl.org (Short, Todd via RT) Date: Thu, 21 Jan 2016 21:11:13 +0000 Subject: [openssl-dev] [openssl.org #4262] Fwd: Configure script warns when no configurations changes occur In-Reply-To: <136C1EAA-AC99-4317-9211-690ED54505DE@akamai.com> References: <136C1EAA-AC99-4317-9211-690ED54505DE@akamai.com> Message-ID: Hello, When ./config is run, the Configure script always complains about 'make depend? needing to be run because the $default_depflags and $depflags do not match. Recent changes to Configure automatically create $default_depflags, but takes special exceptions for shared, zip, hw and asm, which are not normally put into $default_depflags but are put into |$depflags| causing a mismatch leading to the warning. I have a patch, but am waiting for the RT to be created first. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." From rt at openssl.org Thu Jan 21 21:19:31 2016 From: rt at openssl.org (Short, Todd via RT) Date: Thu, 21 Jan 2016 21:19:31 +0000 Subject: [openssl-dev] [openssl.org #4262] Fwd: Configure script warns when no configurations changes occur In-Reply-To: References: <136C1EAA-AC99-4317-9211-690ED54505DE@akamai.com> Message-ID: Added pull request: https://github.com/openssl/openssl/pull/578 -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Jan 21, 2016, at 4:11 PM, Short, Todd via RT > wrote: Hello, When ./config is run, the Configure script always complains about 'make depend? needing to be run because the $default_depflags and $depflags do not match. Recent changes to Configure automatically create $default_depflags, but takes special exceptions for shared, zip, hw and asm, which are not normally put into $default_depflags but are put into |$depflags| causing a mismatch leading to the warning. I have a patch, but am waiting for the RT to be created first. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Thu Jan 21 21:23:31 2016 From: rt at openssl.org (Short, Todd via RT) Date: Thu, 21 Jan 2016 21:23:31 +0000 Subject: [openssl-dev] [openssl.org #4263] store does not compile with opaque data structures In-Reply-To: <131FB596-0881-4ADD-A573-D18A2420E142@akamai.com> References: <131FB596-0881-4ADD-A573-D18A2420E142@akamai.com> Message-ID: Hello, When experimental-store is enabled in the master branch, the compile fails, due to structures that are now opaque. I have a patch, but am waiting for the RT to be created first. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." From rt at openssl.org Thu Jan 21 21:26:40 2016 From: rt at openssl.org (Short, Todd via RT) Date: Thu, 21 Jan 2016 21:26:40 +0000 Subject: [openssl-dev] [openssl.org #4263] store does not compile with opaque data structures In-Reply-To: References: <131FB596-0881-4ADD-A573-D18A2420E142@akamai.com> Message-ID: I added a pull request: https://github.com/openssl/openssl/pull/579 -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Jan 21, 2016, at 4:23 PM, Short, Todd via RT > wrote: Hello, When experimental-store is enabled in the master branch, the compile fails, due to structures that are now opaque. I have a patch, but am waiting for the RT to be created first. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From levitte at openssl.org Fri Jan 22 00:20:54 2016 From: levitte at openssl.org (Richard Levitte) Date: Fri, 22 Jan 2016 01:20:54 +0100 (CET) Subject: [openssl-dev] [eng_rdrand] alloc and free In-Reply-To: References: Message-ID: <20160122.012054.39432466456966917.levitte@openssl.org> In message on Thu, 21 Jan 2016 10:57:19 +0000, Catalin Vasile said: cata.vasile> ENGINE_load_rdrand() creates a new engine, it adds cata.vasile> it/registers it and then frees it. Looking further into cata.vasile> these functions, the registration does NOT create a new cata.vasile> object and then copy the data into it, so the cata.vasile> registration is based on an object that it's later cata.vasile> released. Welllll.... not quite! Pointers to engines aren't merely pointers, they are more like handles and have reference counters. So, the called `ENGINE *toad = ENGINE_rdrand()' will create the reference to a new ENGINE object, that is correct. Three lines later, the call `ENGINE_add(toadd)' will create a new reference to the same object, by incrementing the reference counter, and will store the pointer to the object in OpenSSL's internal list. The following call `ENGINE_free(toadd)' simply decrements the reference counter (from 2 to 1) but does not actually free the object (that would require another ENGINE_free). Does that make it clearer? For further info, may I suggest you do `perldoc doc/crypto/engine.pod', and most specifically read the section titled "Reference counting and handles"? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Fri Jan 22 12:20:52 2016 From: rt at openssl.org (Claus Assmann via RT) Date: Fri, 22 Jan 2016 12:20:52 +0000 Subject: [openssl-dev] [openssl.org #4264] [typo] doc/crypto/X509_LOOKUP_hash_dir.pod In-Reply-To: <20160122122033.GA24311@x2.esmtp.org> References: <20160122122033.GA24311@x2.esmtp.org> Message-ID: diff --git a/doc/crypto/X509_LOOKUP_hash_dir.pod b/doc/crypto/X509_LOOKUP_hash_dir.pod index 680a9fd..7a5d684 100644 --- a/doc/crypto/X509_LOOKUP_hash_dir.pod +++ b/doc/crypto/X509_LOOKUP_hash_dir.pod @@ -24,7 +24,7 @@ lookup methods B and B are two certificate lookup methods to use with B, provided by OpenSSL library. -Users of the library typically do not need to create instanses of these +Users of the library typically do not need to create instances of these methods manually, they would be created automatically by L or L From rt at openssl.org Fri Jan 22 13:50:58 2016 From: rt at openssl.org (Claus Assmann via RT) Date: Fri, 22 Jan 2016 13:50:58 +0000 Subject: [openssl-dev] [openssl.org #4264] [typo] doc/crypto/X509_LOOKUP_hash_dir.pod In-Reply-To: <20160122135047.GA24765@x2.esmtp.org> References: <20160122122033.GA24311@x2.esmtp.org> <20160122135047.GA24765@x2.esmtp.org> Message-ID: More spelling errors, and the text about "is sequentual number" should probably be rewritten. diff --git a/doc/crypto/X509_LOOKUP_hash_dir.pod b/doc/crypto/X509_LOOKUP_hash_dir.pod index 680a9fd..fab28b6 100644 --- a/doc/crypto/X509_LOOKUP_hash_dir.pod +++ b/doc/crypto/X509_LOOKUP_hash_dir.pod @@ -24,7 +24,7 @@ lookup methods B and B are two certificate lookup methods to use with B, provided by OpenSSL library. -Users of the library typically do not need to create instanses of these +Users of the library typically do not need to create instances of these methods manually, they would be created automatically by L or L @@ -86,7 +86,7 @@ function of with option B<-hash> of L or L command. This hash value is appended by suffix .I for certificates and -B<.r>I for CRLs where I is sequentual +B<.r>I for CRLs where I is sequential number among certificates with same hash value, so it is possible to have in the store several certificates with same subject or several CRLs with same issuer (and, for example, different validity period). @@ -96,7 +96,7 @@ hash_dir lookup method checks only for certificates with sequentual number greater than one of already cached CRL. Note that hash algorithm used for subject hashing is changed in OpenSSL -1.0, so all certificate stores have to be rehashed upon transitopn from +1.0, so all certificate stores have to be rehashed upon transition from 0.9.8 to 1.0.0. OpenSSL includes utility L which creates From rt at openssl.org Fri Jan 22 15:00:38 2016 From: rt at openssl.org (Short, Todd via RT) Date: Fri, 22 Jan 2016 15:00:38 +0000 Subject: [openssl-dev] [openssl.org #4265] [BUG/PATCH] OpenSSL does not compile when SRTP is disabled In-Reply-To: References: Message-ID: Hello, When SRTP is disabled, OpenSSL does not successfully compile due to an error in s_server.c I have a patch for this, I am just waiting for the RT to be created first. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." From rt at openssl.org Fri Jan 22 15:18:42 2016 From: rt at openssl.org (Short, Todd via RT) Date: Fri, 22 Jan 2016 15:18:42 +0000 Subject: [openssl-dev] [openssl.org #4265] [BUG/PATCH] OpenSSL does not compile when SRTP is disabled In-Reply-To: References: Message-ID: Apologies, apparently I already reported this problem ~5 weeks ago as RT4188. So, RT4188 and RT4265 are duplicates. However, the latest pull request is : https://github.com/openssl/openssl/pull/582 -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Jan 22, 2016, at 10:00 AM, Short, Todd via RT > wrote: Hello, When SRTP is disabled, OpenSSL does not successfully compile due to an error in s_server.c I have a patch for this, I am just waiting for the RT to be created first. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From ca+ssl-dev at esmtp.org Sat Jan 23 00:35:52 2016 From: ca+ssl-dev at esmtp.org (Claus Assmann) Date: Fri, 22 Jan 2016 16:35:52 -0800 Subject: [openssl-dev] SSL_get0_dane_authority() and session reuse Message-ID: <20160123003552.GA23855@x2.esmtp.org> SSL_get0_dane_authority() returns -1 on a reused TLS session in my test program. Is that - expected? - a problem with my test program? - an error in SSL_get0_dane_authority()? From rt at openssl.org Sat Jan 23 01:29:27 2016 From: rt at openssl.org (deengert@gmail.com via RT) Date: Sat, 23 Jan 2016 01:29:27 +0000 Subject: [openssl-dev] [openssl.org #4266] OpenSSL-1.1-pre2 cms can not use engine with parameters to sign cms msg In-Reply-To: <56A2D596.8020805@gmail.com> References: <56A2D596.8020805@gmail.com> Message-ID: The inkey parameter of the cms command does not does not accept parameters for an engine to sign the message. P.S. Also attached are the changes for req.c. to use the key to hold engine parameters. See #4226 -- Douglas E. Engert -------------- next part -------------- A non-text attachment was scrubbed... Name: use.apps.with.smartcard.diff Type: text/x-patch Size: 2000 bytes Desc: not available URL: From openssl-users at dukhovni.org Sat Jan 23 02:47:14 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 22 Jan 2016 21:47:14 -0500 Subject: [openssl-dev] SSL_get0_dane_authority() and session reuse In-Reply-To: <20160123003552.GA23855@x2.esmtp.org> References: <20160123003552.GA23855@x2.esmtp.org> Message-ID: <4F0D1328-0D58-4C63-A374-0BE667279BFD@dukhovni.org> > On Jan 22, 2016, at 7:35 PM, Claus Assmann wrote: > > SSL_get0_dane_authority() returns -1 on a reused TLS session > in my test program. > Is that > - expected? > - a problem with my test program? > - an error in SSL_get0_dane_authority()? It is expected, but probably should be documented. With session resumption no server certificates are presented and accordingly no certificate verification takes place, so the DANE state remains in its initial unmatched form. With a re-used session, only the verification state (X509_V_OK or error value) of the peer certificate is retained in the session, the chain and DANE state are not retained. So with resumption enabled, and for re-used sessions check only the verify result, and skip any attempt to discover the match depth, TLSA RR values, ... those were available only with the original session. Perhaps the example in the manpage should cover this in brief? -- Viktor. From rt at openssl.org Sat Jan 23 09:40:19 2016 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Sat, 23 Jan 2016 09:40:19 +0000 Subject: [openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv In-Reply-To: References: Message-ID: Hello, After making the EVP_CIPHER_CTX struct opaque I found that there is a missing non-const accessor to the oiv member. It is used in GOST engine when we set the cipher parameters from the ASN1 parameters. Thank you! -- SY, Dmitry Belyavsky From ca+ssl-dev at esmtp.org Sat Jan 23 11:42:38 2016 From: ca+ssl-dev at esmtp.org (Claus Assmann) Date: Sat, 23 Jan 2016 03:42:38 -0800 Subject: [openssl-dev] SSL_get0_dane_authority() and session reuse In-Reply-To: <4F0D1328-0D58-4C63-A374-0BE667279BFD@dukhovni.org> References: <20160123003552.GA23855@x2.esmtp.org> <4F0D1328-0D58-4C63-A374-0BE667279BFD@dukhovni.org> Message-ID: <20160123114238.GA22647@x2.esmtp.org> On Fri, Jan 22, 2016, Viktor Dukhovni wrote: > > On Jan 22, 2016, at 7:35 PM, Claus Assmann wrote: > > SSL_get0_dane_authority() returns -1 on a reused TLS session > > in my test program. > It is expected, but probably should be documented. Thanks; is there any chance to change that behaviour? Let me explain what I'm trying to do (sorry for not including that in the original mail): For SMTP STARTTLS I try to determine some properties of the TLS connection so the MTA can decide whether the connection should be aborted or continue. Those properties are for example: cert issuer, cert subject, cipher bits, verification status, e.g., X509_V_OK, (all of which can be retrieved from SSL via some function calls), and in the last case I would like to know if DANE was (originally/successfully) used. I could try to store that information somehow in the TLS session context (SSL) myself, but it would make things much easier if OpenSSL can provide that information. From rt at openssl.org Sat Jan 23 13:24:31 2016 From: rt at openssl.org (Claus Assmann via RT) Date: Sat, 23 Jan 2016 13:24:31 +0000 Subject: [openssl-dev] [openssl.org #4268] [typo?] doc/ssl/SSL_get_session.pod In-Reply-To: <20160123132417.GA28814@x2.esmtp.org> References: <20160123132417.GA28814@x2.esmtp.org> Message-ID: Not sure whether this patch is right, but AFAICT SSL_get_session() does not return a "Pointer to an SSL". diff --git a/doc/ssl/SSL_get_session.pod b/doc/ssl/SSL_get_session.pod index d360e8a..d8aa705 100644 --- a/doc/ssl/SSL_get_session.pod +++ b/doc/ssl/SSL_get_session.pod @@ -58,7 +58,7 @@ The following return values can occur: There is no session available in B. -=item Pointer to an SSL +=item Pointer to an SSL_SESSION The return value points to the data of an SSL session. From rt at openssl.org Sat Jan 23 14:18:44 2016 From: rt at openssl.org (Kurt Roeckx via RT) Date: Sat, 23 Jan 2016 14:18:44 +0000 Subject: [openssl-dev] [openssl.org #4148] PCKS1 type 1 Padding check error In-Reply-To: <20160123141832.GA1789@roeckx.be> References: <81BFD559DE725D46BA495E091789F8DD016AF6C497@MAILSERV2A.lorien.fkie.fgan.de> <20160123141832.GA1789@roeckx.be> Message-ID: On Wed, Nov 18, 2015 at 03:24:51PM +0000, ?zgan, Tolgahan Jonas via RT wrote: > Dear List, > I have found a BUG in the function > " RSA_padding_check_PKCS1_type_1 " [...] > > the pointer p is incremented after the check therefore p is always the first octet of the padded string. In the Case of PKCS1 type 1 padding always p=0, hence the error. > Notes: > Changing the check to > if ((num != (flen+1)) || (*(++p) != 01)) > results also in a failure since the next check of p expects p to be "0xff" . So the problem is that at least RSA_padding_check_PKCS1_type_1() and RSA_padding_check_PKCS1_type_2() are called with the 0 byte skipped internally in OpenSSL. This is because it's the result of a BN calculation, that is turned back into a char array, but it's not padded to RSA size. So the expected 0 byte is missing as first character. And the current functions depend on that behaviour. When RSA_padding_check_PKCS1_type_2() was updated to be most constant time, it internally pads it again, and then also checks that it's starts with the 0 byte. That commit also suggested to use BN_bn2bin_padded from BoringSSL. So we could change it so it works as you expect and that the 0 byte would be included. This could potentionally break other applications that try to use those functions, so maybe the 1.1 release might be the right time to change this. Looking at all sources in Debian I only find libdigidoc that tried to use RSA_padding_check_PKCS1_type_1 but it's commented out. For RSA_padding_check_PKCS1_type_2 I found yubico-piv-tool that has a comment about needing +1 (and so fails to check the 0), and mixmaster where like in the openssl internal cases it's a result of BN_bn2bin(). Kurt From doctor at doctor.nl2k.ab.ca Sat Jan 23 15:56:41 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 23 Jan 2016 08:56:41 -0700 Subject: [openssl-dev] Openssl-SNAP-20160123 issues Re: openssl-SNAP-20160121 issues In-Reply-To: <45B46BF9-FA4D-470C-B64D-8243FD7CB6B9@dukhovni.org> References: <20160121135602.GA6020@doctor.nl2k.ab.ca> <45B46BF9-FA4D-470C-B64D-8243FD7CB6B9@dukhovni.org> Message-ID: <20160123155641.GA15443@doctor.nl2k.ab.ca> On Thu, Jan 21, 2016 at 10:05:59AM -0500, Viktor Dukhovni wrote: > > > On Jan 21, 2016, at 8:56 AM, The Doctor wrote: > > > > > > All right > > > > gcc -I.. -I../.. -I../modes -I../include -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=i486 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c str_lib.c > > str_lib.c: In function `STORE_generate_key': > > str_lib.c:423: dereferencing pointer to incomplete type > > str_lib.c: In function `STORE_get_private_key': > > str_lib.c:447: dereferencing pointer to incomplete type > > str_lib.c: In function `STORE_store_private_key': > > str_lib.c:477: dereferencing pointer to incomplete type > > str_lib.c: In function `STORE_list_private_key_next': > > str_lib.c:581: dereferencing pointer to incomplete type > > str_lib.c: In function `STORE_get_public_key': > > str_lib.c:631: dereferencing pointer to incomplete type > > str_lib.c: In function `STORE_store_public_key': > > str_lib.c:661: dereferencing pointer to incomplete type > > str_lib.c: In function `STORE_list_public_key_next': > > str_lib.c:765: dereferencing pointer to incomplete type > > The fix for now is to not build the store code, it is not ready. > When will it be ready? Also now in openssl-SNAP-20160123 to start make making all in crypto... -I. -I.. -I../include -Iinclude -DOPENSSL_THREADS -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -DWHIRLPOOL_ASM -c cryptlib.c -I.: not found *** Error code 1 Stop. *** Error code 1 Stop. What happened here? > -- > Viktor. > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From rsalz at akamai.com Sat Jan 23 16:02:35 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 23 Jan 2016 16:02:35 +0000 Subject: [openssl-dev] Openssl-SNAP-20160123 issues Re: openssl-SNAP-20160121 issues In-Reply-To: <20160123155641.GA15443@doctor.nl2k.ab.ca> References: <20160121135602.GA6020@doctor.nl2k.ab.ca> <45B46BF9-FA4D-470C-B64D-8243FD7CB6B9@dukhovni.org> <20160123155641.GA15443@doctor.nl2k.ab.ca> Message-ID: <82fd475898e84c09968cd24778a2846b@ustx2ex-dag1mb1.msg.corp.akamai.com> Perhaps it's time to level-set. Snapshots are literally snapshots of the daily tree. There's no expectation that things work, or even compile. From vinschen at redhat.com Sat Jan 23 20:27:58 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 23 Jan 2016 21:27:58 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160118.235012.1388704382358841060.levitte@openssl.org> References: <20160114.215903.813205413779228431.levitte@openssl.org> <20160118.235012.1388704382358841060.levitte@openssl.org> Message-ID: <20160123202758.GA13479@calimero.vinschen.de> Hi Richard, On Jan 18 23:50, Richard Levitte wrote: > FYI, > > The branch has been updated, the Makfile template now has install > targets as well, and I did the mods I could see would be necessary for > Cygwin and Mingw. I would appreciate it if someone could help me try > those out. > > Remember to configure with --unified. I tested this on 64 bit Cygwin and stumbled over a minor and a major problem. First, there's a typo in crypto/bn/Makefile.in, using eight spaces rather than a TAB: diff -upr origsrc/openssl-1.1-rc1/crypto/bn/Makefile.in src/openssl-1.1-rc1/crypto/bn/Makefile.in --- origsrc/openssl-1.1-rc1/crypto/bn/Makefile.in 2016-01-23 21:02:12.604753995 +0100 +++ src/openssl-1.1-rc1/crypto/bn/Makefile.in 2016-01-23 21:03:58.394966621 +0100 @@ -161,6 +161,6 @@ clean: # Different flavours of make disagree on where output goes .c.o: - $(CC) $(CFLAGS) -c $< -o $@ + $(CC) $(CFLAGS) -c $< -o $@ # DO NOT DELETE THIS LINE -- make depend depends on it. Second, the build fails trying to compile crypto/cversion.c: crypto/cversion.c:62:23: fatal error: buildinf.h: No such file or directory # include "buildinf.h" ^ The reason is that buildinf.h can't be built because util/mkbuildinf.pl requires /usr/local/bin/perl rather than /usr/bin/perl: diff -upr origsrc/openssl-1.1-rc1/util/mkbuildinf.pl src/openssl-1.1-rc1/util/mkbuildinf.pl --- origsrc/openssl-1.1-rc1/util/mkbuildinf.pl 2016-01-23 21:02:18.386710976 +0100 +++ src/openssl-1.1-rc1/util/mkbuildinf.pl 2016-01-23 21:15:19.705883094 +0100 @@ -1,4 +1,4 @@ -#!/usr/local/bin/perl +#!/usr/bin/perl my ($cflags, $platform) = @ARGV; The build eventually fails with the following error message, which I don't quite understand. The libraries should have been built before trying to build the engines due to hard dependencies, but for some reason they aren't. Sorry, I have no fix for that :( Last but not least, we have another problem with enginesdir. To allow a rolling release cycle, we have to support multiple versions of openssl in parallel. The problem here is that the enginesdir needs to be versioned to allow per-openssl version engines. The build scripts don't allow for this. Right now we're using a patch as the below one to tweak the configury to allow specifying the engines dir during build time. Would it hurt terribly to include something like the below patch? +++ src/openssl-1.1-rc1/Configure 2016-01-23 21:03:43.604076740 +0100 @@ -221,6 +221,7 @@ $config{prefix}=""; $config{openssldir}=""; $config{processor}=""; $config{libdir}=""; +$config{enginesdir}=""; $config{install_prefix}= "$ENV{'INSTALL_PREFIX'}"; $config{cross_compile_prefix}=""; $config{fipslibdir}="/usr/local/ssl/fips-2.0/lib/"; @@ -633,6 +634,10 @@ foreach (@argvcopy) { $config{libdir}=$1; } + elsif (/^--enginesdir=(.*)$/) + { + $config{enginesdir}=$1; + } elsif (/^--openssldir=(.*)$/) { $config{openssldir}=$1; @@ -893,7 +898,7 @@ if ($target{build_file} eq "Makefile" $target{multilib}="" if !-d "$config{prefix}/lib$target{multilib}"; $config{libdir}="lib$target{multilib}" if $config{libdir} eq ""; -$config{enginesdir}=$config{prefix} . "/" . $config{libdir} . "/engines"; +$config{enginesdir}=$config{prefix} . "/" . $config{libdir} . "/engines" if $config{enginesdir} eq ""; push @{$config{defines}}, map { (my $x = $_) =~ s/^OPENSSL_NO_/OPENSSL_EXPERIMENTAL_/; $x } Thanks, Corinna -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kurt at roeckx.be Sat Jan 23 20:35:58 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 23 Jan 2016 21:35:58 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160123202758.GA13479@calimero.vinschen.de> References: <20160114.215903.813205413779228431.levitte@openssl.org> <20160118.235012.1388704382358841060.levitte@openssl.org> <20160123202758.GA13479@calimero.vinschen.de> Message-ID: <20160123203557.GA11838@roeckx.be> On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna Vinschen wrote: > > Last but not least, we have another problem with enginesdir. To allow a > rolling release cycle, we have to support multiple versions of openssl > in parallel. The problem here is that the enginesdir needs to be > versioned to allow per-openssl version engines. The build scripts don't > allow for this. Right now we're using a patch as the below one to tweak > the configury to allow specifying the engines dir during build time. > Would it hurt terribly to include something like the below patch? In general, I would like to have a directory for the engines that relates to OSSL_DYNAMIC_OLDEST. Kurt From vinschen at redhat.com Sat Jan 23 21:01:16 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 23 Jan 2016 22:01:16 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160123203557.GA11838@roeckx.be> References: <20160114.215903.813205413779228431.levitte@openssl.org> <20160118.235012.1388704382358841060.levitte@openssl.org> <20160123202758.GA13479@calimero.vinschen.de> <20160123203557.GA11838@roeckx.be> Message-ID: <20160123210116.GB13479@calimero.vinschen.de> On Jan 23 21:35, Kurt Roeckx wrote: > On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna Vinschen wrote: > > > > Last but not least, we have another problem with enginesdir. To allow a > > rolling release cycle, we have to support multiple versions of openssl > > in parallel. The problem here is that the enginesdir needs to be > > versioned to allow per-openssl version engines. The build scripts don't > > allow for this. Right now we're using a patch as the below one to tweak > > the configury to allow specifying the engines dir during build time. > > Would it hurt terribly to include something like the below patch? > > In general, I would like to have a directory for the engines that > relates to OSSL_DYNAMIC_OLDEST. That probably won't work for Cygwin. The engines are linked against the versioned DLLs of the OpenSSL version they have been built for, Even assuming binary compatibility, an engine linked against openssl-1.0 will pull in openssl-1.0 DLLs, even when loaded from openssl-1.1. We have to keep the engines separate. Corinna -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kurt at roeckx.be Sat Jan 23 21:05:03 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 23 Jan 2016 22:05:03 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160123210116.GB13479@calimero.vinschen.de> References: <20160114.215903.813205413779228431.levitte@openssl.org> <20160118.235012.1388704382358841060.levitte@openssl.org> <20160123202758.GA13479@calimero.vinschen.de> <20160123203557.GA11838@roeckx.be> <20160123210116.GB13479@calimero.vinschen.de> Message-ID: <20160123210503.GA14354@roeckx.be> On Sat, Jan 23, 2016 at 10:01:16PM +0100, Corinna Vinschen wrote: > On Jan 23 21:35, Kurt Roeckx wrote: > > On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna Vinschen wrote: > > > > > > Last but not least, we have another problem with enginesdir. To allow a > > > rolling release cycle, we have to support multiple versions of openssl > > > in parallel. The problem here is that the enginesdir needs to be > > > versioned to allow per-openssl version engines. The build scripts don't > > > allow for this. Right now we're using a patch as the below one to tweak > > > the configury to allow specifying the engines dir during build time. > > > Would it hurt terribly to include something like the below patch? > > > > In general, I would like to have a directory for the engines that > > relates to OSSL_DYNAMIC_OLDEST. > > That probably won't work for Cygwin. The engines are linked against the > versioned DLLs of the OpenSSL version they have been built for, Even > assuming binary compatibility, an engine linked against openssl-1.0 will > pull in openssl-1.0 DLLs, even when loaded from openssl-1.1. We have to > keep the engines separate. How does that work on cygwin? Kurt From openssl-users at dukhovni.org Sat Jan 23 21:08:00 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 23 Jan 2016 16:08:00 -0500 Subject: [openssl-dev] SSL_get0_dane_authority() and session reuse In-Reply-To: <20160123114238.GA22647@x2.esmtp.org> References: <20160123003552.GA23855@x2.esmtp.org> <4F0D1328-0D58-4C63-A374-0BE667279BFD@dukhovni.org> <20160123114238.GA22647@x2.esmtp.org> Message-ID: <12620E33-72C4-4DD7-ADE8-7A183A19CFC3@dukhovni.org> > On Jan 23, 2016, at 6:42 AM, Claus Assmann wrote: > > For SMTP STARTTLS I try to determine some properties of the TLS > connection so the MTA can decide whether the connection should be > aborted or continue. Those properties are for example: cert issuer, > cert subject, cipher bits, verification status, e.g., X509_V_OK, > (all of which can be retrieved from SSL via some function calls), > and in the last case I would like to know if DANE was > (originally/successfully) used. > > I could try to store that information somehow in the TLS session > context (SSL) myself, but it would make things much easier if OpenSSL > can provide that information. The solution is to look at the return value of SSL_get_verify_result(). If this is X509_V_OK, then the peer's certificate chain was valid when originally verified, and continues to be valid for the resumed session, provided you're careful about which sessions are suitable for resuming for a given nexthop domain and MX host. Postfix is careful to make sure that for a DANE nexthop domain the session lookup key hashes together all the relevant policy info: Firstly: /* * The following assumes sites that use TLS in a perverse configuration: * multiple hosts per hostname, or even multiple hosts per IP address. * All this without a shared TLS session cache, and they still want to * use TLS session caching??? * * The TLS session cache records the trust chain verification status of * cached sessions. Different transports may have different CAfile or * CApath settings, perhaps to allow authenticated connections to sites * with private CA certs without trusting said private certs for other * sites. So we cannot assume that a trust chain valid for one transport * is valid for another. Therefore the client session id must include * either the transport name or the values of CAfile and CApath. We use * the transport name. * * XXX: We store only one session per lookup key. Ideally the the key maps * 1-to-1 to a server TLS session cache. We use the IP address, port and * ehlo response name to build a lookup key that works for split caches * (that announce distinct names) behind a load balancer. * * XXX: The TLS library will salt the serverid with further details of the * protocol and cipher requirements including the server ehlo response. * Deferring the helo to the digested suffix results in more predictable * SSL session lookup key lengths. */ serverid = vstring_alloc(10); smtp_key_prefix(serverid, "&", state->iterator, SMTP_KEY_FLAG_SERVICE | SMTP_KEY_FLAG_NEXTHOP /* With port */ | SMTP_KEY_FLAG_HOSTNAME | SMTP_KEY_FLAG_ADDR); Which means that the serverid lookup has a prefix of the form: &&& This is followed by "&", where the digest (sha256) combines all the key policy data that might affect the validity of a cached verification status. /* * OpenSSL will ignore cached sessions that use the wrong protocol. So we * do not need to filter out cached sessions with the "wrong" protocol, * rather OpenSSL will simply negotiate a new session. * * We salt the session lookup key with the protocol list, so that sessions * found in the cache are plausibly acceptable. * * By the time a TLS client is negotiating ciphers it has already offered to * re-use a session, it is too late to renege on the offer. So we must * not attempt to re-use sessions whose ciphers are too weak. We salt the * session lookup key with the cipher list, so that sessions found in the * cache are always acceptable. * * With DANE, (more generally any TLScontext where we specified explicit * trust-anchor or end-entity certificates) the verification status of * the SSL session depends on the specified list. Since we verify the * certificate only during the initial handshake, we must segregate * sessions with different TA lists. Note, that TA re-verification is * not possible with cached sessions, since these don't hold the complete * peer trust chain. Therefore, we compute a digest of the sorted TA * parameters and append it to the serverid. */ myserverid = tls_serverid_digest(props, protomask, cipher_list); Under the covers: mdctx = EVP_MD_CTX_create(); checkok(EVP_DigestInit_ex(mdctx, md, NULL)); digest_string(props->helo ? props->helo : ""); digest_object(&sslversion); digest_object(&protomask); digest_string(ciphers); The "helo" string is important for split caches where multiple hosts sit behind a load balancer and don't share their session caches. This is taken from in: C: EHLO S: 250- [WSP line-noise]? Then we hash the library SSL version, because the cache is shared across processes, but SSL_SESSION internals may change across library versions. The the protocol support mask, and cipherlist. This is followed by a digest of the TLSA records or applicable destination-specific trust-anchors. (Postfix uses the DANE code to implement destination-specific trust-anchors as synthetic TLSA records). The result is that cached verification state is only valid for a particular (transport, nexthop, mxhostname, ip address, helo-name, policy-digest). This ensures that all the TLS policy bits are the same as at the time the session was added to the cache. With that, there is no need to examine anything other than the verification status being X509_V_OK. You can of course still extract the peer certificate from the session, but not the full chain, or the DANE match details. -- Viktor. From levitte at openssl.org Sat Jan 23 21:08:42 2016 From: levitte at openssl.org (Richard Levitte) Date: Sat, 23 Jan 2016 22:08:42 +0100 (CET) Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160123202758.GA13479@calimero.vinschen.de> References: <20160114.215903.813205413779228431.levitte@openssl.org> <20160118.235012.1388704382358841060.levitte@openssl.org> <20160123202758.GA13479@calimero.vinschen.de> Message-ID: <20160123.220842.2219047951873553393.levitte@openssl.org> In message <20160123202758.GA13479 at calimero.vinschen.de> on Sat, 23 Jan 2016 21:27:58 +0100, Corinna Vinschen said: vinschen> Hi Richard, vinschen> vinschen> On Jan 18 23:50, Richard Levitte wrote: vinschen> > FYI, vinschen> > vinschen> > The branch has been updated, the Makfile template now has install vinschen> > targets as well, and I did the mods I could see would be necessary for vinschen> > Cygwin and Mingw. I would appreciate it if someone could help me try vinschen> > those out. vinschen> > vinschen> > Remember to configure with --unified. vinschen> vinschen> I tested this on 64 bit Cygwin and stumbled over a minor and a major vinschen> problem. First, there's a typo in crypto/bn/Makefile.in, using eight vinschen> spaces rather than a TAB: vinschen> vinschen> vinschen> diff -upr origsrc/openssl-1.1-rc1/crypto/bn/Makefile.in src/openssl-1.1-rc1/crypto/bn/Makefile.in vinschen> --- origsrc/openssl-1.1-rc1/crypto/bn/Makefile.in 2016-01-23 21:02:12.604753995 +0100 vinschen> +++ src/openssl-1.1-rc1/crypto/bn/Makefile.in 2016-01-23 21:03:58.394966621 +0100 vinschen> @@ -161,6 +161,6 @@ clean: vinschen> vinschen> # Different flavours of make disagree on where output goes vinschen> .c.o: vinschen> - $(CC) $(CFLAGS) -c $< -o $@ vinschen> + $(CC) $(CFLAGS) -c $< -o $@ Ah hah! I wonder why my make hasn't complained? vinschen> Second, the build fails trying to compile crypto/cversion.c: vinschen> vinschen> crypto/cversion.c:62:23: fatal error: buildinf.h: No such file or directory vinschen> # include "buildinf.h" vinschen> ^ vinschen> vinschen> The reason is that buildinf.h can't be built because util/mkbuildinf.pl vinschen> requires /usr/local/bin/perl rather than /usr/bin/perl: vinschen> vinschen> diff -upr origsrc/openssl-1.1-rc1/util/mkbuildinf.pl src/openssl-1.1-rc1/util/mkbuildinf.pl vinschen> --- origsrc/openssl-1.1-rc1/util/mkbuildinf.pl 2016-01-23 21:02:18.386710976 +0100 vinschen> +++ src/openssl-1.1-rc1/util/mkbuildinf.pl 2016-01-23 21:15:19.705883094 +0100 vinschen> @@ -1,4 +1,4 @@ vinschen> -#!/usr/local/bin/perl vinschen> +#!/usr/bin/perl vinschen> vinschen> my ($cflags, $platform) = @ARGV; Interesting... Shouldn't the crypto/buildinf.h target have failed? vinschen> The build eventually fails with the following error message, which I vinschen> don't quite understand. The libraries should have been built before vinschen> trying to build the engines due to hard dependencies, but for some vinschen> reason they aren't. Sorry, I have no fix for that :( I do. Don't remember the details this moment, but that did happen to me as well, and I recall figuring out what went on. vinschen> Last but not least, we have another problem with enginesdir. To allow a vinschen> rolling release cycle, we have to support multiple versions of openssl vinschen> in parallel. The problem here is that the enginesdir needs to be vinschen> versioned to allow per-openssl version engines. The build scripts don't vinschen> allow for this. Right now we're using a patch as the below one to tweak vinschen> the configury to allow specifying the engines dir during build time. vinschen> Would it hurt terribly to include something like the below patch? vinschen> vinschen> vinschen> +++ src/openssl-1.1-rc1/Configure 2016-01-23 21:03:43.604076740 +0100 vinschen> @@ -221,6 +221,7 @@ $config{prefix}=""; vinschen> $config{openssldir}=""; vinschen> $config{processor}=""; vinschen> $config{libdir}=""; vinschen> +$config{enginesdir}=""; vinschen> $config{install_prefix}= "$ENV{'INSTALL_PREFIX'}"; vinschen> $config{cross_compile_prefix}=""; vinschen> $config{fipslibdir}="/usr/local/ssl/fips-2.0/lib/"; vinschen> @@ -633,6 +634,10 @@ foreach (@argvcopy) vinschen> { vinschen> $config{libdir}=$1; vinschen> } vinschen> + elsif (/^--enginesdir=(.*)$/) vinschen> + { vinschen> + $config{enginesdir}=$1; vinschen> + } vinschen> elsif (/^--openssldir=(.*)$/) vinschen> { vinschen> $config{openssldir}=$1; vinschen> @@ -893,7 +898,7 @@ if ($target{build_file} eq "Makefile" vinschen> $target{multilib}="" if !-d "$config{prefix}/lib$target{multilib}"; vinschen> vinschen> $config{libdir}="lib$target{multilib}" if $config{libdir} eq ""; vinschen> -$config{enginesdir}=$config{prefix} . "/" . $config{libdir} . "/engines"; vinschen> +$config{enginesdir}=$config{prefix} . "/" . $config{libdir} . "/engines" if $config{enginesdir} eq ""; vinschen> vinschen> push @{$config{defines}}, vinschen> map { (my $x = $_) =~ s/^OPENSSL_NO_/OPENSSL_EXPERIMENTAL_/; $x } Sure, that can be done. BTW, the refactor-build branch is a little off right now... I have a bunch of fixes in my personal repo that haven't gone out there yet. Dunno if you've followed what's happening in master, but FYI, the refactor-build branch is starting to show up there, one little piece at a time (doing it that way made it easier for our review process). So right now, refactor-build is on pause until enough has come out on master. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sat Jan 23 21:12:40 2016 From: levitte at openssl.org (Richard Levitte) Date: Sat, 23 Jan 2016 22:12:40 +0100 (CET) Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160123210116.GB13479@calimero.vinschen.de> References: <20160123202758.GA13479@calimero.vinschen.de> <20160123203557.GA11838@roeckx.be> <20160123210116.GB13479@calimero.vinschen.de> Message-ID: <20160123.221240.1811377317049592412.levitte@openssl.org> In message <20160123210116.GB13479 at calimero.vinschen.de> on Sat, 23 Jan 2016 22:01:16 +0100, Corinna Vinschen said: vinschen> On Jan 23 21:35, Kurt Roeckx wrote: vinschen> > On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna Vinschen wrote: vinschen> > > vinschen> > > Last but not least, we have another problem with enginesdir. To allow a vinschen> > > rolling release cycle, we have to support multiple versions of openssl vinschen> > > in parallel. The problem here is that the enginesdir needs to be vinschen> > > versioned to allow per-openssl version engines. The build scripts don't vinschen> > > allow for this. Right now we're using a patch as the below one to tweak vinschen> > > the configury to allow specifying the engines dir during build time. vinschen> > > Would it hurt terribly to include something like the below patch? vinschen> > vinschen> > In general, I would like to have a directory for the engines that vinschen> > relates to OSSL_DYNAMIC_OLDEST. vinschen> vinschen> That probably won't work for Cygwin. The engines are linked against the vinschen> versioned DLLs of the OpenSSL version they have been built for, Even vinschen> assuming binary compatibility, an engine linked against openssl-1.0 will vinschen> pull in openssl-1.0 DLLs, even when loaded from openssl-1.1. We have to vinschen> keep the engines separate. This is interesting, actually. OSSL_DYNAMIC_OLDEST has some design around it that's meant to permit EXACTLY that kind of mixture. It's in the macro IMPLEMENT_DYNAMIC_BIND_FN. However, it's possible it's not doing enough, and figuring out what else it needs to do is a venture I think is worth spending some time on. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From tim at multitalents.net Sat Jan 23 22:55:54 2016 From: tim at multitalents.net (Tim Rice) Date: Sat, 23 Jan 2016 14:55:54 -0800 (PST) Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160123202758.GA13479@calimero.vinschen.de> References: <20160114.215903.813205413779228431.levitte@openssl.org> <20160118.235012.1388704382358841060.levitte@openssl.org> <20160123202758.GA13479@calimero.vinschen.de> Message-ID: On Sat, 23 Jan 2016, Corinna Vinschen wrote: > diff -upr origsrc/openssl-1.1-rc1/util/mkbuildinf.pl src/openssl-1.1-rc1/util/mkbuildinf.pl > --- origsrc/openssl-1.1-rc1/util/mkbuildinf.pl 2016-01-23 21:02:18.386710976 +0100 > +++ src/openssl-1.1-rc1/util/mkbuildinf.pl 2016-01-23 21:15:19.705883094 +0100 > @@ -1,4 +1,4 @@ > -#!/usr/local/bin/perl > +#!/usr/bin/perl A more portable fix would be #!/usr/bin/env perl -- Tim Rice Multitalents (707) 456-1146 tim at multitalents.net From levitte at openssl.org Sun Jan 24 08:32:22 2016 From: levitte at openssl.org (Richard Levitte) Date: Sun, 24 Jan 2016 09:32:22 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: References: <20160114.215903.813205413779228431.levitte@openssl.org> <20160118.235012.1388704382358841060.levitte@openssl.org> <20160123202758.GA13479@calimero.vinschen.de> Message-ID: <131D047E-8E04-45CE-9D8E-773A29682948@openssl.org> On January 23, 2016 11:55:54 PM GMT+01:00, Tim Rice wrote: >On Sat, 23 Jan 2016, Corinna Vinschen wrote: > >> diff -upr origsrc/openssl-1.1-rc1/util/mkbuildinf.pl >src/openssl-1.1-rc1/util/mkbuildinf.pl >> --- origsrc/openssl-1.1-rc1/util/mkbuildinf.pl 2016-01-23 >21:02:18.386710976 +0100 >> +++ src/openssl-1.1-rc1/util/mkbuildinf.pl 2016-01-23 >21:15:19.705883094 +0100 >> @@ -1,4 +1,4 @@ >> -#!/usr/local/bin/perl >> +#!/usr/bin/perl > >A more portable fix would be >#!/usr/bin/env perl Yes. Thanks for the reminder. -- levitte at openssl.org From vinschen at redhat.com Sun Jan 24 12:04:04 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 24 Jan 2016 13:04:04 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160123.220842.2219047951873553393.levitte@openssl.org> References: <20160114.215903.813205413779228431.levitte@openssl.org> <20160118.235012.1388704382358841060.levitte@openssl.org> <20160123202758.GA13479@calimero.vinschen.de> <20160123.220842.2219047951873553393.levitte@openssl.org> Message-ID: <20160124120404.GA27363@calimero.vinschen.de> On Jan 23 22:08, Richard Levitte wrote: > In message <20160123202758.GA13479 at calimero.vinschen.de> on Sat, 23 Jan 2016 21:27:58 +0100, Corinna Vinschen said: > vinschen> Second, the build fails trying to compile crypto/cversion.c: > vinschen> > vinschen> crypto/cversion.c:62:23: fatal error: buildinf.h: No such file or directory > vinschen> # include "buildinf.h" > vinschen> ^ > vinschen> > vinschen> The reason is that buildinf.h can't be built because util/mkbuildinf.pl > vinschen> requires /usr/local/bin/perl rather than /usr/bin/perl: > vinschen> > vinschen> diff -upr origsrc/openssl-1.1-rc1/util/mkbuildinf.pl src/openssl-1.1-rc1/util/mkbuildinf.pl > vinschen> --- origsrc/openssl-1.1-rc1/util/mkbuildinf.pl 2016-01-23 21:02:18.386710976 +0100 > vinschen> +++ src/openssl-1.1-rc1/util/mkbuildinf.pl 2016-01-23 21:15:19.705883094 +0100 > vinschen> @@ -1,4 +1,4 @@ > vinschen> -#!/usr/local/bin/perl > vinschen> +#!/usr/bin/perl > vinschen> > vinschen> my ($cflags, $platform) = @ARGV; > > Interesting... Shouldn't the crypto/buildinf.h target have failed? It didn't. I just got the error message later with crypto/cversion.c. > vinschen> Last but not least, we have another problem with enginesdir. To allow a > vinschen> rolling release cycle, we have to support multiple versions of openssl > vinschen> in parallel. The problem here is that the enginesdir needs to be > vinschen> versioned to allow per-openssl version engines. The build scripts don't > vinschen> allow for this. Right now we're using a patch as the below one to tweak > vinschen> the configury to allow specifying the engines dir during build time. > vinschen> Would it hurt terribly to include something like the below patch? > vinschen> > vinschen> > vinschen> +++ src/openssl-1.1-rc1/Configure 2016-01-23 21:03:43.604076740 +0100 > vinschen> @@ -221,6 +221,7 @@ $config{prefix}=""; > vinschen> $config{openssldir}=""; > vinschen> $config{processor}=""; > vinschen> $config{libdir}=""; > vinschen> +$config{enginesdir}=""; > vinschen> $config{install_prefix}= "$ENV{'INSTALL_PREFIX'}"; > vinschen> $config{cross_compile_prefix}=""; > vinschen> $config{fipslibdir}="/usr/local/ssl/fips-2.0/lib/"; > vinschen> @@ -633,6 +634,10 @@ foreach (@argvcopy) > vinschen> { > vinschen> $config{libdir}=$1; > vinschen> } > vinschen> + elsif (/^--enginesdir=(.*)$/) > vinschen> + { > vinschen> + $config{enginesdir}=$1; > vinschen> + } > vinschen> elsif (/^--openssldir=(.*)$/) > vinschen> { > vinschen> $config{openssldir}=$1; > vinschen> @@ -893,7 +898,7 @@ if ($target{build_file} eq "Makefile" > vinschen> $target{multilib}="" if !-d "$config{prefix}/lib$target{multilib}"; > vinschen> > vinschen> $config{libdir}="lib$target{multilib}" if $config{libdir} eq ""; > vinschen> -$config{enginesdir}=$config{prefix} . "/" . $config{libdir} . "/engines"; > vinschen> +$config{enginesdir}=$config{prefix} . "/" . $config{libdir} . "/engines" if $config{enginesdir} eq ""; > vinschen> > vinschen> push @{$config{defines}}, > vinschen> map { (my $x = $_) =~ s/^OPENSSL_NO_/OPENSSL_EXPERIMENTAL_/; $x } > > Sure, that can be done. Thanks! > BTW, the refactor-build branch is a little off right now... I have a > bunch of fixes in my personal repo that haven't gone out there yet. > Dunno if you've followed what's happening in master, but FYI, the > refactor-build branch is starting to show up there, one little piece > at a time (doing it that way made it easier for our review process). > So right now, refactor-build is on pause until enough has come out on > master. Ok, no worries. I'm quite busy with non-Cygwin stuff right now anyway so I'm not concerned if this takes a bit more time :} Corinna -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From vinschen at redhat.com Sun Jan 24 12:19:00 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 24 Jan 2016 13:19:00 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160123.221240.1811377317049592412.levitte@openssl.org> References: <20160123202758.GA13479@calimero.vinschen.de> <20160123203557.GA11838@roeckx.be> <20160123210116.GB13479@calimero.vinschen.de> <20160123.221240.1811377317049592412.levitte@openssl.org> Message-ID: <20160124121900.GB27363@calimero.vinschen.de> On Jan 23 22:12, Richard Levitte wrote: > In message <20160123210116.GB13479 at calimero.vinschen.de> on Sat, 23 Jan 2016 22:01:16 +0100, Corinna Vinschen said: > > vinschen> On Jan 23 21:35, Kurt Roeckx wrote: > vinschen> > On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna Vinschen wrote: > vinschen> > > > vinschen> > > Last but not least, we have another problem with enginesdir. To allow a > vinschen> > > rolling release cycle, we have to support multiple versions of openssl > vinschen> > > in parallel. The problem here is that the enginesdir needs to be > vinschen> > > versioned to allow per-openssl version engines. The build scripts don't > vinschen> > > allow for this. Right now we're using a patch as the below one to tweak > vinschen> > > the configury to allow specifying the engines dir during build time. > vinschen> > > Would it hurt terribly to include something like the below patch? > vinschen> > > vinschen> > In general, I would like to have a directory for the engines that > vinschen> > relates to OSSL_DYNAMIC_OLDEST. > vinschen> > vinschen> That probably won't work for Cygwin. The engines are linked against the > vinschen> versioned DLLs of the OpenSSL version they have been built for, Even > vinschen> assuming binary compatibility, an engine linked against openssl-1.0 will > vinschen> pull in openssl-1.0 DLLs, even when loaded from openssl-1.1. We have to > vinschen> keep the engines separate. > > This is interesting, actually. OSSL_DYNAMIC_OLDEST has some design > around it that's meant to permit EXACTLY that kind of mixture. It's > in the macro IMPLEMENT_DYNAMIC_BIND_FN. However, it's possible it's > not doing enough, and figuring out what else it needs to do is a > venture I think is worth spending some time on. The problem here is Windows and how DLL dependencies are resolved. We're using versioned DLLs, e.g. /usr/bin/cygcrypto-0.9.8.dll /usr/bin/cygcrypto-1.0.0.dll /usr/bin/cygcrypto-1.1.dll When building engines, the engines are shared libs linking against the crypto DLL. This creates a hard dependency to the DLL the engine has been linked against. So, consider using an application linked against cygcrypto-1.1.dll. It loads an engine built with and thus linked against cygcrypto-1.0.0.dll. While the application will use functions from cygcrypto-1.1.dll, the engine will use functions from cygcrypto-1.0.0.dll. Hilarity ensues. Unless cygcrypto-1.0.0.dll has been deprecated and removed. In which case loading the engine fails. To decouple an engine from a DLL version, what we would have to do is to change the engines not to link against libcrypto, but rather to load *all* functions dynamically at runtime (dlload/dlsym(*)). Only this would allow to decouple the engines from a specific versioned DLL. Corinna (*) On Windows (but NOT Cygwin): LoadLibrary/GetProcAddress. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From vinschen at redhat.com Sun Jan 24 13:02:36 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 24 Jan 2016 14:02:36 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160124121900.GB27363@calimero.vinschen.de> References: <20160123202758.GA13479@calimero.vinschen.de> <20160123203557.GA11838@roeckx.be> <20160123210116.GB13479@calimero.vinschen.de> <20160123.221240.1811377317049592412.levitte@openssl.org> <20160124121900.GB27363@calimero.vinschen.de> Message-ID: <20160124130236.GC27363@calimero.vinschen.de> On Jan 24 13:19, Corinna Vinschen wrote: > On Jan 23 22:12, Richard Levitte wrote: > > In message <20160123210116.GB13479 at calimero.vinschen.de> on Sat, 23 Jan 2016 22:01:16 +0100, Corinna Vinschen said: > > > > vinschen> On Jan 23 21:35, Kurt Roeckx wrote: > > vinschen> > On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna Vinschen wrote: > > vinschen> > > > > vinschen> > > Last but not least, we have another problem with enginesdir. To allow a > > vinschen> > > rolling release cycle, we have to support multiple versions of openssl > > vinschen> > > in parallel. The problem here is that the enginesdir needs to be > > vinschen> > > versioned to allow per-openssl version engines. The build scripts don't > > vinschen> > > allow for this. Right now we're using a patch as the below one to tweak > > vinschen> > > the configury to allow specifying the engines dir during build time. > > vinschen> > > Would it hurt terribly to include something like the below patch? > > vinschen> > > > vinschen> > In general, I would like to have a directory for the engines that > > vinschen> > relates to OSSL_DYNAMIC_OLDEST. > > vinschen> > > vinschen> That probably won't work for Cygwin. The engines are linked against the > > vinschen> versioned DLLs of the OpenSSL version they have been built for, Even > > vinschen> assuming binary compatibility, an engine linked against openssl-1.0 will > > vinschen> pull in openssl-1.0 DLLs, even when loaded from openssl-1.1. We have to > > vinschen> keep the engines separate. > > > > This is interesting, actually. OSSL_DYNAMIC_OLDEST has some design > > around it that's meant to permit EXACTLY that kind of mixture. It's > > in the macro IMPLEMENT_DYNAMIC_BIND_FN. However, it's possible it's > > not doing enough, and figuring out what else it needs to do is a > > venture I think is worth spending some time on. > > The problem here is Windows and how DLL dependencies are resolved. > We're using versioned DLLs, e.g. > > /usr/bin/cygcrypto-0.9.8.dll > /usr/bin/cygcrypto-1.0.0.dll > /usr/bin/cygcrypto-1.1.dll > > When building engines, the engines are shared libs linking against the > crypto DLL. This creates a hard dependency to the DLL the engine has > been linked against. So, consider using an application linked against > cygcrypto-1.1.dll. It loads an engine built with and thus linked > against cygcrypto-1.0.0.dll. While the application will use functions > from cygcrypto-1.1.dll, the engine will use functions from > cygcrypto-1.0.0.dll. Hilarity ensues. Unless cygcrypto-1.0.0.dll has > been deprecated and removed. In which case loading the engine fails. > > To decouple an engine from a DLL version, what we would have to do is > to change the engines not to link against libcrypto, but rather to load > *all* functions dynamically at runtime (dlload/dlsym(*)). ...in conjunction with symlinks, e.g. dlload ("/usr/lib/libcrypto.so", ...) with /usr/lib/libcrypto.so being a symlink to the latest DLL: /usr/lib/libcrypto.so -> /usr/bin/cygcrypto-1.1.dll Corinna -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kurt at roeckx.be Sun Jan 24 13:35:28 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 24 Jan 2016 14:35:28 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160124121900.GB27363@calimero.vinschen.de> References: <20160123202758.GA13479@calimero.vinschen.de> <20160123203557.GA11838@roeckx.be> <20160123210116.GB13479@calimero.vinschen.de> <20160123.221240.1811377317049592412.levitte@openssl.org> <20160124121900.GB27363@calimero.vinschen.de> Message-ID: <20160124133528.GA24995@roeckx.be> On Sun, Jan 24, 2016 at 01:19:00PM +0100, Corinna Vinschen wrote: > On Jan 23 22:12, Richard Levitte wrote: > > In message <20160123210116.GB13479 at calimero.vinschen.de> on Sat, 23 Jan 2016 22:01:16 +0100, Corinna Vinschen said: > > > > vinschen> On Jan 23 21:35, Kurt Roeckx wrote: > > vinschen> > On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna Vinschen wrote: > > vinschen> > > > > vinschen> > > Last but not least, we have another problem with enginesdir. To allow a > > vinschen> > > rolling release cycle, we have to support multiple versions of openssl > > vinschen> > > in parallel. The problem here is that the enginesdir needs to be > > vinschen> > > versioned to allow per-openssl version engines. The build scripts don't > > vinschen> > > allow for this. Right now we're using a patch as the below one to tweak > > vinschen> > > the configury to allow specifying the engines dir during build time. > > vinschen> > > Would it hurt terribly to include something like the below patch? > > vinschen> > > > vinschen> > In general, I would like to have a directory for the engines that > > vinschen> > relates to OSSL_DYNAMIC_OLDEST. > > vinschen> > > vinschen> That probably won't work for Cygwin. The engines are linked against the > > vinschen> versioned DLLs of the OpenSSL version they have been built for, Even > > vinschen> assuming binary compatibility, an engine linked against openssl-1.0 will > > vinschen> pull in openssl-1.0 DLLs, even when loaded from openssl-1.1. We have to > > vinschen> keep the engines separate. > > > > This is interesting, actually. OSSL_DYNAMIC_OLDEST has some design > > around it that's meant to permit EXACTLY that kind of mixture. It's > > in the macro IMPLEMENT_DYNAMIC_BIND_FN. However, it's possible it's > > not doing enough, and figuring out what else it needs to do is a > > venture I think is worth spending some time on. > > The problem here is Windows and how DLL dependencies are resolved. > We're using versioned DLLs, e.g. > > /usr/bin/cygcrypto-0.9.8.dll > /usr/bin/cygcrypto-1.0.0.dll > /usr/bin/cygcrypto-1.1.dll So it's name is like the soname on Linux and others? I'm guessing only cygwin is doing that and other windows versions still use things like libeay32.dll? So engines build for 1.0.X can be loaded with any "cygcrypto-1.0.0.dll"? > When building engines, the engines are shared libs linking against the > crypto DLL. This creates a hard dependency to the DLL the engine has > been linked against. So, consider using an application linked against > cygcrypto-1.1.dll. It loads an engine built with and thus linked > against cygcrypto-1.0.0.dll. While the application will use functions > from cygcrypto-1.1.dll, the engine will use functions from > cygcrypto-1.0.0.dll. Hilarity ensues. Unless cygcrypto-1.0.0.dll has > been deprecated and removed. In which case loading the engine fails. > > To decouple an engine from a DLL version, what we would have to do is > to change the engines not to link against libcrypto, but rather to load > *all* functions dynamically at runtime (dlload/dlsym(*)). Only this > would allow to decouple the engines from a specific versioned DLL. Note that OSSL_DYNAMIC_OLDEST changed in 1.1. Even if the engines for 1.1 were compatible with 1.0, we'd have the same problem on Linux, it also knows to which soname it was linked. Kurt From levitte at openssl.org Sun Jan 24 13:41:43 2016 From: levitte at openssl.org (Richard Levitte) Date: Sun, 24 Jan 2016 14:41:43 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160124121900.GB27363@calimero.vinschen.de> References: <20160123202758.GA13479@calimero.vinschen.de> <20160123203557.GA11838@roeckx.be> <20160123210116.GB13479@calimero.vinschen.de> <20160123.221240.1811377317049592412.levitte@openssl.org> <20160124121900.GB27363@calimero.vinschen.de> Message-ID: <08877513-CF42-419A-B6C2-EE52A9807946@openssl.org> Corinna Vinschen skrev: (24 januari 2016 13:19:00 CET) >On Jan 23 22:12, Richard Levitte wrote: >> In message <20160123210116.GB13479 at calimero.vinschen.de> on Sat, 23 >Jan 2016 22:01:16 +0100, Corinna Vinschen said: >> >> vinschen> On Jan 23 21:35, Kurt Roeckx wrote: >> vinschen> > On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna >Vinschen wrote: >> vinschen> > > >> vinschen> > > Last but not least, we have another problem with >enginesdir. To allow a >> vinschen> > > rolling release cycle, we have to support multiple >versions of openssl >> vinschen> > > in parallel. The problem here is that the enginesdir >needs to be >> vinschen> > > versioned to allow per-openssl version engines. The >build scripts don't >> vinschen> > > allow for this. Right now we're using a patch as the >below one to tweak >> vinschen> > > the configury to allow specifying the engines dir >during build time. >> vinschen> > > Would it hurt terribly to include something like the >below patch? >> vinschen> > >> vinschen> > In general, I would like to have a directory for the >engines that >> vinschen> > relates to OSSL_DYNAMIC_OLDEST. >> vinschen> >> vinschen> That probably won't work for Cygwin. The engines are >linked against the >> vinschen> versioned DLLs of the OpenSSL version they have been built >for, Even >> vinschen> assuming binary compatibility, an engine linked against >openssl-1.0 will >> vinschen> pull in openssl-1.0 DLLs, even when loaded from >openssl-1.1. We have to >> vinschen> keep the engines separate. >> >> This is interesting, actually. OSSL_DYNAMIC_OLDEST has some design >> around it that's meant to permit EXACTLY that kind of mixture. It's >> in the macro IMPLEMENT_DYNAMIC_BIND_FN. However, it's possible it's >> not doing enough, and figuring out what else it needs to do is a >> venture I think is worth spending some time on. > >The problem here is Windows and how DLL dependencies are resolved. >We're using versioned DLLs, e.g. > > /usr/bin/cygcrypto-0.9.8.dll > /usr/bin/cygcrypto-1.0.0.dll > /usr/bin/cygcrypto-1.1.dll > >When building engines, the engines are shared libs linking against the >crypto DLL. This creates a hard dependency to the DLL the engine has >been linked against. So, consider using an application linked against >cygcrypto-1.1.dll. It loads an engine built with and thus linked >against cygcrypto-1.0.0.dll. While the application will use functions >from cygcrypto-1.1.dll, the engine will use functions from >cygcrypto-1.0.0.dll. Yes, exactly. The way the engine API was designed from the start, that exact situation is meant to be supported. However, it's been long since I tested that aspect, so I can't personally tell if there's a bit of rot in there. That's certainly worth investigating... > Hilarity ensues. Ok, so, a bit of rot or something other I fail to think of. Do you have details you'd like to share? > Unless cygcrypto-1.0.0.dll has >been deprecated and removed. In which case loading the engine fails. > >To decouple an engine from a DLL version, what we would have to do is >to change the engines not to link against libcrypto, but rather to load >*all* functions dynamically at runtime (dlload/dlsym(*)). Only this >would allow to decouple the engines from a specific versioned DLL. The decoupling of versions is supposed to be between the loading application and the loaded engine, not between them and the libcrypto versions they each use. > > >Corinna > > >(*) On Windows (but NOT Cygwin): LoadLibrary/GetProcAddress. > > >------------------------------------------------------------------------ > >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From cata.vasile at nxp.com Sun Jan 24 13:47:13 2016 From: cata.vasile at nxp.com (Catalin Vasile) Date: Sun, 24 Jan 2016 13:47:13 +0000 Subject: [openssl-dev] [eng_rdrand] alloc and free In-Reply-To: <20160122.012054.39432466456966917.levitte@openssl.org> References: , <20160122.012054.39432466456966917.levitte@openssl.org> Message-ID: ________________________________________ From: openssl-dev on behalf of Richard Levitte Sent: Friday, January 22, 2016 2:20 AM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] [eng_rdrand] alloc and free In message on Thu, 21 Jan 2016 10:57:19 +0000, Catalin Vasile said: cata.vasile> ENGINE_load_rdrand() creates a new engine, it adds cata.vasile> it/registers it and then frees it. Looking further into cata.vasile> these functions, the registration does NOT create a new cata.vasile> object and then copy the data into it, so the cata.vasile> registration is based on an object that it's later cata.vasile> released. Welllll.... not quite! Pointers to engines aren't merely pointers, they are more like handles and have reference counters. So, the called `ENGINE *toad = ENGINE_rdrand()' will create the reference to a new ENGINE object, that is correct. Three lines later, the call `ENGINE_add(toadd)' will create a new reference to the same object, by incrementing the reference counter, and will store the pointer to the object in OpenSSL's internal list. The following call `ENGINE_free(toadd)' simply decrements the reference counter (from 2 to 1) but does not actually free the object (that would require another ENGINE_free). Does that make it clearer? Absolutely clear For further info, may I suggest you do `perldoc doc/crypto/engine.pod', and most specifically read the section titled "Reference counting and handles"? Thanks for the reference. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From vinschen at redhat.com Sun Jan 24 14:52:19 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 24 Jan 2016 15:52:19 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <08877513-CF42-419A-B6C2-EE52A9807946@openssl.org> References: <20160123202758.GA13479@calimero.vinschen.de> <20160123203557.GA11838@roeckx.be> <20160123210116.GB13479@calimero.vinschen.de> <20160123.221240.1811377317049592412.levitte@openssl.org> <20160124121900.GB27363@calimero.vinschen.de> <08877513-CF42-419A-B6C2-EE52A9807946@openssl.org> Message-ID: <20160124145219.GD27363@calimero.vinschen.de> On Jan 24 14:41, Richard Levitte wrote: > Corinna Vinschen skrev: (24 januari 2016 13:19:00 CET) > >On Jan 23 22:12, Richard Levitte wrote: > >> This is interesting, actually. OSSL_DYNAMIC_OLDEST has some design > >> around it that's meant to permit EXACTLY that kind of mixture. It's > >> in the macro IMPLEMENT_DYNAMIC_BIND_FN. However, it's possible it's > >> not doing enough, and figuring out what else it needs to do is a > >> venture I think is worth spending some time on. > > > >The problem here is Windows and how DLL dependencies are resolved. > >We're using versioned DLLs, e.g. > > > > /usr/bin/cygcrypto-0.9.8.dll > > /usr/bin/cygcrypto-1.0.0.dll > > /usr/bin/cygcrypto-1.1.dll > > > >When building engines, the engines are shared libs linking against the > >crypto DLL. This creates a hard dependency to the DLL the engine has > >been linked against. So, consider using an application linked against > >cygcrypto-1.1.dll. It loads an engine built with and thus linked > >against cygcrypto-1.0.0.dll. While the application will use functions > >from cygcrypto-1.1.dll, the engine will use functions from > >cygcrypto-1.0.0.dll. > > Yes, exactly. The way the engine API was designed from the start, that > exact situation is meant to be supported. However, it's been long > since I tested that aspect, so I can't personally tell if there's a > bit of rot in there. That's certainly worth investigating... > > > Hilarity ensues. > > Ok, so, a bit of rot or something other I fail to think of. Do you > have details you'd like to share? No, that was only an attempt at humor. I don't know either if that works as desired... > > Unless cygcrypto-1.0.0.dll has > >been deprecated and removed. In which case loading the engine fails. > > > >To decouple an engine from a DLL version, what we would have to do is > >to change the engines not to link against libcrypto, but rather to load > >*all* functions dynamically at runtime (dlload/dlsym(*)). Only this > >would allow to decouple the engines from a specific versioned DLL. > > The decoupling of versions is supposed to be between the loading > application and the loaded engine, not between them and the libcrypto > versions they each use. Hmm, ok. I thought that it's not desired to run an application with one crypto lib and the engine with another. I can't exactly judge the implications, but that sounds like it could result in problems, not only on Cygwin, FWIW. Is there any shared data between the calling crypto lib and the engine? What if the idea how to handle this shared data is different between the crypto lib *calling* the engine and the crypto lib *called* by the engine? Still, the immediate problem is that a rolling release distro has to keep two sets of engines depending on the OpenSSL release to support existing packages until they have been rebuilt. The other issues is stuff you can judge much better than me, Thanks, Corinna -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From vinschen at redhat.com Sun Jan 24 14:54:35 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 24 Jan 2016 15:54:35 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160124133528.GA24995@roeckx.be> References: <20160123202758.GA13479@calimero.vinschen.de> <20160123203557.GA11838@roeckx.be> <20160123210116.GB13479@calimero.vinschen.de> <20160123.221240.1811377317049592412.levitte@openssl.org> <20160124121900.GB27363@calimero.vinschen.de> <20160124133528.GA24995@roeckx.be> Message-ID: <20160124145435.GE27363@calimero.vinschen.de> On Jan 24 14:35, Kurt Roeckx wrote: > On Sun, Jan 24, 2016 at 01:19:00PM +0100, Corinna Vinschen wrote: > > On Jan 23 22:12, Richard Levitte wrote: > > > This is interesting, actually. OSSL_DYNAMIC_OLDEST has some design > > > around it that's meant to permit EXACTLY that kind of mixture. It's > > > in the macro IMPLEMENT_DYNAMIC_BIND_FN. However, it's possible it's > > > not doing enough, and figuring out what else it needs to do is a > > > venture I think is worth spending some time on. > > > > The problem here is Windows and how DLL dependencies are resolved. > > We're using versioned DLLs, e.g. > > > > /usr/bin/cygcrypto-0.9.8.dll > > /usr/bin/cygcrypto-1.0.0.dll > > /usr/bin/cygcrypto-1.1.dll > > So it's name is like the soname on Linux and others? I'm guessing > only cygwin is doing that and other windows versions still use > things like libeay32.dll? Yes, exactly. Cygwin is much more trying to be like a Linux distro on top of Windows. This includes how we handle shared libs, within the bounds of [history and] what can be done under Windows, of course. > So engines build for 1.0.X can be loaded with any > "cygcrypto-1.0.0.dll"? Yep. > > When building engines, the engines are shared libs linking against the > > crypto DLL. This creates a hard dependency to the DLL the engine has > > been linked against. So, consider using an application linked against > > cygcrypto-1.1.dll. It loads an engine built with and thus linked > > against cygcrypto-1.0.0.dll. While the application will use functions > > from cygcrypto-1.1.dll, the engine will use functions from > > cygcrypto-1.0.0.dll. Hilarity ensues. Unless cygcrypto-1.0.0.dll has > > been deprecated and removed. In which case loading the engine fails. > > > > To decouple an engine from a DLL version, what we would have to do is > > to change the engines not to link against libcrypto, but rather to load > > *all* functions dynamically at runtime (dlload/dlsym(*)). Only this > > would allow to decouple the engines from a specific versioned DLL. > > Note that OSSL_DYNAMIC_OLDEST changed in 1.1. > > Even if the engines for 1.1 were compatible with 1.0, we'd have > the same problem on Linux, it also knows to which soname it was > linked. Ah, good to know. Thanks, Corinna -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From levitte at openssl.org Sun Jan 24 17:16:40 2016 From: levitte at openssl.org (Richard Levitte) Date: Sun, 24 Jan 2016 18:16:40 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160124145219.GD27363@calimero.vinschen.de> References: <20160123202758.GA13479@calimero.vinschen.de> <20160123203557.GA11838@roeckx.be> <20160123210116.GB13479@calimero.vinschen.de> <20160123.221240.1811377317049592412.levitte@openssl.org> <20160124121900.GB27363@calimero.vinschen.de> <08877513-CF42-419A-B6C2-EE52A9807946@openssl.org> <20160124145219.GD27363@calimero.vinschen.de> Message-ID: On January 24, 2016 3:52:19 PM GMT+01:00, Corinna Vinschen wrote: >On Jan 24 14:41, Richard Levitte wrote: >> Corinna Vinschen skrev: (24 januari 2016 >13:19:00 CET) >> >On Jan 23 22:12, Richard Levitte wrote: >> >> This is interesting, actually. OSSL_DYNAMIC_OLDEST has some >design >> >> around it that's meant to permit EXACTLY that kind of mixture. >It's >> >> in the macro IMPLEMENT_DYNAMIC_BIND_FN. However, it's possible >it's >> >> not doing enough, and figuring out what else it needs to do is a >> >> venture I think is worth spending some time on. >> > >> >The problem here is Windows and how DLL dependencies are resolved. >> >We're using versioned DLLs, e.g. >> > >> > /usr/bin/cygcrypto-0.9.8.dll >> > /usr/bin/cygcrypto-1.0.0.dll >> > /usr/bin/cygcrypto-1.1.dll >> > >> >When building engines, the engines are shared libs linking against >the >> >crypto DLL. This creates a hard dependency to the DLL the engine >has >> >been linked against. So, consider using an application linked >against >> >cygcrypto-1.1.dll. It loads an engine built with and thus linked >> >against cygcrypto-1.0.0.dll. While the application will use >functions >> >from cygcrypto-1.1.dll, the engine will use functions from >> >cygcrypto-1.0.0.dll. >> >> Yes, exactly. The way the engine API was designed from the start, >that >> exact situation is meant to be supported. However, it's been long >> since I tested that aspect, so I can't personally tell if there's a >> bit of rot in there. That's certainly worth investigating... >> >> > Hilarity ensues. >> >> Ok, so, a bit of rot or something other I fail to think of. Do you >> have details you'd like to share? > >No, that was only an attempt at humor. I don't know either if that >works as desired... > >> > Unless cygcrypto-1.0.0.dll has >> >been deprecated and removed. In which case loading the engine >fails. >> > >> >To decouple an engine from a DLL version, what we would have to do >is >> >to change the engines not to link against libcrypto, but rather to >load >> >*all* functions dynamically at runtime (dlload/dlsym(*)). Only this >> >would allow to decouple the engines from a specific versioned DLL. >> >> The decoupling of versions is supposed to be between the loading >> application and the loaded engine, not between them and the libcrypto >> versions they each use. > >Hmm, ok. I thought that it's not desired to run an application with >one >crypto lib and the engine with another. I can't exactly judge the >implications, but that sounds like it could result in problems, not >only >on Cygwin, FWIW. Is there any shared data between the calling crypto >lib and the engine? What if the idea how to handle this shared data is >different between the crypto lib *calling* the engine and the crypto >lib >*called* by the engine? They aren't supposed to share data, except for a few things, such as the heap. That's why heap handling hooks are passed when binding an engine, among a few other things... >Still, the immediate problem is that a rolling release distro has to >keep two sets of engines depending on the OpenSSL release to support >existing packages until they have been rebuilt. The other issues >is stuff you can judge much better than me, > > >Thanks, >Corinna > > >------------------------------------------------------------------------ > >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- levitte at openssl.org From levitte at openssl.org Sun Jan 24 17:16:40 2016 From: levitte at openssl.org (Richard Levitte) Date: Sun, 24 Jan 2016 18:16:40 +0100 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160124145219.GD27363@calimero.vinschen.de> References: <20160123202758.GA13479@calimero.vinschen.de> <20160123203557.GA11838@roeckx.be> <20160123210116.GB13479@calimero.vinschen.de> <20160123.221240.1811377317049592412.levitte@openssl.org> <20160124121900.GB27363@calimero.vinschen.de> <08877513-CF42-419A-B6C2-EE52A9807946@openssl.org> <20160124145219.GD27363@calimero.vinschen.de> Message-ID: On January 24, 2016 3:52:19 PM GMT+01:00, Corinna Vinschen wrote: >On Jan 24 14:41, Richard Levitte wrote: >> Corinna Vinschen skrev: (24 januari 2016 >13:19:00 CET) >> >On Jan 23 22:12, Richard Levitte wrote: >> >> This is interesting, actually. OSSL_DYNAMIC_OLDEST has some >design >> >> around it that's meant to permit EXACTLY that kind of mixture. >It's >> >> in the macro IMPLEMENT_DYNAMIC_BIND_FN. However, it's possible >it's >> >> not doing enough, and figuring out what else it needs to do is a >> >> venture I think is worth spending some time on. >> > >> >The problem here is Windows and how DLL dependencies are resolved. >> >We're using versioned DLLs, e.g. >> > >> > /usr/bin/cygcrypto-0.9.8.dll >> > /usr/bin/cygcrypto-1.0.0.dll >> > /usr/bin/cygcrypto-1.1.dll >> > >> >When building engines, the engines are shared libs linking against >the >> >crypto DLL. This creates a hard dependency to the DLL the engine >has >> >been linked against. So, consider using an application linked >against >> >cygcrypto-1.1.dll. It loads an engine built with and thus linked >> >against cygcrypto-1.0.0.dll. While the application will use >functions >> >from cygcrypto-1.1.dll, the engine will use functions from >> >cygcrypto-1.0.0.dll. >> >> Yes, exactly. The way the engine API was designed from the start, >that >> exact situation is meant to be supported. However, it's been long >> since I tested that aspect, so I can't personally tell if there's a >> bit of rot in there. That's certainly worth investigating... >> >> > Hilarity ensues. >> >> Ok, so, a bit of rot or something other I fail to think of. Do you >> have details you'd like to share? > >No, that was only an attempt at humor. I don't know either if that >works as desired... > >> > Unless cygcrypto-1.0.0.dll has >> >been deprecated and removed. In which case loading the engine >fails. >> > >> >To decouple an engine from a DLL version, what we would have to do >is >> >to change the engines not to link against libcrypto, but rather to >load >> >*all* functions dynamically at runtime (dlload/dlsym(*)). Only this >> >would allow to decouple the engines from a specific versioned DLL. >> >> The decoupling of versions is supposed to be between the loading >> application and the loaded engine, not between them and the libcrypto >> versions they each use. > >Hmm, ok. I thought that it's not desired to run an application with >one >crypto lib and the engine with another. I can't exactly judge the >implications, but that sounds like it could result in problems, not >only >on Cygwin, FWIW. Is there any shared data between the calling crypto >lib and the engine? What if the idea how to handle this shared data is >different between the crypto lib *calling* the engine and the crypto >lib >*called* by the engine? They aren't supposed to share data, except for a few things, such as the heap. That's why heap handling hooks are passed when binding an engine, among a few other things... >Still, the immediate problem is that a rolling release distro has to >keep two sets of engines depending on the OpenSSL release to support >existing packages until they have been rebuilt. The other issues >is stuff you can judge much better than me, > > >Thanks, >Corinna > > >------------------------------------------------------------------------ > >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- levitte at openssl.org From quanah at zimbra.com Sun Jan 24 20:36:29 2016 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Sun, 24 Jan 2016 12:36:29 -0800 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <131D047E-8E04-45CE-9D8E-773A29682948@openssl.org> References: <20160114.215903.813205413779228431.levitte@openssl.org> <20160118.235012.1388704382358841060.levitte@openssl.org> <20160123202758.GA13479@calimero.vinschen.de> <131D047E-8E04-45CE-9D8E-773A29682948@openssl.org> Message-ID: --On Sunday, January 24, 2016 9:32 AM +0100 Richard Levitte wrote: >> A more portable fix would be >># !/usr/bin/env perl > > Yes. Thanks for the reminder. Hm, we did that in some script in Zimbra, and it ended up causing segfaults on RHEL systems that were pulling in a different perl than the system perl. I'll see if I can track down exactly what the issue was. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From levitte at openssl.org Sun Jan 24 22:30:40 2016 From: levitte at openssl.org (Richard Levitte) Date: Sun, 24 Jan 2016 23:30:40 +0100 (CET) Subject: [openssl-dev] Upcoming build system change In-Reply-To: References: <131D047E-8E04-45CE-9D8E-773A29682948@openssl.org> Message-ID: <20160124.233040.2082623958189635163.levitte@openssl.org> In message on Sun, 24 Jan 2016 12:36:29 -0800, Quanah Gibson-Mount said: quanah> --On Sunday, January 24, 2016 9:32 AM +0100 Richard Levitte quanah> -- wrote: quanah> quanah> >> A more portable fix would be quanah> >># !/usr/bin/env perl quanah> > quanah> > Yes. Thanks for the reminder. quanah> quanah> Hm, we did that in some script in Zimbra, and it ended up causing quanah> segfaults on RHEL systems that were pulling in a different perl than quanah> the system perl. I'll see if I can track down exactly what the issue quanah> was. Sounds like crappy $PATH... -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From quanah at zimbra.com Sun Jan 24 22:45:13 2016 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Sun, 24 Jan 2016 14:45:13 -0800 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160124.233040.2082623958189635163.levitte@openssl.org> References: <131D047E-8E04-45CE-9D8E-773A29682948@openssl.org> <20160124.233040.2082623958189635163.levitte@openssl.org> Message-ID: --On Sunday, January 24, 2016 11:30 PM +0100 Richard Levitte wrote: > In message on Sun, 24 Jan 2016 > 12:36:29 -0800, Quanah Gibson-Mount said: > > quanah> --On Sunday, January 24, 2016 9:32 AM +0100 Richard Levitte > quanah> -- wrote: > quanah> > quanah> >> A more portable fix would be > quanah> >># !/usr/bin/env perl > quanah> > > quanah> > Yes. Thanks for the reminder. > quanah> > quanah> Hm, we did that in some script in Zimbra, and it ended up causing > quanah> segfaults on RHEL systems that were pulling in a different perl > than quanah> the system perl. I'll see if I can track down exactly what > the issue quanah> was. > > Sounds like crappy $PATH... Actually it was Ubuntu rather than RHEL. Unfortuantely, beyond that, we're lacking on details, other than it was a perl found in /usr/local/bin. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From levitte at openssl.org Sun Jan 24 23:05:13 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 25 Jan 2016 00:05:13 +0100 (CET) Subject: [openssl-dev] Upcoming build system change In-Reply-To: References: <20160124.233040.2082623958189635163.levitte@openssl.org> Message-ID: <20160125.000513.96094806724924806.levitte@openssl.org> In message on Sun, 24 Jan 2016 14:45:13 -0800, Quanah Gibson-Mount said: quanah> --On Sunday, January 24, 2016 11:30 PM +0100 Richard Levitte quanah> -- wrote: quanah> quanah> > In message on Sun, 24 Jan quanah> > 2016 quanah> > 12:36:29 -0800, Quanah Gibson-Mount said: quanah> > quanah> > quanah> --On Sunday, January 24, 2016 9:32 AM +0100 Richard Levitte quanah> > quanah> -- wrote: quanah> > quanah> quanah> > quanah> >> A more portable fix would be quanah> > quanah> >># !/usr/bin/env perl quanah> > quanah> > quanah> > quanah> > Yes. Thanks for the reminder. quanah> > quanah> quanah> > quanah> Hm, we did that in some script in Zimbra, and it ended up quanah> > causing quanah> > quanah> segfaults on RHEL systems that were pulling in a different quanah> > perl quanah> > than quanah> the system perl. I'll see if I can track down exactly quanah> > what quanah> > the issue quanah> was. quanah> > quanah> > Sounds like crappy $PATH... quanah> quanah> Actually it was Ubuntu rather than RHEL. Unfortuantely, beyond that, quanah> we're lacking on details, other than it was a perl found in quanah> /usr/local/bin. Ok, so I take it someone had made a local build and installation of perl and forgot to clear it out when the perl package was installed. That *ahem* happens to me at times. That's nothing the OpenSSL build can have any control over, or env. Generally speaking, '#!/usr/bin/env perl' is the right thing to do, really. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From wilson.judson at gmail.com Sun Jan 24 23:56:15 2016 From: wilson.judson at gmail.com (Judson Wilson) Date: Sun, 24 Jan 2016 15:56:15 -0800 Subject: [openssl-dev] Check for heartbeat response without reading? Message-ID: Is it possible to check for a heartbeat response without calling SSL_read? I'm pretty sure the answer is no. This is problematic for me. I'm trying to make a library layer on top of OpenSSL that uses the heartbeat as an authenticated ack of earlier messages, without changing the application layer above. Doing a dummy SSL_read is problematic because it will fail (there is no data), and the same parameters (buffer address and size) will need to be repeated when a real SSL_read comes in. That's pretty messy. Future reads will need to be done in two parts. It would be nice if there were looser rules on ERROR_WANT_READ/WRITE. Specifically, it would be nice to relax the requirement of using the same parameters for the read/write operation. It seems like it should be OK if you transplant the buffer, i.e. realloc, between calls. It also seems like it should be OK to increase the size of the operation, but not decrease it. I can see how this would be a problem if the innards are storing buffer pointers between calls. -------------- next part -------------- An HTML attachment was scrubbed... URL: From quanah at zimbra.com Mon Jan 25 00:12:00 2016 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Sun, 24 Jan 2016 16:12:00 -0800 Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160125.000513.96094806724924806.levitte@openssl.org> References: <20160124.233040.2082623958189635163.levitte@openssl.org> <20160125.000513.96094806724924806.levitte@openssl.org> Message-ID: --On Monday, January 25, 2016 12:05 AM +0100 Richard Levitte wrote: > quanah> Actually it was Ubuntu rather than RHEL. Unfortuantely, beyond > that, quanah> we're lacking on details, other than it was a perl found in > quanah> /usr/local/bin. > > Ok, so I take it someone had made a local build and installation of > perl and forgot to clear it out when the perl package was installed. > That *ahem* happens to me at times. That's nothing the OpenSSL build > can have any control over, or env. > > Generally speaking, '#!/usr/bin/env perl' is the right thing to do, > really. Yeah, I'm primarily noting it so that if it comes up in the future, there's an idea as to what the solution is for the end user (fix their path, etc). --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From rsalz at akamai.com Mon Jan 25 00:50:54 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 25 Jan 2016 00:50:54 +0000 Subject: [openssl-dev] Check for heartbeat response without reading? In-Reply-To: References: Message-ID: <53f40d6c49ab4fc6946a712c04091640@ustx2ex-dag1mb1.msg.corp.akamai.com> TLS does this automatically with its record layer and MAC's. Why do you need to repeat it? From wilson.judson at gmail.com Mon Jan 25 01:04:02 2016 From: wilson.judson at gmail.com (Judson Wilson) Date: Sun, 24 Jan 2016 17:04:02 -0800 Subject: [openssl-dev] Check for heartbeat response without reading? In-Reply-To: <53f40d6c49ab4fc6946a712c04091640@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <53f40d6c49ab4fc6946a712c04091640@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: It's for research. I need a way, using only SSL layer functionality, for a client to know with certainty that the server has received a message. This is trivial at the application layer, but that is not what is wanted. In particular, the client needs to know that the server has completed a resume (for key rotation, not connection initiation). If a client performs a resume and no messages exchange afterwards, the client cannot be guaranteed that the server has received ChangeCipherSpec. Anyways, it doesn't matter. I just need a way for my application to know if a heartbeat response has been received, without committing to reading a chunk of application layer data of a specific size in a certain memory address. On Sun, Jan 24, 2016 at 4:50 PM, Salz, Rich wrote: > TLS does this automatically with its record layer and MAC's. Why do you > need to repeat it? > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Jan 25 01:06:41 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 25 Jan 2016 01:06:41 +0000 Subject: [openssl-dev] Check for heartbeat response without reading? In-Reply-To: References: <53f40d6c49ab4fc6946a712c04091640@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: I don't think you can do this. You will have to have your layer wrap application data in its own packaging layer. And of course, if there's a TCP break, you have no idea how many bytes were sent/received on either end. From wilson.judson at gmail.com Mon Jan 25 01:12:21 2016 From: wilson.judson at gmail.com (Judson Wilson) Date: Sun, 24 Jan 2016 17:12:21 -0800 Subject: [openssl-dev] Check for heartbeat response without reading? In-Reply-To: References: <53f40d6c49ab4fc6946a712c04091640@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: I was hoping SSL_peek might work, but I can't find any documentation. I do have the guarantee from the application layer that messaging occurs in a strict client request -> server response sequence, without any pipelining, etc. I know with certainty that the heartbeat response is the next record; I just need to coax the OpenSSL layer to read the next record, which I know will not be application data. On Sun, Jan 24, 2016 at 5:06 PM, Salz, Rich wrote: > I don't think you can do this. You will have to have your layer wrap > application data in its own packaging layer. And of course, if there's a > TCP break, you have no idea how many bytes were sent/received on either end. > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Jan 25 01:17:05 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 25 Jan 2016 01:17:05 +0000 Subject: [openssl-dev] Check for heartbeat response without reading? In-Reply-To: References: <53f40d6c49ab4fc6946a712c04091640@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <87f99d3b656d4ab1beac72a839d1a8fe@ustx2ex-dag1mb1.msg.corp.akamai.com> Like I said, I don't know that you can do it without changing some source. And also, heartbeats for TLS (and maybe DTLS) are going away in the next release. From wilson.judson at gmail.com Mon Jan 25 01:21:53 2016 From: wilson.judson at gmail.com (Judson Wilson) Date: Sun, 24 Jan 2016 17:21:53 -0800 Subject: [openssl-dev] Check for heartbeat response without reading? In-Reply-To: <87f99d3b656d4ab1beac72a839d1a8fe@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <53f40d6c49ab4fc6946a712c04091640@ustx2ex-dag1mb1.msg.corp.akamai.com> <87f99d3b656d4ab1beac72a839d1a8fe@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: Really? Strange. They are recommended for TLS 1.3 On Sun, Jan 24, 2016 at 5:17 PM, Salz, Rich wrote: > Like I said, I don't know that you can do it without changing some > source. And also, heartbeats for TLS (and maybe DTLS) are going away in > the next release. > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Jan 25 02:03:11 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 25 Jan 2016 02:03:11 +0000 Subject: [openssl-dev] Check for heartbeat response without reading? In-Reply-To: References: <53f40d6c49ab4fc6946a712c04091640@ustx2ex-dag1mb1.msg.corp.akamai.com> <87f99d3b656d4ab1beac72a839d1a8fe@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: > Really? Strange. They are recommended for TLS 1.3 No they're not. Start perhaps at this thread: https://www.ietf.org/mail-archive/web/tls/current/msg12283.html From wilson.judson at gmail.com Mon Jan 25 02:13:37 2016 From: wilson.judson at gmail.com (Judson Wilson) Date: Sun, 24 Jan 2016 18:13:37 -0800 Subject: [openssl-dev] Check for heartbeat response without reading? In-Reply-To: References: <53f40d6c49ab4fc6946a712c04091640@ustx2ex-dag1mb1.msg.corp.akamai.com> <87f99d3b656d4ab1beac72a839d1a8fe@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: The table in the following section of the latest draft for TLS 1.3 started the confusion: https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-11 On Sun, Jan 24, 2016 at 6:03 PM, Salz, Rich wrote: > > Really? Strange. They are recommended for TLS 1.3 > > No they're not. > > Start perhaps at this thread: > https://www.ietf.org/mail-archive/web/tls/current/msg12283.html > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Jan 25 02:17:31 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 25 Jan 2016 02:17:31 +0000 Subject: [openssl-dev] Check for heartbeat response without reading? In-Reply-To: References: <53f40d6c49ab4fc6946a712c04091640@ustx2ex-dag1mb1.msg.corp.akamai.com> <87f99d3b656d4ab1beac72a839d1a8fe@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: Yes just means an RFC is on the standards track. Not TLS. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Jan 25 10:46:38 2016 From: rt at openssl.org (Billy Brumley via RT) Date: Mon, 25 Jan 2016 10:46:38 +0000 Subject: [openssl-dev] [openssl.org #4269] Extend ECDH tests to more curves. Add more ECDH KATs. In-Reply-To: References: Message-ID: https://github.com/openssl/openssl/pull/587 From mark at openssl.org Mon Jan 25 11:17:05 2016 From: mark at openssl.org (Mark J Cox) Date: Mon, 25 Jan 2016 11:17:05 +0000 Subject: [openssl-dev] Forthcoming OpenSSL releases Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Forthcoming OpenSSL releases ============================ The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2f, 1.0.1r. These releases will be made available on 28th January between approx. 1pm and 5pm (UTC). They will fix two security defects, one of "high" severity affecting 1.0.2 releases, and one "low" severity affecting all releases. Please see the following page for further details of severity levels: https://www.openssl.org/policies/secpolicy.html Please also note that, as per our previous announcements, support for 1.0.0 and 0.9.8 releases ended on 31st December 2015 and are no longer receiving security updates. Support for 1.0.1 will end on 31st December 2016. Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWpgNkAAoJEAEKUEB8TIy9QcwH/3C7y700FjGjDBcNMcVO++GU 81cs87VqsoziuMSU9Sx8XlDWA8tH5JWXpES4+p9iWdKbks+2E0EahVZVaS5yDaLM LY6MaUM2Pucmrd/I7mvQ02AzzMWEUrFlbk1GtFVjU7IkYc1/ZOZLhjM6H0X8M8lO 5kvqpgWTGV5lMCJdOQLr/eIGIdGTy5Xqerm3Qz/nzvhbwaOu5pjvq0eub8AWbPb3 wwdB4GIKW4XaU7YAJl61o8jNeVoy/kMTfZmZYEefQzXf/1JYO2p8oqCMTIEUrSoN P7sT2d2DpjQvrK3j8MsIPMYUHLhxZt+MJ2+wuOLyznkPTdEIV+ylr6q0I74Wv1Q= =gzHe -----END PGP SIGNATURE----- From rt at openssl.org Fri Jan 8 17:27:40 2016 From: rt at openssl.org (Paul Necsoiu via RT) Date: Fri, 08 Jan 2016 17:27:40 -0000 Subject: [openssl-dev] [openssl.org #4226] FIX: ADD IPv6 support for OCSP Responder In-Reply-To: References: Message-ID: Hello, I have configured an OCSP responder with OpenSSL 1.0.2d which I started with the following command sudo openssl ocsp -index db/index -CA int-ca.crt -rsigner int-ocsp.crt >> -rkey private/int-ocsp.key -url http://[::1] > > Enter pass phrase for private/int-ocsp.key: > > Waiting for OCSP client connections... > > Verifying a certificate seems to be OK openssl ocsp -issuer int-ca.crt -CAfile ~/root-ca/root-ca.crt -verify_other > int-ca.crt -cert ~/cafe.ro.ecdsa.crt -url http://ip6-loopback Response verify OK /home/paul/cafe.ro.ecdsa.crt: good This Update: Jan 8 15:06:37 2016 GMT The problem is that even the OCSP responder is started with -url http://[::1] and accessed with -url http://ip6-loopback it seems that it doesn't use the IPv6 addresses but the IPv4 ones. See the attached wireshark capture. -- O zi cat mai placuta! Paul Necsoiu Tel: 0721 36 75 33 E-mail:paul.necsoiu at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: wireshark capture.png Type: image/png Size: 115898 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From michel.sales at free.fr Sun Jan 10 13:40:32 2016 From: michel.sales at free.fr (Michel) Date: Sun, 10 Jan 2016 13:40:32 -0000 Subject: [openssl-dev] s_client version 1.1 fails to handshake to s_server when -nocert option Message-ID: <001101d14bac$63e4eb60$2baec220$@sales@free.fr> Hi, s_client version 1.0.2e handshakes successfully to s_server when option -nocert is used : openssl s_server -nocert -cipher "ALL:eNULL:@STRENGTH" openssl s_client -cipher "ALL:eNULL:@STRENGTH" result : TLS 1.2, AECDH-AES256-SHA openssl s_server -nocert -cipher "ALL:eNULL:!ECDH:@STRENGTH" openssl s_client -cipher "ALL:eNULL:@STRENGTH" result : TLS 1.2, ADH-AES256-GCM-SHA384 but NOT with version 1.1-pre : openssl s_server -nocert -cipher "ALL:eNULL:@STRENGTH" openssl s_client -cipher "ALL:eNULL:@STRENGTH" server : Using default temp DH parameters ACCEPT ERROR 6952:error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:.\ssl\statem\statem_srvr.c:1528: shutting down SSL CONNECTION CLOSED client: CONNECTED(00000304) 11432:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:.\ssl\record\rec_layer_s3.c:1355:SSL alert number 40 As I do not see any reason for that, I believe it is a bug but I was not able to diagnose/fix it. (traces are attached to this mail). Regards, Michel. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: client_err_out.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: client_out.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: server_err_out.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: server_out.txt URL: From deengert at gmail.com Wed Jan 20 20:49:52 2016 From: deengert at gmail.com (Douglas E Engert) Date: Wed, 20 Jan 2016 14:49:52 -0600 Subject: [openssl-dev] ECDH engine In-Reply-To: <20160120201925.17788998.82513.46556@ll.mit.edu> References: <20160120201925.17788998.82513.46556@ll.mit.edu> Message-ID: <569FF2F0.60905@gmail.com> An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Jan 25 14:06:32 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 25 Jan 2016 14:06:32 +0000 Subject: [openssl-dev] [openssl.org #4226] FIX: ADD IPv6 support for OCSP Responder In-Reply-To: References: Message-ID: We are working on full IPv6 support and it will appear in the next release. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From beldmit at gmail.com Mon Jan 25 14:10:57 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 25 Jan 2016 17:10:57 +0300 Subject: [openssl-dev] [openssl.org #4226] FIX: ADD IPv6 support for OCSP Responder In-Reply-To: References: Message-ID: Dear Rich, On Mon, Jan 25, 2016 at 5:06 PM, Rich Salz via RT wrote: > We are working on full IPv6 support and it will appear in the next release. > Do you mean 1.1.0? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Jan 25 14:11:06 2016 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Mon, 25 Jan 2016 14:11:06 +0000 Subject: [openssl-dev] [openssl.org #4226] FIX: ADD IPv6 support for OCSP Responder In-Reply-To: References: Message-ID: Dear Rich, On Mon, Jan 25, 2016 at 5:06 PM, Rich Salz via RT wrote: > We are working on full IPv6 support and it will appear in the next release. > Do you mean 1.1.0? Thank you! -- SY, Dmitry Belyavsky From rt at openssl.org Mon Jan 25 14:12:07 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 25 Jan 2016 14:12:07 +0000 Subject: [openssl-dev] [openssl.org #4226] FIX: ADD IPv6 support for OCSP Responder In-Reply-To: References: Message-ID: Yes, the 1.1.0 release will have ipv6 support (down at the BIO layer). From openssl-users at dukhovni.org Mon Jan 25 14:54:49 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 25 Jan 2016 09:54:49 -0500 Subject: [openssl-dev] s_client version 1.1 fails to handshake to s_server when -nocert option In-Reply-To: <001101d14bac$63e4eb60$2baec220$@sales@free.fr> References: <001101d14bac$63e4eb60$2baec220$@sales@free.fr> Message-ID: > On Jan 10, 2016, at 8:39 AM, Michel wrote: > > but NOT with version 1.1-pre : > openssl s_server -nocert -cipher "ALL:eNULL:@STRENGTH" > openssl s_client -cipher "ALL:eNULL:@STRENGTH" > Try: -cipher "ALL:eNULL:@STRENGTH:@SECLEVEL=0" The default security level 1 disables aNULL ciphers. Perhaps disabling aNULL via @SECLEVEL is not the right thing to do. The semantics of SECLEVEL are not yet set in stone, and authentication is quite separate from crypto security, so perhaps if you enable aNULL ciphers you should get them. After all, even if certificates are used, nothing forces you to verify them. -- Viktor. From rt at openssl.org Mon Jan 25 15:18:16 2016 From: rt at openssl.org (Josh D via RT) Date: Mon, 25 Jan 2016 15:18:16 +0000 Subject: [openssl-dev] [openssl.org #4270] OpenSSL 1.0.1 Installation bug In-Reply-To: References: Message-ID: This was the result after a make report command. Is it a linking error on my part? -------------- next part -------------- A non-text attachment was scrubbed... Name: testlog Type: application/octet-stream Size: 20320 bytes Desc: not available URL: From michel.sales at free.fr Mon Jan 25 16:36:37 2016 From: michel.sales at free.fr (Michel) Date: Mon, 25 Jan 2016 17:36:37 +0100 Subject: [openssl-dev] s_client version 1.1 fails to handshake to s_server when -nocert option In-Reply-To: References: <001101d14bac$63e4eb60$2baec220$@sales@free.fr> Message-ID: <000001d1578e$9004c7e0$b00e57a0$@sales@free.fr> Thank you very much for your answer Viktor ! It works, using : openssl s_server -nocert -cipher "ALL:@STRENGTH:@SECLEVEL=0" openssl s_client -cipher "ALL:@STRENGTH:@SECLEVEL=0" I was able to handshake a "AECDH-AES256-SHA" cipher. :-) I will try to investigate deeper around the SECLEVEL=... keyword that I completely missed. Regards, Michel. -----Message d'origine----- De?: openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Viktor Dukhovni Envoy??: lundi 25 janvier 2016 15:55 ??: openssl-dev at openssl.org Objet?: Re: [openssl-dev] s_client version 1.1 fails to handshake to s_server when -nocert option > On Jan 10, 2016, at 8:39 AM, Michel wrote: > > but NOT with version 1.1-pre : > openssl s_server -nocert -cipher "ALL:eNULL:@STRENGTH" > openssl s_client -cipher "ALL:eNULL:@STRENGTH" > Try: -cipher "ALL:eNULL:@STRENGTH:@SECLEVEL=0" The default security level 1 disables aNULL ciphers. Perhaps disabling aNULL via @SECLEVEL is not the right thing to do. The semantics of SECLEVEL are not yet set in stone, and authentication is quite separate from crypto security, so perhaps if you enable aNULL ciphers you should get them. After all, even if certificates are used, nothing forces you to verify them. -- Viktor. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From openssl-users at dukhovni.org Mon Jan 25 17:47:32 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 25 Jan 2016 12:47:32 -0500 Subject: [openssl-dev] s_client version 1.1 fails to handshake to s_server when -nocert option In-Reply-To: <000001d1578e$9004c7e0$b00e57a0$@sales@free.fr> References: <001101d14bac$63e4eb60$2baec220$@sales@free.fr> <000001d1578e$9004c7e0$b00e57a0$@sales@free.fr> Message-ID: <7C234D6A-9013-4F88-86EC-0444D0345F9A@dukhovni.org> > On Jan 25, 2016, at 11:36 AM, Michel wrote: > > Thank you very much for your answer Viktor ! > It works, using : > openssl s_server -nocert -cipher "ALL:@STRENGTH:@SECLEVEL=0" > openssl s_client -cipher "ALL:@STRENGTH:@SECLEVEL=0" > I was able to handshake a "AECDH-AES256-SHA" cipher. > :-) > I will try to investigate deeper around the SECLEVEL=... keyword that I > completely missed. It is a very new feature and easy to miss amidst all other other new features. I am currently working on fixing some corner cases in this very code, so this is a good time to discuss whether @SECLEVEL should have any bearing on aNULL support. My instinct is that it should not, and I'm going to submit code that allows one to set a floor on the various crypto primitives allowed even for aNULL connections (which may be authenticated by other means). -- Viktor. From rt at openssl.org Mon Jan 25 18:24:55 2016 From: rt at openssl.org (Sara Dickinson via RT) Date: Mon, 25 Jan 2016 18:24:55 +0000 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: References: Message-ID: Hi, I would like to request that support be added to OpenSSL to enable client applications to make use use of TCP Fast Open (https://tools.ietf.org/html/rfc7413 ) when initiating the TLS handshake on Linux (TCP Fast Open is available in Linux kernel > 4.1). This was discussed in detail on the OpenSSL Users list: https://mta.openssl.org/pipermail/openssl-users/2016-January/002835.html Regards Sara. ------------------------- Sara Dickinson http://sinodun.com Sinodun Internet Technologies Ltd. Magdalen Centre The Oxford Science Park Oxford OX4 4GA U.K. From rt at openssl.org Mon Jan 25 18:42:02 2016 From: rt at openssl.org (Kurt Roeckx via RT) Date: Mon, 25 Jan 2016 18:42:02 +0000 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: <20160125184159.GA27842@roeckx.be> References: <20160125184159.GA27842@roeckx.be> Message-ID: On Mon, Jan 25, 2016 at 06:24:55PM +0000, Sara Dickinson via RT wrote: > Hi, > > I would like to request that support be added to OpenSSL to enable client applications to make use use of TCP Fast Open (https://tools.ietf.org/html/rfc7413 ) when initiating the TLS handshake on Linux (TCP Fast Open is available in Linux kernel > 4.1). I've seen that request, and I have tought about it. I'm just wondering if that comes with security consequences, like replay attacks. Specially in combination with what they're doing with TLS 1.3. The API clearly doesn't support anything like that currently. Kurt From openssl-users at dukhovni.org Mon Jan 25 18:51:11 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 25 Jan 2016 18:51:11 +0000 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: References: <20160125184159.GA27842@roeckx.be> Message-ID: <20160125185111.GO25513@mournblade.imrryr.org> On Mon, Jan 25, 2016 at 06:42:02PM +0000, Kurt Roeckx via RT wrote: > On Mon, Jan 25, 2016 at 06:24:55PM +0000, Sara Dickinson via RT wrote: > > Hi, > > > > I would like to request that support be added to OpenSSL to enable client applications to make use use of TCP Fast Open (https://tools.ietf.org/html/rfc7413 ) when initiating the TLS handshake on Linux (TCP Fast Open is available in Linux kernel > 4.1). > > I've seen that request, and I have tought about it. I'm just > wondering if that comes with security consequences, like replay > attacks. Specially in combination with what they're doing with > TLS 1.3. > > The API clearly doesn't support anything like that currently. No security impact. Just a saving of 1-RTT on "warm" TCP reconnects. If the client's first flight payload also carries 0-RTT TLS 1.3 data, the exposure is the same whether TCP fast open is used or not. -- Viktor. From dkg at fifthhorseman.net Mon Jan 25 19:32:14 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 25 Jan 2016 14:32:14 -0500 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: <20160125185111.GO25513@mournblade.imrryr.org> References: <20160125184159.GA27842@roeckx.be> <20160125185111.GO25513@mournblade.imrryr.org> Message-ID: <87zivta20x.fsf@alice.fifthhorseman.net> On Mon 2016-01-25 13:51:11 -0500, Viktor Dukhovni wrote: > On Mon, Jan 25, 2016 at 06:42:02PM +0000, Kurt Roeckx via RT wrote: > >> On Mon, Jan 25, 2016 at 06:24:55PM +0000, Sara Dickinson via RT wrote: >> > I would like to request that support be added to OpenSSL to enable >> > client applications to make use use of TCP Fast Open >> > (https://tools.ietf.org/html/rfc7413 >> > ) when initiating the TLS >> > handshake on Linux (TCP Fast Open is available in Linux kernel > >> > 4.1). I think it was added even earlier to the Linux kernel: http://kernelnewbies.org/Linux_3.13#head-159ff61ea3acfd67b88855e75dbbb140f8825c4a >> I've seen that request, and I have tought about it. I'm just >> wondering if that comes with security consequences, like replay >> attacks. Specially in combination with what they're doing with >> TLS 1.3. >> >> The API clearly doesn't support anything like that currently. > > No security impact. Just a saving of 1-RTT on "warm" TCP reconnects. > > If the client's first flight payload also carries 0-RTT TLS 1.3 > data, the exposure is the same whether TCP fast open is used or > not. I agree with this cryptographic analysis, fwiw. if 0-RTT support is added to OpenSSL, then we definitely need a clear API adjustment so that applications can know whether their data is going out in the non-PFS/non-replay-protected preflights, or in the regularly-protected session. But i don't think this has any bearing on TFO. --dkg From michel.sales at free.fr Mon Jan 25 21:26:49 2016 From: michel.sales at free.fr (Michel) Date: Mon, 25 Jan 2016 22:26:49 +0100 Subject: [openssl-dev] s_client version 1.1 fails to handshake to s_server when -nocert option In-Reply-To: <7C234D6A-9013-4F88-86EC-0444D0345F9A@dukhovni.org> References: <001101d14bac$63e4eb60$2baec220$@sales@free.fr> <000001d1578e$9004c7e0$b00e57a0$@sales@free.fr> <7C234D6A-9013-4F88-86EC-0444D0345F9A@dukhovni.org> Message-ID: <000101d157b7$1a65b5c0$4f312140$@sales@free.fr> I just found the man about setting the security level which is very helpful. May I suggest that a link be added to the 'see also' paragraph of the ciphers documentation ? >From https://www.openssl.org/docs/manmaster/apps/ciphers.html To https://www.openssl.org/docs/manmaster/ssl/SSL_set_security_level.html > this is a good time to discuss whether @SECLEVEL should have any bearing on aNULL support. Unfortunatly, I have no valuable opinion, but I would be pleased to read about arguments that will be discussed on this list. Thanks again, Michel. -----Message d'origine----- De?: openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Viktor Dukhovni Envoy??: lundi 25 janvier 2016 18:48 ??: openssl-dev at openssl.org Objet?: Re: [openssl-dev] s_client version 1.1 fails to handshake to s_server when -nocert option > On Jan 25, 2016, at 11:36 AM, Michel wrote: > > Thank you very much for your answer Viktor ! > It works, using : > openssl s_server -nocert -cipher "ALL:@STRENGTH:@SECLEVEL=0" > openssl s_client -cipher "ALL:@STRENGTH:@SECLEVEL=0" > I was able to handshake a "AECDH-AES256-SHA" cipher. > :-) > I will try to investigate deeper around the SECLEVEL=... keyword that I > completely missed. It is a very new feature and easy to miss amidst all other other new features. I am currently working on fixing some corner cases in this very code, so this is a good time to discuss whether @SECLEVEL should have any bearing on aNULL support. My instinct is that it should not, and I'm going to submit code that allows one to set a floor on the various crypto primitives allowed even for aNULL connections (which may be authenticated by other means). -- Viktor. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From bbrumley at gmail.com Tue Jan 26 07:14:45 2016 From: bbrumley at gmail.com (Billy Brumley) Date: Tue, 26 Jan 2016 09:14:45 +0200 Subject: [openssl-dev] recent EC_PRE_COMP changes Message-ID: https://github.com/openssl/openssl/commit/3aef36ffef89849348049296892327e6fdf9d705 That commit caused EC_PRE_COMP to lose a lot of generality. Was a function pointer approach like below considered? I'm not trying to resurrect EC_EXTRA_DATA, but a *little* flexibility would be nice. BBB diff --git a/crypto/ec/ec_lcl.h b/crypto/ec/ec_lcl.h index 2c5e1d9..9f5d4ec 100644 --- a/crypto/ec/ec_lcl.h +++ b/crypto/ec/ec_lcl.h @@ -256,24 +256,11 @@ struct ec_group_st { BN_MONT_CTX *mont_data; /* precomputed values for speed. */ - enum { - pct_none, - pct_nistp224, pct_nistp256, pct_nistp521, pct_nistz256, - pct_ec } pre_comp_type; - union { - NISTP224_PRE_COMP *nistp224; - NISTP256_PRE_COMP *nistp256; - NISTP521_PRE_COMP *nistp521; - NISTZ256_PRE_COMP *nistz256; - EC_PRE_COMP *ec; - } pre_comp; + void (*pre_comp_free) (EC_PRE_COMP *); + EC_PRE_COMP *(*pre_comp_dup) (EC_PRE_COMP *); + EC_PRE_COMP *pre_comp; } /* EC_GROUP */ ; From matt at openssl.org Tue Jan 26 13:22:32 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 26 Jan 2016 13:22:32 +0000 Subject: [openssl-dev] OpenSSL 1.1 SSL_CTX issues In-Reply-To: <20160121175743.GB25513@mournblade.imrryr.org> References: <56A1167F.2050700@highlandsun.com> <20160121175743.GB25513@mournblade.imrryr.org> Message-ID: <56A77318.2050107@openssl.org> On 21/01/16 17:57, Viktor Dukhovni wrote: > On Thu, Jan 21, 2016 at 05:33:51PM +0000, Howard Chu wrote: > >> In OpenLDAP we've been using >> CRYPTO_add(&ctx->references, 1, CRYPTO_LOCK_SSL_CTX) >> to manage our own SSL_CTXs but this is not possible with current 1.1. Making >> the structures opaque is a good move, but please provide methods to >> manipulate refcounts. >> >> Currently ssl_lib.c appears to bump the ctx refcount twice, in SSL_new. Why >> is that? > > Because the SSL handle has two references to the SSL_CTX. > > ssl->ctx > ssl->initial_ctx > > they are initially the same, but may diverge. These are freed > independently. > > Indeed there are at present no SSL_up_ref() or SSL_CTX_up_ref() > functions. The up_ref functions are at present: This has now been fixed. I have added SSL_up_ref() and SSL_CTX_up_ref(). Matt From rt at openssl.org Tue Jan 26 14:17:57 2016 From: rt at openssl.org (Sara Dickinson via RT) Date: Tue, 26 Jan 2016 14:17:57 +0000 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: <21D45226-2207-4E46-9AB4-C05E6D2C14AD@sinodun.com> References: <20160125184159.GA27842@roeckx.be> <21D45226-2207-4E46-9AB4-C05E6D2C14AD@sinodun.com> Message-ID: > On 25 Jan 2016, at 18:42, Kurt Roeckx via RT wrote: > > On Mon, Jan 25, 2016 at 06:24:55PM +0000, Sara Dickinson via RT wrote: >> Hi, >> >> I would like to request that support be added to OpenSSL to enable client applications to make use use of TCP Fast Open (https://tools.ietf.org/html/rfc7413 ) when initiating the TLS handshake on Linux (TCP Fast Open is available in Linux kernel > 4.1). > > I've seen that request, and I have tought about it. I'm just > wondering if that comes with security consequences, like replay > attacks. Not that I am aware of. I?ve seen the question of security vulnerabilities of TFO raised a few times but never with any concrete examples, just speculation. I?ve also observed Chromium using TFO with TLS. I can take the question to the TCPM and/or TLS WG if that is helpful? Sara. From rt at openssl.org Tue Jan 26 14:31:27 2016 From: rt at openssl.org (Short, Todd via RT) Date: Tue, 26 Jan 2016 14:31:27 +0000 Subject: [openssl-dev] [openssl.org #4272] [BUG/PATCH] Unit tests fail when DTLS is disabled In-Reply-To: <72FBC0B9-7C0C-46BD-8F44-871C2361A5CB@akamai.com> References: <72FBC0B9-7C0C-46BD-8F44-871C2361A5CB@akamai.com> Message-ID: Hello: When DTLS is disabled in master (./config no-dtls) the corresponding unit tests fail. The same thing would happen if TLS were disabled. The issue is in the ?TLS Version min/max tests? and DTLS Version min/max tests?. The skip function is not called within a SKIP: { } block, causing the tests to fail unexpectedly by ?skipping? the planned test, and then doing another test (i.e. ok()) later. I have a patch, but I am waiting for the RT number. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." From rt at openssl.org Tue Jan 26 14:36:59 2016 From: rt at openssl.org (Short, Todd via RT) Date: Tue, 26 Jan 2016 14:36:59 +0000 Subject: [openssl-dev] [openssl.org #4272] [BUG/PATCH] Unit tests fail when DTLS is disabled In-Reply-To: References: <72FBC0B9-7C0C-46BD-8F44-871C2361A5CB@akamai.com> Message-ID: Pull request for RT4272: https://github.com/openssl/openssl/pull/589 -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." From rsalz at akamai.com Tue Jan 26 15:33:14 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 26 Jan 2016 15:33:14 +0000 Subject: [openssl-dev] recent EC_PRE_COMP changes In-Reply-To: References: Message-ID: <44663e46724241dea23d28a25d7a4d36@ustx2ex-dag1mb1.msg.corp.akamai.com> > That commit caused EC_PRE_COMP to lose a lot of generality. Was a function > pointer approach like below considered? I'm not trying to resurrect > EC_EXTRA_DATA, but a *little* flexibility would be nice. What functionality was lost that isn't available in the public and standard EX_DATA model? From rt at openssl.org Tue Jan 26 15:44:41 2016 From: rt at openssl.org (Klein Marek via RT) Date: Tue, 26 Jan 2016 15:44:41 +0000 Subject: [openssl-dev] [openssl.org #4273] explicitText encoding In-Reply-To: References: Message-ID: Hello, I came across a problem while I was creating a certificate. I tried to set encoding type of the explicitText in Certificate Policies to utf-8 by prependig a corresponding tag in my .cnf file, as shown in the following example. ... userNotice.1=@noticesec1 [ noticesec1 ] explicitText= UTF8:UTF8 encoded explicit text ... However, the tag was ignored and handled as a part of the explicitText, and the type was set to VISIBLESTRING. I examined the code and found that the type of explicitText is hardcoded and always set to VISIBLESTRING. It is defined in RFC 5280 that the explicitText in a UserNotice is DisplayText, which can be of UTF8String, VisibleString, BMPString or IA5String type. Please see the following pull request https://github.com/openssl/openssl/pull/576, which fixes the issue. This patch allows user to decide for the type of explicitText by prepending it by UTF8, UTF8String, IA5STRING, IA5, BMPSTRING, BMP, VISIBLE or VISIBLESTRING. (as in nconf) Original functionality was preserved. Please let me know if you want me to modify the patch. Kind Regards / S pozdravom Marek Klein Disig, a.s. Zahradnicka 151, 821 08 Bratislava 2 marek.klein at disig.sk www.disig.sk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5187 bytes Desc: not available URL: From bbrumley at gmail.com Tue Jan 26 17:28:41 2016 From: bbrumley at gmail.com (Billy Brumley) Date: Tue, 26 Jan 2016 19:28:41 +0200 Subject: [openssl-dev] recent EC_PRE_COMP changes In-Reply-To: <44663e46724241dea23d28a25d7a4d36@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <44663e46724241dea23d28a25d7a4d36@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: >> That commit caused EC_PRE_COMP to lose a lot of generality. Was a function >> pointer approach like below considered? I'm not trying to resurrect >> EC_EXTRA_DATA, but a *little* flexibility would be nice. > > What functionality was lost that isn't available in the public and standard EX_DATA model? Well I don't see an ex_data attached to EC_GROUP or EC_METHOD. I must be missing something? I guess I can hijack one of the spare void pointers in EC_GROUP. I was somewhat familiar with the old point precomp flow for an EC_METHOD, so I'm having a bit of trouble wrapping my head around it. When I look at ec_lib.c, pre_comp_type is only being checked in switch statements in _free and _dup style wrappers. Seems out of place and oddly specific. Just one dude's opinion :) Thanks! BBB From rsalz at akamai.com Tue Jan 26 17:29:59 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 26 Jan 2016 17:29:59 +0000 Subject: [openssl-dev] recent EC_PRE_COMP changes In-Reply-To: References: <44663e46724241dea23d28a25d7a4d36@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: > Well I don't see an ex_data attached to EC_GROUP or EC_METHOD. No, do you need those? We can add them. > When I look at ec_lib.c, pre_comp_type is only being checked in switch > statements in _free and _dup style wrappers. Seems out of place and oddly > specific. Just one dude's opinion :) The precomp stuff is internal to openssl, so I think it's reasonable to put there. From rt at openssl.org Tue Jan 26 21:05:40 2016 From: rt at openssl.org (Kurt Roeckx via RT) Date: Tue, 26 Jan 2016 21:05:40 +0000 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: <20160126210533.GA29423@roeckx.be> References: <20160125184159.GA27842@roeckx.be> <21D45226-2207-4E46-9AB4-C05E6D2C14AD@sinodun.com> <20160126210533.GA29423@roeckx.be> Message-ID: On Tue, Jan 26, 2016 at 02:17:57PM +0000, Sara Dickinson via RT wrote: > > > On 25 Jan 2016, at 18:42, Kurt Roeckx via RT wrote: > > > > On Mon, Jan 25, 2016 at 06:24:55PM +0000, Sara Dickinson via RT wrote: > >> Hi, > >> > >> I would like to request that support be added to OpenSSL to enable client applications to make use use of TCP Fast Open (https://tools.ietf.org/html/rfc7413 ) when initiating the TLS handshake on Linux (TCP Fast Open is available in Linux kernel > 4.1). > > > > I've seen that request, and I have tought about it. I'm just > > wondering if that comes with security consequences, like replay > > attacks. > > Not that I am aware of. I've seen the question of security vulnerabilities of TFO raised a few times but never with any concrete examples, just speculation. I've also observed Chromium using TFO with TLS. It's just that I've seen this speculation at other places, and didn't understand it. > I can take the question to the TCPM and/or TLS WG if that is helpful? I don't think it's needed. Kurt From rsalz at akamai.com Tue Jan 26 21:37:58 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 26 Jan 2016 21:37:58 +0000 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: References: <20160125184159.GA27842@roeckx.be> <21D45226-2207-4E46-9AB4-C05E6D2C14AD@sinodun.com> <20160126210533.GA29423@roeckx.be> Message-ID: <7139fa5494fb4475881ad7c0af41b784@usma1ex-dag1mb1.msg.corp.akamai.com> TFO is interesting because it lets UDP-style attacks happen at the TCP level. Normally you can't do a TCP attack unless you have a valid client IP address. Imagine connecting once and then sending the syncookie to the botnet. This might be outside the scope of things OpenSSL cares about and I know recent Linux kernels have some mitigation capabilities. Also note that the server side should just work with no changes, it's on a TFO client that needs API changes. From rt at openssl.org Tue Jan 26 21:38:03 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 26 Jan 2016 21:38:03 +0000 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: <7139fa5494fb4475881ad7c0af41b784@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160125184159.GA27842@roeckx.be> <21D45226-2207-4E46-9AB4-C05E6D2C14AD@sinodun.com> <20160126210533.GA29423@roeckx.be> <7139fa5494fb4475881ad7c0af41b784@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: TFO is interesting because it lets UDP-style attacks happen at the TCP level. Normally you can't do a TCP attack unless you have a valid client IP address. Imagine connecting once and then sending the syncookie to the botnet. This might be outside the scope of things OpenSSL cares about and I know recent Linux kernels have some mitigation capabilities. Also note that the server side should just work with no changes, it's on a TFO client that needs API changes. From quanah at zimbra.com Tue Jan 26 21:47:44 2016 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Tue, 26 Jan 2016 13:47:44 -0800 Subject: [openssl-dev] OpenSSL 1.1 X509_NAME issues In-Reply-To: <56A11C29.4070907@highlandsun.com> References: <56A11C29.4070907@highlandsun.com> Message-ID: <87CB2DF22EA7CB296325229A@[192.168.1.9]> --On Thursday, January 21, 2016 5:58 PM +0000 Howard Chu wrote: > In OpenLDAP we reference X509_NAME->bytes->data directly, we want the DER > bytes which we then pass thru our own DN validator/formatter. This no > longer works with OpenSSL 1.1 and I don't see any provided method to > return the DER bytes. I don't want a malloc'd copy, I just want read-only > access to the bytes already cached inside the X509_NAME structure. > > for reference: > https://github.com/openldap/openldap/blob/master/libraries/libldap/tls_o. > c#L448 > https://github.com/openldap/openldap/blob/master/libraries/libldap/tls_o. > c#L475 Any update on this request? Thanks, Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From hyc at highlandsun.com Tue Jan 26 21:54:49 2016 From: hyc at highlandsun.com (Howard Chu) Date: Tue, 26 Jan 2016 21:54:49 +0000 Subject: [openssl-dev] OpenSSL 1.1 X509_NAME issues In-Reply-To: <87CB2DF22EA7CB296325229A@[192.168.1.9]> References: <56A11C29.4070907@highlandsun.com> <87CB2DF22EA7CB296325229A@[192.168.1.9]> Message-ID: <56A7EB29.7070107@highlandsun.com> Quanah Gibson-Mount wrote: > --On Thursday, January 21, 2016 5:58 PM +0000 Howard Chu > wrote: > >> In OpenLDAP we reference X509_NAME->bytes->data directly, we want the DER >> bytes which we then pass thru our own DN validator/formatter. This no >> longer works with OpenSSL 1.1 and I don't see any provided method to >> return the DER bytes. I don't want a malloc'd copy, I just want read-only >> access to the bytes already cached inside the X509_NAME structure. >> >> for reference: >> https://github.com/openldap/openldap/blob/master/libraries/libldap/tls_o. >> c#L448 >> https://github.com/openldap/openldap/blob/master/libraries/libldap/tls_o. >> c#L475 > > Any update on this request? I sent a patch to rt at openssl.org a couple hours ago. Hasn't shown up yet. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From rt at openssl.org Tue Jan 26 22:49:57 2016 From: rt at openssl.org (Howard Chu via RT) Date: Tue, 26 Jan 2016 22:49:57 +0000 Subject: [openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der() In-Reply-To: <56A7C890.7060706@symas.com> References: <56A7C890.7060706@symas.com> Message-ID: In OpenLDAP we reference X509_NAME->bytes->data directly, we want the DER bytes which we then pass thru our own DN validator/formatter. This no longer works with OpenSSL 1.1 and I don't see any provided method to return the DER bytes. I don't want a malloc'd copy, I just want read-only access to the bytes already cached inside the X509_NAME structure. The attached patch would be sufficient to meet this requirement. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-X509_NAME_der.patch Type: text/x-diff Size: 1124 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Jan 27 00:27:04 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 26 Jan 2016 19:27:04 -0500 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: <7139fa5494fb4475881ad7c0af41b784@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160125184159.GA27842@roeckx.be> <21D45226-2207-4E46-9AB4-C05E6D2C14AD@sinodun.com> <20160126210533.GA29423@roeckx.be> <7139fa5494fb4475881ad7c0af41b784@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <87fuxj7tpj.fsf@alice.fifthhorseman.net> On Tue 2016-01-26 16:37:58 -0500, Salz, Rich wrote: > TFO is interesting because it lets UDP-style attacks happen at the TCP > level. Normally you can't do a TCP attack unless you have a valid > client IP address. > > Imagine connecting once and then sending the syncookie to the botnet. This suggests that you have on-path capabilities between each of the reflectors and the victim, right? If you have on-path capabilities, couldn't you do a similar attack against a live TCP session? learn (or create) the sequence number of a TCP session between each of the reflectors and the target, and distribute them to the botnet? Then each member of the botnet sends out a TCP packet (sequence numbers augmented in some coordinated fashion) to the reflector that triggers an ACK (and even worse, a data flow) from the reflector to the victim. I've never done this, so maybe i've missed some mitigating detail, but it seems like the same risk with or without TFO. --dkg From rt at openssl.org Wed Jan 27 04:52:00 2016 From: rt at openssl.org (Daniel Kahn Gillmor via RT) Date: Wed, 27 Jan 2016 04:52:00 +0000 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: <87fuxj7tpj.fsf@alice.fifthhorseman.net> References: <20160125184159.GA27842@roeckx.be> <21D45226-2207-4E46-9AB4-C05E6D2C14AD@sinodun.com> <20160126210533.GA29423@roeckx.be> <7139fa5494fb4475881ad7c0af41b784@usma1ex-dag1mb1.msg.corp.akamai.com> <87fuxj7tpj.fsf@alice.fifthhorseman.net> Message-ID: On Tue 2016-01-26 16:37:58 -0500, Salz, Rich wrote: > TFO is interesting because it lets UDP-style attacks happen at the TCP > level. Normally you can't do a TCP attack unless you have a valid > client IP address. > > Imagine connecting once and then sending the syncookie to the botnet. This suggests that you have on-path capabilities between each of the reflectors and the victim, right? If you have on-path capabilities, couldn't you do a similar attack against a live TCP session? learn (or create) the sequence number of a TCP session between each of the reflectors and the target, and distribute them to the botnet? Then each member of the botnet sends out a TCP packet (sequence numbers augmented in some coordinated fashion) to the reflector that triggers an ACK (and even worse, a data flow) from the reflector to the victim. I've never done this, so maybe i've missed some mitigating detail, but it seems like the same risk with or without TFO. --dkg From agostrer at gmail.com Wed Jan 27 05:19:56 2016 From: agostrer at gmail.com (Alexander Gostrer) Date: Tue, 26 Jan 2016 21:19:56 -0800 Subject: [openssl-dev] ECDH engine In-Reply-To: <569FF2F0.60905@gmail.com> References: <20160120201925.17788998.82513.46556@ll.mit.edu> <569FF2F0.60905@gmail.com> Message-ID: Hi Uri, Let me know if you have any questions about these patches. Thank you, Alex. On Wed, Jan 20, 2016 at 12:49 PM, Douglas E Engert wrote: > When I started to write the ECDSA code for engine_pkcs11 in 2011 the code > to support the method hooks was not > in the code. So I used internal OpenSSL header files to copy the > ECDSA_METHOD and replace the function needed. > Look for "BUILD_WITH_ECS_LOCL_H" in libp11. Not until 1.0.2 did OpenSSL > support the needed calls to hook ECDSA. > They did not add the hooks for ECDH. > > If you can't wait then you have to do it your self. *YOU* could do the > same thing for ECDH. But your code would only > be good for 1.0.2 because the whole way of doing EC methods changes in > 1.1. > > I believe Alexander said he had changes to OpenSSL, which is another > approach. > He has said there were here: > https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches > > You could also hire someone who could do more then: "test it and offer > minor enhancements". > (And not me. I am taking the 1.1 approach to getting ECDH. working in > engine.) > > On 1/20/2016 2:19 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > Very possible that I'm missing the point here. > > Still, since openssl-1_0_2 does ECDH, and it exposes ?ECDSA to external > engine(s), how difficult would it be to add ECDH exposure? I suspect - a > good deal easier than getting 1.1 replace 1.0.x as the de-facto deployment > standard. > > Plus, by this time there already are (and reasonably common) tokens that > support ECDH, other packages that do ECDH, and people (like myself :-) > willing to test it and offer minor enhancements. > > Another point I seem to be missing - if what's necessary to implement ECDH > in an external engine is missing from 1_0_2 - how could ?Alexander write a > (presumably) working ECDH engine for 1_0_2? If he could do it, why can't > engine_pkcs11 be extended to do the same? > > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > *From: *Douglas E Engert > *Sent: *Wednesday, January 20, 2016 14:59 > *To: *openssl-dev at openssl.org? > *Reply To: *openssl-dev at openssl.org > *Subject: *Re: [openssl-dev] ECDH engine > ? > You are missing the point. OpenSSL-1.0.2 only exposed ECDSA, not ECDH to > external engines. It took years to even get ECDSA exposed. > OpenSSL approach to support this is OpenSSL-1.1 that does a lot of other > things. But that was there approach. Its their package. > >From working package to distribution always takes several years... > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jan 27 06:05:45 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 27 Jan 2016 06:05:45 +0000 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: <7139fa5494fb4475881ad7c0af41b784@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160125184159.GA27842@roeckx.be> <21D45226-2207-4E46-9AB4-C05E6D2C14AD@sinodun.com> <20160126210533.GA29423@roeckx.be> <7139fa5494fb4475881ad7c0af41b784@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160127060545.GA3896@mournblade.imrryr.org> On Tue, Jan 26, 2016 at 09:37:58PM +0000, Salz, Rich wrote: > TFO is interesting because it lets UDP-style attacks happen at the TCP > level. Normally you can't do a TCP attack unless you have a valid client > IP address. > > Imagine connecting once and then sending the syncookie to the botnet. I would expect that there is no "the cookie", and the cookie for each client is different. So no single connection would obtain cookies usable from multiple sources. That is, cookies militate UDP-style attacks. -- Viktor. From rt at openssl.org Wed Jan 27 14:19:32 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 27 Jan 2016 14:19:32 +0000 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: <13cb0a655ad643bcb98bc0eb3da0e4ed@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160125184159.GA27842@roeckx.be> <20160126210533.GA29423@roeckx.be> <7139fa5494fb4475881ad7c0af41b784@usma1ex-dag1mb1.msg.corp.akamai.com> <87fuxj7tpj.fsf@alice.fifthhorseman.net> <13cb0a655ad643bcb98bc0eb3da0e4ed@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > This suggests that you have on-path capabilities between each of the > reflectors and the victim, right? I don't think so: you need the first attacker to get the cookie, then you spread it out. > If you have on-path capabilities, couldn't you do a similar attack against a live > TCP session? Different because there you are interrupting a session, whereas with TFO you're starting a new connection and pushing data to the receiving app on a "new" connection. From rt at openssl.org Wed Jan 27 15:35:02 2016 From: rt at openssl.org (Billy Brumley via RT) Date: Wed, 27 Jan 2016 15:35:02 +0000 Subject: [openssl-dev] [openssl.org #4275] Test all built-in curves and let the library choose the EC_METHOD In-Reply-To: References: Message-ID: https://github.com/openssl/openssl/pull/592 Some of the other unit tests specify EC_METHOD. This additional test loop lets the library choose based on the default for the built-in curve's NID. BBB From foleyj at cisco.com Wed Jan 27 16:09:37 2016 From: foleyj at cisco.com (John Foley) Date: Wed, 27 Jan 2016 11:09:37 -0500 Subject: [openssl-dev] Verification of ABI compatibility Message-ID: <56A8EBC1.5090803@cisco.com> If anyone is interested, I've added a new build to the Jenkins workflow to verify ABI compatibility on the 1.0.2-stable branch. This job will run nightly and look for ABI differences between the current build and the build from the previous night. If a commit goes into the branch that changes ABI, this job should alert the openssl-commits alias. This results of this job can be viewed here: https://openssl-sanity.cisco.com:8443/view/1.0.2%20Stable/job/1_0_2_abi/ From rsalz at akamai.com Wed Jan 27 16:56:43 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 27 Jan 2016 16:56:43 +0000 Subject: [openssl-dev] Verification of ABI compatibility In-Reply-To: <56A8EBC1.5090803@cisco.com> References: <56A8EBC1.5090803@cisco.com> Message-ID: <5af07dfc3430443aafb1974b46ed4da6@usma1ex-dag1mb1.msg.corp.akamai.com> Way cool. Can you send mail to openssl-commits also? -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz > -----Original Message----- > From: John Foley [mailto:foleyj at cisco.com] > Sent: Wednesday, January 27, 2016 11:10 AM > To: openssl-dev at openssl.org > Subject: [openssl-dev] Verification of ABI compatibility > > If anyone is interested, I've added a new build to the Jenkins workflow to > verify ABI compatibility on the 1.0.2-stable branch. This job will run nightly > and look for ABI differences between the current build and the build from > the previous night. If a commit goes into the branch that changes ABI, this > job should alert the openssl-commits alias. > > This results of this job can be viewed here: > > https://openssl-sanity.cisco.com:8443/view/1.0.2%20Stable/job/1_0_2_abi/ > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From uri at ll.mit.edu Wed Jan 27 17:30:38 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 27 Jan 2016 17:30:38 +0000 Subject: [openssl-dev] ECDH engine In-Reply-To: References: <20160120201925.17788998.82513.46556@ll.mit.edu> <569FF2F0.60905@gmail.com> Message-ID: > Let me know if you have any questions about these patches. My only questions at this time (I briefly looked at your patches only, haven?t looked at your engine at all) are: why you needed to add ECDH\generate key() to crypto/ech/ecdh_key.c, and what?s the purpose of enabling (*init)(EC_KEY *eckey) and (*finish)(EC_KEY *eckey) in crypto/ecdh/ech_locl.h. Thanks! > On Wed, Jan 20, 2016 at 12:49 PM, Douglas E Engert wrote: >> When I started to write the ECDSA code for engine_pkcs11 in 2011 the code to >> support the method hooks was not >> in the code. So I used internal OpenSSL header files to copy the ECDSA_METHOD >> and replace the function needed. >> Look for "BUILD_WITH_ECS_LOCL_H" in libp11. Not until 1.0.2 did OpenSSL >> support the needed calls to hook ECDSA. >> They did not add the hooks for ECDH. >> >> If you can't wait then you have to do it your self. *YOU* could do the same >> thing for ECDH. But your code would only >> be good for 1.0.2 because the whole way of doing EC methods changes in 1.1. >> >> I believe Alexander said he had changes to OpenSSL, which is another >> approach. >> He has said there were here: >> https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches >> >> You could also hire someone who could do more then: "test it and offer minor >> enhancements". >> (And not me. I am taking the 1.1 approach to getting ECDH. working in >> engine.) >> >> On 1/20/2016 2:19 PM, Blumenthal, Uri - 0553 - MITLL wrote: >>> Very possible that I'm missing the point here. >>> >>> Still, since openssl-1_0_2 does ECDH, and it exposes ?ECDSA to external >>> engine(s), how difficult would it be to add ECDH exposure? I suspect - a >>> good deal easier than getting 1.1 replace 1.0.x as the de-facto deployment >>> standard. >>> >>> Plus, by this time there already are (and reasonably common) tokens that >>> support ECDH, other packages that do ECDH, and people (like myself :-) >>> willing to test it and offer minor enhancements. >>> >>> Another point I seem to be missing - if what's necessary to implement ECDH >>> in an external engine is missing from 1_0_2 - how could ?Alexander write a >>> (presumably) working ECDH engine for 1_0_2? If he could do it, why can't >>> engine_pkcs11 be extended to do the same? >>> >>> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE >>> network. >>> From: Douglas E Engert >>> Sent: Wednesday, January 20, 2016 14:59 >>> To: openssl-dev at openssl.org? >>> Reply To: openssl-dev at openssl.org >>> Subject: Re: [openssl-dev] ECDH engine >>> ? >>> You are missing the point. OpenSSL-1.0.2 only exposed ECDSA, not ECDH to >>> external engines. It took years to even get ECDSA exposed. >>> OpenSSL approach to support this is OpenSSL-1.1 that does a lot of other >>> things. But that was there approach. Its their package. >>>> >From working package to distribution always takes several years... >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From openssl-users at dukhovni.org Wed Jan 27 19:04:00 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 27 Jan 2016 19:04:00 +0000 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: References: <20160125184159.GA27842@roeckx.be> <20160126210533.GA29423@roeckx.be> <7139fa5494fb4475881ad7c0af41b784@usma1ex-dag1mb1.msg.corp.akamai.com> <87fuxj7tpj.fsf@alice.fifthhorseman.net> <13cb0a655ad643bcb98bc0eb3da0e4ed@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160127190400.GE3896@mournblade.imrryr.org> On Wed, Jan 27, 2016 at 02:19:32PM +0000, Salz, Rich via RT wrote: > > > This suggests that you have on-path capabilities between each of the > > reflectors and the victim, right? > > I don't think so: you need the first attacker to get the cookie, then you spread it out. Cheng, et al. Experimental [Page 8] RFC 7413 TCP Fast Open December 2014 The server is in charge of cookie generation and authentication. The cookie SHOULD be a MAC tag with the following properties. We use "SHOULD" because, in some cases, the cookie may be trivially generated as discussed in Section 7.3. 1. The cookie authenticates the client's (source) IP address of the SYN packet. The IP address may be an IPv4 or IPv6 address. 2. The cookie can only be generated by the server and cannot be fabricated by any other parties, including the client. 3. The generation and verification are fast relative to the rest of SYN and SYN-ACK processing. 4. A server may encode other information in the cookie and accept more than one valid cookie per client at any given time. But this is server-implementation dependent and transparent to the client. 5. The cookie expires after a certain amount of time. The reason for cookie expiration is detailed in the "Security Considerations" section (Section 5). This can be done by either periodically changing the server key used to generate cookies or including a timestamp when generating the cookie. To gradually invalidate cookies over time, the server can implement key rotation to generate and verify cookies using multiple keys. This approach is useful for large-scale servers to retain Fast Open rolling key updates. We do not specify a particular mechanism because the implementation is server specific. What attack do you have in mind via spreading a cookie good for just one source IP address? Sure the botnet can source TFO from that same IP address that got the original cookie. Why is that useful? -- Viktor. From rsalz at akamai.com Wed Jan 27 19:07:36 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 27 Jan 2016 19:07:36 +0000 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: <20160127190400.GE3896@mournblade.imrryr.org> References: <20160125184159.GA27842@roeckx.be> <20160126210533.GA29423@roeckx.be> <7139fa5494fb4475881ad7c0af41b784@usma1ex-dag1mb1.msg.corp.akamai.com> <87fuxj7tpj.fsf@alice.fifthhorseman.net> <13cb0a655ad643bcb98bc0eb3da0e4ed@usma1ex-dag1mb1.msg.corp.akamai.com> <20160127190400.GE3896@mournblade.imrryr.org> Message-ID: <69f4c7f90e89481f9703885cbeada390@usma1ex-dag1mb1.msg.corp.akamai.com> > What attack do you have in mind via spreading a cookie good for just one > source IP address? Sure the botnet can source TFO from that same IP > address that got the original cookie. Why is that useful? It's an amplification attack. I don't care about ever getting any reply back. As I first said, it makes UDP-style attacks possible in the TCP domain, and you don't know where the attack is coming from. From openssl-users at dukhovni.org Wed Jan 27 19:14:59 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 27 Jan 2016 19:14:59 +0000 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: <69f4c7f90e89481f9703885cbeada390@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160125184159.GA27842@roeckx.be> <20160126210533.GA29423@roeckx.be> <7139fa5494fb4475881ad7c0af41b784@usma1ex-dag1mb1.msg.corp.akamai.com> <87fuxj7tpj.fsf@alice.fifthhorseman.net> <13cb0a655ad643bcb98bc0eb3da0e4ed@usma1ex-dag1mb1.msg.corp.akamai.com> <20160127190400.GE3896@mournblade.imrryr.org> <69f4c7f90e89481f9703885cbeada390@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160127191459.GH3896@mournblade.imrryr.org> On Wed, Jan 27, 2016 at 07:07:36PM +0000, Salz, Rich wrote: > > What attack do you have in mind via spreading a cookie good for just one > > source IP address? Sure the botnet can source TFO from that same IP > > address that got the original cookie. Why is that useful? > > It's an amplification attack. I don't care about ever getting any reply > back. As I first said, it makes UDP-style attacks possible in the TCP > domain, and you don't know where the attack is coming from. Please explain. The traffic can only come from the party who initially obtains the cookie in a full round-trip. How does the botnet DoS some third party with this? Or is it just the slightly larger response size in the server's SYN-ACK + cookie vs. SYN-ACK on the initial cookie request? A reasonably secure HMAC need not be longer that 256 bits or 32 bytes, so the SYN-ACK is larger by 32 bytes + a couple of bytes of option encapsulation. If that's all, UDP is far more effective. Anyway, this has little relevance to support of TFO in OpenSSL, the attack is the same whether we support SSL handshakes with TFO or not. -- Viktor. From rsalz at akamai.com Wed Jan 27 19:20:04 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 27 Jan 2016 19:20:04 +0000 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: <20160127191459.GH3896@mournblade.imrryr.org> References: <20160125184159.GA27842@roeckx.be> <20160126210533.GA29423@roeckx.be> <7139fa5494fb4475881ad7c0af41b784@usma1ex-dag1mb1.msg.corp.akamai.com> <87fuxj7tpj.fsf@alice.fifthhorseman.net> <13cb0a655ad643bcb98bc0eb3da0e4ed@usma1ex-dag1mb1.msg.corp.akamai.com> <20160127190400.GE3896@mournblade.imrryr.org> <69f4c7f90e89481f9703885cbeada390@usma1ex-dag1mb1.msg.corp.akamai.com> <20160127191459.GH3896@mournblade.imrryr.org> Message-ID: <18f5f15e5126467180e4375c1fbfb38a@usma1ex-dag1mb1.msg.corp.akamai.com> > Please explain. The traffic can only come from the party who initially obtains > the cookie in a full round-trip. How does the botnet DoS some third party > with this? Attacker wants to bring down an akamai host. They connect to one of our servers with the fast-open option and get the cookie. They then spread that cookie all over the internet and zillions of bots connect. Our server spawns zillions of threads and starts to do some work, or the TCP queue fills up. I can't filter on IP address to stop the attack because the client IP address is bogus. It's just like a DNS/UDP attack, except at the TCP layer which much software is not prepared to handle. From openssl-users at dukhovni.org Wed Jan 27 19:32:07 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 27 Jan 2016 19:32:07 +0000 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: <18f5f15e5126467180e4375c1fbfb38a@usma1ex-dag1mb1.msg.corp.akamai.com> References: <7139fa5494fb4475881ad7c0af41b784@usma1ex-dag1mb1.msg.corp.akamai.com> <87fuxj7tpj.fsf@alice.fifthhorseman.net> <13cb0a655ad643bcb98bc0eb3da0e4ed@usma1ex-dag1mb1.msg.corp.akamai.com> <20160127190400.GE3896@mournblade.imrryr.org> <69f4c7f90e89481f9703885cbeada390@usma1ex-dag1mb1.msg.corp.akamai.com> <20160127191459.GH3896@mournblade.imrryr.org> <18f5f15e5126467180e4375c1fbfb38a@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160127193206.GJ3896@mournblade.imrryr.org> On Wed, Jan 27, 2016 at 07:20:04PM +0000, Salz, Rich wrote: > > Please explain. The traffic can only come from the party who initially obtains > > the cookie in a full round-trip. How does the botnet DoS some third party > > with this? > > Attacker wants to bring down an akamai host. They connect to one of our > servers with the fast-open option and get the cookie. They then spread > that cookie all over the internet and zillions of bots connect. The connections need to be from the attacker's original IP address that obtained the cookie. > Our server > spawns zillions of threads and starts to do some work, or the TCP queue > fills up. I can't filter on IP address to stop the attack because the > client IP address is bogus. The client IP address is not entirely "bogus", it is the IP address of the client that obtained the cookie, otherwise the cookie is not valid. Block sending cookies to sources whose cookies are abused. Also note that the TFO queue length is limited, and most requests will require a full round-trips when the request volume is high. Anyway, this is not the right forum for TFO threat analysis that has nothing to do with SSL. We should add client-side support for TFO. -- Viktor. From michel.sales at free.fr Wed Jan 27 20:05:07 2016 From: michel.sales at free.fr (Michel) Date: Wed, 27 Jan 2016 21:05:07 +0100 Subject: [openssl-dev] unexpected message, SSL alert 10 Message-ID: <003201d1593e$0531a8c0$0f94fa40$@sales@free.fr> Hi, Doing some OpenSSL 1.1 pre-2 tests between a client and a server I got : client : error:141600F4:SSL routines:read_state_machine:unexpected message server : error:140943F2:SSL routines:ssl3_read_bytes:reason(1010); SSL alert number 10 As I read somewhere that this alert should never be observed between proper implementations, I thought best to report it. What I did : Neither client or server context was initialisied with certificates or key. (I wanted to test anonymous ciphers) But I erroneously used SSL_CTX_set_verify() with SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT; (server side). Let me know if you need more informations. Regards, Michel -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Wed Jan 27 22:38:16 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 27 Jan 2016 23:38:16 +0100 Subject: [openssl-dev] MSVC 2015 internal compiler error In-Reply-To: <569A1EAC.1000607@yahoo.no> References: <569A1EAC.1000607@yahoo.no> Message-ID: <20160127223816.GA25165@roeckx.be> On Sat, Jan 16, 2016 at 11:42:52AM +0100, Gisle Vanem wrote: > While building OpenSSL from today's git-repo: > > ssl\d1_srtp.c : fatal error C1001: An internalerror has occurred in the compiler. > (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 246) > To work around this problem, try simplifying or changing the program near the locations listed above. > Please choose the Technical Support command on the Visual C++ > Help menu, or open the Technical Support help file for more information > > INTERNAL COMPILER ERROR in 'f:\gv\VC_2015\bin\cl.exe' > Please choose the Technical Support command on the Visual C++ > Help menu, or open the Technical Support help file for more information > > ----- > > Seems to be related to: > typedef const char *OPENSSL_CSTRING; > > in safestack.h Changing this into: > > #ifdef _MSC_VER > typedef char *OPENSSL_CSTRING; > #else > typedef const char *OPENSSL_CSTRING; > #endif > > helps, but triggers the same internal compiler error later on. > > It suspect the compiler sees 'const const *x' in some > places. So I assume that's the trigger for this fault. So we've been seeing this on AppVeyor too. As far as I can see, this happens somewhere between commit 249d9719 and 59fd40d4. The file itself has only minor changes, turning some "SSL_CIPHER *" into "const SSL_CIPHER *", so it's most likely one of the include files that changed in between. It includes changes to safestack, including adding inline functions instead of the defines. So that is probably why it fails, but I currently don't see a way to work around this, or how we could simplify things. The problem also only seems to have with VC 14/2015. It works in all the older versions we have on AppVeyor. Have you actually tried to contact Microsoft about this issue? Kurt From anthony.chow at al-enterprise.com Wed Jan 27 22:43:42 2016 From: anthony.chow at al-enterprise.com (Anthony T CHOW) Date: Wed, 27 Jan 2016 22:43:42 +0000 Subject: [openssl-dev] Using openssl to check for cert reovcation using OCSP In-Reply-To: <20160127223816.GA25165@roeckx.be> References: <569A1EAC.1000607@yahoo.no>,<20160127223816.GA25165@roeckx.be> Message-ID: If this is not the correct forum to ask this question, can someone please point me to the right direction. On the search engine, I can only find articles to use OpenSSL to configure OCSP server and to issue certificate that uses OCSP. My question is that do I need to write my function to call OpenSSL to use OCSP to check if a certificate is revoked or I can configure OpenSSL to check this by setting flag in openssl.cnf? Thanks so much for the information, anthony. From erik at efca.com Wed Jan 27 23:12:33 2016 From: erik at efca.com (Erik Forsberg) Date: Wed, 27 Jan 2016 15:12:33 -0800 Subject: [openssl-dev] MSVC 2015 internal compiler error In-Reply-To: <20160127223816.GA25165@roeckx.be> References: <569A1EAC.1000607@yahoo.no><20160127223816.GA25165@roeckx.be> Message-ID: I also noticed compiler warnings generated by this code using SunStudio compilers. This patch fixes those for me and seems to do the correct thing. Maybe it makes the VC compiler work too ? *** lhash.h Thu Jan 14 01:51:33 2016 --- ../../../x64/include/openssl//lhash.h Wed Jan 27 15:09:47 2016 *************** *** 99,105 **** unsigned long name##_LHASH_HASH(const void *); # define IMPLEMENT_LHASH_HASH_FN(name, o_type) \ unsigned long name##_LHASH_HASH(const void *arg) { \ ! const o_type *a = arg; \ return name##_hash(a); } # define LHASH_HASH_FN(name) name##_LHASH_HASH --- 99,105 ---- unsigned long name##_LHASH_HASH(const void *); # define IMPLEMENT_LHASH_HASH_FN(name, o_type) \ unsigned long name##_LHASH_HASH(const void *arg) { \ ! o_type *a = (o_type *) arg; \ return name##_hash(a); } # define LHASH_HASH_FN(name) name##_LHASH_HASH *************** *** 108,115 **** int name##_LHASH_COMP(const void *, const void *); # define IMPLEMENT_LHASH_COMP_FN(name, o_type) \ int name##_LHASH_COMP(const void *arg1, const void *arg2) { \ ! const o_type *a = arg1; \ ! const o_type *b = arg2; \ return name##_cmp(a,b); } # define LHASH_COMP_FN(name) name##_LHASH_COMP --- 108,115 ---- int name##_LHASH_COMP(const void *, const void *); # define IMPLEMENT_LHASH_COMP_FN(name, o_type) \ int name##_LHASH_COMP(const void *arg1, const void *arg2) { \ ! o_type *a = (o_type *) arg1; \ ! o_type *b = (o_type *) arg2; \ return name##_cmp(a,b); } # define LHASH_COMP_FN(name) name##_LHASH_COMP *************** *** 118,125 **** void name##_LHASH_DOALL_ARG(void *, void *); # define IMPLEMENT_LHASH_DOALL_ARG_FN(name, o_type, a_type) \ void name##_LHASH_DOALL_ARG(void *arg1, void *arg2) { \ ! o_type *a = arg1; \ ! a_type *b = arg2; \ name##_doall_arg(a, b); } # define LHASH_DOALL_ARG_FN(name) name##_LHASH_DOALL_ARG --- 118,125 ---- void name##_LHASH_DOALL_ARG(void *, void *); # define IMPLEMENT_LHASH_DOALL_ARG_FN(name, o_type, a_type) \ void name##_LHASH_DOALL_ARG(void *arg1, void *arg2) { \ ! o_type *a = (o_type *) arg1; \ ! a_type *b = (o_type *) arg2; \ name##_doall_arg(a, b); } # define LHASH_DOALL_ARG_FN(name) name##_LHASH_DOALL_ARG >-- Original Message -- > >On Sat, Jan 16, 2016 at 11:42:52AM +0100, Gisle Vanem wrote: >> While building OpenSSL from today's git-repo: >> >> ssl\d1_srtp.c : fatal error C1001: An internalerror has occurred in the compiler. >> (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 246) >> To work around this problem, try simplifying or changing the program near the locations listed above. >> Please choose the Technical Support command on the Visual C++ >> Help menu, or open the Technical Support help file for more information >> >> INTERNAL COMPILER ERROR in 'f:\gv\VC_2015\bin\cl.exe' >> Please choose the Technical Support command on the Visual C++ >> Help menu, or open the Technical Support help file for more information >> >> ----- >> >> Seems to be related to: >> typedef const char *OPENSSL_CSTRING; >> >> in safestack.h Changing this into: >> >> #ifdef _MSC_VER >> typedef char *OPENSSL_CSTRING; >> #else >> typedef const char *OPENSSL_CSTRING; >> #endif >> >> helps, but triggers the same internal compiler error later on. >> >> It suspect the compiler sees 'const const *x' in some >> places. So I assume that's the trigger for this fault. > >So we've been seeing this on AppVeyor too. As far as I can see, >this happens somewhere between commit 249d9719 and 59fd40d4. The >file itself has only minor changes, turning some "SSL_CIPHER *" >into "const SSL_CIPHER *", so it's most likely one of the include >files that changed in between. > >It includes changes to safestack, including adding inline >functions instead of the defines. So that is probably why it >fails, but I currently don't see a way to work around this, or how >we could simplify things. > >The problem also only seems to have with VC 14/2015. It works in >all the older versions we have on AppVeyor. > >Have you actually tried to contact Microsoft about this issue? > > >Kurt > >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rsalz at akamai.com Thu Jan 28 00:22:06 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 28 Jan 2016 00:22:06 +0000 Subject: [openssl-dev] Using openssl to check for cert reovcation using OCSP In-Reply-To: References: <569A1EAC.1000607@yahoo.no>,<20160127223816.GA25165@roeckx.be> Message-ID: > If this is not the correct forum to ask this question, can someone please point > me to the right direction. You might try openssl-users. > My question is that do I need to write my function to call OpenSSL to use > OCSP to check if a certificate is revoked or I can configure OpenSSL to check > this by setting flag in openssl.cnf? You have to write your own code. Openssl does not fetch things automatically. From agostrer at gmail.com Thu Jan 28 03:54:22 2016 From: agostrer at gmail.com (Alexander Gostrer) Date: Wed, 27 Jan 2016 19:54:22 -0800 Subject: [openssl-dev] ECDH engine In-Reply-To: References: <20160120201925.17788998.82513.46556@ll.mit.edu> <569FF2F0.60905@gmail.com> Message-ID: Hi Uri, On Wed, Jan 27, 2016 at 9:30 AM, Blumenthal, Uri - 0553 - MITLL < uri at ll.mit.edu> wrote: > Let me know if you have any questions about these patches. > > > My only questions at this time (I briefly looked at your patches only, > haven?t looked at your engine at all) are: why you needed to add > ECDH\generate key() to crypto/ech/ecdh_key.c, > In the TLS-1.2 protocol (sl_srvr.c) the server generates an ephemeral key pair for ECDH and sends the public key in the server key exchange message (see ssl3_send_server_key_exchange(SSL *s) function). It does not use the private key until it gets the client public key in the "ssl3_send_server_key_exchange(SSL *s)". Just then it calls the "ECDH_compute_key()" with the client public key and the server private key generated much earlier. If I do not call this new function then the openssl sends a software-generated ephemeral key to the client. Adding this function was the simplest way to fix the problem. On client everything happens in the same function so it wasn't a problem. > and what?s the purpose of enabling (*init)(EC_KEY *eckey) and (*finish)(EC_KEY > *eckey) in crypto/ecdh/ech_locl.h. > I used "ecdh->meth->init(eckey)" in this new "ECDH_generate_key(EC_KEY *eckey)" function to actually generate the ephemeral pair. Probably should call it "generate_key()" instead but again was trying to minimize the impact. "finish()" was in the same package - didn't use it. Regards, Alex. Sorry for delay: take some time to go over the code to remember things :) > > Thanks! > > > On Wed, Jan 20, 2016 at 12:49 PM, Douglas E Engert > wrote: > >> When I started to write the ECDSA code for engine_pkcs11 in 2011 the >> code to support the method hooks was not >> in the code. So I used internal OpenSSL header files to copy the >> ECDSA_METHOD and replace the function needed. >> Look for "BUILD_WITH_ECS_LOCL_H" in libp11. Not until 1.0.2 did OpenSSL >> support the needed calls to hook ECDSA. >> They did not add the hooks for ECDH. >> >> If you can't wait then you have to do it your self. *YOU* could do the >> same thing for ECDH. But your code would only >> be good for 1.0.2 because the whole way of doing EC methods changes in >> 1.1. >> >> I believe Alexander said he had changes to OpenSSL, which is another >> approach. >> He has said there were here: >> https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches >> >> You could also hire someone who could do more then: "test it and offer >> minor enhancements". >> (And not me. I am taking the 1.1 approach to getting ECDH. working in >> engine.) >> >> On 1/20/2016 2:19 PM, Blumenthal, Uri - 0553 - MITLL wrote: >> >> Very possible that I'm missing the point here. >> >> Still, since openssl-1_0_2 does ECDH, and it exposes ?ECDSA to external >> engine(s), how difficult would it be to add ECDH exposure? I suspect - a >> good deal easier than getting 1.1 replace 1.0.x as the de-facto deployment >> standard. >> >> Plus, by this time there already are (and reasonably common) tokens that >> support ECDH, other packages that do ECDH, and people (like myself :-) >> willing to test it and offer minor enhancements. >> >> Another point I seem to be missing - if what's necessary to implement >> ECDH in an external engine is missing from 1_0_2 - how could ?Alexander >> write a (presumably) working ECDH engine for 1_0_2? If he could do it, why >> can't engine_pkcs11 be extended to do the same? >> >> >> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. >> *From: *Douglas E Engert >> *Sent: *Wednesday, January 20, 2016 14:59 >> *To: *openssl-dev at openssl.org? >> *Reply To: *openssl-dev at openssl.org >> *Subject: *Re: [openssl-dev] ECDH engine >> ? >> You are missing the point. OpenSSL-1.0.2 only exposed ECDSA, not ECDH to >> external engines. It took years to even get ECDSA exposed. >> OpenSSL approach to support this is OpenSSL-1.1 that does a lot of other >> things. But that was there approach. Its their package. >> >From working package to distribution always takes several years... >> >> >> >> > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gvanem at yahoo.no Thu Jan 28 06:02:43 2016 From: gvanem at yahoo.no (Gisle Vanem) Date: Thu, 28 Jan 2016 07:02:43 +0100 Subject: [openssl-dev] MSVC 2015 internal compiler error In-Reply-To: <20160127223816.GA25165@roeckx.be> References: <569A1EAC.1000607@yahoo.no> <20160127223816.GA25165@roeckx.be> Message-ID: <56A9AF03.4050104@yahoo.no> Kurt Roeckx wrote: > So we've been seeing this on AppVeyor too. As far as I can see, > this happens somewhere between commit 249d9719 and 59fd40d4. The > file itself has only minor changes, turning some "SSL_CIPHER *" > into "const SSL_CIPHER *", so it's most likely one of the include > files that changed in between. > > It includes changes to safestack, including adding inline > functions instead of the defines. So that is probably why it > fails, but I currently don't see a way to work around this, or how > we could simplify things. I haven't tried Erik Forsberg's patch for lhash.h. And have no time to look into this. I use TDM-gcc in the meantime. > Have you actually tried to contact Microsoft about this issue? No, for the reason above. -- --gv From deengert at gmail.com Thu Jan 28 11:54:03 2016 From: deengert at gmail.com (Douglas E Engert) Date: Thu, 28 Jan 2016 05:54:03 -0600 Subject: [openssl-dev] ECDH engine In-Reply-To: References: <20160120201925.17788998.82513.46556@ll.mit.edu> <569FF2F0.60905@gmail.com> Message-ID: <56AA015B.8000505@gmail.com> An HTML attachment was scrubbed... URL: From tshort at akamai.com Thu Jan 28 14:15:30 2016 From: tshort at akamai.com (Short, Todd) Date: Thu, 28 Jan 2016 14:15:30 +0000 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: <20160127193206.GJ3896@mournblade.imrryr.org> References: <7139fa5494fb4475881ad7c0af41b784@usma1ex-dag1mb1.msg.corp.akamai.com> <87fuxj7tpj.fsf@alice.fifthhorseman.net> <13cb0a655ad643bcb98bc0eb3da0e4ed@usma1ex-dag1mb1.msg.corp.akamai.com> <20160127190400.GE3896@mournblade.imrryr.org> <69f4c7f90e89481f9703885cbeada390@usma1ex-dag1mb1.msg.corp.akamai.com> <20160127191459.GH3896@mournblade.imrryr.org> <18f5f15e5126467180e4375c1fbfb38a@usma1ex-dag1mb1.msg.corp.akamai.com> <20160127193206.GJ3896@mournblade.imrryr.org> Message-ID: <46E1268F-9839-4E90-B5CD-0451B7D1AE74@akamai.com> However, we?re talking about botnets. They do bad things, they don?t follow the rules. They can masquerade as the original sender and send additional data. The received data held ought to be limited to the initial window of the connection, AND, since these are all original SYNs (pun intended) the server receiving the data ought to only be saving one packet worth of data (i.e. TFO queue), since the first data pack should be repeated (because it?s the initial data on the connection) on subsequent SYNs on the to-be established connection. So, the problem isn?t other members of the botnet receiving cookies, because they can?t exceed the TFO queue, but multiple members of the botnet doing TFO on their own, and not responding to the SYN-ACK, potentially opening up thousands of embryonic sockets with thousands of bytes of data, which is what the original SYN-cookies were meant to prevent in the first place. Regardless, this can happen with or without OpenSSL support, and any server that supports TFO is ?Asking For Trouble?, IMHO. While I personally don?t think that TFO should be supported anywhere for security reasons (it is ?experimental?), there?s no reason to not support it in in OpenSSL. On the other hand, if someone really wanted to support this, they could write their own BIO. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Jan 27, 2016, at 2:32 PM, Viktor Dukhovni > wrote: On Wed, Jan 27, 2016 at 07:20:04PM +0000, Salz, Rich wrote: Please explain. The traffic can only come from the party who initially obtains the cookie in a full round-trip. How does the botnet DoS some third party with this? Attacker wants to bring down an akamai host. They connect to one of our servers with the fast-open option and get the cookie. They then spread that cookie all over the internet and zillions of bots connect. The connections need to be from the attacker's original IP address that obtained the cookie. Our server spawns zillions of threads and starts to do some work, or the TCP queue fills up. I can't filter on IP address to stop the attack because the client IP address is bogus. The client IP address is not entirely "bogus", it is the IP address of the client that obtained the cookie, otherwise the cookie is not valid. Block sending cookies to sources whose cookies are abused. Also note that the TFO queue length is limited, and most requests will require a full round-trips when the request volume is high. Anyway, this is not the right forum for TFO threat analysis that has nothing to do with SSL. We should add client-side support for TFO. -- Viktor. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Thu Jan 28 15:03:27 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 28 Jan 2016 15:03:27 +0000 Subject: [openssl-dev] OpenSSL version 1.0.1r published Message-ID: <20160128150327.GA23362@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.1r released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.1r of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.1-notes.html OpenSSL 1.0.1r is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.1r.tar.gz Size: 4547786 SHA1 checksum: d2cfa980ef4548da6079fa1e51fe1fb2e5a53e99 SHA256 checksum: 784bd8d355ed01ce98b812f873f8b2313da61df7c7b5677fcf2e57b0863a3346 The checksums were calculated using the following commands: openssl sha1 openssl-1.0.1r.tar.gz openssl sha256 openssl-1.0.1r.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWqiPkAAoJENnE0m0OYESRcmgIAJidxSVl5K1TE23gWxVrj75z tYY1YGGi+DjyYMJCxuXaKKZ/Yidhj8w3d+b0HnUs8r2YJNRjDQmh+BvGtA4FIgcq WQlypzUL/hmyicdvhTz/Y0r3O0DNOpYFIrjkWGkJFiYYm2bZIwDqkx4UAImOM3r1 qh0SfUuILDsHhwsi/EMexmTNKOuqcXWc/UVy2a5q074Va7BRJnUvAApD/jBpZgdh fIWOlVs1BnVE87wPddyXHK6UlyUd+5Zuc91ytvxYQayqx9D/t0AZ73isfzoE1jj9 dDS9H2+SJyN+WwJI1UUxZ8QthmPbnWwKpR733xtMUZ5r0M2e+V92eOgTNfcVvEI= =AYwY -----END PGP SIGNATURE----- From openssl at openssl.org Thu Jan 28 15:03:37 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 28 Jan 2016 15:03:37 +0000 Subject: [openssl-dev] OpenSSL version 1.0.2f published Message-ID: <20160128150337.GA23585@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.2f released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2f of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2f is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2f.tar.gz Size: 5258384 SHA1 checksum: 2047c592a6e5a42bd37970bdb4a931428110a927 SHA256 checksum: 932b4ee4def2b434f85435d9e3e19ca8ba99ce9a065a61524b429a9d5e9b2e9c The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2f.tar.gz openssl sha256 openssl-1.0.2f.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWqh5GAAoJENnE0m0OYESRsd8IALq/rtH2LTBSva5EahcoHWbp wa/bcqnk84tWhBtFdsPY6bc842I7KUuajdlb/O/tKket/7XDBtO8Ud+xwajCDjUR 0Ui56bWUD6KzDCKOuarTQ2zSdrnbBvO20x4WZlpNQ67ZsEQ3DuSouTetFGRmNgfb Te2BNteBZ//OGsqfvzuegbMbAuaePwwOO8XurNqwm4O1F1dphz7BuBx9IiCsHypa ISmmx27WzGYUS30nQuseFTHj8wd++zaJVRX8xM/alqoDdOT6qkavqpVku8RhwKuZ gnmeIXPRPzktYagQ1w+Py5ZGEIEZhvJpf/UQktuGw6xJ+D8PXC3D3i1Rth9UHIA= =ITZs -----END PGP SIGNATURE----- From openssl at openssl.org Thu Jan 28 15:05:47 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 28 Jan 2016 15:05:47 +0000 Subject: [openssl-dev] OpenSSL Security Advisory Message-ID: <20160128150547.GA26799@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL Security Advisory [28th Jan 2016] ========================================= NOTE: SUPPORT FOR VERSION 1.0.1 WILL BE ENDING ON 31ST DECEMBER 2016. NO SECURITY FIXES WILL BE PROVIDED AFTER THAT DATE. UNTIL THAT TIME SECURITY FIXES ONLY ARE BEING APPLIED. DH small subgroups (CVE-2016-0701) ================================== Severity: High Historically OpenSSL usually only ever generated DH parameters based on "safe" primes. More recently (in version 1.0.2) support was provided for generating X9.42 style parameter files such as those required for RFC 5114 support. The primes used in such files may not be "safe". Where an application is using DH configured with parameters based on primes that are not "safe" then an attacker could use this fact to find a peer's private DH exponent. This attack requires that the attacker complete multiple handshakes in which the peer uses the same private DH exponent. For example this could be used to discover a TLS server's private DH exponent if it's reusing the private DH exponent or it's using a static DH ciphersuite. OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in TLS. It is not on by default. If the option is not set then the server reuses the same private DH exponent for the life of the server process and would be vulnerable to this attack. It is believed that many popular applications do set this option and would therefore not be at risk. OpenSSL before 1.0.2f will reuse the key if: - - SSL_CTX_set_tmp_dh()/SSL_set_tmp_dh() is used and SSL_OP_SINGLE_DH_USE is not set. - - SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used, and both the parameters and the key are set and SSL_OP_SINGLE_DH_USE is not used. This is an undocumted feature and parameter files don't contain the key. - - Static DH ciphersuites are used. The key is part of the certificate and so it will always reuse it. This is only supported in 1.0.2. It will not reuse the key for DHE ciphers suites if: - - SSL_OP_SINGLE_DH_USE is set - - SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used and the callback does not provide the key, only the parameters. The callback is almost always used like this. Non-safe primes are generated by OpenSSL when using: - - genpkey with the dh_rfc5114 option. This will write an X9.42 style file including the prime-order subgroup size "q". This is supported since the 1.0.2 version. Older versions can't read files generated in this way. - - dhparam with the -dsaparam option. This has always been documented as requiring the single use. The fix for this issue adds an additional check where a "q" parameter is available (as is the case in X9.42 based parameters). This detects the only known attack, and is the only possible defense for static DH ciphersuites. This could have some performance impact. Additionally the SSL_OP_SINGLE_DH_USE option has been switched on by default and cannot be disabled. This could have some performance impact. This issue affects OpenSSL version 1.0.2. OpenSSL 1.0.2 users should upgrade to 1.0.2f OpenSSL 1.0.1 is not affected by this CVE because it does not support X9.42 based parameters. It is possible to generate parameters using non "safe" primes, but this option has always been documented as requiring single use and is not the default or believed to be common. However, as a precaution, the SSL_OP_SINGLE_DH_USE change has also been backported to 1.0.1r. This issue was reported to OpenSSL on 12 January 2016 by Antonio Sanso (Adobe). The fix was developed by Matt Caswell of the OpenSSL development team (incorporating some work originally written by Stephen Henson of the OpenSSL core team). SSLv2 doesn't block disabled ciphers (CVE-2015-3197) ==================================================== Severity: Low A malicious client can negotiate SSLv2 ciphers that have been disabled on the server and complete SSLv2 handshakes even if all SSLv2 ciphers have been disabled, provided that the SSLv2 protocol was not also disabled via SSL_OP_NO_SSLv2. This issue affects OpenSSL versions 1.0.2 and 1.0.1. OpenSSL 1.0.2 users should upgrade to 1.0.2f OpenSSL 1.0.1 users should upgrade to 1.0.1r This issue was reported to OpenSSL on 26th December 2015 by Nimrod Aviram and Sebastian Schinzel. The fix was developed by Nimrod Aviram with further development by Viktor Dukhovni of the OpenSSL development team. An update on DHE man-in-the-middle protection (Logjam) ==================================================================== A previously published vulnerability in the TLS protocol allows a man-in-the-middle attacker to downgrade vulnerable TLS connections using ephemeral Diffie-Hellman key exchange to 512-bit export-grade cryptography. This vulnerability is known as Logjam (CVE-2015-4000). OpenSSL added Logjam mitigation for TLS clients by rejecting handshakes with DH parameters shorter than 768 bits in releases 1.0.2b and 1.0.1n. This limit has been increased to 1024 bits in this release, to offer stronger cryptographic assurance for all TLS connections using ephemeral Diffie-Hellman key exchange. OpenSSL 1.0.2 users should upgrade to 1.0.2f OpenSSL 1.0.1 users should upgrade to 1.0.1r The fix was developed by Kurt Roeckx of the OpenSSL development team. Note ==== As per our previous announcements and our Release Strategy (https://www.openssl.org/policies/releasestrat.html), support for OpenSSL version 1.0.1 will cease on 31st December 2016. No security updates for that version will be provided after that date. Users of 1.0.1 are advised to upgrade. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20160128.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWqiT1AAoJENnE0m0OYESR07gIAJ65FdP2oFR9pspmLh+iZ978 Q+1R8vShqUjkpE14gUOHaidgsU8l7HoR7v3mWFtv+XqBUp94ISOFeyt4B4jlDsHE SSgO60zlnYha0KaOeRv/aH1quiWhx8bxNZ1HJbbwlxPclqmEplhXqoSEbVvOZKFZ VPu8gmJg3fzdQpQT0eAZ/5ez6SMvIM1FO47FlqtstWgHSs0iq1scIr1LKNmH3uMZ tmNmq5U/tTX/51eKYqFIrWXIeyHSiOTXRBUjnw4ybCiobklLH1qiEApJW6iPkOob 9WthtiyBVBxCpYpF8h4mQc3h77J/q4rLcL/b56sqMsHTV4ULhbN2VIUnzcuzIUI= =Dfuh -----END PGP SIGNATURE----- From rt at openssl.org Thu Jan 28 16:16:29 2016 From: rt at openssl.org (Mario Scalabrino via RT) Date: Thu, 28 Jan 2016 16:16:29 +0000 Subject: [openssl-dev] [openssl.org #4276] Possible bug - ts -verify -digest, error:ts_rsp_verify.c:291: In-Reply-To: <56AA3226.3060801@andifyou.com> References: <56AA3226.3060801@andifyou.com> Message-ID: Good afternoon Openssl, please forward this email to whomever it may concern. I receive an error and the Timestamping provider suspects it is a Openssl bug. Could you please check if it is openssl or the certificate? This is when the error occurr /openssl ts -verify -digest e16db7d30581e44a5540f19553852b5a4e4e26f9adc365cc846f94038ee33025 -in /tmp/namirial.tsr -CAfile /tmp/NamirialCATSA.pem (result:) ************* *Verification: FAILED** **140236013643424:error:2F067065:time stamp routines:TS_CHECK_SIGNING_CERTS:ess signing certificate error:ts_rsp_verify.c:291:*/ I attach a complete reproduction scenario. I don't know if it is a problem of this TSA certificate or in Openssl due to sha256 digest, please help. (in the curl command I cannot provide you the username and password, it is a paid service) Attached are the files resulting from the below commands in sequence and the certificate of the TSA, but I'm sure you can check yourself the last command where the error occur and advice. you can copy and paste the commands below if you're in Linux Ubuntu and the files are in the /tmp/ folder *Reproduction scenario:* OS: Ubuntu 14.04 Openssl version: OpenSSL 1.0.1f 6 Jan 2014 Generate tsq: openssl ts -query -digest e16db7d30581e44a5540f19553852b5a4e4e26f9adc365cc846f94038ee33025 -sha256 -cert -out /tmp/namirial.tsq Readable tsq: openssl ts -query -in /tmp/namirial.tsq -text (result:) ************ Hash Algorithm: sha256 Message data: 0000 - e1 6d b7 d3 05 81 e4 4a-55 40 f1 95 53 85 2b 5a .m.....JU at ..S.+Z 0010 - 4e 4e 26 f9 ad c3 65 cc-84 6f 94 03 8e e3 30 25 NN&...e..o....0% Policy OID: unspecified Nonce: 0x8CA62B5766A29A8B Certificate required: yes Extensions: **************** Generate tsr (using curl) curl -u xxxxxxx:yyyyyy -s --data-binary @/tmp/namirial.tsq -H 'Content-Type: application/timestamp-query' -H 'Pragma: no-cache' -H 'Accept: application/timestamp-reply' --output /tmp/namirial.tsr http://timestamp.firmacerta.it Readable tsr openssl ts -reply -in /tmp/namirial.tsr -out /tmp/readable_tsr.txt -text (result:) ****************** Status info: Status: Granted. Status description: Operation Okay Failure info: unspecified TST info: Version: 1 Policy OID: 1.3.6.1.4.1.36203.2.1 Hash Algorithm: sha256 Message data: 0000 - e1 6d b7 d3 05 81 e4 4a-55 40 f1 95 53 85 2b 5a .m.....JU at ..S.+Z 0010 - 4e 4e 26 f9 ad c3 65 cc-84 6f 94 03 8e e3 30 25 NN&...e..o....0% Serial number: 0x1947FD96B97A42DE Time stamp: Jan 28 14:56:16 2016 GMT Accuracy: unspecified seconds, 0x01F4 millis, unspecified micros Ordering: no Nonce: 0x8CA62B5766A29A8B TSA: unspecified Extensions: ************************ Verify openssl ts -verify -digest e16db7d30581e44a5540f19553852b5a4e4e26f9adc365cc846f94038ee33025 -in /tmp/namirial.tsr -CAfile /tmp/NamirialCATSA.pem (result:) ************* *Verification: FAILED** **140236013643424:error:2F067065:time stamp routines:TS_CHECK_SIGNING_CERTS:ess signing certificate error:ts_rsp_verify.c:291:* *************** -- Untitled Document *Certify Doc * *MARIO SCALABRINO * Founder & CEO (+34) 680 128 282 mario.scalabrino at andifyou.com www.certifydoc.eu Linkedin Facebook Twitter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ScenarioOpensslNamirial.zip Type: application/x-zip-compressed Size: 4753 bytes Desc: not available URL: From foleyj at cisco.com Thu Jan 28 16:40:37 2016 From: foleyj at cisco.com (John Foley) Date: Thu, 28 Jan 2016 11:40:37 -0500 Subject: [openssl-dev] 1.0.1r release not committed to git repo Message-ID: <56AA4485.7000105@cisco.com> I just cloned the OpenSSL git repo at git://git.openssl.org/openssl.git. Looking at the OpenSSL_1_0_1-stable branch, the fix for CVE-2015-3197 still isn't in the repo. The most recent commit is: foleyj at hobknob:~/gitsync/ossl/openssl$ git log commit 126ac21c80967ec00f802d356462c1b83fa0f54c Author: Richard Levitte Date: Tue Jan 19 20:35:41 2016 +0100 Fix BSD -rpath parameter For BSD systems, Configure adds a shared_ldflags including a reference to the Makefile variable LIBRPATH, but since it must be passed down to Makefile.shared, care must be taken so the value of LIBRPATH doesn't get expanded too early, or it ends up giving an empty string. Reviewed-by: Viktor Dukhovni (cherry picked from commit c64879d3f3cc4c7f1c436a9fe3bd109847a23629) Did someone forgot to push the commit after generating the 1.0.1r release today? || -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jan 28 17:20:38 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 28 Jan 2016 17:20:38 +0000 Subject: [openssl-dev] 1.0.1r release not committed to git repo In-Reply-To: <56AA4485.7000105@cisco.com> References: <56AA4485.7000105@cisco.com> Message-ID: <56AA4DE6.103@openssl.org> On 28/01/16 16:40, John Foley wrote: > I just cloned the OpenSSL git repo at > git://git.openssl.org/openssl.git. Looking at the OpenSSL_1_0_1-stable > branch, the fix for CVE-2015-3197 still isn't in the repo. The most > recent commit is: > > foleyj at hobknob:~/gitsync/ossl/openssl$ git log > commit 126ac21c80967ec00f802d356462c1b83fa0f54c > Author: Richard Levitte > Date: Tue Jan 19 20:35:41 2016 +0100 > > Fix BSD -rpath parameter > > For BSD systems, Configure adds a shared_ldflags including a reference > to the Makefile variable LIBRPATH, but since it must be passed down to > Makefile.shared, care must be taken so the value of LIBRPATH doesn't > get expanded too early, or it ends up giving an empty string. > > Reviewed-by: Viktor Dukhovni > (cherry picked from commit c64879d3f3cc4c7f1c436a9fe3bd109847a23629) > > Did someone forgot to push the commit after generating the 1.0.1r > release today? Oops. I failed to notice that the push had failed. Resolved now. Thanks. Matt From rt at openssl.org Thu Jan 28 17:50:13 2016 From: rt at openssl.org (David Benjamin via RT) Date: Thu, 28 Jan 2016 17:50:13 +0000 Subject: [openssl-dev] [openssl.org #4277] DSAPublicKey should use dsa_cb in 1.1.0 In-Reply-To: References: Message-ID: DSAPublicKey lost the dsa_cb in https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=ea6b07b54c1f8fc2275a121cdda071e2df7bd6c1 This results in d2i_DSAPublicKey using crypto/asn1's default allocation logic rather than calling into DSA_new. I believe it should use ASN1_SEQUENCE_cb. I've attached a tiny sample program. On my machine, when building against master, the second reference count is 0 and then the second DSA_free crashes. Also, the comment in dsa_asn1.c and d2i_DSAPublicKey.pod both still refer to write_params which no longer exists. David -------------- next part -------------- A non-text attachment was scrubbed... Name: dsa_public_key.c Type: application/octet-stream Size: 593 bytes Desc: not available URL: From foleyj at cisco.com Thu Jan 28 17:43:47 2016 From: foleyj at cisco.com (John Foley) Date: Thu, 28 Jan 2016 12:43:47 -0500 Subject: [openssl-dev] 1.0.1r release not committed to git repo In-Reply-To: <56AA4DE6.103@openssl.org> References: <56AA4485.7000105@cisco.com> <56AA4DE6.103@openssl.org> Message-ID: <56AA5353.7090309@cisco.com> Thank you. On 01/28/2016 12:20 PM, Matt Caswell wrote: > > On 28/01/16 16:40, John Foley wrote: >> I just cloned the OpenSSL git repo at >> git://git.openssl.org/openssl.git. Looking at the OpenSSL_1_0_1-stable >> branch, the fix for CVE-2015-3197 still isn't in the repo. The most >> recent commit is: >> >> foleyj at hobknob:~/gitsync/ossl/openssl$ git log >> commit 126ac21c80967ec00f802d356462c1b83fa0f54c >> Author: Richard Levitte >> Date: Tue Jan 19 20:35:41 2016 +0100 >> >> Fix BSD -rpath parameter >> >> For BSD systems, Configure adds a shared_ldflags including a reference >> to the Makefile variable LIBRPATH, but since it must be passed down to >> Makefile.shared, care must be taken so the value of LIBRPATH doesn't >> get expanded too early, or it ends up giving an empty string. >> >> Reviewed-by: Viktor Dukhovni >> (cherry picked from commit c64879d3f3cc4c7f1c436a9fe3bd109847a23629) >> >> Did someone forgot to push the commit after generating the 1.0.1r >> release today? > Oops. I failed to notice that the push had failed. Resolved now. Thanks. > > Matt > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > . > From rt at openssl.org Thu Jan 28 19:19:33 2016 From: rt at openssl.org (David Benjamin via RT) Date: Thu, 28 Jan 2016 19:19:33 +0000 Subject: [openssl-dev] [openssl.org #4278] DH_CHECK_PUBKEY_INVALID should be 0x4, not 0x3 In-Reply-To: References: Message-ID: The recently-added DH_CHECK_PUBKEY_INVALID was set to 0x3, but DH_CHECK_PUBKEY_* values are flags, so it should be 0x4 to avoid colliding with DH_CHECK_PUBKEY_TOO_SMALL (0x01) and DH_CHECK_PUBKEY_TOO_LARGE (0x02). See DH_check_pub_key's *ret |= logic. https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=b128abc3437600c3143cb2145185ab87ba3156a2 (Also, that code is missing malloc failure checks on BN_set_word, BN_sub_word, and BN_copy. Though I could believe the first two don't actually end up calling malloc; I didn't check.) David From rt at openssl.org Thu Jan 28 20:45:58 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 28 Jan 2016 20:45:58 +0000 Subject: [openssl-dev] [openssl.org #4252] [PATCH] Fix the inclusion of e_os2.h In-Reply-To: References: Message-ID: test was removed -- it hasn't been compiled in a very long time, and it is not useful. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Jan 28 23:43:50 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Thu, 28 Jan 2016 23:43:50 +0000 Subject: [openssl-dev] [openssl.org #4277] DSAPublicKey should use dsa_cb in 1.1.0 In-Reply-To: References: Message-ID: Thanks for the report, fixed now. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From anthony.chow at al-enterprise.com Thu Jan 28 23:58:39 2016 From: anthony.chow at al-enterprise.com (Anthony T CHOW) Date: Thu, 28 Jan 2016 23:58:39 +0000 Subject: [openssl-dev] X509_V_FLAG_OCSP_CHECK In-Reply-To: References: Message-ID: On the openssl-user mailing list archive, I found this: http://www.mail-archive.com/openssl-users at openssl.org/msg67721.html On GitHub, I don't find this flag X509_V_FLAG_OCSP_CHECK Seems like this proposed change is not merged into the Master branch. Or, is it by default, OpenSSL will check for the certificate revocation using OCSP? Thanks for the information, Anthony. From rt at openssl.org Fri Jan 29 09:59:23 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Fri, 29 Jan 2016 09:59:23 +0000 Subject: [openssl-dev] [openssl.org #4279] openssl-1.1.0-pre2 make failes on Solaris10 x64 In-Reply-To: <375309.47091.qm@web101209.mail.kks.yahoo.co.jp> References: <375309.47091.qm@web101209.mail.kks.yahoo.co.jp> Message-ID: Hello, I tried openssl-1.1.0-pre2 on Solaris10 x86/x64. For x86, no error found. But for X64, make fails in crypto/modes. Got the same result with solarisstudio12.4 & gcc-4.8.5. 1. with solarisstudio12.4 % ./Configure solaris64-x86_64-cc % make ? : cc -I.. -I../.. -I../modes -I../include -I../../include? -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xarch=generic64 -xstrconst -Xa -DL_ENDIAN -DFILIO_H -xO5 -xdepend -xbuiltin -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c? -o ghash-x86_64.o ghash-x86_64.s cc: Warning: -xarch=generic64 is deprecated, use -m64 to create 64-bit programs Assembler: ??????? "ghash-x86_64.s", line 890 : Syntax error ??????? Near line: "??? movq??? $1.15473355479995e+19,%rax" cc: fbe failed for ghash-x86_64.s : recipe for target 'ghash-x86_64.o' failed make[2]: *** [ghash-x86_64.o] Error 2 make[2]: Leaving directory '/tmp/openssl-1.1.0-pre2/crypto/modes' 2. with gcc-4.8.5 % ./Configure solaris64-x86_64-gcc % make ? : make[2]: Entering directory '/tmp/openssl-1.1.0-pre2/crypto/modes' gcc -I.. -I../.. -I../modes -I../include -I../../include? -DOPENSSL_THREADS -pthread -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -Wall -DL_ENDIAN -DFILIO_H -O3 -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c? -o ghash-x86_64.o ghash-x86_64.s ghash-x86_64.s: Assembler messages: ghash-x86_64.s:890: Error: junk `.15473355479995e+19' after expression : recipe for target 'ghash-x86_64.o' failed make[2]: *** [ghash-x86_64.o] Error 1 make[2]: Leaving directory '/tmp/openssl-1.1.0-pre2/crypto/modes' Makefile:90: recipe for target 'subdirs' failed make[1]: *** [subdirs] Error 1 make[1]: Leaving directory '/tmp/openssl-1.1.0-pre2/crypto' Makefile:287: recipe for target 'build_crypto' failed make: *** [build_crypto] Error 1 Regards, --- Kiyoshi From rt at openssl.org Fri Jan 29 09:59:23 2016 From: rt at openssl.org (Aleksey Sanin via RT) Date: Fri, 29 Jan 2016 09:59:23 +0000 Subject: [openssl-dev] [openssl.org #4280] OpenSSL 1.1.0 pre 2: feature request: ECDSA_SIG_set0(const ECDSA_SIG*, BIGNUM *, BIGNUM *) is needed In-Reply-To: <56AAF976.7010102@aleksey.com> References: <56AAF976.7010102@aleksey.com> Message-ID: Hello, At the moment, there is no way to set r/s in the ECDSA_SIG structure manually to verify the signature encoded into a different format. Would be great to add a simple function: void ECDSA_SIG_set0(const ECDSA_SIG*, BIGNUM *, BIGNUM *) to set these values similar to other XXX_set0() functions. Thanks, -- Aleksey From hanno at hboeck.de Fri Jan 29 11:02:48 2016 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Fri, 29 Jan 2016 12:02:48 +0100 Subject: [openssl-dev] OpenSSL Security Advisory In-Reply-To: <20160128150547.GA26799@openssl.org> References: <20160128150547.GA26799@openssl.org> Message-ID: <20160129120248.5c2171d5@pc1> On Thu, 28 Jan 2016 15:05:47 +0000 OpenSSL wrote: > Additionally the SSL_OP_SINGLE_DH_USE option has been switched on by > default and cannot be disabled. This could have some performance > impact. I think it's good that this has been changed now. I found this ephemeral key reuse always problematic. However as far as I'm aware there's still the same situation with elliptic curve diffie hellman. It reuses the ephemeral key for several connections unless one sets SSL_OP_SINGLE_ECDH_USE. As with the DH one most server apps already set this. This is unrelated to the current vuln, but I find this risky. It creates an additional server secret that can leak and bugs in the elliptic curve key exchange that would be harmless without this feature could become very severe. I would therefore propose to do the same change also for ECDH and make SSL_OP_SINGLE_ECDH_USE the default. -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rt at openssl.org Fri Jan 29 12:01:58 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 29 Jan 2016 12:01:58 +0000 Subject: [openssl-dev] [openssl.org #4278] DH_CHECK_PUBKEY_INVALID should be 0x4, not 0x3 In-Reply-To: References: Message-ID: Thanks David - fixed. Matt From rt at openssl.org Fri Jan 29 13:14:57 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 29 Jan 2016 13:14:57 +0000 Subject: [openssl-dev] [openssl.org #3600] When compiling with enable-ec_nistp_64_gcc_128, then EC_GROUP_have_precompute_mult always returns 0 In-Reply-To: References: Message-ID: Fixed in master and 1.0.2. Thanks for the report. Matt From deengert at gmail.com Fri Jan 29 13:18:53 2016 From: deengert at gmail.com (Douglas E Engert) Date: Fri, 29 Jan 2016 07:18:53 -0600 Subject: [openssl-dev] [openssl.org #4280] OpenSSL 1.1.0 pre 2: feature request: ECDSA_SIG_set0(const ECDSA_SIG*, BIGNUM *, BIGNUM *) is needed In-Reply-To: References: <56AAF976.7010102@aleksey.com> Message-ID: <56AB66BD.3040106@gmail.com> I agree. Until OpenSSL adds a ECDSA_SIG_set0 there is a way, for example: rv = PKCS11_ecdsa_sign(dgst, dlen, sigret, &siglen, key); nLen = siglen / 2; if (rv > 0) { sig = ECDSA_SIG_new(); if (sig) { #if OPENSSL_VERSION_NUMBER >= 0x10100000L /* * OpenSSL 1.1 does not have a way to allocate r and s * in ECDSA_SIG as it is now hidden. * Will us dummy ASN1 so r and s are allocated then * use ECDSA_SIG_get0 to get access to r and s * can then update r annd s */ const unsigned char *a; unsigned char dasn1[8] = {0x30, 0x06, 0x02, 0x01, 0x00, 0x02, 0x01, 0x00}; BIGNUM *r; BIGNUM *s; a = dasn1; d2i_ECDSA_SIG(&sig, &a, 8); ECDSA_SIG_get0(&r, &s, sig); BN_bin2bn(&sigret[0], nLen, r); BN_bin2bn(&sigret[nLen], nLen, s); #else BN_bin2bn(&sigret[0], nLen, sig->r); BN_bin2bn(&sigret[nLen], nLen, sig->s); #endif } } return sig; On 1/29/2016 3:59 AM, Aleksey Sanin via RT wrote: > Hello, > > At the moment, there is no way to set r/s in the ECDSA_SIG structure > manually to verify the signature encoded into a different format. > Would be great to add a simple function: > > void ECDSA_SIG_set0(const ECDSA_SIG*, BIGNUM *, BIGNUM *) > > to set these values similar to other XXX_set0() functions. > > Thanks, > -- Douglas E. Engert From rt at openssl.org Fri Jan 29 13:44:45 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 29 Jan 2016 13:44:45 +0000 Subject: [openssl-dev] [openssl.org #4280] OpenSSL 1.1.0 pre 2: feature request: ECDSA_SIG_set0(const ECDSA_SIG*, BIGNUM *, BIGNUM *) is needed In-Reply-To: <56AAF976.7010102@aleksey.com> References: <56AAF976.7010102@aleksey.com> Message-ID: On Fri Jan 29 09:59:23 2016, aleksey at aleksey.com wrote: > Hello, > > At the moment, there is no way to set r/s in the ECDSA_SIG structure > manually to verify the signature encoded into a different format. > Would be great to add a simple function: > > void ECDSA_SIG_set0(const ECDSA_SIG*, BIGNUM *, BIGNUM *) > > to set these values similar to other XXX_set0() functions. > The way ECDSA_SIG_new() work r and s should always be non-NULL so you should be able to use the the ECDSA_SIG_get0 function to retrieve pointers to r and s which can then be modified. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From uri at ll.mit.edu Fri Jan 29 13:58:33 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 29 Jan 2016 13:58:33 +0000 Subject: [openssl-dev] OpenSSL Security Advisory Message-ID: <20160129135841.17788998.11010.48180@ll.mit.edu> +1 Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Hanno B?ck Sent: Friday, January 29, 2016 06:18 To: openssl-dev at openssl.org Reply To: openssl-dev at openssl.org Cc: openssl at openssl.org Subject: Re: [openssl-dev] OpenSSL Security Advisory On Thu, 28 Jan 2016 15:05:47 +0000 OpenSSL wrote: > Additionally the SSL_OP_SINGLE_DH_USE option has been switched on by > default and cannot be disabled. This could have some performance > impact. I think it's good that this has been changed now. I found this ephemeral key reuse always problematic. However as far as I'm aware there's still the same situation with elliptic curve diffie hellman. It reuses the ephemeral key for several connections unless one sets SSL_OP_SINGLE_ECDH_USE. As with the DH one most server apps already set this. This is unrelated to the current vuln, but I find this risky. It creates an additional server secret that can leak and bugs in the elliptic curve key exchange that would be harmless without this feature could become very severe. I would therefore propose to do the same change also for ECDH and make SSL_OP_SINGLE_ECDH_USE the default. -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From swall at redcom.com Fri Jan 29 13:55:50 2016 From: swall at redcom.com (Wall, Stephen) Date: Fri, 29 Jan 2016 08:55:50 -0500 Subject: [openssl-dev] X509_V_FLAG_OCSP_CHECK In-Reply-To: References: Message-ID: <401084E5E73F4241A44F3C9E6FD79428036688A064@exch-01> > -----Original Message----- > From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Anthony T CHOW > > On the openssl-user mailing list archive, I found this: > > http://www.mail-archive.com/openssl-users at openssl.org/msg67721.html > > On GitHub, I don't find this flag X509_V_FLAG_OCSP_CHECK I've previously asked about this, the OpenSSL team had no plans to act on the patch at that time (a few months ago). From hyc at highlandsun.com Fri Jan 29 14:59:26 2016 From: hyc at highlandsun.com (Howard Chu) Date: Fri, 29 Jan 2016 14:59:26 +0000 Subject: [openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der() In-Reply-To: References: <56A7C890.7060706@symas.com> Message-ID: <56AB7E4E.90909@highlandsun.com> Howard Chu via RT wrote: > In OpenLDAP we reference X509_NAME->bytes->data directly, we want the DER > bytes which we then pass thru our own DN validator/formatter. This no longer > works with OpenSSL 1.1 and I don't see any provided method to return the DER > bytes. I don't want a malloc'd copy, I just want read-only access to the bytes > already cached inside the X509_NAME structure. > > The attached patch would be sufficient to meet this requirement. We are tracking this here as well: http://www.openldap.org/its/index.cgi/Development?id=8353 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From rt at openssl.org Fri Jan 29 15:08:47 2016 From: rt at openssl.org (Howard Chu via RT) Date: Fri, 29 Jan 2016 15:08:47 +0000 Subject: [openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der() In-Reply-To: <56AB7E4E.90909@highlandsun.com> References: <56A7C890.7060706@symas.com> <56AB7E4E.90909@highlandsun.com> Message-ID: Howard Chu via RT wrote: > In OpenLDAP we reference X509_NAME->bytes->data directly, we want the DER > bytes which we then pass thru our own DN validator/formatter. This no longer > works with OpenSSL 1.1 and I don't see any provided method to return the DER > bytes. I don't want a malloc'd copy, I just want read-only access to the bytes > already cached inside the X509_NAME structure. > > The attached patch would be sufficient to meet this requirement. We are tracking this here as well: http://www.openldap.org/its/index.cgi/Development?id=8353 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From openssl-users at dukhovni.org Fri Jan 29 17:03:58 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 29 Jan 2016 12:03:58 -0500 Subject: [openssl-dev] [openssl.org #4279] openssl-1.1.0-pre2 make failes on Solaris10 x64 In-Reply-To: References: <375309.47091.qm@web101209.mail.kks.yahoo.co.jp> Message-ID: <83FCAF38-8F28-4761-A6BD-8879D077E40B@dukhovni.org> > On Jan 29, 2016, at 4:59 AM, Kiyoshi KANAZAWA via RT wrote: > > cc -I.. -I../.. -I../modes -I../include -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xarch=generic64 -xstrconst -Xa -DL_ENDIAN -DFILIO_H -xO5 -xdepend -xbuiltin -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o ghash-x86_64.o ghash-x86_64.s > cc: Warning: -xarch=generic64 is deprecated, use -m64 to create 64-bit programs > Assembler: > "ghash-x86_64.s", line 890 : Syntax error > Near line: " movq $1.15473355479995e+19,%rax" You'll need a 64-bit Perl. When I try "perl ghash-x86_64.pl" I get: ... subq $48,%rcx movq $11547335547999543296,%rax movdqu 48(%rsi),%xmm14 movdqu 64(%rsi),%xmm15 ... -- Viktor. From rt at openssl.org Fri Jan 29 17:04:05 2016 From: rt at openssl.org (Viktor Dukhovni via RT) Date: Fri, 29 Jan 2016 17:04:05 +0000 Subject: [openssl-dev] [openssl.org #4279] openssl-1.1.0-pre2 make failes on Solaris10 x64 In-Reply-To: <83FCAF38-8F28-4761-A6BD-8879D077E40B@dukhovni.org> References: <375309.47091.qm@web101209.mail.kks.yahoo.co.jp> <83FCAF38-8F28-4761-A6BD-8879D077E40B@dukhovni.org> Message-ID: > On Jan 29, 2016, at 4:59 AM, Kiyoshi KANAZAWA via RT wrote: > > cc -I.. -I../.. -I../modes -I../include -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xarch=generic64 -xstrconst -Xa -DL_ENDIAN -DFILIO_H -xO5 -xdepend -xbuiltin -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o ghash-x86_64.o ghash-x86_64.s > cc: Warning: -xarch=generic64 is deprecated, use -m64 to create 64-bit programs > Assembler: > "ghash-x86_64.s", line 890 : Syntax error > Near line: " movq $1.15473355479995e+19,%rax" You'll need a 64-bit Perl. When I try "perl ghash-x86_64.pl" I get: ... subq $48,%rcx movq $11547335547999543296,%rax movdqu 48(%rsi),%xmm14 movdqu 64(%rsi),%xmm15 ... -- Viktor. From tshort at akamai.com Fri Jan 29 17:14:25 2016 From: tshort at akamai.com (Short, Todd) Date: Fri, 29 Jan 2016 17:14:25 +0000 Subject: [openssl-dev] [openssl.org #4279] openssl-1.1.0-pre2 make failes on Solaris10 x64 In-Reply-To: References: <375309.47091.qm@web101209.mail.kks.yahoo.co.jp> <83FCAF38-8F28-4761-A6BD-8879D077E40B@dukhovni.org> Message-ID: <78EEA715-EF95-4B66-A71F-85D1808F3593@akamai.com> This sounds like RT3885. I have an available fix: https://github.com/openssl/openssl/pull/597 -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Jan 29, 2016, at 12:04 PM, Viktor Dukhovni via RT > wrote: On Jan 29, 2016, at 4:59 AM, Kiyoshi KANAZAWA via RT > wrote: cc -I.. -I../.. -I../modes -I../include -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xarch=generic64 -xstrconst -Xa -DL_ENDIAN -DFILIO_H -xO5 -xdepend -xbuiltin -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o ghash-x86_64.o ghash-x86_64.s cc: Warning: -xarch=generic64 is deprecated, use -m64 to create 64-bit programs Assembler: "ghash-x86_64.s", line 890 : Syntax error Near line: " movq $1.15473355479995e+19,%rax" You'll need a 64-bit Perl. When I try "perl ghash-x86_64.pl" I get: ... subq $48,%rcx movq $11547335547999543296,%rax movdqu 48(%rsi),%xmm14 movdqu 64(%rsi),%xmm15 ... -- Viktor. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Jan 29 17:14:29 2016 From: rt at openssl.org (Short, Todd via RT) Date: Fri, 29 Jan 2016 17:14:29 +0000 Subject: [openssl-dev] [openssl.org #4279] openssl-1.1.0-pre2 make failes on Solaris10 x64 In-Reply-To: <78EEA715-EF95-4B66-A71F-85D1808F3593@akamai.com> References: <375309.47091.qm@web101209.mail.kks.yahoo.co.jp> <83FCAF38-8F28-4761-A6BD-8879D077E40B@dukhovni.org> <78EEA715-EF95-4B66-A71F-85D1808F3593@akamai.com> Message-ID: This sounds like RT3885. I have an available fix: https://github.com/openssl/openssl/pull/597 -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Jan 29, 2016, at 12:04 PM, Viktor Dukhovni via RT > wrote: On Jan 29, 2016, at 4:59 AM, Kiyoshi KANAZAWA via RT > wrote: cc -I.. -I../.. -I../modes -I../include -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xarch=generic64 -xstrconst -Xa -DL_ENDIAN -DFILIO_H -xO5 -xdepend -xbuiltin -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o ghash-x86_64.o ghash-x86_64.s cc: Warning: -xarch=generic64 is deprecated, use -m64 to create 64-bit programs Assembler: "ghash-x86_64.s", line 890 : Syntax error Near line: " movq $1.15473355479995e+19,%rax" You'll need a 64-bit Perl. When I try "perl ghash-x86_64.pl" I get: ... subq $48,%rcx movq $11547335547999543296,%rax movdqu 48(%rsi),%xmm14 movdqu 64(%rsi),%xmm15 ... -- Viktor. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Fri Jan 29 17:16:42 2016 From: rt at openssl.org (Short, Todd via RT) Date: Fri, 29 Jan 2016 17:16:42 +0000 Subject: [openssl-dev] [openssl.org #3885] [BUGFIX] OpenSSL fails to cross-compile on 32-bit->64-bit In-Reply-To: References: <78EEA715-EF95-4B66-A71F-85D1808F3593@akamai.com> Message-ID: I have an available fix: https://github.com/openssl/openssl/pull/597 -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." From rt at openssl.org Fri Jan 29 17:35:05 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 29 Jan 2016 17:35:05 +0000 Subject: [openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der() In-Reply-To: References: <56A7C890.7060706@symas.com> <56AB7E4E.90909@highlandsun.com> Message-ID: On Fri Jan 29 15:08:47 2016, hyc at highlandsun.com wrote: > Howard Chu via RT wrote: > > In OpenLDAP we reference X509_NAME->bytes->data directly, we want the > > DER > > bytes which we then pass thru our own DN validator/formatter. This no > > longer > > works with OpenSSL 1.1 and I don't see any provided method to return > > the DER > > bytes. I don't want a malloc'd copy, I just want read-only access to > > the bytes > > already cached inside the X509_NAME structure. > > > > The attached patch would be sufficient to meet this requirement. > > We are tracking this here as well: > > http://www.openldap.org/its/index.cgi/Development?id=8353 I'd rather we didn't return a pointer to the internal BUF_MEM as we might want to change that at some point. Would a function like: int X509_NAME_der(const X509_NAME *nm, const char **pder); be suitable for your needs? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Fri Jan 29 17:36:21 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 29 Jan 2016 17:36:21 +0000 Subject: [openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der() In-Reply-To: References: <56A7C890.7060706@symas.com> <56AB7E4E.90909@highlandsun.com> Message-ID: On Fri Jan 29 17:35:05 2016, steve wrote: > On Fri Jan 29 15:08:47 2016, hyc at highlandsun.com wrote: > > Howard Chu via RT wrote: > > > In OpenLDAP we reference X509_NAME->bytes->data directly, we want > > > the > > > DER > > > bytes which we then pass thru our own DN validator/formatter. This > > > no > > > longer > > > works with OpenSSL 1.1 and I don't see any provided method to > > > return > > > the DER > > > bytes. I don't want a malloc'd copy, I just want read-only access > > > to > > > the bytes > > > already cached inside the X509_NAME structure. > > > > > > The attached patch would be sufficient to meet this requirement. > > > > We are tracking this here as well: > > > > http://www.openldap.org/its/index.cgi/Development?id=8353 > > > I'd rather we didn't return a pointer to the internal BUF_MEM as we > might want > to change that at some point. > > Would a function like: > > int X509_NAME_der(const X509_NAME *nm, const char **pder); > > be suitable for your needs? > Thinking about it a better name for comply with our naming convention would be X509_NAME_get0_der. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Fri Jan 29 17:59:59 2016 From: rt at openssl.org (Aleksey Sanin via RT) Date: Fri, 29 Jan 2016 17:59:59 +0000 Subject: [openssl-dev] [openssl.org #4280] OpenSSL 1.1.0 pre 2: feature request: ECDSA_SIG_set0(const ECDSA_SIG*, BIGNUM *, BIGNUM *) is needed In-Reply-To: <56ABA897.9040303@aleksey.com> References: <56AAF976.7010102@aleksey.com> <56ABA897.9040303@aleksey.com> Message-ID: Thanks! It works great. Do you have plan to change the behavior of DSA_SIG_new() as well to pre-create r and s? Currently both are NULL. Thanks in advance, Aleksey On 1/29/16 5:44 AM, Stephen Henson via RT wrote: > On Fri Jan 29 09:59:23 2016, aleksey at aleksey.com wrote: >> Hello, >> >> At the moment, there is no way to set r/s in the ECDSA_SIG structure >> manually to verify the signature encoded into a different format. >> Would be great to add a simple function: >> >> void ECDSA_SIG_set0(const ECDSA_SIG*, BIGNUM *, BIGNUM *) >> >> to set these values similar to other XXX_set0() functions. >> > > The way ECDSA_SIG_new() work r and s should always be non-NULL so you > should be able to use the the ECDSA_SIG_get0 function to retrieve pointers to r > and s which can then be modified. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > From rt at openssl.org Fri Jan 29 18:54:38 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 29 Jan 2016 18:54:38 +0000 Subject: [openssl-dev] [openssl.org #4280] OpenSSL 1.1.0 pre 2: feature request: ECDSA_SIG_set0(const ECDSA_SIG*, BIGNUM *, BIGNUM *) is needed In-Reply-To: References: <56AAF976.7010102@aleksey.com> <56ABA897.9040303@aleksey.com> Message-ID: On Fri Jan 29 17:59:59 2016, aleksey at aleksey.com wrote: > > Do you have plan to change the behavior of DSA_SIG_new() as well > to pre-create r and s? Currently both are NULL. > That seems like a reasonable change. In 1.0.x we can't do that because it would result in compatibility issues. For 1.1.0 DSA_SIG will be made opaque at some point and a DSA_SIG_get0() function will be added and pre-allocating r and s simplifies the code. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Fri Jan 29 19:11:35 2016 From: rt at openssl.org (Howard Chu via RT) Date: Fri, 29 Jan 2016 19:11:35 +0000 Subject: [openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der() In-Reply-To: <56ABB949.4050200@symas.com> References: <56A7C890.7060706@symas.com> <56AB7E4E.90909@highlandsun.com> <56ABB949.4050200@symas.com> Message-ID: Stephen Henson via RT wrote: > On Fri Jan 29 15:08:47 2016, hyc at highlandsun.com wrote: >> Howard Chu via RT wrote: >>> In OpenLDAP we reference X509_NAME->bytes->data directly, we want the >>> DER >>> bytes which we then pass thru our own DN validator/formatter. This no >>> longer >>> works with OpenSSL 1.1 and I don't see any provided method to return >>> the DER >>> bytes. I don't want a malloc'd copy, I just want read-only access to >>> the bytes >>> already cached inside the X509_NAME structure. >>> >>> The attached patch would be sufficient to meet this requirement. >> >> We are tracking this here as well: >> >> http://www.openldap.org/its/index.cgi/Development?id=8353 > > > I'd rather we didn't return a pointer to the internal BUF_MEM as we might want > to change that at some point. > > Would a function like: > > int X509_NAME_der(const X509_NAME *nm, const char **pder); > > be suitable for your needs? Yes, that would be fine. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From rt at openssl.org Fri Jan 29 19:14:50 2016 From: rt at openssl.org (Howard Chu via RT) Date: Fri, 29 Jan 2016 19:14:50 +0000 Subject: [openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der() In-Reply-To: <56ABBA15.50501@symas.com> References: <56A7C890.7060706@symas.com> <56AB7E4E.90909@highlandsun.com> <56ABBA15.50501@symas.com> Message-ID: Stephen Henson via RT wrote: > On Fri Jan 29 17:35:05 2016, steve wrote: >> On Fri Jan 29 15:08:47 2016, hyc at highlandsun.com wrote: >>> Howard Chu via RT wrote: >>>> In OpenLDAP we reference X509_NAME->bytes->data directly, we want >>>> the >>>> DER >>>> bytes which we then pass thru our own DN validator/formatter. This >>>> no >>>> longer >>>> works with OpenSSL 1.1 and I don't see any provided method to >>>> return >>>> the DER >>>> bytes. I don't want a malloc'd copy, I just want read-only access >>>> to >>>> the bytes >>>> already cached inside the X509_NAME structure. >>>> >>>> The attached patch would be sufficient to meet this requirement. >>> >>> We are tracking this here as well: >>> >>> http://www.openldap.org/its/index.cgi/Development?id=8353 >> >> >> I'd rather we didn't return a pointer to the internal BUF_MEM as we >> might want >> to change that at some point. >> >> Would a function like: >> >> int X509_NAME_der(const X509_NAME *nm, const char **pder); >> >> be suitable for your needs? >> > > Thinking about it a better name for comply with our naming convention would be > X509_NAME_get0_der. Just to be clear - in our use case we already know the length. But if the function you're proposing is returning only a success/error code, then the function should probably also provide the length as a return parameter, for more general users. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From anthony.chow at al-enterprise.com Fri Jan 29 20:23:20 2016 From: anthony.chow at al-enterprise.com (Anthony T CHOW) Date: Fri, 29 Jan 2016 20:23:20 +0000 Subject: [openssl-dev] X509_V_FLAG_OCSP_CHECK In-Reply-To: <401084E5E73F4241A44F3C9E6FD79428036688A064@exch-01> References: <401084E5E73F4241A44F3C9E6FD79428036688A064@exch-01> Message-ID: Stephen, Thanks for the info and have a nice weekend, Anthony. -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Wall, Stephen Sent: Friday, January 29, 2016 5:56 AM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] X509_V_FLAG_OCSP_CHECK > -----Original Message----- > From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Anthony T CHOW > > On the openssl-user mailing list archive, I found this: > > http://www.mail-archive.com/openssl-users at openssl.org/msg67721.html > > On GitHub, I don't find this flag X509_V_FLAG_OCSP_CHECK I've previously asked about this, the OpenSSL team had no plans to act on the patch at that time (a few months ago). _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Sun Jan 31 00:04:16 2016 From: rt at openssl.org (Fedor Indutny via RT) Date: Sun, 31 Jan 2016 00:04:16 +0000 Subject: [openssl-dev] [openssl.org #4281] [PATCH] Allow downgrading when reusing sessions on client In-Reply-To: References: Message-ID: When connecting to pool of diverse servers (both TLS1.0 and TLS1.2), a following scenario may happen: 1. Connect to TLS1.2 server, receive new session 2. Store this session 3. Attempt to reuse it later when connecting to server 4. Connect to different server from the pool, which speaks only TLS1.0 5. Get `SSL_R_WRONG_VERSION_NUMBER` error Expected behavior would be scrapping off the session, and allowing server to downgrade to supported protocol version the way it would do it if no client session would be supplied. This issue was discovered while working on following node.js bug: https://github.com/nodejs/node/issues/3692 --- ssl/s3_pkt.c | 39 +++++++++++++++++++++++++++++++++++++++ ssl/ssltest.c | 22 +++++++++++++++++++++- test/testssl | 6 ++++++ 3 files changed, 66 insertions(+), 1 deletion(-) -------------- next part -------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJWrTMxAAoJENcGPM4Zt+iQ+GMQAILay2nyh47kVAv1wV3QBgfw 403IrqpoGqLCklZg0SL7zgce+gfOXMydtqbLbK6wtpFNawLPTkbDvLSVyPyixDwy 56UD+neByBXtIuOSs75qVjmAZcuT5GQMoQlIPrX2zGoaRdJls0w4TCrqcoXTDVlL 4QKbaage+EeymPyadEOKmNX2vZmoLRE+t+cMC5gLAtk7ykpAHMWmEZlwhdryP847 uJA8dI1HjvEDcUJvwSsnZLj/wZSrZcC5+QEVsEba8zlKszFYMalygPBZAneZ6zWT GOp5oqUEEyXMlZB8VCTZcMIdEx79otpOYURYGwxNU0P6reZngc1syfgZQYYGqZ0s ohKcWCvbKgZMfI3Vh/LhKVCho0n2G4Uy0k32vOtotmg3zyQjCaUCHdiiWPSiNYDm BlIunymx2ZvCdIZgy/JnAOE2zXe2Hi9qlw+v6wnNH5xowVQvOf0fOgR/R3qhIdrN 6ZFMDY4Ldq0hOFwplAyQRBJZqnHxA6z43lTr5Uk8mad0kIngciFUjvmaBLpiw0r/ R8FT2uVbpDVHf6HUHGobA4cIWZ4nOYBL/mnOfp81gcG3Sd727dV0/dP0K4nyfbim aaF5VuM2nZWlLTJZnMNZJYDGm7lM1BhkCuniD/t+ycrAHS9cdoT9H/HvcAIBnmMn GrIf2pe3UbMmidg/TAtb =Ci8J -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-downgrading-when-reusing-sessions-on-client.patch Type: application/octet-stream Size: 6250 bytes Desc: not available URL: From rt at openssl.org Sun Jan 31 00:04:17 2016 From: rt at openssl.org (Fedor Indutny via RT) Date: Sun, 31 Jan 2016 00:04:17 +0000 Subject: [openssl-dev] [openssl.org #4282] Re: [PATCH] Allow downgrading when reusing sessions on client In-Reply-To: References: Message-ID: Hello, Please disregard first version of this patch. Making that change at s3_pkt.c was too broad, and pretty much incorrect. Attached is a new version of patch. I would appreciate any kind of feedback on this. Open questions that I am not sure about so far: is it safe to set `s->first_packet = 1` on renegotiation? Why is it DTLS-only right now? Should this patch do anything else to reset the current session? Thank you very much, Fedor. On Sat, Jan 30, 2016 at 5:04 PM, Fedor Indutny wrote: > When connecting to pool of diverse servers (both TLS1.0 and TLS1.2), a > following scenario may happen: > > 1. Connect to TLS1.2 server, receive new session > 2. Store this session > 3. Attempt to reuse it later when connecting to server > 4. Connect to different server from the pool, which speaks only TLS1.0 > 5. Get `SSL_R_WRONG_VERSION_NUMBER` error > > Expected behavior would be scrapping off the session, and allowing > server to downgrade to supported protocol version the way it would do it > if no client session would be supplied. > > This issue was discovered while working on following node.js bug: > > https://github.com/nodejs/node/issues/3692 > --- > ssl/s3_pkt.c | 39 +++++++++++++++++++++++++++++++++++++++ > ssl/ssltest.c | 22 +++++++++++++++++++++- > test/testssl | 6 ++++++ > 3 files changed, 66 insertions(+), 1 deletion(-) > -------------- next part -------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJWrURJAAoJENcGPM4Zt+iQ0WgP/3QE4w13G+30DYgyKWPGZf7U SSVF0Yy5ezn+syzKNEkypO2iqL4MnjuBqlyXDlWWQv534Pcmw9uJWe6sCCVf6Tls BA+v12Fd85QoX4RqhLa6XM8BusY4srAxZbX+D6Z5C7VVLO+2ZjTGYCJhXOoBlOvf 3hYKaVlnfpP1+5Yae8VKEKm3nb6USsvTXn/UDuxxCocaGA3/O3t+vW3U/+jNbtdK RY60T+jVSkt4fw9eL9qR072eHkUaBWIad9KgGj0gcoJA6RjDn/78Ik6P/mPCrXmG 8/wLdR+qQbjAjWB48JY9f0Vv3XhtG5KLdX/g6w6T1n3F+dVO+rRWxuG7E6J6eMuL th+Nj3hhhtBEFwW7WnU2+MhxYyy82d1OwFs6A4tRuav86wHEi1zutfWeEcwqg5jM c6QuERxkPeWbRnIeBcdJVguQ4kO2cWl64a7YzT46RCMSF1GAUMVpB2e38LEd11oa Uk0KVw2dApXEmVbe8jpRSlBejKafp6lTujE5fiD+6/4foG2hwRUwBjEDpMKtHjs9 AlWzXr5vmwAQ4QKb68h+eC25C6ii4wgSflL0q8Z2hDTdAPi/5ftGOZFNSyBPh6Ub 6wVqZFrwrk5GF2HKwT1KAUEWhUeWbRXFzeknsb5P+vMNZ6qf5j+y7uYaFC+1S4SK JmxLddBgP2N3VkKfXF7C =QuAH -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-downgrading-when-reusing-sessions-on-client.patch Type: application/octet-stream Size: 6675 bytes Desc: not available URL: From rt at openssl.org Sun Jan 31 00:14:01 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 00:14:01 +0000 Subject: [openssl-dev] [openssl.org #4281] [PATCH] Allow downgrading when reusing sessions on client In-Reply-To: References: Message-ID: cancelling as OP suggests. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 00:47:15 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 00:47:15 +0000 Subject: [openssl-dev] [openssl.org #2158] X509_STORE_set_default_paths also use lookup by_capi In-Reply-To: <4B6405A4.7060001@airemix.jp> References: <4B6405A4.7060001@airemix.jp> Message-ID: No action in years. Closing. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 00:48:28 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 00:48:28 +0000 Subject: [openssl-dev] =?utf-8?b?W29wZW5zc2wub3JnICMzMzk1XSBDYW7igJl0IENv?= =?utf-8?q?mpile_0=2E9=2E8za_FIPS_on_Win_7_32_Bit_w/_Visual_Studio_?= =?utf-8?q?2010=2E?= In-Reply-To: References: Message-ID: unsupported release, closoing. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 00:50:19 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 00:50:19 +0000 Subject: [openssl-dev] [openssl.org #1261] [PATCH] Binary S/MIME handling in openssl smime (0.9.8a) In-Reply-To: <20051229124648.G8863@elma.net> References: <20051229124648.G8863@elma.net> Message-ID: Please open a defect and patch current release if necessary. Closing this. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 00:50:50 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 00:50:50 +0000 Subject: [openssl-dev] [openssl.org #1698] potential bugs discovered by interprocedural code analysis for version 0.9.8g of Openssl In-Reply-To: References: Message-ID: Please open a new ticket if there is similar tool run against the current release. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 00:51:26 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 00:51:26 +0000 Subject: [openssl-dev] [openssl.org #1737] [PATCH openssl 0.9.8g] s_client: add sieve starttls protocol support In-Reply-To: <20080903173114.GA11139@tuxdriver.com> References: <20080903173114.GA11139@tuxdriver.com> Message-ID: Please open a new ticket against new release (and port the patch) if still necessary. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 00:52:02 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 00:52:02 +0000 Subject: [openssl-dev] [openssl.org #1739] [PATCH] [openssl 0.9.8c] Using a private key in an engine to timestamp. In-Reply-To: <48C0FC8F.7030205@det.uvigo.es> References: <48C0FC8F.7030205@det.uvigo.es> Message-ID: Old release, not supported. Engine stuff has been reivsed, this maybe even works now :) Open new ticket if not. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 00:52:32 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 00:52:32 +0000 Subject: [openssl-dev] [openssl.org #1775] 0.9.9-today: bug: size_tification missed a few spots --> compile issues on native Win32/64 + SuSE64: patch/diff included In-Reply-To: <561cc61d0811020131k2749bf6eq4808da99063d82bb@mail.gmail.com> References: <561cc61d0811020131k2749bf6eq4808da99063d82bb@mail.gmail.com> Message-ID: old release, closing. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 00:53:09 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 00:53:09 +0000 Subject: [openssl-dev] [openssl.org #1886] [PATCH] Null chiper support PSK/PKI for 0.9.8j In-Reply-To: <3932E3E7D9C8CB428D4E4FC3887B6CEF09AEDF7CDD@hasmsx503.ger.corp.intel.com> References: <3932E3E7D9C8CB428D4E4FC3887B6CEF09AEDF7CDD@hasmsx503.ger.corp.intel.com> Message-ID: Old release, please re-port and open a new ticket if necessray. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 00:53:38 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 00:53:38 +0000 Subject: [openssl-dev] [openssl.org #2245] [PATCH] Add /Zi to VC++ CFLAG in debug configuration (1.0.0 and 0.9.8) In-Reply-To: <4BD4C8D9.4010901@idrix.net> References: <4BD4C8D9.4010901@idrix.net> Message-ID: many updates have been made, clsoing this ticket. re-open if needed. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 00:54:04 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 00:54:04 +0000 Subject: [openssl-dev] [openssl.org #3435] I updated George Shaw's 0.9.8e port to OS/400 from 2007 In-Reply-To: References: Message-ID: Old release, no longer supported. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 00:57:05 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 00:57:05 +0000 Subject: [openssl-dev] [openssl.org #2447] possible weakness, encryption password truncation (FreeBSD 8.0; OpenSSL 0.9.8n) In-Reply-To: <4D514A9F.6010804@gmail.com> References: <4D514A9F.6010804@gmail.com> Message-ID: please open new ticket if still and issue in the current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 00:57:38 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 00:57:38 +0000 Subject: [openssl-dev] [openssl.org #3745] OpenSSl Bug, affected release 0.9.8zd In-Reply-To: References: Message-ID: old release, closing. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 00:58:14 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 00:58:14 +0000 Subject: [openssl-dev] [openssl.org #3821] Possible bug/request for help 0.9.8 on windows - OpenSSL verify error. In-Reply-To: References: Message-ID: old release. hope you got the issue fixed by now :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 00:59:01 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 00:59:01 +0000 Subject: [openssl-dev] [openssl.org #3689] Bug report - OpenSSL 0.9.8ze with FIPS canister 1.2.4 big number test failure In-Reply-To: <9e13e9aca86d4caa99cdd4681a542770@US-EXCH13-4.na.uis.unisys.com> References: <9e13e9aca86d4caa99cdd4681a542770@US-EXCH13-4.na.uis.unisys.com> Message-ID: we were only taking security fixes back then. closing this. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 00:59:30 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 00:59:30 +0000 Subject: [openssl-dev] [openssl.org #2870] OpenSSL 0.9.8o 01 Jun 2010 configuration file dir bug In-Reply-To: References: Message-ID: please open a new ticket if this is still an issue. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 01:00:10 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 01:00:10 +0000 Subject: [openssl-dev] [openssl.org #2473] openssl-0.9.8i : How generate Import libraries for the export symbols in shared libraray In-Reply-To: References: Message-ID: release no longer supported. hopefully you resolved this issue before that :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 01:08:54 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 01:08:54 +0000 Subject: [openssl-dev] [openssl.org #4132] test/dsatest.c wrong argument to BIO_printf In-Reply-To: <20151110152542.GE18577@suse.de> References: <20151110152542.GE18577@suse.de> Message-ID: done in dec 3 commit 70c9f1c878502ccb717fbec54cecfc17187cf501 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From fedor at indutny.com Sun Jan 31 01:13:58 2016 From: fedor at indutny.com (Fedor Indutny) Date: Sat, 30 Jan 2016 20:13:58 -0500 Subject: [openssl-dev] [openssl.org #4281] [PATCH] Allow downgrading when reusing sessions on client In-Reply-To: References: Message-ID: Hello Rich, Do I need to submit updated patch separately, or was it ok to attach it to the second email? Thank you, Fedor. On Sat, Jan 30, 2016 at 7:14 PM, Rich Salz via RT wrote: > cancelling as OP suggests. > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sun Jan 31 01:14:21 2016 From: rt at openssl.org (Fedor Indutny via RT) Date: Sun, 31 Jan 2016 01:14:21 +0000 Subject: [openssl-dev] [openssl.org #4281] [PATCH] Allow downgrading when reusing sessions on client In-Reply-To: References: Message-ID: Hello Rich, Do I need to submit updated patch separately, or was it ok to attach it to the second email? Thank you, Fedor. On Sat, Jan 30, 2016 at 7:14 PM, Rich Salz via RT wrote: > cancelling as OP suggests. > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org > > From rt at openssl.org Sun Jan 31 01:16:12 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Sun, 31 Jan 2016 01:16:12 +0000 Subject: [openssl-dev] [openssl.org #4281] [PATCH] Allow downgrading when reusing sessions on client In-Reply-To: <5e90dfb0f8fe468ebab26c66d47cbc62@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5e90dfb0f8fe468ebab26c66d47cbc62@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: I closed the first ticket, so everything is okay. If you want to do GitHub pull requests and just open an RT to refer to that, that is also okay. From fedor at indutny.com Sun Jan 31 01:20:08 2016 From: fedor at indutny.com (Fedor Indutny) Date: Sat, 30 Jan 2016 20:20:08 -0500 Subject: [openssl-dev] [openssl.org #4281] [PATCH] Allow downgrading when reusing sessions on client In-Reply-To: References: <5e90dfb0f8fe468ebab26c66d47cbc62@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: This actually sounds like a lovely idea. See: https://github.com/openssl/openssl/pull/603 Thank you! On Sat, Jan 30, 2016 at 8:16 PM, Salz, Rich via RT wrote: > I closed the first ticket, so everything is okay. > If you want to do GitHub pull requests and just open an RT to refer to > that, that is also okay. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sun Jan 31 01:20:30 2016 From: rt at openssl.org (Fedor Indutny via RT) Date: Sun, 31 Jan 2016 01:20:30 +0000 Subject: [openssl-dev] [openssl.org #4281] [PATCH] Allow downgrading when reusing sessions on client In-Reply-To: References: <5e90dfb0f8fe468ebab26c66d47cbc62@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: This actually sounds like a lovely idea. See: https://github.com/openssl/openssl/pull/603 Thank you! On Sat, Jan 30, 2016 at 8:16 PM, Salz, Rich via RT wrote: > I closed the first ticket, so everything is okay. > If you want to do GitHub pull requests and just open an RT to refer to > that, that is also okay. > > > From rt at openssl.org Sun Jan 31 01:31:11 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 01:31:11 +0000 Subject: [openssl-dev] [openssl.org #4125] Got Error In-Reply-To: <328820850.97013.1446702288123.JavaMail.yahoo@mail.yahoo.com> References: <328820850.97013.1446702288123.JavaMail.yahoo.ref@mail.yahoo.com> <328820850.97013.1446702288123.JavaMail.yahoo@mail.yahoo.com> Message-ID: build error, no details, cannot reproduce, closing bug. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 01:40:39 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 01:40:39 +0000 Subject: [openssl-dev] [openssl.org #4118] Failed test 80 with OpenSSL 1.1.0-dev on NetBSD 6_Stable In-Reply-To: <43e6b158a2d90d0c3d37a17842953c08.squirrel@wm.sdf.org> References: <43e6b158a2d90d0c3d37a17842953c08.squirrel@wm.sdf.org> Message-ID: None of the tests are interactive now, so we must have fixed this :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 01:43:32 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 01:43:32 +0000 Subject: [openssl-dev] [openssl.org #4200] extra data for ec keys In-Reply-To: <567BAF78.8070608@roumenpetrov.info> References: <567903B6.9070805@roumenpetrov.info> <8a62b93b720d42b4a295bd51ba8fbd5e@usma1ex-dag1mb1.msg.corp.akamai.com> <567BAF78.8070608@roumenpetrov.info> Message-ID: fixed in commit 3aef36ffef89849348049296892327e6fdf9d705 in Jan 5. Thanks! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 01:45:33 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 01:45:33 +0000 Subject: [openssl-dev] [openssl.org #4182] Error in generating my certificate In-Reply-To: References: Message-ID: user error, not a bug. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 01:50:30 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 01:50:30 +0000 Subject: [openssl-dev] [openssl.org #3664] IDEA patent in Readme In-Reply-To: <54B9337F.6060208@eCosCentric.com> References: <54B9337F.6060208@eCosCentric.com> Message-ID: The IDEA patent text is gone.-- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 02:00:48 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 02:00:48 +0000 Subject: [openssl-dev] [openssl.org #3740] build error in ssl/kssl.c, deferencing pointer of incomplete type In-Reply-To: <1425853749.20606.25.camel@kuix.de> References: <1425853749.20606.25.camel@kuix.de> Message-ID: we removed kssl commit 55a9a16f1c02837058173c41fa26f36ec3acd22e Author: Matt Caswell Date: Tue May 12 10:27:53 2015 +0100 Remove Kerberos support from libssl Remove RFC2712 Kerberos support from libssl. This code and the associated standard is no longer considered fit-for-purpose. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 02:05:19 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 02:05:19 +0000 Subject: [openssl-dev] [openssl.org #3476] Faulting module name: libeay32.dll, version: 1.0.1.8, time stamp: 0x539303fb In-Reply-To: <82D28C489AFEBF499D333E4DD7F6A0C619A6126A70@NAVIG-MBX01.nciwin.local> References: <82D28C489AFEBF499D333E4DD7F6A0C619A6126A70@NAVIG-MBX01.nciwin.local> Message-ID: not repeatable, not enough information, closing. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 02:06:26 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 02:06:26 +0000 Subject: [openssl-dev] [openssl.org #3500] Adopting single-Makefile build structure In-Reply-To: References: Message-ID: we've got work in progress on this. not adopting the approach mentioned here. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 02:09:00 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 02:09:00 +0000 Subject: [openssl-dev] [openssl.org #3503] BUG: "make dclean" results in duplicate symbols on subsequent make's In-Reply-To: References: Message-ID: fixed in 1.1; dclean is gone :) and the whole "make depend" stuff is clean. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 02:09:43 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 02:09:43 +0000 Subject: [openssl-dev] [openssl.org #3311] [PATCH] Introduce GOST R 34.11-2012 hash function In-Reply-To: <534BEB58.4090706@gmail.com> References: <534BEB58.4090706@gmail.com> Message-ID: GOST is done via external engine now. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 02:11:55 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 02:11:55 +0000 Subject: [openssl-dev] [openssl.org #3328] [PATCH] Support for GOST R 34.10-2012 digital signature algorithm In-Reply-To: <5357C3E3.7050100@demos.ru> References: <5357C3E3.7050100@demos.ru> Message-ID: GOST is now a separately-maintained engine, thanks to Dmittry :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 14:43:32 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 14:43:32 +0000 Subject: [openssl-dev] [openssl.org #3755] Double #included headers in openssl/bn.h In-Reply-To: <550AC047.8@aegee.org> References: <550AC047.8@aegee.org> Message-ID: harmless but fixed in master, thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Jan 31 23:55:31 2016 From: rt at openssl.org (Sandra J Peterson via RT) Date: Sun, 31 Jan 2016 23:55:31 +0000 Subject: [openssl-dev] [openssl.org #4283] TLS1.2 & SHA256 in a non-computer OS environment issues In-Reply-To: <76da4a49715e439c91c9291dd369917c@BN3PR72MB0053.MGDPBI.global.pvt> References: <76da4a49715e439c91c9291dd369917c@BN3PR72MB0053.MGDPBI.global.pvt> Message-ID: I'm trying to upgrade an embedded system w/ a non-computer OS (e.g., not Windows, not MAC, not Linux, not Android, not UNIX, etc.) from using SSL3/TLS1 to TLS1.2 so I can use SHA256 certificates. The embedded system uses the Nucleus OS, has a Hitachi 7720 microprocessor and the code is written in C. I have to use the Renesas HEW compiler. I need a .lib file (not a DLL) to link w/ the rest of application software for the embedded system. I can't compile the OpenSSL code because it doesn't follow the simple rule that you can NOT use something before it has been defined. Amongst other things, the OpenSSL v1.0.2 code has structures that reference each other so no matter which one is defined first, I always get errors because the other structure hasn't been defined yet. Is there a version of the OpenSSL code that supports TLS1.2 & SHA256 that does follow the rule that you can't use something before it has been defined? Sincerely, Sandra Peterson Principal Software Engineer Pitney Bowes, Inc. Please consider your email server and your email mailbox before attaching a huge signature block or a signature block that contains graphics. This email message may contain confidential, proprietary and/or privileged information. It is intended only for the use of the intended recipient(s). If you have received it in error, please immediately advise the sender by reply email and then delete this email message. Any disclosure, copying, distribution or use of the information contained in this email message to or by anyone other than the intended recipient is strictly prohibited. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to the views of the Company. Thank you. ________________________________ From rt at openssl.org Sun Jan 31 23:58:11 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 31 Jan 2016 23:58:11 +0000 Subject: [openssl-dev] [openssl.org #4283] TLS1.2 & SHA256 in a non-computer OS environment issues In-Reply-To: <76da4a49715e439c91c9291dd369917c@BN3PR72MB0053.MGDPBI.global.pvt> References: <76da4a49715e439c91c9291dd369917c@BN3PR72MB0053.MGDPBI.global.pvt> Message-ID: No, you are allowed to do that in C. Sorry, but the compiler you have to use seems crippled. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From doctor at doctor.nl2k.ab.ca Wed Jan 27 17:00:16 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 27 Jan 2016 17:00:16 -0000 Subject: [openssl-dev] Post openssl-SNAP-20160120 issues Message-ID: <20160127165617.GA20848@doctor.nl2k.ab.ca> All right the last verion of Openssl-SNAP that I got to work was openssl-SNAP-20160120 Since then and issue with store was discovered and now Script started on Tue Jan 26 08:03:12 2016 ns2.nl2k.ab.ca//usr/source/openssl-SNAP-20160126$ !/bin /bin/sh ../configopenssl11 Configuring OpenSSL version 1.1.0-pre3-dev (0x0x10100003L) no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-egd [default] OPENSSL_NO_EGD (skip dir) no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-sctp [option] OPENSSL_NO_SCTP (skip dir) no-sse2 [option] no-zlib [default] no-zlib-dynamic [default] Configuring for Warning! target doesn't exist! IsMK1MF =no CC = CFLAG =-DOPENSSL_THREADS -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -DWHIRLPOOL_ASM EX_LIBS = CPUID_OBJ =mem_clr.o BN_ASM =bn_asm.o EC_ASM = DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes_core.o aes_cbc.o BF_ENC =bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4_enc.o rc4_skey.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM = SHA1_OBJ_ASM = RMD160_OBJ_ASM= CMLL_ENC =camellia.o cmll_misc.o cmll_cbc.o MODES_OBJ = PADLOCK_OBJ = CHACHA_ENC =chacha_enc.o POLY1305_OBJ = PROCESSOR =386 RANLIB =/usr/bin/ranlib ARFLAGS = PERL =/usr/bin/perl5 THIRTY_TWO_BIT mode RC4_CHUNK is undefined Configured for . You gave the option 'shared', which is not supported on this platform, so we will pretend you gave the option 'no-shared'. If you know how to implement shared libraries, please let us know (but please first make sure you have tried with a current version of OpenSSL). *** Because of configuration changes, you MUST do the following before *** building: make depend enable-srp: not found (cd apps && make generate) (cd crypto/bn && make generate) (cd crypto/objects && make generate) /usr/bin/perl5 util/ck_errf.pl -strict */*.c */*/*.c /usr/bin/perl5 util/mkerr.pl -recurse -write TS: No new error codes DSO: No new error codes ENGINE: No new error codes OCSP: No new error codes EC: No new error codes BN: No new error codes ASYNC: No new error codes UI: No new error codes DH: No new error codes HMAC: No new error codes CONF: No new error codes EVP: No new error codes SSL: No new error codes OBJ: No new error codes X509V3: No new error codes BUF: No new error codes PKCS7: No new error codes ASN1: No new error codes STORE: No new error codes DSA: No new error codes FIPS: No new error codes X509: No new error codes CMS: No new error codes PEM: No new error codes COMP: No new error codes JPAKE: No new error codes CRYPTO: No new error codes RAND: No new error codes PKCS12: No new error codes RSA: No new error codes BIO: No new error codes (cd engines; make PERL=/usr/bin/perl5 errors) set -e; for l in padlock capi dasync; do /usr/bin/perl5 ../util/mkerr.pl -conf e_$l.ec -nostatic -staticloader -write e_$l.c; done PADLOCK: No new error codes CAPI: No new error codes DASYNC: No new error codes (cd crypto/ct; make PERL=/usr/bin/perl5 errors) /usr/bin/perl5 ../../util/mkerr.pl -conf ct.ec -hprefix internal/ -write *.c CT: No new error codes /usr/bin/perl5 util/mkdef.pl crypto update Updating LIBEAY info No old symbols needed info update Rewriting LIBEAY Updating LIBEAY numbers No New symbols Added /usr/bin/perl5 util/mkdef.pl ssl update Updating SSLEAY info No old symbols needed info update Rewriting SSLEAY Updating SSLEAY numbers No New symbols Added TOP=. PERL=/usr/bin/perl5 /usr/bin/perl5 test/run_tests.pl test_ordinals test/recipes/01-test_ordinals.t .. test/recipes/01-test_ordinals.t .. 1/2 test/recipes/01-test_ordinals.t .. ok All tests successful. Files=1, Tests=2, 1 wallclock secs ( 0.03 usr 0.08 sys + 0.33 cusr 0.07 csys = 0.52 CPU) Result: PASS (echo 'Output of `Configure TABLE'"':"; /usr/bin/perl5 Configure TABLE) > TABLE making depend in crypto... Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $newfile in substitution (s///) at ../util/clean-depend.pl line 41, line 404. Use of uninitialized value $newfile in string ne at ../util/clean-depend.pl line 42, line 404. Use of uninitialized value $newfile in hash element at ../util/clean-depend.pl line 43, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 404. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 404. making depend in crypto/objects... ${TOP}/util/domd ${TOP} -MD makedepend -- -DOPENSSL_THREADS -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -DWHIRLPOOL_ASM -I.. -I../.. -I../modes -I../include -I../../include -DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_EGD -DOPENSSL_NO_MD2 -DOPENSSL_NO_SCTP -- o_names.c obj_dat.c obj_lib.c obj_err.c obj_xref.c Use of uninitialized value $newfile in substitution (s///) at ../../util/clean-depend.pl line 41, line 163. Use of uninitialized value $origfile in regexp compilation at ../util/clean-depend.pl line 50, line 1227. Use of uninitialized value $file in hash element at ../util/clean-depend.pl line 48, line 1227. making depend in tools... You have new mail in /var/mail/doctor ns2.nl2k.ab.ca//usr/source/openssl-SNAP-20160126$ make making all in crypto... /usr/bin/perl5 ../util/mkbuildinf.pl " -I. -I.. -I../include -Iinclude -DOPENSSL_THREADS -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -DWHIRLPOOL_ASM" "" >buildinf.h -I. -I.. -I../include -Iinclude -DOPENSSL_THREADS -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -DWHIRLPOOL_ASM -c cryptlib.c -I.: not found *** Error code 1 Stop. *** Error code 1 Stop. You have new mail in /var/mail/doctor ns2.nl2k.ab.ca//usr/source/openssl-SNAP-20160126$ exit exit Script done on Tue Jan 26 09:01:50 2016 All right, how come my gcc is not getting noticed? Using Perl5.16.3 -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From uri at ll.mit.edu Wed Jan 27 17:25:46 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 27 Jan 2016 17:25:46 -0000 Subject: [openssl-dev] ECDH engine In-Reply-To: <569FF2F0.60905@gmail.com> References: <20160120201925.17788998.82513.46556@ll.mit.edu> <569FF2F0.60905@gmail.com> Message-ID: > When I started to write the ECDSA code for engine_pkcs11 in 2011 the code to > support the method hooks was not > in the code. So I used internal OpenSSL header files to copy the ECDSA_METHOD > and replace the function needed. > Look for "BUILD_WITH_ECS_LOCL_H" in libp11. Not until 1.0.2 did OpenSSL > support the needed calls to hook ECDSA. > They did not add the hooks for ECDH. I am missing one thing here. Hopefully you can help me understanding it. OpenSSL-1.0.2 currently supports ECDH, as I observe by running openssl pkeyutl -derive -inkey /tmp/derive.29494.priv.pem -peerkey /tmp/derive.29494.token.pub.pem -out /tmp/derive.29494.shared1 So clearly there is working code available inside OpenSSL that does what is needed. The only issue then is to add code to libp11 to access that code. Am I correct? If not, could you please point at where/what I?m mistaken in? > If you can't wait then you have to do it your self. *YOU* could do the same > thing for ECDH. But your code would only > be good for 1.0.2 because the whole way of doing EC methods changes in 1.1. That?s perfectly OK, because if my tea leaves reading is correct, OpenSSL-1.0.2 will be around for several years at least. And most of the package providers such as Macports won?t move their packages to OpenSSL-1.1 for probably that long. So making 1.0.2 working with ECDH now will definitely make sense for me. In fact, I think making libp11 compliant with OpenSSL-1.1 now is an overreach, because this effort (unlike work on 1.0.2) is highly unlikely to bring benefits to users for a few years. > I believe Alexander said he had changes to OpenSSL, which is another approach. > He has said there were here: > https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches I see that the actual patch is very small. And the only meaningful (for me) change is adding a new method EC_generate_key(). I would like to understand why this method is needed ? is it only to allow OpenSSL to generate key pair on the token? Alexander, could you comment please? > You could also hire someone who could do more then: "test it and offer minor > enhancements". First, I cannot. Second, I don?t think (and haven?t seen any evidence to the contrary yet) that anything more is needed. Especially seeing the minuscule amount of changes Alexander had to do to OpenSSL, and I?m not even sure I need those if I don?t insist on being able to generate new key pair on the token using only OpenSSL. > (And not me. I am taking the 1.1 approach to getting ECDH. working in engine.) :-) OK, I withdraw my unexpressed and unformulated offer. Consider yourself un-asked. :-) > On 1/20/2016 2:19 PM, Blumenthal, Uri - 0553 - MITLL wrote: >> Very possible that I'm missing the point here. >> >> Still, since openssl-1_0_2 does ECDH, and it exposes ?ECDSA to external >> engine(s), how difficult would it be to add ECDH exposure? I suspect - a good >> deal easier than getting 1.1 replace 1.0.x as the de-facto deployment >> standard. >> >> Plus, by this time there already are (and reasonably common) tokens that >> support ECDH, other packages that do ECDH, and people (like myself :-) >> willing to test it and offer minor enhancements. >> >> Another point I seem to be missing - if what's necessary to implement ECDH in >> an external engine is missing from 1_0_2 - how could ?Alexander write a >> (presumably) working ECDH engine for 1_0_2? If he could do it, why can't >> engine_pkcs11 be extended to do the same? >> >> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. >> From: Douglas E Engert >> Sent: Wednesday, January 20, 2016 14:59 >> To: openssl-dev at openssl.org? >> Reply To: openssl-dev at openssl.org >> Subject: Re: [openssl-dev] ECDH engine >> ? >> You are missing the point. OpenSSL-1.0.2 only exposed ECDSA, not ECDH to >> external engines. It took years to even get ECDSA exposed. >> OpenSSL approach to support this is OpenSSL-1.1 that does a lot of other >> things. But that was there approach. Its their package. >>> >From working package to distribution always takes several years... >> >> >> >> ? >> On 1/20/2016 1:34 PM, Blumenthal, Uri - 0553 - MITLL wrote: >>>> Probably it was one of the main reasons why we didn't use pkcs11 for >>>> ATECC508A and wrote an engine instead >>> >>> I still argue with the approach (IMHO nobody needs yet another limited >>> engine), but constraining ECC additions to 1.1 does not make any sense to >>> me. 1.0.2 is going to be around for a quite a while. A lot of applications >>> won?t migrate to 1.1 quickly ? a few years would be a good/reasonable/safe >>> bet. >>> >>> To restrict this work to 1.1 means pushing this basic capability off by >>> (realistically) several years. Most people can?t/won't deploy openssl-1.1 as >>> long as it interferes with the majority of the applications they or their OS >>> is using, is not good. I for one won?t be able to use 1.1 in practice until >>> it becomes the embraced standard and software such as Macports port set is >>> moved to support it. I?m 100% sure there are many more of us in this bus, on >>> different OS (e.g., it looks like Ubuntu is even worse off than Macports). >>> >>> >>>> On Wed, Jan 20, 2016 at 11:10 AM, Blumenthal, Uri - 0553 - MITLL >>>> wrote: >>>>> Are you saying it won't work on OpenSSL_1_0_2-stable?! >>>>> >>>>> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE >>>>> network. >>>>> From: Douglas E Engert >>>>> Sent: Wednesday, January 20, 2016 14:07 >>>>> To: openssl-dev at openssl.org >>>>> Reply To: openssl-dev at openssl.org >>>>> Subject: Re: [openssl-dev] ECDH engine >>>>> >>>>> Patches are underdevelopment for OpenSC's libp11 and engine_pkcs11 to >>>>> support ECDH. There are waiting for OpenSSL-1.1 to be come stable >>>>> and some minor bug fixes. Testing is proceeding using OpenSSL-1.1-pre2 >>>>> today. OpenSSL-1.1 is needed because it exposes the functions needed >>>>> to use ECDH from an external engine i.e. the OPenSC engine_pkcs11. >>>>> ? >>>>> https://github.com/OpenSC/libp11/issues/52 >>>>> https://github.com/dengert/libp11/tree/prep-openssl-1.1 >>>>> https://github.com/dengert/engine_pkcs11/tree/prep-openssl-1.1 >>>>> >>>>> In addition to a major rewrite of combining the ECDSA_METHOD and >>>>> ECDH_METHOD into an C_KEY_METHOD, OpenSSL-1.1 introduces a lot of >>>>> changes, >>>>> mainly because it hides many of the structures that have been exposed in >>>>> the past. This causes a major rewrite of code to use functions to access >>>>> these structures. >>>>> >>>>> Although OpenSC could still use an older version of OpenSSL, there is also >>>>> underway changes for OpenSC to use OpenSSL-1.1: >>>>> https://github.com/OpenSC/OpenSC/pull/654 >>>>> https://github.com/dengert/OpenSC/tree/prep-openssl-1.1 >>>>> >>>>> >>>>> On 1/20/2016 12:02 PM, Blumenthal, Uri - 0553 - MITLL wrote: >>>>>> I forgot to add that ?OpenSSL-1_0-2-stable with the current (Github >>>>>> master) engine-pkcs11, libp11, and OpenSC successfully does ECDSA with >>>>>> keys on the token (tested for ECC256 and ECC384). >>>>>> >>>>>> OpenSC tools successfully derive (i.e., implement ECDH1_DERIVE). I'm >>>>>> waiting for libp11 and engine_pkcs11 to add this capability. >>>>>> ? >>>>>> Ideally this is where your code would plug in, and complete the circle. >>>>>> >>>>>> As it currently is, a separate Atmel-specific ECC-specific engine is of a >>>>>> limited usefulness. >>>>>> >>>>>> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE >>>>>> network. >>>>>> From: Blumenthal, Uri - 0553 - MITLL >>>>>> Sent: Wednesday, January 20, 2016 12:46 >>>>>> To: openssl-dev at openssl.org >>>>>> Reply To: openssl-dev at openssl.org >>>>>> Subject: Re: [openssl-dev] ECDH engine >>>>>> >>>>>>> The ATECC508A is a chip. There are few USB devices built by Atmel on its >>>>>>> base. Or you can use the chip directly over I2C (that many people like >>>>>>> to do). You can follow the links that we posted on the ATECCX08 Engine >>>>>>> repository WiKi to learn about the chip. >>>>>> >>>>>> I see, thanks. >>>>>> >>>>>>> Well, our first indent was to use the pksc11 library. But it didn't go >>>>>>> to well for many reasons. I should go back for several months to collect >>>>>>> these reasons but I think the main reason was that ATECC508A hardware is >>>>>>> based on ECC-256 algorithms while pkcs11 is originally written for RSA - >>>>>>> the overhead was looking too high (many ATECC508 customers are using >>>>>>> limited hardware and want direct I2C connection to the chip). >>>>>> >>>>>> There are a few hardware tokens (USB-pluggable), e.g. Yubikey, that >>>>>> support ECC256 and (in case of Yubikey 4) ECC384. >>>>>> >>>>>>> But let's talk about pkcs11. Can you point me to the set of >>>>>>> documentation for EC-DERIVE? It may be a good time now to add the >>>>>>> ATECC508 support to there. >>>>>> >>>>>> Honestly, I?m more interested in adding ECDH support ? assuming that it >>>>>> would also serve ATECC508, rather than working on ATECC508B and hoping >>>>>> that perhaps it would be usable for other ECC-capable tokens. >>>>>> >>>>>> Here?s the PKCS#11 spec >>>>>> >>>>> f> >>>>>> http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf >>>>>> , which covers ECDH including ECDH1_DERIVE and ECDH1_COFACTOR_DERIVE. I >>>>>> think older versions (like v2.20) have more content, but this is the >>>>>> current one. >>>>>> >>>>>> Hope it helps. >>>>>> >>>>>> P.S. At this time I?m standing by my original opinion ? that a better way >>>>>> is incorporating ECDH1_*DERIVE in libp11 and engine_pkcs11, rather than >>>>>> creating an engine specifically for one chip that add uncertainly of >>>>>> non-interoperability with other chips/tokens. >>>>>> >>>>>> >>>>>>> On Jan 20, 2016, at 8:11 AM, Blumenthal, Uri - 0553 - MITLL < >>>>>>> uri at ll.mit.edu> wrote: >>>>>>> >>>>>>> What is this Atmel x508x? Is it a chip? Is it a token/smartcard? Is it >>>>>>> accessible via PKCS#11 at all? Is it accessible by/via OpenSC? >>>>>>> >>>>>>> I am trying to figure why such a generic and useful set of ECC >>>>>>> operations (Sign, Derive) is implementation-limited to one single >>>>>>> . >>>>>>> >>>>>>> A much better solution to me would be adding EC-DERIVE to engine_pkcs11, >>>>>>> and automatically get all the tokens covered. >>>>>>> >>>>>>> Since I'm probably? missing something, could you please educate me? >>>>>>> >>>>>>> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE >>>>>>> network. >>>>>>> From: Alexander Gostrer? >>>>>>> Sent: Wednesday, January 20, 2016 10:47 >>>>>>> To: Dr. Stephen Henson >>>>>>> Reply To: openssl-dev at openssl.org >>>>>>> Cc: openssl-dev at openssl.org >>>>>>> Subject: Re: [openssl-dev] ECDH engine >>>>>>> ? >>>>>>> Hi Steve, >>>>>>> ? >>>>>>> And here is the ENGINE implementation for Atmel ATECC508A with few small >>>>>>> patches to OpenSSL_1_0_2-stable: >>>>>>> >>>>>>> https://github.com/AtmelCSO/cryptoauth-openssl-engine >>>>>>> >>>>>>> Your comments are welcome. >>>>>>> >>>>>>> Regards, >>>>>>> Alex. >>>>>>> >>>>>>> On Sat, Dec 19, 2015 at 12:49 PM, Dr. Stephen Henson < >>>>>>> steve at openssl.org> wrote: >>>>>>> On Fri, Dec 18, 2015, Alexander Gostrer wrote: >>>>>>> >>>>>>>> > Hi Steve, >>>>>>>> > >>>>>>>> > John and I completed writing an ECDH engine based on the >>>>>>>> > OpenSSL_1_0_2-stable branch. We were planning to expand it to the >>>>>>>> master >>>>>>>> > but found some major changes made by you recently. What is the status >>>>>>>> of >>>>>>>> > this task? Is it stable enough to follow it? Are you planning another >>>>>>>> > changes? Is there a design document that we can use in our work? >>>>>>>> > >>>>>>> >>>>>>> The version in master shouldn't change much any more. Documentation will >>>>>>> be >>>>>>> available in the near future. The changes were meant to remove some of >>>>>>> the >>>>>>> weird "quirks" of ECC compared to other algortihms and to permit future >>>>>>> expansion to a wider range of curves. >>>>>>> >>>>>>> In the meantime it shouldn't be too hard to follow how the new code >>>>>>> works. >>>>>>> Instead of separate ECDH/ECDSA methods with weird locking and ex_data >>>>>>> and >>>>>>> minimal ENGINE support everything is combined into a single >>>>>>> EC_KEY_METHOD >>>>>>> which can contain ECDSA, ECDH and key generation (something which was >>>>>>> impossible with the old code) and be tied directly to an ENGINE. >>>>>>> >>>>>>> Most of the primary APIs such as ECDH_compute_key can be redirected >>>>>>> directly >>>>>>> through an engine supplied function in EC_KEY_METHOD. >>>>>>> >>>>>>> Having said that the code is very new and may have the odd bug that >>>>>>> needs to >>>>>>> be fixed. If you have any problems let me know and I'll look into them. >>>>>>> >>>>>>> Steve. >>>>>>> -- >>>>>>> Dr Stephen N. Henson. OpenSSL project core developer. >>>>>>> Commercial tech support now available see: >>>>>>> http://www.openssl.org >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> openssl-dev mailing list >>>>>>> To unsubscribe: >>>>>>> >>>>>>> https://mta.openssl.org/mailman/listinfo/openssl-dev >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> openssl-dev mailing list >>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >>>>>> >>>>>> -- >>>>>> >>>>>> Douglas E. Engert >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> openssl-dev mailing list >>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> openssl-dev mailing list >>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >>>> >>>> -- >>>> >>>> Douglas E. Engert >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> openssl-dev mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >>> >>> -- >>> >>> Douglas E. Engert >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: