From rt at openssl.org Mon Aug 1 06:07:33 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 01 Aug 2016 06:07:33 +0000 Subject: [openssl-dev] [openssl.org #4590] accessors without const return arguments In-Reply-To: References: <576EF43A.7010104@roumenpetrov.info> Message-ID: On Fri Jul 22 14:09:12 2016, steve wrote: > On Sat Jun 25 22:09:59 2016, openssl at roumenpetrov.info wrote: > > > > Above is reason the request to remove const from return argument of > > get0 > > methods. > > > > We had a discussion about this and the preference was to have get > methods > retain const for various reasons. > > Instead the DSA_SIG/ECDSA_SIG structures now no longer pre-allocate > r/s so they > aren't immediately freed when you set them. > > > The issue is not only for ECDSA but also for DSA_SIG and RSA, DSA, DH > > keys where situation is similar. > > > > Do you have some examples of how this affects other structures? For > RSA/DSA/DH > keys the fields are NULL initially unless I've missed something. Can this ticket be closed? -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4590 Please log in as guest with password guest if prompted From leonb at parsec.co.za Mon Aug 1 09:17:51 2016 From: leonb at parsec.co.za (Leon Brits) Date: Mon, 1 Aug 2016 09:17:51 +0000 Subject: [openssl-dev] DRBG entropy In-Reply-To: <20160729221916.GB9628@roeckx.be> References: <5798B9A8.6090409@av8n.com> <4f4dcc0b-dcf1-4b1e-a85e-de67c7f20dd6@default> <2d501b0b965b44d481d61afb5443ee25@EXCHANGESRV.PARSEC.local> <579A2E00.5030900@av8n.com> <20160729221916.GB9628@roeckx.be> Message-ID: Kurt, > -----Original Message----- > From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of > Kurt Roeckx > Sent: 30 July 2016 12:19 AM > To: openssl-dev at openssl.org > Subject: Re: [openssl-dev] DRBG entropy > Have you tried running NIST's software > (https://github.com/usnistgov/SP800-90B_EntropyAssessment) > yourself? Can you run it in verbose mode and give the results of all the > tests it ran? Yes, this is the test that indicated an entropy of 2b/B. I ran the test on 1M and 4M and the result was 2.19 and 2.35 respectively. The 4MB file test output is appended below. Now in the OpenSSL UG2.0 section 6.1.1 a paragraph states: "Now suppose we have a low grade entropy source which provides just 1 bit of entropy per byte. Again assume it is uniform (e.g. we don't get 8 bits of entropy in byte 1 and nothing in the next 7). Again let's have a block size of 16 bytes. This time to get 256 bits of entropy the source must provide it in a 256 byte buffer. An extra block is required which makes 272 bytes but because we only have 1 bit of entropy per byte it just needs to supply 272 bits of entropy." Am I correct to state that for a tested entropy source of 2b/B and the same assumptions as in the paragraph, I need to return 8 blocks of 16B each in my get_entropy() callback? Thanks LJB ****************************************************** Read in file randomness.bin, 4194304 bytes long. Dataset: 4194304 8-bit symbols, 256 symbols in alphabet. Output symbol values: min = 0, max = 255 Running entropic statistic estimates: - Most Common Value Estimate: p(max) = 0.00411016, min-entropy = 7.92659 - Collision Estimate: p(max) = 0.00873199, min-entropy = 6.83947 - Markov Estimate (map 6 bits): p(max) = 9.71537e-228, min-entropy = 5.89156 - Compression Estimate: p(max) = 0.00743246, min-entropy = 7.07194 - t-Tuple Estimate: p(max) = 0.00495551, min-entropy = 7.65675 - LRS Estimate: p(max) = 0.155747, min-entropy = 2.68272 Running predictor estimates: Computing MultiMCW Prediction Estimate: 99 percent complete Pglobal: 0.003997 Plocal: 0.001358 MultiMCW Prediction Estimate: p(max) = 0.00399729, min-entropy = 7.96676 Computing Lag Prediction Estimate: 99 percent complete Pglobal: 0.004009 Plocal: 0.001358 Lag Prediction Estimate: p(max) = 0.00400879, min-entropy = 7.96262 Computing MultiMMC Prediction Estimate: 99 percent complete Pglobal: 0.004934 Plocal: 0.195448 MultiMMC Prediction Estimate: p(max) = 0.195448, min-entropy = 2.35514 Computing LZ78Y Prediction Estimate: 99 percent complete Pglobal: 0.004034 Plocal: 0.195448 LZ78Y Prediction Estimate: p(max) = 0.195448, min-entropy = 2.35514 ----------------------- min-entropy = 2.35514 From michel.sales at free.fr Mon Aug 1 09:18:44 2016 From: michel.sales at free.fr (Michel) Date: Mon, 1 Aug 2016 11:18:44 +0200 Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check In-Reply-To: References: <57963956.2060809@mit.edu> Message-ID: <001b01d1ebd5$b611b430$22351c90$@sales@free.fr> Hi David, After checking you are obviously right. Contrary to my belief, my internal buffer was always larger than the longest line I read. :-( Sorry for the noise, but thanks David for the explanations. It helps me to fix my software (even if I will keep some spare bytes for some time) ;-( From rt at openssl.org Mon Aug 1 09:18:57 2016 From: rt at openssl.org (Michel via RT) Date: Mon, 01 Aug 2016 09:18:57 +0000 Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check In-Reply-To: <001b01d1ebd5$b611b430$22351c90$@sales@free.fr> References: <57963956.2060809@mit.edu> <001b01d1ebd5$b611b430$22351c90$@sales@free.fr> Message-ID: Hi David, After checking you are obviously right. Contrary to my belief, my internal buffer was always larger than the longest line I read. :-( Sorry for the noise, but thanks David for the explanations. It helps me to fix my software (even if I will keep some spare bytes for some time) ;-( -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628 Please log in as guest with password guest if prompted From ssx at av8n.com Mon Aug 1 13:33:59 2016 From: ssx at av8n.com (John Denker) Date: Mon, 1 Aug 2016 06:33:59 -0700 Subject: [openssl-dev] DRBG entropy In-Reply-To: References: <5798B9A8.6090409@av8n.com> <4f4dcc0b-dcf1-4b1e-a85e-de67c7f20dd6@default> <2d501b0b965b44d481d61afb5443ee25@EXCHANGESRV.PARSEC.local> <579A2E00.5030900@av8n.com> <20160729221916.GB9628@roeckx.be> Message-ID: On 08/01/2016 02:17 AM, Leon Brits wrote: > Am I correct to state that for a tested entropy source of 2b/B and > the same assumptions as in the paragraph, I need to return 8 blocks > of 16B each in my get_entropy() callback? No, that is not correct, for the reasons previously explained. > Again assume it is uniform (e.g. we don't get 8 bits of entropy in byte 1 and nothing in the next 7). That assumption is invalid, if we believe the LRS test. Quoting from LRS.py: >> # Length of the Longest Repeated Substring Test - Section 5.2.5 >> # This test checks the IID assumption using the length of the longest repeated >> # substring. If this length is significantly longer than the expected value, >> # then the test invalidates the IID assumption. Accumulating 8 or more blocks might make sense if the data were IID, but it isn't. Either that or the LRS test itself is broken, which is a possibility that cannot be ruled out. By way of analogy, note that the p(max) reported by the Markov test is clearly impossible and inconsistent with the reported min-entropy. Suggestion: Modify LRS.py to print (in hex) the longest repeated substring. Then verify by hand that the string really does recur in the data. -- If it doesn't, then the test is broken. -- If it does, then either the chip is broken or you're using it wrong. Remind your boss that the whole point of the certification process is to make sure that broken hardware doesn't get certified. Also: *) Please stop using "entropy" as a synonym for randomness. Some things have very little entropy but are still random enough for a wide range of purposes. Meanwhile other things have large entropy but are not random enough. *) Please stop using "entropy" as a synonym for "min-entropy". The latter is a two-word idiomatic expression. A titmouse is not a mouse. Buckwheat is not a form of wheat. The Holy Roman Empire was neither holy, nor Roman, nor an empire. Just because openssl is sloppy about this doesn't make it OK. From rt at openssl.org Mon Aug 1 13:35:23 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 01 Aug 2016 13:35:23 +0000 Subject: [openssl-dev] [openssl.org #4572] SSL_set_bio and friends In-Reply-To: References: Message-ID: On 30/07/16 23:45, David Benjamin via RT wrote: > It is a behavior change, but > one I'm sure will break no one. Unfortunately I don't share your optimism that it won't break any one :-( Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4572 Please log in as guest with password guest if prompted From rt at openssl.org Mon Aug 1 16:38:11 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 01 Aug 2016 16:38:11 +0000 Subject: [openssl-dev] [openssl.org #4638] Fwd: Missing const EC_KEY *EC_KEY_dup(EC_KEY *src); In-Reply-To: References: Message-ID: Fix for this was merged as 4a9a0d9bcb. Closing. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4638 Please log in as guest with password guest if prompted From rt at openssl.org Mon Aug 1 16:50:21 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 01 Aug 2016 16:50:21 +0000 Subject: [openssl-dev] [openssl.org #4584] Self test failures under X32 In-Reply-To: References: Message-ID: On Mon Jul 25 08:49:27 2016, matt wrote: > Ping Jeff? Ping again? Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584 Please log in as guest with password guest if prompted From rt at openssl.org Mon Aug 1 16:53:22 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 01 Aug 2016 16:53:22 +0000 Subject: [openssl-dev] [openssl.org #4584] Self test failures under X32 In-Reply-To: References: Message-ID: On Mon Aug 01 16:50:21 2016, matt wrote: > On Mon Jul 25 08:49:27 2016, matt wrote: > > Ping Jeff? > > Ping again? > > Matt It's worth mentioning that time is getting short, next beta in a few days, final in 3 weeks. -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584 Please log in as guest with password guest if prompted From rt at openssl.org Mon Aug 1 16:58:18 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 01 Aug 2016 16:58:18 +0000 Subject: [openssl-dev] [openssl.org #4572] SSL_set_bio and friends In-Reply-To: References: Message-ID: Closing this ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4572 Please log in as guest with password guest if prompted From rt at openssl.org Mon Aug 1 17:31:36 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Mon, 01 Aug 2016 17:31:36 +0000 Subject: [openssl-dev] [openssl.org #4590] accessors without const return arguments In-Reply-To: <576EF43A.7010104@roumenpetrov.info> References: <576EF43A.7010104@roumenpetrov.info> Message-ID: This has addressed the original issue. If there are any cases for DH/DSA/RSA you feel need addressing please give details in a new ticket. Steve.; -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4590 Please log in as guest with password guest if prompted From rt at openssl.org Mon Aug 1 18:47:11 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Mon, 01 Aug 2016 18:47:11 +0000 Subject: [openssl-dev] [openssl.org #4637] Fwd: Missing accessor - DSA key length In-Reply-To: References: Message-ID: Added now, thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4637 Please log in as guest with password guest if prompted From rt at openssl.org Mon Aug 1 19:03:49 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Mon, 01 Aug 2016 19:03:49 +0000 Subject: [openssl-dev] [openssl.org #4639] Missing const and docs X509_get_notBefore, X509_get_notAfter In-Reply-To: References: Message-ID: Added documentation now and constified a few more cases. Thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4639 Please log in as guest with password guest if prompted From rt at openssl.org Tue Aug 2 00:26:44 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Tue, 02 Aug 2016 00:26:44 +0000 Subject: [openssl-dev] [openssl.org #4584] Self test failures under X32 In-Reply-To: References: <578E32A8.5090900@openssl.org> Message-ID: On Tue, Jul 19, 2016 at 10:01 AM, Matt Caswell wrote: > > > On 19/07/16 14:41, Richard Levitte via RT wrote: >> Hi Jeff, >> >> I'm going to assume that a newer checkout of the master branch won't change >> much, so if you please, try this command and send mack the result: > > Who is Mack? ;-) > >> >> make test TESTS='test_afalg test_rehash' > > Did you mean to include "VERBOSE=1"? > > VERBOSE=1 make TESTS='test_afalg test_rehash' test The tests run as root because its a Debian Chroot, I did not bother with rehash because it would fail. Here is the result from afalg: # VERBOSE=1 make TESTS='test_afalg' test make depend && make _tests make[1]: Entering directory '/openssl' make[1]: Leaving directory '/openssl' make[1]: Entering directory '/openssl' ( cd test; \ SRCTOP=../. \ BLDTOP=../. \ PERL="perl" \ EXE_EXT= \ OPENSSL_ENGINES=.././engines \ perl .././test/run_tests.pl test_afalg ) ../test/recipes/30-test_afalg.t .. 1..1 ALG_PERR: afalg_fin_cipher_aio: io_read failed : Bad address test_afalg_aes_128_cbc() failed encryption ../util/shlib_wrap.sh ./afalgtest => 1 not ok 1 - running afalgtest # Failed test 'running afalgtest' # at ../test/recipes/30-test_afalg.t line 23. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests Test Summary Report ------------------- ../test/recipes/30-test_afalg.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.03 cusr 0.00 csys = 0.06 CPU) Result: FAIL Failed 1/1 test programs. 1/1 subtests failed. Makefile:148: recipe for target '_tests' failed make[1]: *** [_tests] Error 1 make[1]: Leaving directory '/openssl' Makefile:146: recipe for target 'tests' failed make: *** [tests] Error 2 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584 Please log in as guest with password guest if prompted From bkaduk at akamai.com Tue Aug 2 14:54:42 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 2 Aug 2016 09:54:42 -0500 Subject: [openssl-dev] [openssl-commits] OPENSSL_NO_NEXTPROTONEG and ALPN In-Reply-To: <1470047488.434035.2463.nullmailer@dev.openssl.org> References: <1470047488.434035.2463.nullmailer@dev.openssl.org> Message-ID: <6559ac33-5ff5-b447-3dab-d6f5eaabe47b@akamai.com> On 08/01/2016 05:31 AM, Ben Laurie wrote: > The branch master has been updated > via 68e71e9d000b72d964eb8b4106a1d879a0da4908 (commit) > via 3260adf1901ff3a842676ec7fa8c53dbfc66c4bd (commit) > via 620c6ad3125d7631f08c37033d1cb4302aef819a (commit) > from 087d3e89932e00eede95353fbd988e2752bc2468 (commit) Picking a somewhat-arbitrary chunk to reply to... > diff --git a/test/handshake_helper.c b/test/handshake_helper.c > index eecc6f7..c7023fe 100644 > --- a/test/handshake_helper.c > +++ b/test/handshake_helper.c > @@ -315,6 +316,7 @@ static void configure_handshake_ctx(SSL_CTX *server_ctx, SSL_CTX *server2_ctx, > if (test_ctx->session_ticket_expected == SSL_TEST_SESSION_TICKET_BROKEN) { > SSL_CTX_set_tlsext_ticket_key_cb(server_ctx, broken_session_ticket_cb); > } > +#ifndef OPENSSL_NO_NEXTPROTONEG > if (test_ctx->server_npn_protocols != NULL) { > parse_protos(test_ctx->server_npn_protocols, > &server_ctx_data->npn_protocols, > @@ -360,6 +362,7 @@ static void configure_handshake_ctx(SSL_CTX *server_ctx, SSL_CTX *server2_ctx, > alpn_protos_len) == 0); > OPENSSL_free(alpn_protos); > } > +#endif > /* > * Use fixed session ticket keys so that we can decrypt a ticket created with > * one CTX in another CTX. Don't address server2 for the moment. > I think I'm confused as to whether OPENSSL_NO_NEXTPROTONEG is supposed to also cover ALPN. If we go back to when ALPN was introduced, commit 6f017a8f9db3a79f3a3406cf8d493ccd346db691, even then things seemed inconsistent. We get (in s_client): @@ -364,6 +364,7 @@ static void sc_usage(void) BIO_printf(bio_err," -proof_debug - request an audit proof and print its he # ifndef OPENSSL_NO_NEXTPROTONEG BIO_printf(bio_err," -nextprotoneg arg - enable NPN extension, considering named + BIO_printf(bio_err," -alpn arg - enable ALPN extension, considering name # endif #ifndef OPENSSL_NO_TLSEXT BIO_printf(bio_err," -serverinfo types - send empty ClientHello extensions (comm @@ -636,6 +637,7 @@ int MAIN(int argc, char **argv) {NULL,0}; # ifndef OPENSSL_NO_NEXTPROTONEG const char *next_proto_neg_in = NULL; + const char *alpn_in = NULL; # endif # define MAX_SI_TYPES 100 unsigned short serverinfo_types[MAX_SI_TYPES]; but also @@ -1306,9 +1313,23 @@ bad: */ if (socket_type == SOCK_DGRAM) SSL_CTX_set_read_ahead(ctx, 1); -#if !defined(OPENSSL_NO_TLSEXT) && !defined(OPENSSL_NO_NEXTPROTONEG) +#if !defined(OPENSSL_NO_TLSEXT) +# if !defined(OPENSSL_NO_NEXTPROTONEG) if (next_proto.data) SSL_CTX_set_next_proto_select_cb(ctx, next_proto_cb, &next_proto); +# endif + if (alpn_in) + { + unsigned short alpn_len; + unsigned char *alpn = next_protos_parse(&alpn_len, alpn_in); + + if (alpn == NULL) + { + BIO_printf(bio_err, "Error parsing -alpn argument\n"); + goto end; + } + SSL_CTX_set_alpn_protos(ctx, alpn, alpn_len); + } #endif #ifndef OPENSSL_NO_TLSEXT if (serverinfo_types_count) So some parts are supposed to be compiled out with OPENSSL_NO_NEXTPROTONEG, but others are supposed to only be conditional on OPENSSL_NO_TLSEXT. (These particular chunks look like they would not compile with OPENSSL_NO_NEXTPROTONEG and not OPENSSL_NO_TLSEXT, since alpn_in is used but not declared.) Even in current master, if we look at (e.g.) ssl_locl.h, several next_proto-* fields in struct ssl_ctx_st are ifdef'd out for OPENSSL_NO_NEXTPROTONEG, with the alpn_* bits unconditional Configure doesn't help, just listing nextprotoneg as a disablable, but no comments about what it does. So ... what is OPENSSL_NO_NEXTPROTONEG supposed to control? Does it disable NPN everywhere and also disable ALPN for tests [and apps], but leave ALPN enabled in the library code? That's the best guess I have from reading the code, but it's a bit unusual of an API contract, so maybe it should be documented somewhere. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Tue Aug 2 15:49:15 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 2 Aug 2016 10:49:15 -0500 Subject: [openssl-dev] [openssl-commits] Adding set1 aliases for existing *_set_* functions? In-Reply-To: <1470078125.351650.6192.nullmailer@dev.openssl.org> References: <1470078125.351650.6192.nullmailer@dev.openssl.org> Message-ID: <1f30e2a9-7432-9637-9e2e-6c8e1416fa02@akamai.com> On 08/01/2016 02:02 PM, Dr. Stephen Henson wrote: > The branch master has been updated > via c2e888b54c3b25e89732f6ba66e489ef1ee5ef59 (commit) > via b26ab17f3d3f56be57000e99b8ad94a4e90197a6 (commit) > via 67302ade22b99eaa42031016d4861068b0681db3 (commit) > from 10b0b817a0abe54f5dabe3b21717d77569ad2d9b (commit) > diff --git a/doc/crypto/X509_get_notBefore.pod b/doc/crypto/X509_get_notBefore.pod > new file mode 100644 > index 0000000..ebbd156 > --- /dev/null > +++ b/doc/crypto/X509_get_notBefore.pod > [...] > +X509_set_notBefore() and X509_set_notAfter() set the B > +and B fields of B to B. Ownership of the passed > +parameter B is not transferred by these functions so it must > +be freed up after the call. > + Is it worth adding [at this point in the release cycle] X509_set1_not{Before,After}() aliases to make it easier to deprecate the *_set_* forms in the future? -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Aug 3 13:41:55 2016 From: levitte at openssl.org (Richard Levitte) Date: Wed, 03 Aug 2016 15:41:55 +0200 (CEST) Subject: [openssl-dev] [openssl.org #4602] Missing accessors In-Reply-To: <20160803131344.GB2380@nikhef.nl> References: <20160726095226.GC2457@nikhef.nl> <20160726.175014.587024167281997438.levitte@openssl.org> <20160803131344.GB2380@nikhef.nl> Message-ID: <20160803.154155.2198714958292922881.levitte@openssl.org> In message <20160803131344.GB2380 at nikhef.nl> on Wed, 3 Aug 2016 15:13:44 +0200, Mischa Salle said: msalle> Hi Richard, msalle> msalle> apologies for the delayed answer, I was caught up in work... msalle> msalle> On Tue, Jul 26, 2016 at 05:50:14PM +0200, Richard Levitte wrote: msalle> > msalle> Just for completeness, there are a number of things we need to verify or msalle> > msalle> adapt by hand: msalle> > msalle> - for non-RFC proxies, we need to be able to verify the issuer by hand msalle> > msalle> and override the X509_check_issued(). For GT3 it could be that this is msalle> > msalle> automatically solved by setting the EXFLAG_PROXY, I will need to check msalle> > msalle> that, for legacy /GT2 it cannot be since we need to check for the msalle> > msalle> /CN=proxy or /CN=limited proxy. msalle> > msalle> > You need to set the proxy path length as well for GT3. For GT2, the msalle> > initial value -1 is exactly right. msalle> > msalle> > msalle> - for GT3 proxies we need to verify the pathlength constraint. If your msalle> > msalle> pullrequest https://github.com/openssl/openssl/pull/1348 allows me to msalle> > msalle> set a proxy pathlength constraint for a GT3 proxy which combined with msalle> > msalle> the EXFLAG_PROXY would allow using standard verification, then that msalle> > msalle> would probably indeed solve that problem too. msalle> > msalle> > That's what I'm hoping. Please try it out, for example by disabling msalle> > these lines and seeing if what should verify does verify: msalle> > msalle> > https://github.com/globus/globus-toolkit/blob/globus_6_branch/gsi/callback/source/library/globus_gsi_callback.c#L876-L884 msalle> msalle> The problem with these two points is that I will still have to go msalle> through the chain and set both the pathlength and the proxy flag for msalle> each cert in case of GT3 proxies. In the end I've decided to leave this msalle> part of at least my code as much as it is for now. At some point I will msalle> try to rewrite it. The better idea is to have globus_gsi_callback_check_issued() check for GT2 and GT3 proxies and set the flag and pathlen accordingly. Insert such code before calling X509_check_issued(), i.e. here: https://github.com/globus/globus-toolkit/blob/globus_6_branch/gsi/callback/source/library/globus_gsi_callback.c#L582 That would be a much better use of CPU cycles and already existing OpenSSL code. (also should work for pre-1.1 OpenSSLs) msalle> By the way, even for RFC proxies I still have the problem that setting msalle> the flag X509_V_FLAG_CRL_CHECK (and X509_V_FLAG_CRL_CHECK_ALL) to do CRL msalle> checking results in a failure. I haven't looked yet what causes it, but msalle> that flag should be ignored for proxy certificates in my opinion. msalle> Perhaps I'm doing something wrong...? I believe you've found a bug! Thanks. msalle> > msalle> - for GT3 proxies we also need to be able to set (as you mention) the msalle> > msalle> policy. I need to check that we have the necessary getters/setters for msalle> > msalle> that now. I'll check with your new example. msalle> > msalle> > I've updated the example, it compiles. We don't have that in the ssl msalle> > test any more (or well, we have it in pre-1.1 source), I'm thinking I msalle> > should create a demo... msalle> msalle> I've managed to fix all *my* (that's not VOMS or Globus) code. That also msalle> compiles and works again! msalle> msalle> > msalle> - The errata of the RFC specify actually 3 OIDs, also the msalle> > msalle> id-ppl-anyLanguage / 1.3.6.1.5.5.7.21.0 which is not understood by msalle> > msalle> OpenSSL. I don't think they are used in practice, but I like to have msalle> > msalle> code to verify them. msalle> > msalle> > You can easily do that in verify_cb, per certificate. I think you msalle> > already do? Also, I'm not sure what you mean with "not understood by msalle> > OpenSSL", what is OpenSSL itself supposed to do with it? msalle> Actually, upon looking again at the master branch, I agree that the msalle> id-ppl-anyLanguage is there. I think I accidentally looked at your msalle> example code, which doesn't have it in the switch(). Sorry for the noise. Maybe the example should be expanded, although I've no idea why it must care... msalle> > msalle> More importantly however, in Grid, the so-called limited proxies with msalle> > msalle> globus-owned OID 1.3.6.1.4.1.3536.1.1.1.9 are widely used, they msalle> > msalle> indicate that the proxy may not be used for job submission, only for msalle> > msalle> data access. So we need to have ways to verify that. For legacy/GT2 msalle> > msalle> this is indicated using /CN=limited proxy instead. msalle> > msalle> > 1.3.6.1.4.1.3536.1.1.1.9? That's a policy OID, right? OpenSSL leaves msalle> > it entirely up to verify_cb to check these policies. That would msalle> > correspond to the check_needed_rights() call at the bottom of msalle> > doc/HOWTO/proxy_certificates.txt, right? msalle> msalle> Yes, it's a policy OID, same level as the other three. msalle> I agree we can check them ourselves, but in order to check them, one msalle> needs to go through the whole chain (a non-limited proxy is not allowed msalle> to follow a limited proxy) and that's a tricky thing. In principle one msalle> can do that with cert plus issuer-cert, which is available in the msalle> callback, but that's not very efficient, which was my next point below. I truly don't understand why you need to walk the chain every time verify_cb is called. msalle> > msalle> - Related to the previous point, the chain may not be built up from msalle> > msalle> arbitrary language proxies: for example after a limited proxy, only msalle> > msalle> limited proxies are allowed. msalle> > msalle> > That corresponds to the "rights" idea in msalle> > doc/HOWTO/proxy_certificates.txt msalle> > msalle> > msalle> Also, we need to make sure that the chain is something like msalle> > msalle> CA -> [ subCA ... -> ] EEC -> proxy [ -> proxy ... ] msalle> > msalle> This can of course be done in a chain-local callback (cert+issuer). msalle> > msalle> > The OpenSSL code already ensures that, and works as long as the proxy msalle> > certs are appropriately marked with X509_set_proxy_flag() beforehand msalle> > (for example via the check_issued X509_STORE function for non-RFC msalle> > proxies). If you look in crypto/x509/x509_vfy.c, check msalle> > check_chain_extensions(). You may notice the variable 'must_be_ca', msalle> > which is a tri-state, and controls what kind of cert is expected the msalle> > next step "up". msalle> > msalle> > If you find a bug in that mechanism, we're interested! msalle> msalle> This indeed looks like the right way to go. I guess it would also be the msalle> right place to make sure the proxy pathlength for GT3 proxies is being msalle> set. msalle> msalle> I'm currently rather out of time, but will try to have a look at some msalle> point how we can improve and simplify our code. msalle> msalle> Many thanks for the detailed instructions! msalle> msalle> Mischa msalle> msalle> msalle> > msalle> > msalle> > current_cert, current_issuer, etc are meant as input for verify_cb, msalle> > msalle> > indicating which certificate in the chain the call of the callback is msalle> > msalle> > about. Why one would need to tamper with them from inside the msalle> > msalle> > verify_cb function escapes me... msalle> > msalle> It's true that it's not really what you want to do *if* you can do msalle> > msalle> local-only checks, but that's not possible for the pathlength constraint msalle> > msalle> check (without keeping some global state or by manually setting the msalle> > msalle> effective pathlength inside each cert), hence a renewed walking the msalle> > msalle> chain is typically done upon reaching the last cert. msalle> > msalle> > Like I said, please check what OpenSSL does. There was a bug, so I msalle> > perfectly understand why you needed to override that check. I've msalle> > fixed what I found. If you find a bug in that mechanism, we're msalle> > interested! msalle> > msalle> > -- msalle> > Richard Levitte levitte at openssl.org msalle> > OpenSSL Project http://www.openssl.org/~levitte/ msalle> msalle> -- msalle> Nikhef Room H155 msalle> Science Park 105 Tel. +31-20-592 5102 msalle> 1098 XG Amsterdam Fax +31-20-592 5155 msalle> The Netherlands Email msalle at nikhef.nl msalle> __ .. ... _._. .... ._ ... ._ ._.. ._.. .._.. msalle> From levitte at openssl.org Wed Aug 3 14:10:16 2016 From: levitte at openssl.org (Richard Levitte) Date: Wed, 03 Aug 2016 16:10:16 +0200 (CEST) Subject: [openssl-dev] [openssl.org #4602] Missing accessors In-Reply-To: <20160803.154155.2198714958292922881.levitte@openssl.org> References: <20160726.175014.587024167281997438.levitte@openssl.org> <20160803131344.GB2380@nikhef.nl> <20160803.154155.2198714958292922881.levitte@openssl.org> Message-ID: <20160803.161016.1475095872024951935.levitte@openssl.org> In message <20160803.154155.2198714958292922881.levitte at openssl.org> on Wed, 03 Aug 2016 15:41:55 +0200 (CEST), Richard Levitte said: levitte> In message <20160803131344.GB2380 at nikhef.nl> on Wed, 3 Aug 2016 15:13:44 +0200, Mischa Salle said: levitte> levitte> msalle> By the way, even for RFC proxies I still have the problem that setting levitte> msalle> the flag X509_V_FLAG_CRL_CHECK (and X509_V_FLAG_CRL_CHECK_ALL) to do CRL levitte> msalle> checking results in a failure. I haven't looked yet what causes it, but levitte> msalle> that flag should be ignored for proxy certificates in my opinion. levitte> msalle> Perhaps I'm doing something wrong...? levitte> levitte> I believe you've found a bug! Thanks. I'm attaching the fix I came up with. Please try it out and see if things work better. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -------------- next part -------------- A non-text attachment was scrubbed... Name: x509_vfy.c.patch Type: text/x-patch Size: 842 bytes Desc: not available URL: From rt at openssl.org Wed Aug 3 14:32:57 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 03 Aug 2016 14:32:57 +0000 Subject: [openssl-dev] [openssl.org #4584] Self test failures under X32 In-Reply-To: <5f56d58c-2165-a13d-c6e7-42c1e85b4161@openssl.org> References: <578E32A8.5090900@openssl.org> <5f56d58c-2165-a13d-c6e7-42c1e85b4161@openssl.org> Message-ID: On 02/08/16 01:26, noloader at gmail.com via RT wrote: > On Tue, Jul 19, 2016 at 10:01 AM, Matt Caswell wrote: >> >> >> On 19/07/16 14:41, Richard Levitte via RT wrote: >>> Hi Jeff, >>> >>> I'm going to assume that a newer checkout of the master branch won't change >>> much, so if you please, try this command and send mack the result: >> >> Who is Mack? ;-) >> >>> >>> make test TESTS='test_afalg test_rehash' >> >> Did you mean to include "VERBOSE=1"? >> >> VERBOSE=1 make TESTS='test_afalg test_rehash' test > > The tests run as root because its a Debian Chroot, I did not bother > with rehash because it would fail. > > Here is the result from afalg: > > # VERBOSE=1 make TESTS='test_afalg' test > make depend && make _tests > make[1]: Entering directory '/openssl' > make[1]: Leaving directory '/openssl' > make[1]: Entering directory '/openssl' > ( cd test; \ > SRCTOP=../. \ > BLDTOP=../. \ > PERL="perl" \ > EXE_EXT= \ > OPENSSL_ENGINES=.././engines \ > perl .././test/run_tests.pl test_afalg ) > ../test/recipes/30-test_afalg.t .. > 1..1 > ALG_PERR: afalg_fin_cipher_aio: io_read failed : Bad address > test_afalg_aes_128_cbc() failed encryption Hmmm. I'm thinking there is perhaps some alignment issue in the aio_read call? In any case I think pushing this out to beyond 1.1.0 might be appropriate. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584 Please log in as guest with password guest if prompted From levitte at openssl.org Wed Aug 3 14:43:58 2016 From: levitte at openssl.org (Richard Levitte) Date: Wed, 03 Aug 2016 16:43:58 +0200 (CEST) Subject: [openssl-dev] [openssl.org #4602] Missing accessors In-Reply-To: <20160803142331.GD2380@nikhef.nl> References: <20160803131344.GB2380@nikhef.nl> <20160803.154155.2198714958292922881.levitte@openssl.org> <20160803142331.GD2380@nikhef.nl> Message-ID: <20160803.164358.1864761778986325348.levitte@openssl.org> In message <20160803142331.GD2380 at nikhef.nl> on Wed, 3 Aug 2016 16:23:31 +0200, Mischa Salle said: msalle> On Wed, Aug 03, 2016 at 03:41:55PM +0200, Richard Levitte wrote: msalle> > msalle> By the way, even for RFC proxies I still have the problem that setting msalle> > msalle> the flag X509_V_FLAG_CRL_CHECK (and X509_V_FLAG_CRL_CHECK_ALL) to do CRL msalle> > msalle> checking results in a failure. I haven't looked yet what causes it, but msalle> > msalle> that flag should be ignored for proxy certificates in my opinion. msalle> > msalle> Perhaps I'm doing something wrong...? msalle> > msalle> > I believe you've found a bug! Thanks. msalle> Would you like me to open an issue? I haven't checked in great detail msalle> though... Nah, the two lines that were needed got reviewed quite quickly and are already in master. In fact, it will be part of the beta we're releasing tomorrow. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From viktor.kolodrevskiy at gmail.com Wed Aug 3 15:12:07 2016 From: viktor.kolodrevskiy at gmail.com (Viktor Kolodrevskiy) Date: Wed, 3 Aug 2016 18:12:07 +0300 Subject: [openssl-dev] [openssl.org #4612] Appcrash on SSL_CTX_new(SSLv2_server_method()) on windows 7 x64 with OpenSSL-1.0.1t In-Reply-To: References: <2A55BF74-E647-486D-BF3B-1A2E379315ED@gmail.com> Message-ID: <3F0382C8-96F5-4C24-86FE-FDAE41C07C76@gmail.com> Hi, If I want to enable ssl2 under windows build, will need to pass parameters: no-asm enable-ssl2 -DOPENSSL_USE_IPV6=0 VC-WIN32 So if I will need to build openssl under linux, parameters should be: no-asm enable-ssl2 -DOPENSSL_USE_IPV6=0 Is that right? > On Jul 11, 2016, at 20:20, Kurt Cancemi via RT wrote: > > Hello, > > In 1.0.1s OpenSSL disabled SSLv2 by default in the build. So use perl Configure no-asm enable-ssl2 -DOPENSSL_USE_IPV6=0 VC-WIN32 > > Excerpt from CHANGES > > "Changes between 1.0.1r and 1.0.1s [1 Mar 2016]" > ? > Disable SSLv2 default build, default negotiation and weak ciphers. SSLv2 > is by default disabled at build-time. Builds that are not configured with > "enable-ssl2" will not support SSLv2. Even if "enable-ssl2" is used, > users who want to negotiate SSLv2 via the version-flexible SSLv23_method() > will need to explicitly call either of: > > SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2); > or > SSL_clear_options(ssl, SSL_OP_NO_SSLv2); > > as appropriate. Even if either of those is used, or the application > explicitly uses the version-specific SSLv2_method() or its client and > server variants, SSLv2 ciphers vulnerable to exhaustive search key > recovery have been removed. Specifically, the SSLv2 40-bit EXPORT > ciphers, and SSLv2 56-bit DES are no longer available. > (CVE-2016-0800)? > > I highly advise you to stay clear of SSLv2 as it has numerous flaws. You are receiving crashes because SSLv2_server_method() returns NULL and SSL_CTX_new() returns NULL because the input argument (the server method) is NULL. You should check the return value of SSL_CTX_new() no matter what because it can fail. > > Kurt Cancemi > kurt at x64architecture.com > >> On Jul 11, 2016, at 08:10, Dmytro Shamatrin via RT wrote: >> >> Appcrash on SSL_CTX_new(SSLv2_server_method()) on windows 7 x64 with OpenSSL-1.0.1t >> >> After upgrade from OpenSSL-1.0.1L version to 1.0.1t we got Appcrash on windows machine. After investigation I found that it started to happen after R version. > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4612 > Please log in as guest with password guest if prompted > > -- > 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 Aug 3 15:12:22 2016 From: rt at openssl.org (Viktor Kolodrevskiy via RT) Date: Wed, 03 Aug 2016 15:12:22 +0000 Subject: [openssl-dev] [openssl.org #4612] Appcrash on SSL_CTX_new(SSLv2_server_method()) on windows 7 x64 with OpenSSL-1.0.1t In-Reply-To: <3F0382C8-96F5-4C24-86FE-FDAE41C07C76@gmail.com> References: <2A55BF74-E647-486D-BF3B-1A2E379315ED@gmail.com> <3F0382C8-96F5-4C24-86FE-FDAE41C07C76@gmail.com> Message-ID: Hi, If I want to enable ssl2 under windows build, will need to pass parameters: no-asm enable-ssl2 -DOPENSSL_USE_IPV6=0 VC-WIN32 So if I will need to build openssl under linux, parameters should be: no-asm enable-ssl2 -DOPENSSL_USE_IPV6=0 Is that right? > On Jul 11, 2016, at 20:20, Kurt Cancemi via RT wrote: > > Hello, > > In 1.0.1s OpenSSL disabled SSLv2 by default in the build. So use perl Configure no-asm enable-ssl2 -DOPENSSL_USE_IPV6=0 VC-WIN32 > > Excerpt from CHANGES > > "Changes between 1.0.1r and 1.0.1s [1 Mar 2016]" > ? > Disable SSLv2 default build, default negotiation and weak ciphers. SSLv2 > is by default disabled at build-time. Builds that are not configured with > "enable-ssl2" will not support SSLv2. Even if "enable-ssl2" is used, > users who want to negotiate SSLv2 via the version-flexible SSLv23_method() > will need to explicitly call either of: > > SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2); > or > SSL_clear_options(ssl, SSL_OP_NO_SSLv2); > > as appropriate. Even if either of those is used, or the application > explicitly uses the version-specific SSLv2_method() or its client and > server variants, SSLv2 ciphers vulnerable to exhaustive search key > recovery have been removed. Specifically, the SSLv2 40-bit EXPORT > ciphers, and SSLv2 56-bit DES are no longer available. > (CVE-2016-0800)? > > I highly advise you to stay clear of SSLv2 as it has numerous flaws. You are receiving crashes because SSLv2_server_method() returns NULL and SSL_CTX_new() returns NULL because the input argument (the server method) is NULL. You should check the return value of SSL_CTX_new() no matter what because it can fail. > > Kurt Cancemi > kurt at x64architecture.com > >> On Jul 11, 2016, at 08:10, Dmytro Shamatrin via RT wrote: >> >> Appcrash on SSL_CTX_new(SSLv2_server_method()) on windows 7 x64 with OpenSSL-1.0.1t >> >> After upgrade from OpenSSL-1.0.1L version to 1.0.1t we got Appcrash on windows machine. After investigation I found that it started to happen after R version. > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4612 > Please log in as guest with password guest if prompted > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4612 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 3 16:03:12 2016 From: rt at openssl.org (Kaduk, Ben via RT) Date: Wed, 03 Aug 2016 16:03:12 +0000 Subject: [openssl-dev] [openssl.org #4612] Appcrash on SSL_CTX_new(SSLv2_server_method()) on windows 7 x64 with OpenSSL-1.0.1t In-Reply-To: <3d6892ba-7acb-44aa-1cb4-83fa8c5c9453@akamai.com> References: <2A55BF74-E647-486D-BF3B-1A2E379315ED@gmail.com> <3F0382C8-96F5-4C24-86FE-FDAE41C07C76@gmail.com> <3d6892ba-7acb-44aa-1cb4-83fa8c5c9453@akamai.com> Message-ID: On 08/03/2016 10:12 AM, Viktor Kolodrevskiy wrote: > Hi, > > If I want to enable ssl2 under windows build, will need to pass > parameters: > no-asm enable-ssl2 -DOPENSSL_USE_IPV6=0 VC-WIN32 > > So if I will need to build openssl under linux, parameters should be: > no-asm enable-ssl2 -DOPENSSL_USE_IPV6=0 > > Is that right? > You still need to pass an os/compiler argument to Configure for linux, something like linux-x86_64 or linux-elf, presumably. If you use config instead of Configure, there is autodetection of which os/compiler to use, so no os/compiler argument is needed. -Ben -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4612 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 3 21:13:08 2016 From: rt at openssl.org (Roumen Petrov via RT) Date: Wed, 03 Aug 2016 21:13:08 +0000 Subject: [openssl-dev] [openssl.org #4590] accessors without const return arguments In-Reply-To: <57A25364.8050409@roumenpetrov.info> References: <576EF43A.7010104@roumenpetrov.info> <57A25364.8050409@roumenpetrov.info> Message-ID: Stephen Henson via RT wrote: > On Sat Jun 25 22:09:59 2016, openssl at roumenpetrov.info wrote: >> Above is reason the request to remove const from return argument of get0 >> methods. > We had a discussion about this and the preference was to have get methods > retain const for various reasons. > > Instead the DSA_SIG/ECDSA_SIG structures now no longer pre-allocate r/s so they > aren't immediately freed when you set them. Please update documentation (status of 3.8.2016): 1) DSA_SIG_new.pod DSA_SIG_new() allocates and initializes a B structure. So now function only allocates signature. 2) ECDSA_SIG_new.pod ECDSA_SIG_new() allocates a new B structure (note: this function also allocates the BIGNUMs) and initializes it. Same here, but please indicate that this is changed in 1.1. >> The issue is not only for ECDSA but also for DSA_SIG and RSA, DSA, DH >> keys where situation is similar. > Do you have some examples of how this affects other structures? For RSA/DSA/DH > keys the fields are NULL initially unless I've missed something. Impact is over other software where more or less situation is the same - code allocates and initialize(!) keys. In deserialization process just updates allocated key material. It seemt to me now is more easy just to perform "const cast hack" instead to rewrite totally code. Roumen -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4590 Please log in as guest with password guest if prompted From openssl at openssl.org Thu Aug 4 14:26:55 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 4 Aug 2016 14:26:55 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 6 published Message-ID: <20160804142655.GA19332@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.1.0 pre release 6 (beta) =========================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 1.1.0 is currently in beta. OpenSSL 1.1.0 pre release 6 has now been made available. For details of changes and known issues see the release notes at: https://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 beta release is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0-pre6.tar.gz Size: 5100538 SHA1 checksum: b4c4b64c56813a4dd824b9bb2735ac15331845b8 SHA256 checksum: ca869f843b8a947fb64ca7d7bebb2afe47a48d7bb5e9becc54d9c8fe674535c2 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0-pre6.tar.gz openssl sha256 openssl-1.1.0-pre6.tar.gz Please download and check this beta 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 iQEcBAEBAgAGBQJXo0qTAAoJENnE0m0OYESRj8sH/2sBz0vvkdGHZmNIttjbsrXz Xyx+nZHUkpuNwnQXzq7QuHMrUk+DtPOfgjxt7IOwVyzz/yyDMO+txhTRpgQH0y4e bOjsx+xUz1Bz3AioP06tREGkUdrZSkthVypkF1bKdb043rTZhY4EQ8sr+kw8cha6 sr93CFug/M52P0DLEksQQY0JXWkCvZvBbJK4YcC+ToyVhJ2Iz4og8KeN6X2/bNcB h5+RjdQnaLBMZIWe4MNt4flgtw59vt+3DbwPHiu5WDVl/RngUyGf22qxVV+y9XIu DEJ56V5TKvn7/BonIoUdFthx9s9wzzCcnm71LcfFzW1El9oOP3wOwDpCriRDkhY= =q4/S -----END PGP SIGNATURE----- From ca+ssl-dev at esmtp.org Thu Aug 4 15:41:44 2016 From: ca+ssl-dev at esmtp.org (Claus Assmann) Date: Thu, 4 Aug 2016 08:41:44 -0700 Subject: [openssl-dev] 1.1.0 pre release 6: Installing manpages error: tr Message-ID: <20160804154144.GA14958@x2.esmtp.org> Happens on OpenBSD and Linux (similar error message): *** Installing manpages usage: tr [-cs] string1 string2 tr [-c] -d string1 tr [-c] -s string1 tr [-c] -ds string1 string2 Seems [A-Z] etc needs to be quoted, e.g., tr '[a-z]' '[A-Z]' There are several places like this in the Makefile. From levitte at openssl.org Thu Aug 4 16:08:46 2016 From: levitte at openssl.org (Richard Levitte) Date: Thu, 04 Aug 2016 18:08:46 +0200 (CEST) Subject: [openssl-dev] 1.1.0 pre release 6: Installing manpages error: tr In-Reply-To: <20160804154144.GA14958@x2.esmtp.org> References: <20160804154144.GA14958@x2.esmtp.org> Message-ID: <20160804.180846.2091279733512525080.levitte@openssl.org> In message <20160804154144.GA14958 at x2.esmtp.org> on Thu, 4 Aug 2016 08:41:44 -0700, Claus Assmann said: ca+ssl-dev> Happens on OpenBSD and Linux (similar error message): ca+ssl-dev> ca+ssl-dev> *** Installing manpages ca+ssl-dev> usage: tr [-cs] string1 string2 ca+ssl-dev> tr [-c] -d string1 ca+ssl-dev> tr [-c] -s string1 ca+ssl-dev> tr [-c] -ds string1 string2 ca+ssl-dev> ca+ssl-dev> ca+ssl-dev> Seems [A-Z] etc needs to be quoted, e.g., ca+ssl-dev> tr '[a-z]' '[A-Z]' ca+ssl-dev> ca+ssl-dev> There are several places like this in the Makefile. I suppose this depends on what shell is being used. I've attached a fix (apply with 'patch -p1 < unix-Makefile.tmpl.patch'), would you mind trying it out? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -------------- next part -------------- A non-text attachment was scrubbed... Name: unix-Makefile.tmpl.patch Type: text/x-patch Size: 1358 bytes Desc: not available URL: From rainer.jung at kippdata.de Thu Aug 4 16:57:02 2016 From: rainer.jung at kippdata.de (Rainer Jung) Date: Thu, 4 Aug 2016 18:57:02 +0200 Subject: [openssl-dev] OpenSSL 1.1.0 pre 6: SPARCv9 capability bits problem In-Reply-To: <1461577876.080779.24055.nullmailer@dev.openssl.org> References: <1461577876.080779.24055.nullmailer@dev.openssl.org> Message-ID: <2c080cca-12b8-a05f-8a7a-66e4f0d16d8c@kippdata.de> The following change introduced build problems: Am 25.04.2016 um 11:51 schrieb Andy Polyakov: > The branch master has been updated > via 299ccadcdb99001c618d188fb243c1caaaa86a1c (commit) > from a82a9f71ad0149380a680cae4c0cc693e6324679 (commit) > > > - Log ----------------------------------------------------------------- > commit 299ccadcdb99001c618d188fb243c1caaaa86a1c > Author: Andy Polyakov > Date: Sat Apr 23 19:10:04 2016 +0200 > > crypto/sparc_arch.h: reserve more SPARCv9 capability bits. > > Reviewed-by: Richard Levitte > > ----------------------------------------------------------------------- > > Summary of changes: > crypto/sparc_arch.h | 9 ++++++++- > crypto/sparcv9cap.c | 17 ++++++++++++----- > 2 files changed, 20 insertions(+), 6 deletions(-) > > diff --git a/crypto/sparc_arch.h b/crypto/sparc_arch.h > index 6f8969f..5bcdd9f 100644 > --- a/crypto/sparc_arch.h > +++ b/crypto/sparc_arch.h > @@ -5,12 +5,16 @@ > # define SPARCV9_PREFER_FPU (1<<1) > # define SPARCV9_VIS1 (1<<2) > # define SPARCV9_VIS2 (1<<3)/* reserved */ > -# define SPARCV9_FMADD (1<<4)/* reserved for SPARC64 V */ > +# define SPARCV9_FMADD (1<<4) > # define SPARCV9_BLK (1<<5)/* VIS1 block copy */ > # define SPARCV9_VIS3 (1<<6) > # define SPARCV9_RANDOM (1<<7) > # define SPARCV9_64BIT_STACK (1<<8) > # define SPARCV9_FJAESX (1<<9)/* Fujitsu SPARC64 X AES */ > +# define SPARCV9_FJDESX (1<<10)/* Fujitsu SPARC64 X DES, reserved */ > +# define SPARCV9_FJHPCACE (1<<11)/* Fujitsu HPC-ACE, reserved */ > +# define SPARCV9_IMA (1<<13)/* reserved */ > +# define SPARCV9_VIS4 (1<<14)/* reserved */ > > /* > * OPENSSL_sparcv9cap_P[1] is copy of Compatibility Feature Register, > @@ -29,6 +33,9 @@ > # define CFR_MONTMUL 0x00000200/* Supports MONTMUL opcodes */ > # define CFR_MONTSQR 0x00000400/* Supports MONTSQR opcodes */ > # define CFR_CRC32C 0x00000800/* Supports CRC32C opcodes */ > +# define CFR_XMPMUL 0x00001000/* Supports XMPMUL opcodes */ > +# define CFR_XMONTMUL 0x00002000/* Supports XMONTMUL opcodes */ > +# define CFR_XMONTSQR 0x00004000/* Supports XMONTSQR opcodes */ > > # if defined(OPENSSL_PIC) && !defined(__PIC__) > # define __PIC__ > diff --git a/crypto/sparcv9cap.c b/crypto/sparcv9cap.c > index e1e6d73..30c384b 100644 > --- a/crypto/sparcv9cap.c > +++ b/crypto/sparcv9cap.c > @@ -149,17 +149,24 @@ void OPENSSL_cpuid_setup(void) > unsigned int vec[1]; The vec array still has size 1, but ... > if (getisax (vec,1)) { > - if (vec[0]&0x0020) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS1; > - if (vec[0]&0x0040) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS2; > - if (vec[0]&0x0080) OPENSSL_sparcv9cap_P[0] |= SPARCV9_BLK; > - if (vec[0]&0x0100) OPENSSL_sparcv9cap_P[0] |= SPARCV9_FMADD; > - if (vec[0]&0x0400) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS3; > + if (vec[0]&0x00020) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS1; > + if (vec[0]&0x00040) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS2; > + if (vec[0]&0x00080) OPENSSL_sparcv9cap_P[0] |= SPARCV9_BLK; > + if (vec[0]&0x00100) OPENSSL_sparcv9cap_P[0] |= SPARCV9_FMADD; > + if (vec[0]&0x00400) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS3; > + if (vec[0]&0x01000) OPENSSL_sparcv9cap_P[0] |= SPARCV9_FJHPCACE; > + if (vec[0]&0x02000) OPENSSL_sparcv9cap_P[0] |= SPARCV9_FJDESX; > + if (vec[0]&0x08000) OPENSSL_sparcv9cap_P[0] |= SPARCV9_IMA; > if (vec[0]&0x10000) OPENSSL_sparcv9cap_P[0] |= SPARCV9_FJAESX; > + if (vec[1]&0x00008) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS4; ... here we use vec[1], so the compiler warns: crypto/sparcv9cap.c:179:20: warning: array subscript is above array bounds [-Warray-bounds] if (vec[1]&0x00008) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS4; ^ I also can't check whether 0x00008 is correct for vec[1] (and we need size 2) or 0x00008 should be something else. My Sparc system is too old for VIS4. > /* reconstruct %cfr copy */ > OPENSSL_sparcv9cap_P[1] = (vec[0]>>17)&0x3ff; > OPENSSL_sparcv9cap_P[1] |= (OPENSSL_sparcv9cap_P[1]&CFR_MONTMUL)<<1; > if (vec[0]&0x20000000) OPENSSL_sparcv9cap_P[1] |= CFR_CRC32C; > + if (vec[1]&0x00000020) OPENSSL_sparcv9cap_P[1] |= CFR_XMPMUL; > + if (vec[1]&0x00000040) > + OPENSSL_sparcv9cap_P[1] |= CFR_XMONTMUL|CFR_XMONTSQR; Again vec[1] (twice). > /* Some heuristics */ > /* all known VIS2-capable CPUs have unprivileged tick counter */ Furthermore the following changes: The branch master has been updated via 6944565bd55d147bdb46c708dff06ac310457036 (commit) via 4400f6c61e586dde2aea8dd023c9d4573fbbc547 (commit) via fb65020b37d606659f90aa62163220b72d5560f5 (commit) from 38c5674dda8333288aa5d57ccd046203803aa81f (commit) - Log ----------------------------------------------------------------- commit 6944565bd55d147bdb46c708dff06ac310457036 Author: Andy Polyakov Date: Tue Apr 19 13:09:54 2016 +0200 evp/aes_aes.c: engage Fujitsu SPARC64 X AES support. Reviewed-by: Richard Levitte commit 4400f6c61e586dde2aea8dd023c9d4573fbbc547 Author: Andy Polyakov Date: Tue Apr 19 13:08:47 2016 +0200 sparcv9cap.c: add Fujitsu SPARC64 X AES capability detection. Reviewed-by: Richard Levitte commit fb65020b37d606659f90aa62163220b72d5560f5 Author: Andy Polyakov Date: Tue Apr 19 13:06:18 2016 +0200 Add AES assembly module for Fujitsu SPARC64 X/X+. Reviewed-by: Richard Levitte need the following patch to crypto/sparcv9cap.c here (warning "implicit declaration of function '_sparcv9_fjaesx_probe'"): @@ -93,6 +93,7 @@ void _sparcv9_fmadd_probe(void); unsigned long _sparcv9_rdcfr(void); void _sparcv9_vis3_probe(void); +void _sparcv9_fjaesx_probe(void); unsigned long _sparcv9_random(void); size_t _sparcv9_vis1_instrument_bus(unsigned int *, size_t); size_t _sparcv9_vis1_instrument_bus2(unsigned int *, size_t, size_t); Thanks and regards, Rainer From rainer.jung at kippdata.de Thu Aug 4 17:08:15 2016 From: rainer.jung at kippdata.de (Rainer Jung) Date: Thu, 4 Aug 2016 19:08:15 +0200 Subject: [openssl-dev] OpenSSL 1.1.0 pre 5+6: SPARCv9 assembler stack alignment problem Message-ID: When building OpenSSL 1.1.0 pre 5 or pre 6 on Sparc I get: /usr/ccs/bin/as: "crypto/ec/ecp_nistz256-sparcv9.s", line 4811: warning: stack alignment problem; second operand is not a multiple of 8 /usr/ccs/bin/as: "crypto/ec/ecp_nistz256-sparcv9.s", line 5063: warning: stack alignment problem; second operand is not a multiple of 8 /usr/ccs/bin/as: "crypto/ec/ecp_nistz256-sparcv9.s", line 5539: warning: stack alignment problem; second operand is not a multiple of 8 The lines in question in crypto/ec/ecp_nistz256-sparcv9.s are: save %sp,-(2047+192)-32*10,%sp save %sp,-(2047+192)-32*18-32,%sp save %sp,-(2047+192)-32*15-32,%sp They probably go back to the following lines in crypto/ec/ecp_nistz256-sparcv9.s.S: ... #ifdef __arch64__ .register %g2,#scratch .register %g3,#scratch # define STACK64_FRAME STACK_FRAME # define LOCALS64 LOCALS #else # define STACK64_FRAME (2047+192) # define LOCALS64 STACK64_FRAME #endif ... save %sp,-STACK64_FRAME-32*10,%sp ... save %sp,-STACK64_FRAME-32*18-32,%sp ... save %sp,-STACK64_FRAME-32*15-32,%sp I can't judge on the validity of the "stack alignment problem", but at least 2047 is indeed not divisible by 8 (but all other offsets added or subtracted from 2047 are). Thanks and regards, Rainer From ca+ssl-dev at esmtp.org Thu Aug 4 19:08:43 2016 From: ca+ssl-dev at esmtp.org (Claus Assmann) Date: Thu, 4 Aug 2016 12:08:43 -0700 Subject: [openssl-dev] 1.1.0 pre release 6: Installing manpages error: tr In-Reply-To: <20160804.180846.2091279733512525080.levitte@openssl.org> References: <20160804154144.GA14958@x2.esmtp.org> <20160804.180846.2091279733512525080.levitte@openssl.org> Message-ID: <20160804190843.GA19686@x2.esmtp.org> On Thu, Aug 04, 2016, Richard Levitte wrote: > I suppose this depends on what shell is being used. I've attached a /bin/ksh > fix (apply with 'patch -p1 < unix-Makefile.tmpl.patch'), would you > mind trying it out? That works (I made those changes by hand to Makefile before). From levitte at openssl.org Thu Aug 4 19:34:34 2016 From: levitte at openssl.org (Richard Levitte) Date: Thu, 04 Aug 2016 21:34:34 +0200 (CEST) Subject: [openssl-dev] 1.1.0 pre release 6: Installing manpages error: tr In-Reply-To: <20160804190843.GA19686@x2.esmtp.org> References: <20160804154144.GA14958@x2.esmtp.org> <20160804.180846.2091279733512525080.levitte@openssl.org> <20160804190843.GA19686@x2.esmtp.org> Message-ID: <20160804.213434.2052053096078963266.levitte@openssl.org> In message <20160804190843.GA19686 at x2.esmtp.org> on Thu, 4 Aug 2016 12:08:43 -0700, Claus Assmann said: ca+ssl-dev> On Thu, Aug 04, 2016, Richard Levitte wrote: ca+ssl-dev> ca+ssl-dev> > I suppose this depends on what shell is being used. I've attached a ca+ssl-dev> ca+ssl-dev> /bin/ksh ca+ssl-dev> ca+ssl-dev> > fix (apply with 'patch -p1 < unix-Makefile.tmpl.patch'), would you ca+ssl-dev> > mind trying it out? ca+ssl-dev> ca+ssl-dev> That works (I made those changes by hand to Makefile before). Thanks for confirming. It's now in master and will work correctly in the final release (due in three weeks) Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From appro at openssl.org Thu Aug 4 20:01:29 2016 From: appro at openssl.org (Andy Polyakov) Date: Thu, 4 Aug 2016 22:01:29 +0200 Subject: [openssl-dev] OpenSSL 1.1.0 pre 5+6: SPARCv9 assembler stack alignment problem In-Reply-To: References: Message-ID: <583b0083-fd32-2133-08a2-27df50113c68@openssl.org> > When building OpenSSL 1.1.0 pre 5 or pre 6 on Sparc I get: > > /usr/ccs/bin/as: "crypto/ec/ecp_nistz256-sparcv9.s", line 4811: warning: > stack alignment problem; second operand is not a multiple of 8 > /usr/ccs/bin/as: "crypto/ec/ecp_nistz256-sparcv9.s", line 5063: warning: > stack alignment problem; second operand is not a multiple of 8 > /usr/ccs/bin/as: "crypto/ec/ecp_nistz256-sparcv9.s", line 5539: warning: > stack alignment problem; second operand is not a multiple of 8 > > The lines in question in crypto/ec/ecp_nistz256-sparcv9.s are: > > save %sp,-(2047+192)-32*10,%sp > save %sp,-(2047+192)-32*18-32,%sp > save %sp,-(2047+192)-32*15-32,%sp > > They probably go back to the following lines in > crypto/ec/ecp_nistz256-sparcv9.s.S: > > ... > #ifdef __arch64__ > .register %g2,#scratch > .register %g3,#scratch > # define STACK64_FRAME STACK_FRAME > # define LOCALS64 LOCALS > #else > # define STACK64_FRAME (2047+192) > # define LOCALS64 STACK64_FRAME > #endif > ... > save %sp,-STACK64_FRAME-32*10,%sp > ... > save %sp,-STACK64_FRAME-32*18-32,%sp > ... > save %sp,-STACK64_FRAME-32*15-32,%sp > > I can't judge on the validity of the "stack alignment problem", but at > least 2047 is indeed not divisible by 8 (but all other offsets added or > subtracted from 2047 are). Thing there is following. If if have close look you'll notice that those functions are VIS3 ones. They use 64-bit multiplication and addition instructions. Normally you can't use them in 32-bit application context, because higher halves of most registers are not preserved upon context switch or trap delivery. But there is one special thing about stack in 64-bit[!] application context, namely that it's biased by 2047 bytes. Yes, %sp in 64-bit application is actually misaligned. Linux kernel was modified to recognize misaligned stack *even* in 32-bit application context and preserve full registers' contents, which makes it possible to use faster code path even in 32-bit application (it's discussed in commentary section in bn/asm/sparct4-mont.pl. Solaris doesn't recognize misaligned 32-bit stack, corresponding capability bit in never set, and code is never called. In other words warning is benign. Since you haven't seen similar warning from sparct4-mont module I suppose assembler looks one at save instruction. This in turn should mean that it's possible to work around it... From uri at ll.mit.edu Thu Aug 4 20:30:15 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 4 Aug 2016 20:30:15 +0000 Subject: [openssl-dev] [openssl-users] PKCS7_sign conflict with PKCS7_decrypt? In-Reply-To: <20160726192443.GA10941@openssl.org> References: <008401d1e749$8d021d90$a70658b0$@carroll.com> <20160726152144.GA6638@openssl.org> <00a201d1e752$67c23390$37469ab0$@carroll.com> <20160726160653.GA7351@openssl.org> <00d701d1e767$af695a60$0e3c0f20$@carroll.com> <20160726192443.GA10941@openssl.org> Message-ID: On 7/26/16, 15:24 , "openssl-users on behalf of Dr. Stephen Henson" wrote: >On Tue, Jul 26, 2016, Jim Carroll wrote: >> After experimenting, I can confirm this is the same issue we're seeing, >> although experiencing it very differently from the MIT/Kerberos team. >>I can >> confirm that right now PKCS7 sign/encrypt/decrypt is broken. > >A fix is currently being reviewed. It includes a test. It just happense >that >the standard CMS/PKCS#7 tests use a very short content length. If it is a >little longer they trigger the bug. I don?t think I?ve seen any mentioning of this bug being addressed yet (could?ve missed the notification, of course). So what?s the status if this issue? Has the fix been reviewed and applied? Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5227 bytes Desc: not available URL: From jim at carroll.com Thu Aug 4 21:33:42 2016 From: jim at carroll.com (Jim Carroll) Date: Thu, 4 Aug 2016 17:33:42 -0400 Subject: [openssl-dev] [openssl-users] PKCS7_sign conflict with PKCS7_decrypt? In-Reply-To: References: <008401d1e749$8d021d90$a70658b0$@carroll.com> <20160726152144.GA6638@openssl.org> <00a201d1e752$67c23390$37469ab0$@carroll.com> <20160726160653.GA7351@openssl.org> <00d701d1e767$af695a60$0e3c0f20$@carroll.com> <20160726192443.GA10941@openssl.org> Message-ID: <00a001d1ee97$e05e8be0$a11ba3a0$@carroll.com> I had heard a patch was being worked on, but I do not believe it has been released (or if it is -- I can't find it). I can confirm that "OpenSSL 1.1.0-pre7-dev" still has the bug which prevents PKCS7 sign-->encrypt->decrypt from working. > -----Original Message----- > From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of > Blumenthal, Uri - 0553 - MITLL > Sent: Thursday, August 04, 2016 4:30 PM > To: openssl-dev > Subject: Re: [openssl-dev] [openssl-users] PKCS7_sign conflict with > PKCS7_decrypt? > > On 7/26/16, 15:24 , "openssl-users on behalf of Dr. Stephen Henson" > > wrote: > > >On Tue, Jul 26, 2016, Jim Carroll wrote: > >> After experimenting, I can confirm this is the same issue we're > seeing, > >> although experiencing it very differently from the MIT/Kerberos > team. > >>I can > >> confirm that right now PKCS7 sign/encrypt/decrypt is broken. > > > >A fix is currently being reviewed. It includes a test. It just > happense > >that > >the standard CMS/PKCS#7 tests use a very short content length. If it > is a > >little longer they trigger the bug. > > I don???t think I???ve seen any mentioning of this bug being addressed yet > (could???ve missed the notification, of course). > > So what???s the status if this issue? Has the fix been reviewed and > applied? > > Thanks! begin 666 smime.p7s M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$' M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D& M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14 M'1E%PTP,# U,S Q,#0X,SA:%PTR,# U,S Q,#0X M,SA:,&\Q"S )!@-5! 83`E-%,10P$@8#500*$PM!9&14=,K(D%3IQE\/>)V:0#P.K&&J7A2/GH>A:E#&`JCIJ&DF&)"K3+!/(ZLZ3X38W\Z?X6EON]="UVM$Y,>M[FU! M7W):<0 at WLWEEI%F at E#?W`"\-PI)RVM X DRU0:, L& M`U4=#P0$`P(!!C /!@-5'1,!`?\$!3 #`0'_,(&9!@-5'2,$@9$P at 8Z %*V] MF'HTM";W^L0F5.\#O> DRU0:H7.D<3!O,0LP"08#500&$P)313$4,!(&`U4$ M"A,+061D5')U8'9 M'EL4!R,V98^PV'>[K$%L1V"#4;#Y,CWG_/8F$\> %J6_6OR'SWAYB2&:XDP' M"H8UO/+>4<32EK?L,`E$4+8Z]%N#!WT9UYR2M[/1"M(63:[H<4KPC:^$PWFO6-^>7NG"0U JVK=CXK#]O:, M&D(%4=1%]9^G8B%H%2!#/)GG?+TDV*F1%W.(/U8;,3 at 8M'$/FLW(#IZ.+AOA MC)B#RQ\Q\41,Q at 1S279@#\?XO1> :R[IS$P.6IIY#R *+M6>8R8>59*4V((7 M6GO0O,>/3H8$,(($KS""`Y>@`P(!`@(1`. CRQ42 at U.)K6%N>E1G:R$P#08) M*H9(AO<-`0$+!0`P;S$+, D&`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T M($%",28P) 8#500+$QU!9&14'1E%PTQ-#$R,C(P M,# P,#!:%PTR,# U,S Q,#0X,SA:,(&;,0LP"08#500&$P)'0C$;,!D&`U4$ M"!,21W)E871EE,93G!2';Q6 MI at 8FM[A)X);G4:OQ\%H3216CM(P;8+QZ44*G>8RD(M\784Z1U78C"A332@)_ MMAT)@&ZE!#W9NKL6_J&'J2Y#4D,6?*\R4,BF3UKI"-C/DR6<>XCH,&3FI/A6 M@/TJ)!0S%YFL1.5IBZ-&!DO",]3I0)\&L+&LDT"YM0B3.IPJ4Z,0VST at 83Q5 M`X[93G8E`B$I^J-\<79/[N%?@>G[5(#;PWLU4K>$WB(]+# M,7]9O5(WL#-I M+4/K^M:E\9=W9U&,V>XGZ[RE!SAVC*2I./_?C/4#K$F^RO=SF3H/,JNPP#@8#51T/`0'_! 0#`@&&,!(&`U4=$P$!_P0(, 8!`?\"`0`P'08# M51TE!!8P% 8(*P8!!04'`P(&""L&`04%!P,$,!$&`U4=( 0*, @P!@8$51T@ M`#!$!@-5'1\$/3 [,#F at -Z UAC-H='1P.B\O8W)L+G5S97)T'1EJSMCY=K5<^_LX/M[XJ/_\$(CG,JVC4T^Y$L8`[*H+=38 MNT)+D&F%$-NF-S3H>^ !$*6Y+,KF'$K8F0W!AN*0DOM:0FHC(1#I M913V2A :)OI\BON;,((% M(#""! B@`P(!`@(1`-4+#]T2278FC)\!=Y87SN8P#08)*H9(AO<-`0$+!0`P M at 9LQ"S )!@-5! 83`D=",1LP&08#500($Q)'%PTQ-C Q,3,P,# P,#!:%PTQ-S Q M,3(R,S4Y-3E:," Q'C HV/H^"EPS!W)_L#3<"[3T(BZ3LDTHN"#(\B5A1 M^VO2XN77=+Z\+IU=@1UR!40:,<7&)5,P,O1STRE:UFFYLS65=GVT*:ZY[YK9 M':(_+75)?UCOJQ: M-%=9XH<_VNPXG^;7/:6"2-DDFNH3JMIBVKH$1G/E$ 9 MD8XE<3>#8^@.89*P$#)O+'$"`P$``:."`=SB(9<*/G' MV*_ SS .!@-5'0\!`?\$! ,"!: P# 8#51T3`0'_! (P`# =!@-5'24$%C 4 M!@@K!@$%!0<#! 8(*P8!!04'`P(P1 at 8#51T@!#\P/3 [!@PK!@$$`;(Q`0(! M`P4P*S I!@@K!@$%!0<"`18=:'1T<',Z+R]S96-UDE*'QH34=CM%+[K`1M] M]CL[U/FRY5[^LX>0V\F[3S&JAG>8?S4(\8%YC7"@FZN?&[XNG;*71FB1VC5\ M[C at 1T1/1VFB^.U_DY "31W;:;K"NZ]K)Q3#HO(@&45E,YCJ!NY$AC!C\IGQ: M2/NGP"_K'85*^(.K.&Q*INS)?2E26GN'Y^%BLAID at HA<[DL&']YY*Z 9#&;V MFJ3HYV^Y[HF)FFH-]D/]<5G):'.LJD*"]IJWI4,'-BQ;060E4[7[NKAN!^P\ MBTU&T;&8EQ; '\I'[_^.1-;+K'J.:_]/&2]A0 at L9SC^8NO*8S_4,>"4TRIOH MI'J>$[1$P4TQ@@0C,(($'P(!`3"!L3"!FS$+, D&`U4$!A,"1T(Q&S 9!@-5 M! @3$D=R96%T97(@36%N8VAE6%\[F,('$!@LJADB&]PT!"1 ""S&!M*"!L3"!FS$+, D&`U4$ M!A,"1T(Q&S 9!@-5! @3$D=R96%T97(@36%N8VAE/Y37SD?B^,\1 &P'4\!A-OA M(7N5JCZ<6F%Q*P'P7I!N*W5"=C4G7W@=<[VB&Z+HO9U?WP! \4\#+TESY)$P M%8>(K*914@>AZOD?I0K'P/&W-:( References: <1301517713.9695627.1470433906582.JavaMail.yahoo.ref@mail.yahoo.com> <1301517713.9695627.1470433906582.JavaMail.yahoo@mail.yahoo.com> Message-ID: OpenSSL 1.0.2h, Windows 7 x64, building Win32, using Visual Studio 2010 build environment. ? perl Configure VC-WIN32 no-asm no-hw no-symlinks no-srp no-camellia no-idea no-seed no-gost no-gmp no-krb5 no-mdc2 no-rc5 no-rfc3779 no-shared no-zlib no-zlib-dynamic no-comp no-md2 no-rc2 no-sslv2 no-dso -DOPENSSL_NO_HEARTBEATS -DPURIFY ? perl util\mkfiles.pl > MINFO perl util\mk1mf.pl no-asm VC-WIN32 > ms\nt.mak perl util\mk1mf.pl no-asm dll VC-WIN32 > ms\ntdll.mak ? perl util\mkdef.pl 32 libeay > ms\libeay32.def perl util\mkdef.pl 32 ssleay > ms\ssleay32.def ? Symbol ?SSL_COMP_get_compression_methods? is excluded from ssleay32.def file. ?Even though the function still exists when no-comp is used. ? Leading to failure loading tools and utilities which call this function, but can operate without compression. (like apache mod_ssl.so) Removing "COMP" from the prerequisites in util/ssleay.num did not result in mkddef.pl producing correct output, but it's unclear why. Manually adding "SSL_COMP_get_compression_methods @276" to ssleay32.def and relinking the DLL resolves the issue. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4640 Please log in as guest with password guest if prompted From rt at openssl.org Sun Aug 7 11:35:55 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Sun, 07 Aug 2016 11:35:55 +0000 Subject: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc In-Reply-To: <593784.48311.qm@web101204.mail.kks.yahoo.co.jp> References: <593784.48311.qm@web101204.mail.kks.yahoo.co.jp> Message-ID: Hello, make test stops on Solaris10 x64. % ./Configure solaris64-x86_64-gcc % make % make test ?? : ../test/recipes/01-test_abort.t ............ ok?? ../test/recipes/01-test_sanity.t ........... ok?? ../test/recipes/01-test_symbol_presence.t .. ok?? ../test/recipes/02-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_fuzz.t ............. ok???? ../test/recipes/05-test_hmac.t ............. Tested with gcc-5.4.0. % ./Configure solaris-x86-gcc % make % make test passed. Regards, --- Kiyoshi -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 Please log in as guest with password guest if prompted From bhat.jayalakshmi at gmail.com Mon Aug 8 03:59:17 2016 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Mon, 8 Aug 2016 09:29:17 +0530 Subject: [openssl-dev] Certificates generated using 3k/4k CSR generated with OpenSSL fails on Windows 2008R2 Message-ID: Hi All, I am generating 1k/2k/3k/4k CSR's on our device using OpenSSL library. I am generating these CSR on our device. We have windows 2008 R2 servers and I am signing these CSR using certificate authority on windows server. I am setting only client and server authentication bits in the CSR since these are simple end entity certificates. Once certificates are generated , I am able to install the certificates on our device. These certificates are working well with 802.1x (EAP-TLS) setup on the same windows 2008 R2 server. However when I was trying to test IPsec with certificate based authentication, authentication is failing.Enabling the IPsec event viewer shows error in accepting the certificate and generates a ?invalid signature? message which looks to be generic. Failures are seen only with 3k and 4k certificates. Later I refered to a link http://blog.gentilkiwi.com/tag/bag-attributes added -LMK -CSP "xxx" -name options, certificate worked well. I wanted to know is any one having similar experience with 3k and 4k ID certificates that does not have these fields on windows system. Any help is appreciated. Regards Jayalakshmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Aug 8 08:33:34 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Mon, 08 Aug 2016 08:33:34 +0000 Subject: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc In-Reply-To: <838859.23452.qm@web101209.mail.kks.yahoo.co.jp> References: <838859.23452.qm@web101209.mail.kks.yahoo.co.jp> Message-ID: Hello, % ./Configure solaris-x86-cc % make ?? : Undefined?????????????????????? first referenced ?symbol???????????????????????????? in file __atomic_add_fetch????????????????? ./libcrypto.so ld: fatal: symbol referencing errors. No output written to fuzz/asn1parse-test % ./Configure solaris64-x86_64-cc % make has the same error. Tested on Solaris10 x86/64, with Solaris developerstudio12.5. This is caused because __ATOMIC_RELAXED is #defined as 0 in /opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h Sample patch: --- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c +++ ./crypto/threads_pthread.c @@ -109,7 +109,7 @@ ? ?int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK *lock) ?{ -#ifdef __ATOMIC_RELAXED +#if??? __ATOMIC_RELAXED ???? *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED); ?#else ???? if (!CRYPTO_THREAD_write_lock(lock)) With this patch, % ./Configure solaris-x86-cc % make % make test passes. % ./Configure solaris64-x86_64-cc % make passes but % make test stops. This is another problem, which seems to be the same as bug #4641. Regards, --- Kiyoshi -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 Please log in as guest with password guest if prompted From steve at openssl.org Mon Aug 8 13:29:25 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 8 Aug 2016 13:29:25 +0000 Subject: [openssl-dev] [openssl-users] PKCS7_sign conflict with PKCS7_decrypt? In-Reply-To: <00a001d1ee97$e05e8be0$a11ba3a0$@carroll.com> References: <008401d1e749$8d021d90$a70658b0$@carroll.com> <20160726152144.GA6638@openssl.org> <00a201d1e752$67c23390$37469ab0$@carroll.com> <20160726160653.GA7351@openssl.org> <00d701d1e767$af695a60$0e3c0f20$@carroll.com> <20160726192443.GA10941@openssl.org> <00a001d1ee97$e05e8be0$a11ba3a0$@carroll.com> Message-ID: <20160808132925.GA27865@openssl.org> On Thu, Aug 04, 2016, Jim Carroll wrote: > I had heard a patch was being worked on, but I do not believe it has been > released (or if it is -- I can't find it). > > I can confirm that "OpenSSL 1.1.0-pre7-dev" still has the bug which > prevents PKCS7 sign-->encrypt->decrypt from working. > This should'v e been fixed by commit abdb460d8abe68fedcf00 though some issues remain which are currently being looked into. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Mon Aug 8 13:52:12 2016 From: rt at openssl.org (=?UTF-8?B?U2Now7xsbGVyIEZlbGl4?= via RT) Date: Mon, 08 Aug 2016 13:52:12 +0000 Subject: [openssl-dev] [openssl.org #4643] [patch] pass EVP_MD to engines verifyctx_init and signctx_init In-Reply-To: <9A2D7FB40390D144BE9C16563F849C86046EBB6F@AS000EX.ifd.infodas.de> References: <9A2D7FB40390D144BE9C16563F849C86046EBB6F@AS000EX.ifd.infodas.de> Message-ID: Hello, for some engine-implementations one needs the possibility to change the EVP_MD used in signctx_init and verifyctx_init. (because different EVP_MD are needed for standalone calculating of the digest and calculating the digest during signature-operations.) This is only possible if a pointer-pointer is passed through the calls. The attached patch (against 1.1.0-pre6) realises this. Kind regards Felix Sch?ller -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4643 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-1.1.0-pre6-adding_type_to_fooctx_init.patch Type: application/octet-stream Size: 7517 bytes Desc: not available URL: From rt at openssl.org Mon Aug 8 14:42:54 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Mon, 08 Aug 2016 14:42:54 +0000 Subject: [openssl-dev] [openssl.org #4643] [patch] pass EVP_MD to engines verifyctx_init and signctx_init In-Reply-To: <9A2D7FB40390D144BE9C16563F849C86046EBB6F@AS000EX.ifd.infodas.de> References: <9A2D7FB40390D144BE9C16563F849C86046EBB6F@AS000EX.ifd.infodas.de> Message-ID: On Mon Aug 08 13:52:12 2016, F.Schueller at infodas.de wrote: > Hello, > > for some engine-implementations one needs the possibility to change > the EVP_MD used in signctx_init and verifyctx_init. > (because different EVP_MD are needed for standalone calculating of the > digest and calculating the digest during signature-operations.) > This is only possible if a pointer-pointer is passed through the > calls. The attached patch (against 1.1.0-pre6) realises this. > This shouldn't be necessary becasuse the underlying method gets notified through EVP_PKEY_CTX_set_signature_md() which it can then check and take appropriate action. If the method wants to change the MD it can set the EVP_PKEY_FLAG_SIGCTX_CUSTOM flag and then use whatever EVP_MD is appropriate instead of the passed one. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4643 Please log in as guest with password guest if prompted From hecht at hlrs.de Mon Aug 8 15:38:17 2016 From: hecht at hlrs.de (Martin Hecht) Date: Mon, 8 Aug 2016 17:38:17 +0200 Subject: [openssl-dev] [openssl-announce] OpenSSL version 1.1.0 pre release 6 published In-Reply-To: <20160804142655.GA19332@openssl.org> References: <20160804142655.GA19332@openssl.org> Message-ID: <34942d37-09bd-26f6-15c0-be5bcfca3eeb@hlrs.de> Hi, ./config make make test On my Ubuntu 14.04.5 LTS all tests pass. On Scientific Linux release 6.8 (Carbon) I have to update a couple of perl modules to get the test suite running (see NOTES.PERL and https://mta.openssl.org/pipermail/openssl-dev/2016-April/006538.html). On our SUSE Linux Enterprise Server 11 SP3 (x86_64) I have to update the perl modules, too, and in addition I get: ... # Failed test 'running threadstest' ../test/recipes/90-test_threads............NOK 1/1# at ../test/testlib/OpenSSL/Test/Simple.pm line 77. # Looks like you failed 1 test of 1. ../test/recipes/90-test_threads............dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/1 tests, 0.00% okay ../test/recipes/90-test_v3name.............ok Failed Test Stat Wstat Total Fail List of Failed ------------------------------------------------------------------------------- ../test/recipes/90-test_threads.t 1 256 1 1 1 4 tests and 12 subtests skipped. Failed 1/81 test scripts. 1/445 subtests failed. Files=81, Tests=445, 51 wallclock secs (29.93 cusr + 5.10 csys = 35.03 CPU) Failed 1/81 test programs. 1/445 subtests failed. make[1]: *** [_tests] Error 255 make[1]: Leaving directory `/home/.../tmp/openssl-1.1.0-pre6' make: *** [tests] Error 2 running that one again in verbose mode make VERBOSE=1 TESTS='test_threads' test make depend && make _tests make[1]: Entering directory `/home/.../tmp/openssl-1.1.0-pre6' make[1]: Leaving directory `/home/.../tmp/openssl-1.1.0-pre6' make[1]: Entering directory `/home/.../tmp/openssl-1.1.0-pre6' ( cd test; \ SRCTOP=../. \ BLDTOP=../. \ PERL="/usr/bin/perl" \ EXE_EXT= \ OPENSSL_ENGINES=.././engines \ /usr/bin/perl .././test/run_tests.pl test_threads ) ../test/recipes/90-test_threads....1..1 thread-local thread callback failed ../util/shlib_wrap.sh ./threadstest => 1 # Failed test 'running threadstest' not ok 1 - running threadstest # at ../test/testlib/OpenSSL/Test/Simple.pm line 77. # Looks like you failed 1 test of 1. dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/1 tests, 0.00% okay Failed Test Stat Wstat Total Fail List of Failed ------------------------------------------------------------------------------- ../test/recipes/90-test_threads.t 1 256 1 1 1 Failed 1/1 test scripts. 1/1 subtests failed. Files=1, Tests=1, 0 wallclock secs ( 0.03 cusr + 0.01 csys = 0.04 CPU) Failed 1/1 test programs. 1/1 subtests failed. make[1]: *** [_tests] Error 1 make[1]: Leaving directory `/home/.../tmp/openssl-1.1.0-pre6' make: *** [tests] Error 2 first I thought it might be the perl installation which wouldn't support threads, but building a locally installed perl-5.24.0 explicitly with threads support ddin't solve the problem (I have checked that this perl is actually used): make VERBOSE=1 TESTS='test_threads' test make depend && make _tests make[1]: Entering directory `/home/.../tmp/openssl-1.1.0-pre6' make[1]: Leaving directory `/home/.../tmp/openssl-1.1.0-pre6' make[1]: Entering directory `/home/.../tmp/openssl-1.1.0-pre6' ( cd test; \ SRCTOP=../. \ BLDTOP=../. \ PERL="/home/.../local/bin/perl" \ EXE_EXT= \ OPENSSL_ENGINES=.././engines \ /home/.../local/bin/perl .././test/run_tests.pl test_threads ) ../test/recipes/90-test_threads.t .. 1..1 thread-local thread callback failed ../util/shlib_wrap.sh ./threadstest => 1 not ok 1 - running threadstest # Failed test 'running threadstest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 77. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests Test Summary Report ------------------- ../test/recipes/90-test_threads.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.06 cusr 0.01 csys = 0.10 CPU) Result: FAIL Failed 1/1 test programs. 1/1 subtests failed. make[1]: *** [_tests] Error 1 make[1]: Leaving directory `/home/.../tmp/openssl-1.1.0-pre6' make: *** [tests] Error 2 I'm not sure if this is a problem with openssl or with my environment. I _believe_ that I have tested successfully with openssl-SNAP-20160331 but I'm not 100% sure, and now I get the same result with that tar-ball. So, either I forgot to re-test on SLES back in April or it is a change which happened to our environment in the meantime. Anything more I could try to locate the cause of this issue? Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: S/MIME Cryptographic Signature URL: From openssl-dev at ml.breakpoint.cc Mon Aug 8 18:57:26 2016 From: openssl-dev at ml.breakpoint.cc (Sebastian Andrzej Siewior) Date: Mon, 8 Aug 2016 20:57:26 +0200 Subject: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation Message-ID: <20160808185726.d2yz6midc32hka3r@breakpoint.cc> From: Sebastian Andrzej Siewior If the client performs repeatedly a SSL handshakes (via SSL_renegotiate()) then the server will use much more resources than the client does. I managed to get 30% load on the server and 7% on the client side. This is a computation attack and unfortunately the way a SSL handshake works. I understand that this `feature' is part of the TLS specification and I am not trying to nuke from openssl. Instead I would like to describe the possible attack and some countermeasures to mitigate its outcome. Having it in the doc section would allow one to ping other projects, point them to this section and ask them if they could drop the support for re-negotiation request from the client. From looking around, nginx for instance does not support renegotiation from client's side. Signed-off-by: Sebastian Andrzej Siewior --- doc/ssl/SSL_CTX_set_options.pod | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/doc/ssl/SSL_CTX_set_options.pod b/doc/ssl/SSL_CTX_set_options.pod index 635b470e1245..137035c7f6f0 100644 --- a/doc/ssl/SSL_CTX_set_options.pod +++ b/doc/ssl/SSL_CTX_set_options.pod @@ -255,6 +255,23 @@ renegotiation between OpenSSL clients and unpatched servers B, while B allows initial connections and renegotiation between OpenSSL and unpatched clients or servers. +=head2 Possible attack through renegotiation + +The renegotiation performs a new handshake. A handshake is more expensive on +the server side than on the client side. It is possible that a client with +little bandwidth and with only a few connections to the server will put the +server in a position where it will use 100% of its CPU if the client repeatedly +attempts to renegotiate and therefore constantly performs a new handshake. +Therefore it is recommended not to renegotiate the handshake if the client +requested it but only do it on the server side. + +If the server drops the connections once the client tries to abuse via a +renegotiation attempt then the attack is not yet fully mitigated. The client +can still open multiple connections only for the purpose to perform a handshake +and close it immediately. This is similar to the initial scenario. It is +recommended to track frequent connects at firewall level and reject abusive +connections attemps before the handshake is performed. + =head1 RETURN VALUES SSL_CTX_set_options() and SSL_set_options() return the new options bitmask -- 2.8.1 From openssl-users at dukhovni.org Mon Aug 8 20:16:58 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 8 Aug 2016 20:16:58 +0000 Subject: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation In-Reply-To: <20160808185726.d2yz6midc32hka3r@breakpoint.cc> References: <20160808185726.d2yz6midc32hka3r@breakpoint.cc> Message-ID: <20160808201657.GP4670@mournblade.imrryr.org> On Mon, Aug 08, 2016 at 08:57:26PM +0200, Sebastian Andrzej Siewior wrote: > This is a computation attack and unfortunately the way a SSL handshake > works. I understand that this `feature' is part of the TLS specification > and I am not trying to nuke from openssl. Instead I would like to > describe the possible attack and some countermeasures to mitigate its > outcome. Having it in the doc section would allow one to ping other > projects, point them to this section and ask them if they could drop the > support for re-negotiation request from the client. From looking around, > nginx for instance does not support renegotiation from client's side. Postfix supports rate limiting new session creation: http://www.postfix.org/postconf.5.html#smtpd_client_new_tls_session_rate_limit Other servers can implement similar resource limits as appropriate. -- Viktor. From jonetsu at teksavvy.com Mon Aug 8 20:16:44 2016 From: jonetsu at teksavvy.com (jonetsu) Date: Mon, 8 Aug 2016 13:16:44 -0700 (MST) Subject: [openssl-dev] FIPS mode: how is the code put together ? Message-ID: <1470687404870-67764.post@n7.nabble.com> Hello, When using the FIPS module (version 2.0.9 if it matters, with OpenSSL 1.0.1e) the source code of both the regular openssl and the openssl-fips have a certain number of files named the same. For instance, crypto/bn/bn_rand.c. The FIPS version of this file has an additional check for FIPS_module_mode() and an OPENSSL_FIPSAPI defined. When compiling openssl-fips and then openssl, with the proper options, we could presume that the binary representation of bn_rand.c as found in opnssl-fips will be used. Is that so ? How is this solved at compile time ? Thanks. -- View this message in context: http://openssl.6102.n7.nabble.com/FIPS-mode-how-is-the-code-put-together-tp67764.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. From vishnu.utdcomets at outlook.com Mon Aug 8 23:12:25 2016 From: vishnu.utdcomets at outlook.com (vishnuvaradhan lakshminrarayanan) Date: Mon, 8 Aug 2016 23:12:25 +0000 Subject: [openssl-dev] openssl secure https server code examples Message-ID: Hi, Im trying to build a simple secure ssl server using openssl. Im looking for code examples in c++ to accomplish this. Im new to openssl and this would be of great help. I tried the openssl minimal server example in openssl wiki but it doesnt work. The server should accept a certificate chain, which is signed by another root CA cert. Can someone please help. thanks vishnu -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Aug 9 01:45:24 2016 From: rt at openssl.org (William M Edmonds via RT) Date: Tue, 09 Aug 2016 01:45:24 +0000 Subject: [openssl-dev] [openssl.org #4644] bug: cert verification always examining entire chain In-Reply-To: References: Message-ID: If I specify a CAfile that includes the leaf certificate and/or intermediate CA certificates, but not the root certificate, then verification fails. This doesn't seem at all right. I need to be able to trust a lower layer of the certificate hierarchy without trusting everything from the root CA down, and I can't see any security vulnerability in doing so. It also seems inefficient for OpenSSL to continue checking higher levels of the chain once it has verified that a lower level is trusted. # openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 # cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.2 (Maipo) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4644 Please log in as guest with password guest if prompted From rt at openssl.org Tue Aug 9 01:47:45 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 09 Aug 2016 01:47:45 +0000 Subject: [openssl-dev] [openssl.org #4644] bug: cert verification always examining entire chain In-Reply-To: References: Message-ID: You have to create a trust store with the CA's that you trust. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4644 Please log in as guest with password guest if prompted From openssl-users at dukhovni.org Tue Aug 9 02:08:37 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 9 Aug 2016 02:08:37 +0000 Subject: [openssl-dev] [openssl.org #4644] bug: cert verification always examining entire chain In-Reply-To: References: Message-ID: <20160809020837.GQ4670@mournblade.imrryr.org> On Tue, Aug 09, 2016 at 01:45:24AM +0000, William M Edmonds via RT wrote: > If I specify a CAfile that includes the leaf certificate and/or > intermediate CA certificates, but not the root certificate, then > verification fails. As expected, unless you use the "-partial" flag in the command-line utilities, or use the X509_VERIFY_PARAM_set_flags() to set the X509_V_FLAG_PARTIAL_CHAIN flag when using the API. This ticket should be closed. -- Viktor. From rt at openssl.org Tue Aug 9 02:10:02 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 09 Aug 2016 02:10:02 +0000 Subject: [openssl-dev] [openssl.org #4644] bug: cert verification always examining entire chain In-Reply-To: References: Message-ID: as Viktor pointed out, working as designed. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4644 Please log in as guest with password guest if prompted From neutrino.network1 at gmail.com Tue Aug 9 03:56:42 2016 From: neutrino.network1 at gmail.com (neutrino network) Date: Tue, 9 Aug 2016 08:56:42 +0500 Subject: [openssl-dev] OPENSSL provided by Cavium Message-ID: Hi, Cavium provides a configured OPENSSL for better performance on their hardware. It usage must lowers the CPU utilization by crypto operations offloading. I wanted to ask whether we can install Cavium OPENSSL Toolkit on Linux OS (on Cavium hardware), just as we install a standard OPENSSL? OR the only way to use this Cavium OPENSSL is by making simple executive application/user space and use the provided OPENSSL as an API. Please guide and share any details (readme, tutorial, link etc) regarding Cavium OPENSSL. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From balajimarisetti at gmail.com Tue Aug 9 06:34:48 2016 From: balajimarisetti at gmail.com (balaji marisetti) Date: Tue, 9 Aug 2016 12:04:48 +0530 Subject: [openssl-dev] OPENSSL provided by Cavium In-Reply-To: References: Message-ID: I think this question is better directed at Cavium support centre. >I wanted to ask whether we can install Cavium OPENSSL Toolkit on >Linux OS (on Cavium hardware), just as we install a standard OPENSSL? Yes. You can install it as normal OpenSSL on Linux OS and all your applications should work fine. On Tue, Aug 9, 2016 at 9:26 AM, neutrino network wrote: > Hi, > > Cavium provides a configured OPENSSL for better performance on their > hardware. It usage must lowers the CPU utilization by crypto operations > offloading. I wanted to ask whether we can install Cavium OPENSSL Toolkit on > Linux OS (on Cavium hardware), just as we install a standard OPENSSL? OR the > only way to use this Cavium OPENSSL is by making simple executive > application/user space and use the provided OPENSSL as an API. > > Please guide and share any details (readme, tutorial, link etc) regarding > Cavium OPENSSL. > > > Regards > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- :-)balaji From dwmw2 at infradead.org Tue Aug 9 09:53:59 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 09 Aug 2016 10:53:59 +0100 Subject: [openssl-dev] [openssl.org #4644] bug: cert verification always examining entire chain In-Reply-To: <20160809020837.GQ4670@mournblade.imrryr.org> References: <20160809020837.GQ4670@mournblade.imrryr.org> Message-ID: <1470736439.61594.38.camel@infradead.org> On Tue, 2016-08-09 at 02:08 +0000, Viktor Dukhovni wrote: > On Tue, Aug 09, 2016 at 01:45:24AM +0000, William M Edmonds via RT wrote: > > > > > If I specify a CAfile that includes the leaf certificate and/or > > intermediate CA certificates, but not the root certificate, then > > verification fails. > > As expected, unless you use the "-partial" flag in the command-line > utilities, or use the X509_VERIFY_PARAM_set_flags() to set the > X509_V_FLAG_PARTIAL_CHAIN flag when using the API. Is there an equivalent for 1.0.1? -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From rsalz at akamai.com Tue Aug 9 12:09:15 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 9 Aug 2016 12:09:15 +0000 Subject: [openssl-dev] [openssl-users] OPENSSL provided by Cavium In-Reply-To: References: Message-ID: <2b647945e8cb4b07b1d96edac7cd3422@usma1ex-dag1mb1.msg.corp.akamai.com> Ask Cavium. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From: neutrino network [mailto:neutrino.network1 at gmail.com] Sent: Monday, August 08, 2016 11:57 PM To: openssl-users at openssl.org; openssl-dev at openssl.org Subject: [openssl-users] OPENSSL provided by Cavium Hi, Cavium provides a configured OPENSSL for better performance on their hardware. It usage must lowers the CPU utilization by crypto operations offloading. I wanted to ask whether we can install Cavium OPENSSL Toolkit on Linux OS (on Cavium hardware), just as we install a standard OPENSSL? OR the only way to use this Cavium OPENSSL is by making simple executive application/user space and use the provided OPENSSL as an API. Please guide and share any details (readme, tutorial, link etc) regarding Cavium OPENSSL. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Aug 9 15:15:54 2016 From: rt at openssl.org (=?UTF-8?B?U2Now7xsbGVyIEZlbGl4?= via RT) Date: Tue, 09 Aug 2016 15:15:54 +0000 Subject: [openssl-dev] [openssl.org #4643] [patch] pass EVP_MD to engines verifyctx_init and signctx_init In-Reply-To: <9A2D7FB40390D144BE9C16563F849C8604733A41@AS000EX.ifd.infodas.de> References: <9A2D7FB40390D144BE9C16563F849C86046EBB6F@AS000EX.ifd.infodas.de> <9A2D7FB40390D144BE9C16563F849C8604733A41@AS000EX.ifd.infodas.de> Message-ID: On Mon Aug 08 13:52:12 2016, Stephen Henson wrote: >> for some engine-implementations one needs the possibility to change >> the EVP_MD used in signctx_init and verifyctx_init. >> (because different EVP_MD are needed for standalone calculating of the >> digest and calculating the digest during signature-operations.) This >> is only possible if a pointer-pointer is passed through the calls. The >> attached patch (against 1.1.0-pre6) realises this. >This shouldn't be necessary becasuse the underlying method gets notified through EVP_PKEY_CTX_set_signature_md() which it can then check >and take appropriate action. Ok, I didn?t see this way (maybe because my first solution was to use ENGINE_set_digest() which didn?t work in my case) but it works. Thanks for the quick hint and please ignore the patch. >If the method wants to change the MD it can set the EVP_PKEY_FLAG_SIGCTX_CUSTOM flag and then use whatever EVP_MD is appropriate >instead of the passed one. JFTR: Actually the trick is not to use any EVP_MD later, but use EVP_MD_CTX_set_update(). Kind regards Felix Sch?ller -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4643 Please log in as guest with password guest if prompted From rt at openssl.org Tue Aug 9 15:18:57 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 09 Aug 2016 15:18:57 +0000 Subject: [openssl-dev] [openssl.org #4643] [patch] pass EVP_MD to engines verifyctx_init and signctx_init In-Reply-To: <9A2D7FB40390D144BE9C16563F849C86046EBB6F@AS000EX.ifd.infodas.de> References: <9A2D7FB40390D144BE9C16563F849C86046EBB6F@AS000EX.ifd.infodas.de> Message-ID: Closing per original poster. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4643 Please log in as guest with password guest if prompted From openssl-users at dukhovni.org Tue Aug 9 15:28:20 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 9 Aug 2016 15:28:20 +0000 Subject: [openssl-dev] [openssl.org #4644] bug: cert verification always examining entire chain In-Reply-To: <1470736439.61594.38.camel@infradead.org> References: <20160809020837.GQ4670@mournblade.imrryr.org> <1470736439.61594.38.camel@infradead.org> Message-ID: <20160809152820.GT4670@mournblade.imrryr.org> On Tue, Aug 09, 2016 at 10:53:59AM +0100, David Woodhouse wrote: > > As expected, unless you use the "-partial" flag in the command-line > > utilities, or use the X509_VERIFY_PARAM_set_flags() to set the > > X509_V_FLAG_PARTIAL_CHAIN flag when using the API. > > Is there an equivalent for 1.0.1? None that I'm aware of, partial chain support was added in 1.0.2. -- Viktor. From rt at openssl.org Tue Aug 9 18:10:22 2016 From: rt at openssl.org (William M Edmonds via RT) Date: Tue, 09 Aug 2016 18:10:22 +0000 Subject: [openssl-dev] [openssl.org #4644] bug: cert verification always examining entire chain In-Reply-To: References: Message-ID: Why do you have to trust root CAs? Why can't you trust at a lower level, e.g. an intermediate CA or even a leaf certificate that is not a CA at all? Allowing this should inject no security issue and in fact enhance security by allowing you to be more restrictive in what you are willing to trust. W. Matthew Edmonds IBM Systems & Technology Group Email: edmondsw at us.ibm.com Phone: (919) 543-7538 / Tie-Line: 441-7538 From: Rich Salz via RT To: William M Edmonds/Raleigh/IBM at IBMUS Cc: openssl-dev at openssl.org Date: 08/08/2016 09:47 PM Subject: [openssl.org #4644] bug: cert verification always examining entire chain You have to create a trust store with the CA's that you trust. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4644 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4644 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From rt at openssl.org Tue Aug 9 18:52:27 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 09 Aug 2016 18:52:27 +0000 Subject: [openssl-dev] [openssl.org #4644] bug: cert verification always examining entire chain In-Reply-To: References: Message-ID: > Why do you have to trust root CAs? Why can't you trust at a lower level, e.g. > an intermediate CA or even a leaf certificate that is not a CA at all? I said CA's, not root CA's. As Viktor pointed out, this doesn't work in 1.0.1 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4644 Please log in as guest with password guest if prompted From openssl-users at dukhovni.org Tue Aug 9 19:18:00 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 9 Aug 2016 15:18:00 -0400 Subject: [openssl-dev] [openssl.org #4644] bug: cert verification always examining entire chain In-Reply-To: References: Message-ID: <0DDBD02A-49F1-4CEF-891E-76850D4ECE5D@dukhovni.org> > On Aug 9, 2016, at 2:52 PM, Salz, Rich via RT wrote: > > As Viktor pointed out, this doesn't work in 1.0.1 The story is a bit more complicated. What's really going on is that root (self-signed) CAs in the trust store are backwards-compatible implicit trust-anchors for all purposes. Intermediate certificates require auxiliary trust settings in the trust store to specify any purposes for which they are trusted or rejected as trust-anchors. Trusted certificates can be created via the "-addtrust" option of "openssl x509". I've not checked 1.0.1, but explicitly trusted intermediates are likely to work with 1.0.1 if decorated as trusted via: openssl x509 -in cert.pem -trustout -addtrust serverAuth -out trusted.pem or: openssl x509 -in cert.pem -trustout -addtrust anyExtendedKeyUsage -out trusted.pem or similar. -- Viktor. From rt at openssl.org Tue Aug 9 19:18:09 2016 From: rt at openssl.org (Viktor Dukhovni via RT) Date: Tue, 09 Aug 2016 19:18:09 +0000 Subject: [openssl-dev] [openssl.org #4644] bug: cert verification always examining entire chain In-Reply-To: <0DDBD02A-49F1-4CEF-891E-76850D4ECE5D@dukhovni.org> References: <0DDBD02A-49F1-4CEF-891E-76850D4ECE5D@dukhovni.org> Message-ID: > On Aug 9, 2016, at 2:52 PM, Salz, Rich via RT wrote: > > As Viktor pointed out, this doesn't work in 1.0.1 The story is a bit more complicated. What's really going on is that root (self-signed) CAs in the trust store are backwards-compatible implicit trust-anchors for all purposes. Intermediate certificates require auxiliary trust settings in the trust store to specify any purposes for which they are trusted or rejected as trust-anchors. Trusted certificates can be created via the "-addtrust" option of "openssl x509". I've not checked 1.0.1, but explicitly trusted intermediates are likely to work with 1.0.1 if decorated as trusted via: openssl x509 -in cert.pem -trustout -addtrust serverAuth -out trusted.pem or: openssl x509 -in cert.pem -trustout -addtrust anyExtendedKeyUsage -out trusted.pem or similar. -- Viktor. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4644 Please log in as guest with password guest if prompted From openssl-dev at ml.breakpoint.cc Tue Aug 9 19:18:58 2016 From: openssl-dev at ml.breakpoint.cc (Sebastian Andrzej Siewior) Date: Tue, 9 Aug 2016 21:18:58 +0200 Subject: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation In-Reply-To: <20160808201657.GP4670@mournblade.imrryr.org> References: <20160808185726.d2yz6midc32hka3r@breakpoint.cc> <20160808201657.GP4670@mournblade.imrryr.org> Message-ID: <20160809191857.zcz5tfld4y2ljqru@breakpoint.cc> On 2016-08-08 20:16:58 [+0000], Viktor Dukhovni wrote: > On Mon, Aug 08, 2016 at 08:57:26PM +0200, Sebastian Andrzej Siewior wrote: > > support for re-negotiation request from the client. From looking around, > > nginx for instance does not support renegotiation from client's side. > > Postfix supports rate limiting new session creation: > > http://www.postfix.org/postconf.5.html#smtpd_client_new_tls_session_rate_limit > > Other servers can implement similar resource limits as appropriate. I don't really know what I am supposed to do with this information. Do you want me to add this as an example into the doc patch or do you simply point out that others already took precautions? Sebastian From openssl-users at dukhovni.org Tue Aug 9 19:26:44 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 9 Aug 2016 19:26:44 +0000 Subject: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation In-Reply-To: <20160809191857.zcz5tfld4y2ljqru@breakpoint.cc> References: <20160808185726.d2yz6midc32hka3r@breakpoint.cc> <20160808201657.GP4670@mournblade.imrryr.org> <20160809191857.zcz5tfld4y2ljqru@breakpoint.cc> Message-ID: <20160809192644.GU4670@mournblade.imrryr.org> On Tue, Aug 09, 2016 at 09:18:58PM +0200, Sebastian Andrzej Siewior wrote: > > Postfix supports rate limiting new session creation: > > > > http://www.postfix.org/postconf.5.html#smtpd_client_new_tls_session_rate_limit > > > > Other servers can implement similar resource limits as appropriate. > > I don't really know what I am supposed to do with this information. Do > you want me to add this as an example into the doc patch or do you > simply point out that others already took precautions? CPU exhaustion attacks on servers are a fundamental feature of TLS. I am not sure that OpenSSL needs to say anything about this. Server applications that want to protect against inadvertent DoS by buggy clients can implement the obvious counter-measure (rate limit handshakes with clients that generate too many new sessions per sample interval). If you feel that this is not obvious, and others agree, feel free to propose some text. Note, that deliberate DoS and especially DDoS will overcome even rate limits, by attacking from multiple clients, or just flooding the target network. So this can only protect against accidents, not malice by capable adversaries. -- Viktor. From openssl-dev at ml.breakpoint.cc Tue Aug 9 19:51:32 2016 From: openssl-dev at ml.breakpoint.cc (Sebastian Andrzej Siewior) Date: Tue, 9 Aug 2016 21:51:32 +0200 Subject: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation In-Reply-To: <20160809192644.GU4670@mournblade.imrryr.org> References: <20160808185726.d2yz6midc32hka3r@breakpoint.cc> <20160808201657.GP4670@mournblade.imrryr.org> <20160809191857.zcz5tfld4y2ljqru@breakpoint.cc> <20160809192644.GU4670@mournblade.imrryr.org> Message-ID: <20160809195132.ibiqkq247obbq6es@breakpoint.cc> On 2016-08-09 19:26:44 [+0000], Viktor Dukhovni wrote: > On Tue, Aug 09, 2016 at 09:18:58PM +0200, Sebastian Andrzej Siewior wrote: > > I don't really know what I am supposed to do with this information. Do > > you want me to add this as an example into the doc patch or do you > > simply point out that others already took precautions? > > CPU exhaustion attacks on servers are a fundamental feature of TLS. I mentioned this. > I am not sure that OpenSSL needs to say anything about this. Server > applications that want to protect against inadvertent DoS by buggy > clients can implement the obvious counter-measure (rate limit > handshakes with clients that generate too many new sessions per > sample interval). If you feel that this is not obvious, and others > agree, feel free to propose some text. I tried. There was some text in the patch. > Note, that deliberate DoS and especially DDoS will overcome even > rate limits, by attacking from multiple clients, or just flooding > the target network. So this can only protect against accidents, > not malice by capable adversaries. I don't claim the opposite. I came across server software which supports client side renegotiation and I don't think that this is required and would like to patch it out. So far, so good? And then there is the "same" thing if the attacker starts multiple connections the sake of a handshake. So I though to point this out as well. And then I though it would be nice to document this within the openssl documentation so I could just point there and make them aware. Sebastian From jim at carroll.com Tue Aug 9 21:06:16 2016 From: jim at carroll.com (Jim C.) Date: Tue, 9 Aug 2016 17:06:16 -0400 Subject: [openssl-dev] [openssl-users] PKCS7_sign conflict with PKCS7_decrypt? In-Reply-To: <20160808132925.GA27865@openssl.org> References: <008401d1e749$8d021d90$a70658b0$@carroll.com> <20160726152144.GA6638@openssl.org> <00a201d1e752$67c23390$37469ab0$@carroll.com> <20160726160653.GA7351@openssl.org> <00d701d1e767$af695a60$0e3c0f20$@carroll.com> <20160726192443.GA10941@openssl.org> <00a001d1ee97$e05e8be0$a11ba3a0$@carroll.com> <20160808132925.GA27865@openssl.org> Message-ID: <2405601d1f281$df0b55a0$9d2200e0$@carroll.com> I can confirm -- commit abdb460d8abe68fedcf00 solves the problem we were seeing. > -----Original Message----- > From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of > Dr. Stephen Henson > Sent: Monday, August 08, 2016 9:29 AM > To: openssl-dev at openssl.org > Subject: Re: [openssl-dev] [openssl-users] PKCS7_sign conflict with > PKCS7_decrypt? > > On Thu, Aug 04, 2016, Jim Carroll wrote: > > > I had heard a patch was being worked on, but I do not believe it has > been > > released (or if it is -- I can't find it). > > > > I can confirm that "OpenSSL 1.1.0-pre7-dev" still has the bug which > > prevents PKCS7 sign-->encrypt->decrypt from working. > > > > This should'v e been fixed by commit abdb460d8abe68fedcf00 though some > issues remain which are currently being looked into. > > 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 begin 666 smime.p7s M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$' M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D& M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14 M'1E%PTP,# U,S Q,#0X,SA:%PTR,# U,S Q,#0X M,SA:,&\Q"S )!@-5! 83`E-%,10P$@8#500*$PM!9&14=,K(D%3IQE\/>)V:0#P.K&&J7A2/GH>A:E#&`JCIJ&DF&)"K3+!/(ZLZ3X38W\Z?X6EON]="UVM$Y,>M[FU! M7W):<0 at WLWEEI%F at E#?W`"\-PI)RVM X DRU0:, L& M`U4=#P0$`P(!!C /!@-5'1,!`?\$!3 #`0'_,(&9!@-5'2,$@9$P at 8Z %*V] MF'HTM";W^L0F5.\#O> DRU0:H7.D<3!O,0LP"08#500&$P)313$4,!(&`U4$ M"A,+061D5')U8'9 M'EL4!R,V98^PV'>[K$%L1V"#4;#Y,CWG_/8F$\> %J6_6OR'SWAYB2&:XDP' M"H8UO/+>4<32EK?L,`E$4+8Z]%N#!WT9UYR2M[/1"M(63:[H<4KPC:^$PWFO6-^>7NG"0U JVK=CXK#]O:, M&D(%4=1%]9^G8B%H%2!#/)GG?+TDV*F1%W.(/U8;,3 at 8M'$/FLW(#IZ.+AOA MC)B#RQ\Q\41,Q at 1S279@#\?XO1> :R[IS$P.6IIY#R *+M6>8R8>59*4V((7 M6GO0O,>/3H8$,(($KS""`Y>@`P(!`@(1`. CRQ42 at U.)K6%N>E1G:R$P#08) M*H9(AO<-`0$+!0`P;S$+, D&`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T M($%",28P) 8#500+$QU!9&14'1E%PTQ-#$R,C(P M,# P,#!:%PTR,# U,S Q,#0X,SA:,(&;,0LP"08#500&$P)'0C$;,!D&`U4$ M"!,21W)E871EE,93G!2';Q6 MI at 8FM[A)X);G4:OQ\%H3216CM(P;8+QZ44*G>8RD(M\784Z1U78C"A332@)_ MMAT)@&ZE!#W9NKL6_J&'J2Y#4D,6?*\R4,BF3UKI"-C/DR6<>XCH,&3FI/A6 M@/TJ)!0S%YFL1.5IBZ-&!DO",]3I0)\&L+&LDT"YM0B3.IPJ4Z,0VST at 83Q5 M`X[93G8E`B$I^J-\<79/[N%?@>G[5(#;PWLU4K>$WB(]+# M,7]9O5(WL#-I M+4/K^M:E\9=W9U&,V>XGZ[RE!SAVC*2I./_?C/4#K$F^RO=SF3H/,JNPP#@8#51T/`0'_! 0#`@&&,!(&`U4=$P$!_P0(, 8!`?\"`0`P'08# M51TE!!8P% 8(*P8!!04'`P(&""L&`04%!P,$,!$&`U4=( 0*, @P!@8$51T@ M`#!$!@-5'1\$/3 [,#F at -Z UAC-H='1P.B\O8W)L+G5S97)T'1EJSMCY=K5<^_LX/M[XJ/_\$(CG,JVC4T^Y$L8`[*H+=38 MNT)+D&F%$-NF-S3H>^ !$*6Y+,KF'$K8F0W!AN*0DOM:0FHC(1#I M913V2A :)OI\BON;,((% M(#""! B@`P(!`@(1`-4+#]T2278FC)\!=Y87SN8P#08)*H9(AO<-`0$+!0`P M at 9LQ"S )!@-5! 83`D=",1LP&08#500($Q)'%PTQ-C Q,3,P,# P,#!:%PTQ-S Q M,3(R,S4Y-3E:," Q'C HV/H^"EPS!W)_L#3<"[3T(BZ3LDTHN"#(\B5A1 M^VO2XN77=+Z\+IU=@1UR!40:,<7&)5,P,O1STRE:UFFYLS65=GVT*:ZY[YK9 M':(_+75)?UCOJQ: M-%=9XH<_VNPXG^;7/:6"2-DDFNH3JMIBVKH$1G/E$ 9 MD8XE<3>#8^@.89*P$#)O+'$"`P$``:."`=SB(9<*/G' MV*_ SS .!@-5'0\!`?\$! ,"!: P# 8#51T3`0'_! (P`# =!@-5'24$%C 4 M!@@K!@$%!0<#! 8(*P8!!04'`P(P1 at 8#51T@!#\P/3 [!@PK!@$$`;(Q`0(! M`P4P*S I!@@K!@$%!0<"`18=:'1T<',Z+R]S96-UDE*'QH34=CM%+[K`1M] M]CL[U/FRY5[^LX>0V\F[3S&JAG>8?S4(\8%YC7"@FZN?&[XNG;*71FB1VC5\ M[C at 1T1/1VFB^.U_DY "31W;:;K"NZ]K)Q3#HO(@&45E,YCJ!NY$AC!C\IGQ: M2/NGP"_K'85*^(.K.&Q*INS)?2E26GN'Y^%BLAID at HA<[DL&']YY*Z 9#&;V MFJ3HYV^Y[HF)FFH-]D/]<5G):'.LJD*"]IJWI4,'-BQ;060E4[7[NKAN!^P\ MBTU&T;&8EQ; '\I'[_^.1-;+K'J.:_]/&2]A0 at L9SC^8NO*8S_4,>"4TRIOH MI'J>$[1$P4TQ@@0C,(($'P(!`3"!L3"!FS$+, D&`U4$!A,"1T(Q&S 9!@-5 M! @3$D=R96%T97(@36%N8VAE6%\[F,('$!@LJADB&]PT!"1 ""S&!M*"!L3"!FS$+, D&`U4$ M!A,"1T(Q&S 9!@-5! @3$D=R96%T97(@36%N8VAEA5R;DQH%JQ.81$FMS6X$+"!RR^R?D=<:\(ZLE+_"Z]!.FW6J@") MT)&U-]+1W"A,&ZMT4DB]]JX,9N*'15;PDL5V%B/%YB-X]"D9 at S9_+;2D98BP M*>*GD];)\/>F'=7W]_IQL!'/N'MMH>S'ZKQ:V/^*#H^!GC?,8[J.1G MIN->V+@'@V-%/B_.;.STGAQX(>_33 J/6':. D`/=4#@*Q<..UCMG=37]4#/&_\0\&S)W"98A2,#QDD```````` ` end From michel.sales at free.fr Tue Aug 9 21:28:49 2016 From: michel.sales at free.fr (Michel) Date: Tue, 9 Aug 2016 23:28:49 +0200 Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check In-Reply-To: References: <57963956.2060809@mit.edu> Message-ID: <006801d1f285$06ac6ab0$14054010$@sales@free.fr> Hi, As I obviously needed to improve my test program, I am now encrypting and decrypting files trying all ciphers in all their available modes. ( ChaCha20, AES-128, AES-192, AES-256, Blowfish, Cast5, Camellia-128, Camellia-192, Camellia-256, IDEA, Seed, 3 Keys Triple-DES, 2 Keys Triple-DES ) ( Poly1305, OCB, GCM, OFB, CFB, CFB1, CFB8, CTR, CBC ) You are certainly already informed (as I believe it may be caused by the same problem that David diagnosed) but I felt preferable to report that even with an output buffer larger than the expected data size, I always got a heap corrupted, but *ONLY* when I use the CBC mode. FWIW, here is the call stack : [External Code] Test.exe!CRYPTO_free(void * str, const char * file, int line) Line 179 C Test.exe!buffer_free(bio_st * a) Line 76 C Test.exe!BIO_free(bio_st * a) Line 72 C Test.exe!OCrypto::IO::Free() Line 1204 C++ Test.exe!WinFile::Close() Line 388 C++ Test.exe!WinFile::~WinFile() Line 456 C++ Test.exe!LoadData(const char * sFullFileName) Line 186 C++ Test.exe!main(int argc, char * * argv) Line 154 C++ [External Code] HEAP CORRUPTION DETECTED All ciphers look to work good in all other modes than CBC (still using a buffer greater than needed). Regards, Michel. From rt at openssl.org Tue Aug 9 21:29:15 2016 From: rt at openssl.org (Michel via RT) Date: Tue, 09 Aug 2016 21:29:15 +0000 Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check In-Reply-To: <006801d1f285$06ac6ab0$14054010$@sales@free.fr> References: <57963956.2060809@mit.edu> <006801d1f285$06ac6ab0$14054010$@sales@free.fr> Message-ID: Hi, As I obviously needed to improve my test program, I am now encrypting and decrypting files trying all ciphers in all their available modes. ( ChaCha20, AES-128, AES-192, AES-256, Blowfish, Cast5, Camellia-128, Camellia-192, Camellia-256, IDEA, Seed, 3 Keys Triple-DES, 2 Keys Triple-DES ) ( Poly1305, OCB, GCM, OFB, CFB, CFB1, CFB8, CTR, CBC ) You are certainly already informed (as I believe it may be caused by the same problem that David diagnosed) but I felt preferable to report that even with an output buffer larger than the expected data size, I always got a heap corrupted, but *ONLY* when I use the CBC mode. FWIW, here is the call stack : [External Code] Test.exe!CRYPTO_free(void * str, const char * file, int line) Line 179 C Test.exe!buffer_free(bio_st * a) Line 76 C Test.exe!BIO_free(bio_st * a) Line 72 C Test.exe!OCrypto::IO::Free() Line 1204 C++ Test.exe!WinFile::Close() Line 388 C++ Test.exe!WinFile::~WinFile() Line 456 C++ Test.exe!LoadData(const char * sFullFileName) Line 186 C++ Test.exe!main(int argc, char * * argv) Line 154 C++ [External Code] HEAP CORRUPTION DETECTED All ciphers look to work good in all other modes than CBC (still using a buffer greater than needed). Regards, Michel. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628 Please log in as guest with password guest if prompted From brian at briansmith.org Wed Aug 10 00:12:24 2016 From: brian at briansmith.org (Brian Smith) Date: Tue, 9 Aug 2016 14:12:24 -1000 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg Message-ID: I was curious about the function ecp_nistz256_neg. This function seems to work exactly how I expect for reduced inputs; i.e. inputs in the range [0, P). And, it also seems to work how I expect for P: ecp_nistz256_neg(P) == ecp_nistz256_neg(0) == 0. So, everything seems fine for inputs in the range [0, P]. But, I don't understand how it works for the value P + 1. I expect that one of the following is true: ecp_nistz256_neg(P + 1) == ecp_nistz256_neg(1) ecp_nistz256_neg(P + 1) == ecp_nistz256_neg(1) + P. But, instead, ecp_nistz256_neg(P + 1) returns a result of 2**256 - 1. That is: input = ffffffff00000001000000000000000000000001000000000000000000000000 expected = ffffffff00000001000000000000000000000000fffffffffffffffffffffffe actual: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff Similarly, I decided to test ecp_nistz256_neg(2**256 - 1). I expected that one of the following would be true: ecp_nistz256_neg(2**256 - 1) = ecp_nistz256_neg(2**256 - 1 - P) ecp_nistz256_neg(2**256 - 1) == ecp_nistz256_neg(2**256 - 1 - P) + P. But, instead, ecp_nistz256_neg(2**256 - 1) == 1. That is: input = ffffffff00000001000000000000000000000000fffffffffffffffffffffffe expected = ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff actual: 01 Based on these two results, then, it seems that when the input is in the range [P + 1, 2**256 - 1], the result is actually the negation taken modulo 2**256, instead of the negation modulo p256 (perhaps not fully reduced). I don't know if this is actually problematic, but it was surprising to me. It seems to me that it would be a good idea for ecp_nistz256_neg to first reduce its input modulo P (i.e. do a conditional subtraction of P) before it does its calculation. At least, this would make it clear that it is correct. Note in particular that, IIUC, ecp_nistz256_neg will never get an unreduced input when applied to the the based point multiples, because those are already fully reduced. But, when it is used in ecp_nistz256_windowed_mul, it isn't clear whether or how the input Y coordinate is fully reduced mod P before passed to ecp_nistz256_neg. More generally, I'm think it might be a good idea to unit test all of the primitive operations in ecp_nistz256, with particular emphasis placed on whether unreduced inputs are supposed to be accepted for certain functions and, if so, whether unreduced inputs are handled correctly. And also, since many of the ecp_nistz256 field arithmetic functions are inlined into the ecp_nistz256_point functions, I think it would be worthwhile to review that the inlined versions of those functions actually are operating in the same way as the analogous standalone (C-callable) ecp_nistz256_* functions. Sorry if I'm overlooking something fundamental, which I admit is likely. Any help is appreciated. Cheers, Brian -- https://briansmith.org/ From hkario at redhat.com Thu Aug 11 09:34:24 2016 From: hkario at redhat.com (Hubert Kario) Date: Thu, 11 Aug 2016 11:34:24 +0200 Subject: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation In-Reply-To: <20160809195132.ibiqkq247obbq6es@breakpoint.cc> References: <20160808185726.d2yz6midc32hka3r@breakpoint.cc> <20160809192644.GU4670@mournblade.imrryr.org> <20160809195132.ibiqkq247obbq6es@breakpoint.cc> Message-ID: <4346054.VO6kfd9FD2@pintsize.usersys.redhat.com> On Tuesday, 9 August 2016 21:51:32 CEST Sebastian Andrzej Siewior wrote: > On 2016-08-09 19:26:44 [+0000], Viktor Dukhovni wrote: > > On Tue, Aug 09, 2016 at 09:18:58PM +0200, Sebastian Andrzej Siewior wrote: > > > I don't really know what I am supposed to do with this information. Do > > > you want me to add this as an example into the doc patch or do you > > > simply point out that others already took precautions? > > > > CPU exhaustion attacks on servers are a fundamental feature of TLS. > > I mentioned this. > > > I am not sure that OpenSSL needs to say anything about this. Server > > applications that want to protect against inadvertent DoS by buggy > > clients can implement the obvious counter-measure (rate limit > > handshakes with clients that generate too many new sessions per > > sample interval). If you feel that this is not obvious, and others > > agree, feel free to propose some text. > > I tried. There was some text in the patch. > > > Note, that deliberate DoS and especially DDoS will overcome even > > rate limits, by attacking from multiple clients, or just flooding > > the target network. So this can only protect against accidents, > > not malice by capable adversaries. > > I don't claim the opposite. I came across server software which supports > client side renegotiation and I don't think that this is required and > would like to patch it out. So far, so good? And then there is the > "same" thing if the attacker starts multiple connections the sake of a > handshake. So I though to point this out as well. And then I though it > would be nice to document this within the openssl documentation so I > could just point there and make them aware. it all depends on the environment, in some renegotiation is completely unnecessary (public HTTP servers without client certificate based authentication), in others just client-initiated renegotiation is needed (typical configuration for HTTP with client certificates), while in other still renegotiation is necessary for both sides (long sessions that want the ability to renew encryption keys). -- 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 openssl-dev at ml.breakpoint.cc Thu Aug 11 11:50:53 2016 From: openssl-dev at ml.breakpoint.cc (Sebastian Andrzej Siewior) Date: Thu, 11 Aug 2016 13:50:53 +0200 Subject: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation In-Reply-To: <4346054.VO6kfd9FD2@pintsize.usersys.redhat.com> References: <20160808185726.d2yz6midc32hka3r@breakpoint.cc> <20160809192644.GU4670@mournblade.imrryr.org> <20160809195132.ibiqkq247obbq6es@breakpoint.cc> <4346054.VO6kfd9FD2@pintsize.usersys.redhat.com> Message-ID: <20160811115053.ojnpyjl4kkgcbuej@breakpoint.cc> On 2016-08-11 11:34:24 [+0200], Hubert Kario wrote: > it all depends on the environment, in some renegotiation is completely > unnecessary (public HTTP servers without client certificate based > authentication), in others just client-initiated renegotiation is needed > (typical configuration for HTTP with client certificates), while in other Is this renegotiation (in this case) triggert by the client or by the server? I have here access to a few servers which require a client certs and they don't support renegotiation (triggert by the client) right after connect. > still renegotiation is necessary for both sides (long sessions that want the > ability to renew encryption keys). You are talking here about long sessions. A simple rate limit would be okay. My wording was "remove client initiated renegotiation if possible" I think. Also keeping a rate limit per connection would be nice then. Sebastian From appro at openssl.org Thu Aug 11 11:57:12 2016 From: appro at openssl.org (Andy Polyakov) Date: Thu, 11 Aug 2016 13:57:12 +0200 Subject: [openssl-dev] OpenSSL 1.1.0 pre 6: SPARCv9 capability bits problem In-Reply-To: <2c080cca-12b8-a05f-8a7a-66e4f0d16d8c@kippdata.de> References: <1461577876.080779.24055.nullmailer@dev.openssl.org> <2c080cca-12b8-a05f-8a7a-66e4f0d16d8c@kippdata.de> Message-ID: <9cedf8c6-4fd4-a661-ee30-14a9db597c7c@openssl.org> > The following change introduced build problems: > >> + if (vec[1]&0x00008) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS4; > > ... here we use vec[1], so the compiler warns: > > crypto/sparcv9cap.c:179:20: warning: array subscript is above array > bounds [-Warray-bounds] > if (vec[1]&0x00008) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS4; > ^ Fixed. > need the following patch to crypto/sparcv9cap.c here (warning "implicit > declaration of function '_sparcv9_fjaesx_probe'"): > > @@ -93,6 +93,7 @@ > void _sparcv9_fmadd_probe(void); > unsigned long _sparcv9_rdcfr(void); > void _sparcv9_vis3_probe(void); > +void _sparcv9_fjaesx_probe(void); > unsigned long _sparcv9_random(void); > size_t _sparcv9_vis1_instrument_bus(unsigned int *, size_t); > size_t _sparcv9_vis1_instrument_bus2(unsigned int *, size_t, size_t); Being fixed. Thanks for report. From rt at openssl.org Thu Aug 11 12:17:56 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 11 Aug 2016 12:17:56 +0000 Subject: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc In-Reply-To: References: <593784.48311.qm@web101204.mail.kks.yahoo.co.jp> Message-ID: Hi, > make test stops on Solaris10 x64. > > > % ./Configure solaris64-x86_64-gcc > > % make > % make test > : > ../test/recipes/01-test_abort.t ............ ok > ../test/recipes/01-test_sanity.t ........... ok > ../test/recipes/01-test_symbol_presence.t .. ok > ../test/recipes/02-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_fuzz.t ............. ok > ../test/recipes/05-test_hmac.t ............. There was private report about similar problem. I mean if you can confirm that it's stuck in OPENSSL_cleanse, then it's same problem(*). Trouble is that it doesn't seem to be OpenSSL problem, because generated code appears to be mis-compiled. When single-stepping with 'stepi' you are likely to observe "lea 0(%rdi),%rdi" instruction, and it should be "lea 1(%rdi),%rdi". I mean it *is* "lea 1(%rdi),%rdi" in source file, crypto/x86_64cpuid.pl, and that's where our responsibility ends. In sense that we are responsible for providing source, and you are effectively responsible for providing working compiler environment. I don't know which components were involved in first report, I mean things like perl version, which assembler and its version, so I can't give any advice about updates that might be required... (*) To confirm run test/hmactest under debugger, break, see if it's in OPENSSL_cleanse, issue 'stepi' command few times to see if it's going "in circles". -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 Please log in as guest with password guest if prompted From rt at openssl.org Thu Aug 11 12:29:07 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 11 Aug 2016 12:29:07 +0000 Subject: [openssl-dev] [openssl.org #4584] Self test failures under X32 In-Reply-To: <61f85ebe-291e-da20-f24a-238708503cc9@openssl.org> References: <578E32A8.5090900@openssl.org> <61f85ebe-291e-da20-f24a-238708503cc9@openssl.org> Message-ID: > ( cd test; \ > SRCTOP=../. \ > BLDTOP=../. \ > PERL="perl" \ > EXE_EXT= \ > OPENSSL_ENGINES=.././engines \ > perl .././test/run_tests.pl test_afalg ) > ../test/recipes/30-test_afalg.t .. > 1..1 > ALG_PERR: afalg_fin_cipher_aio: io_read failed : Bad address > test_afalg_aes_128_cbc() failed encryption > ../util/shlib_wrap.sh ./afalgtest => 1 > not ok 1 - running afalgtest > > # Failed test 'running afalgtest' > # at ../test/recipes/30-test_afalg.t line 23. > # Looks like you failed 1 test of 1. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/1 subtests For reference, problem is not specific to x32, real x86 32-bit build fails in same manner as well. [As well as executed under qemu-user, but we are probably not in position to expect *that* work.] What's common between x32 and x86 is that system calls pass an "emulation" layer where 32-bit arguments are adjusted for 64-bit kernel and return values back for 32-bit application... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584 Please log in as guest with password guest if prompted From rt at openssl.org Thu Aug 11 14:39:30 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Thu, 11 Aug 2016 14:39:30 +0000 Subject: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc In-Reply-To: <952067.71572.qm@web101213.mail.kks.yahoo.co.jp> References: <593784.48311.qm@web101204.mail.kks.yahoo.co.jp> <952067.71572.qm@web101213.mail.kks.yahoo.co.jp> Message-ID: Hello, I have no time to check with debugger now, but I do not think it is caused by assembler, because, - gcc-5.4.0 with gas (GNU Binutils) 2.27 - cc (Solaris developerstudio12.5) with /usr/ccs/bin/as have the same result (see openssl.org #4642 also). perl version which I use is v5.24.0. Regards, --- Kiyoshi ? ----- Original Message ----- > From: Andy Polyakov via RT > To: yoi_no_myoujou at yahoo.co.jp > Cc: openssl-dev at openssl.org > Date: 2016/8/11, Thu 21:17 > Subject: Re: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc > > Hi, > >> make test stops on Solaris10 x64. >> >> >> % ./Configure solaris64-x86_64-gcc >> >> % make >> % make test >> ? ? : >> ../test/recipes/01-test_abort.t ............ ok? >> ../test/recipes/01-test_sanity.t ........... ok? >> ../test/recipes/01-test_symbol_presence.t .. ok? >> ../test/recipes/02-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_fuzz.t ............. ok? ? >> ../test/recipes/05-test_hmac.t ............. > > There was private report about similar problem. I mean if you can > confirm that it's stuck in OPENSSL_cleanse, then it's same problem(*). > Trouble is that it doesn't seem to be OpenSSL problem, because generated > code appears to be mis-compiled. When single-stepping with 'stepi' you > are likely to observe "lea 0(%rdi),%rdi" instruction, and it should be > "lea 1(%rdi),%rdi". I mean it *is* "lea 1(%rdi),%rdi" in > source file, > crypto/x86_64cpuid.pl, and that's where our responsibility ends. In > sense that we are responsible for providing source, and you are > effectively responsible for providing working compiler environment. I > don't know which components were involved in first report, I mean things > like perl version, which assembler and its version, so I can't give any > advice about updates that might be required... > > (*) To confirm run test/hmactest under debugger, break, see if it's in > OPENSSL_cleanse, issue 'stepi' command few times to see if it's > going > "in circles". > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 > Please log in as guest with password guest if prompted > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 Please log in as guest with password guest if prompted From hkario at redhat.com Thu Aug 11 16:04:41 2016 From: hkario at redhat.com (Hubert Kario) Date: Thu, 11 Aug 2016 18:04:41 +0200 Subject: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation In-Reply-To: <20160811115053.ojnpyjl4kkgcbuej@breakpoint.cc> References: <20160808185726.d2yz6midc32hka3r@breakpoint.cc> <4346054.VO6kfd9FD2@pintsize.usersys.redhat.com> <20160811115053.ojnpyjl4kkgcbuej@breakpoint.cc> Message-ID: <2914072.TKK7TpKWmS@pintsize.usersys.redhat.com> On Thursday, 11 August 2016 13:50:53 CEST Sebastian Andrzej Siewior wrote: > On 2016-08-11 11:34:24 [+0200], Hubert Kario wrote: > > it all depends on the environment, in some renegotiation is completely > > unnecessary (public HTTP servers without client certificate based > > authentication), in others just client-initiated renegotiation is needed > > (typical configuration for HTTP with client certificates), while in other > > Is this renegotiation (in this case) triggert by the client or by the > server? I have here access to a few servers which require a client certs > and they don't support renegotiation (triggert by the client) right > after connect. in this case the renegotiation is triggered by server -- 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 Thu Aug 11 16:36:42 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 11 Aug 2016 16:36:42 +0000 Subject: [openssl-dev] [openssl.org #4584] Self test failures under X32 In-Reply-To: <51884590-ccd1-fb10-0c91-0d450888be72@openssl.org> References: <578E32A8.5090900@openssl.org> <61f85ebe-291e-da20-f24a-238708503cc9@openssl.org> <51884590-ccd1-fb10-0c91-0d450888be72@openssl.org> Message-ID: On 11/08/16 13:29, Andy Polyakov via RT wrote: >> ( cd test; \ >> SRCTOP=../. \ >> BLDTOP=../. \ >> PERL="perl" \ >> EXE_EXT= \ >> OPENSSL_ENGINES=.././engines \ >> perl .././test/run_tests.pl test_afalg ) >> ../test/recipes/30-test_afalg.t .. >> 1..1 >> ALG_PERR: afalg_fin_cipher_aio: io_read failed : Bad address >> test_afalg_aes_128_cbc() failed encryption >> ../util/shlib_wrap.sh ./afalgtest => 1 >> not ok 1 - running afalgtest >> >> # Failed test 'running afalgtest' >> # at ../test/recipes/30-test_afalg.t line 23. >> # Looks like you failed 1 test of 1. >> Dubious, test returned 1 (wstat 256, 0x100) >> Failed 1/1 subtests > > For reference, problem is not specific to x32, real x86 32-bit build > fails in same manner as well. [As well as executed under qemu-user, but > we are probably not in position to expect *that* work.] What's common > between x32 and x86 is that system calls pass an "emulation" layer where > 32-bit arguments are adjusted for 64-bit kernel and return values back > for 32-bit application... > > Could be this: https://github.com/openssl/openssl/pull/1432 Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584 Please log in as guest with password guest if prompted From rt at openssl.org Thu Aug 11 17:12:10 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 11 Aug 2016 17:12:10 +0000 Subject: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc In-Reply-To: <9feb5530-ce49-1400-8ef1-fa1206ae1ce2@openssl.org> References: <593784.48311.qm@web101204.mail.kks.yahoo.co.jp> <952067.71572.qm@web101213.mail.kks.yahoo.co.jp> <9feb5530-ce49-1400-8ef1-fa1206ae1ce2@openssl.org> Message-ID: Hi, > I have no time to check with debugger now, Then no progress will be made. Problem needs to be identified first, and since similar problem was identified earlier, I'd have to insist on confirmation whether or not it's the same. > but I do not think it is caused by assembler, > because, > - gcc-5.4.0 with gas (GNU Binutils) 2.27 > - cc (Solaris developerstudio12.5) with /usr/ccs/bin/as > have the same result (see openssl.org #4642 also). > > perl version which I use is v5.24.0. Well, (assuming for a moment it's the same problem) there is *less* reason to believe that x86_64cpuid.pl is broken. Because it's used with a *number* of other toolchains, Linux, BSD, mingw, MSVC, without any problem. Nor can I reproduce the problem on my Solaris VM. It's not as fancy as yours, apparently, but it also kind of speak in favour of suggestion that it's not an OpenSSL problem... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 Please log in as guest with password guest if prompted From openssl-dev at ml.breakpoint.cc Thu Aug 11 19:13:45 2016 From: openssl-dev at ml.breakpoint.cc (Sebastian Andrzej Siewior) Date: Thu, 11 Aug 2016 21:13:45 +0200 Subject: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation In-Reply-To: <2914072.TKK7TpKWmS@pintsize.usersys.redhat.com> References: <20160808185726.d2yz6midc32hka3r@breakpoint.cc> <4346054.VO6kfd9FD2@pintsize.usersys.redhat.com> <20160811115053.ojnpyjl4kkgcbuej@breakpoint.cc> <2914072.TKK7TpKWmS@pintsize.usersys.redhat.com> Message-ID: <20160811191344.jqmahk43g3433pmu@breakpoint.cc> On 2016-08-11 18:04:41 [+0200], Hubert Kario wrote: > On Thursday, 11 August 2016 13:50:53 CEST Sebastian Andrzej Siewior wrote: > > On 2016-08-11 11:34:24 [+0200], Hubert Kario wrote: > > > it all depends on the environment, in some renegotiation is completely > > > unnecessary (public HTTP servers without client certificate based > > > authentication), in others just client-initiated renegotiation is needed > > > (typical configuration for HTTP with client certificates), while in other > > > > Is this renegotiation (in this case) triggert by the client or by the > > server? I have here access to a few servers which require a client certs > > and they don't support renegotiation (triggert by the client) right > > after connect. > > in this case the renegotiation is triggered by server good. So still no reason to accept a renegotiation request from the client (except your "long standing connection" point (which could be ratelimited or shifted to the server)). Sebastian From erik at efca.com Fri Aug 12 19:30:14 2016 From: erik at efca.com (Erik Forsberg) Date: Fri, 12 Aug 2016 12:30:14 -0700 Subject: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc In-Reply-To: References: Message-ID: For the time being, I think the atomic function should be GNU GCC only conditional. #if defined(__GNUC__) && defined(__ATOMIC_RELAXED) >-- Original Message -- > >Hello, > >% ./Configure solaris-x86-cc >% make >?? : >Undefined?????????????????????? first referenced >?symbol???????????????????????????? in file >__atomic_add_fetch????????????????? ./libcrypto.so >ld: fatal: symbol referencing errors. No output written to fuzz/asn1parse-test > > >% ./Configure solaris64-x86_64-cc >% make >has the same error. > >Tested on Solaris10 x86/64, with Solaris developerstudio12.5. > > >This is caused because __ATOMIC_RELAXED is #defined as 0 >in /opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h > > >Sample patch: >--- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c >+++ ./crypto/threads_pthread.c >@@ -109,7 +109,7 @@ >? >?int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK *lock) >?{ >-#ifdef __ATOMIC_RELAXED >+#if??? __ATOMIC_RELAXED >???? *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED); >?#else >???? if (!CRYPTO_THREAD_write_lock(lock)) > > >With this patch, >% ./Configure solaris-x86-cc >% make >% make test >passes. > >% ./Configure solaris64-x86_64-cc >% make >passes but >% make test >stops. >This is another problem, which seems to be the same as bug #4641. > > >Regards, > >--- Kiyoshi > > > >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 >Please log in as guest with password guest if prompted > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Fri Aug 12 19:50:28 2016 From: rt at openssl.org (Erik Forsberg via RT) Date: Fri, 12 Aug 2016 19:50:28 +0000 Subject: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc In-Reply-To: References: Message-ID: For the time being, I think the atomic function should be GNU GCC only conditional. #if defined(__GNUC__) && defined(__ATOMIC_RELAXED) >-- Original Message -- > >Hello, > >% ./Configure solaris-x86-cc >% make >?? : >Undefined?????????????????????? first referenced >?symbol???????????????????????????? in file >__atomic_add_fetch????????????????? ./libcrypto.so >ld: fatal: symbol referencing errors. No output written to fuzz/asn1parse-test > > >% ./Configure solaris64-x86_64-cc >% make >has the same error. > >Tested on Solaris10 x86/64, with Solaris developerstudio12.5. > > >This is caused because __ATOMIC_RELAXED is #defined as 0 >in /opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h > > >Sample patch: >--- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c >+++ ./crypto/threads_pthread.c >@@ -109,7 +109,7 @@ >? >?int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK *lock) >?{ >-#ifdef __ATOMIC_RELAXED >+#if??? __ATOMIC_RELAXED >???? *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED); >?#else >???? if (!CRYPTO_THREAD_write_lock(lock)) > > >With this patch, >% ./Configure solaris-x86-cc >% make >% make test >passes. > >% ./Configure solaris64-x86_64-cc >% make >passes but >% make test >stops. >This is another problem, which seems to be the same as bug #4641. > > >Regards, > >--- Kiyoshi > > > >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 >Please log in as guest with password guest if prompted > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 Please log in as guest with password guest if prompted From erik at efca.com Sun Aug 14 03:27:30 2016 From: erik at efca.com (Erik Forsberg) Date: Sat, 13 Aug 2016 20:27:30 -0700 Subject: [openssl-dev] weird linker warnings on solaris 11 Message-ID: just updated to developer studio 12.5 on Solaris 11.3 I see lot of warnings when linking OpenSSL 1.1 looking like these link_app.solaris-shared LD_LIBRARY_PATH=.: cc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -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 -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/amd64/engines-1.1" -xc99 -m64 -xarch=gen eric -xstrconst -DL_ENDIAN -xO5 -xdepend -xbuiltin -D_REENTRANT -DFILIO_H -mt -R /usr/local/lib/amd64 -o apps/openssl apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/c rl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/op t.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_ser ver.o apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o apps/x509.o -L. -lssl -L. -lcrypto -lresolv -lsocket -lnsl -ldl -lpthread ld: warning: relocation warning: R_AMD64_COPY: file ./libcrypto.so: symbol PBEPARAM_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_AMD64_COPY: file ./libcrypto.so: symbol PBE2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_AMD64_COPY: file ./libcrypto.so: symbol PBKDF2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility seems the common thing here is that libcrypto.num does this, not sure what the implied effect is, but seems contradictory to me, one line says export as function the other one says ! (export as variable instead) PBEPARAM_it 1307 1_1_0 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE: PBEPARAM_it 1307 1_1_0 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION: From kurt at roeckx.be Sun Aug 14 11:59:51 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 14 Aug 2016 13:59:51 +0200 Subject: [openssl-dev] weird linker warnings on solaris 11 In-Reply-To: References: Message-ID: <20160814115950.GA11021@roeckx.be> On Sat, Aug 13, 2016 at 08:27:30PM -0700, Erik Forsberg wrote: > > just updated to developer studio 12.5 on Solaris 11.3 > I see lot of warnings when linking OpenSSL 1.1 > looking like these > > link_app.solaris-shared > LD_LIBRARY_PATH=.: cc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -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 -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/amd64/engines-1.1" -xc99 -m64 -xarch=gen > eric -xstrconst -DL_ENDIAN -xO5 -xdepend -xbuiltin -D_REENTRANT -DFILIO_H -mt -R /usr/local/lib/amd64 -o apps/openssl apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/c > rl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/op > t.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_ser > ver.o apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o apps/x509.o -L. -lssl -L. -lcrypto -lresolv -lsocket -lnsl -ldl -lpthread > ld: warning: relocation warning: R_AMD64_COPY: file ./libcrypto.so: symbol PBEPARAM_it: relocation bound to a symbol with STV_PROTECTED visibility > ld: warning: relocation warning: R_AMD64_COPY: file ./libcrypto.so: symbol PBE2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility > ld: warning: relocation warning: R_AMD64_COPY: file ./libcrypto.so: symbol PBKDF2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility I'm not sure why those symbols are marked as protected. The only thing we seem to be doing with visibilit is this: ./crypto/sparcv9cap.c:__attribute__ ((visibility("hidden"))) And you're not on sparc. > seems the common thing here is that libcrypto.num does this, not sure what > the implied effect is, but seems contradictory to me, one line says export as function > the other one says ! (export as variable instead) > > PBEPARAM_it 1307 1_1_0 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE: > PBEPARAM_it 1307 1_1_0 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION: As far as I know, this is a windows only thing. For ELF files everything is just a symbol. Anyway, from what I understand, it should be a harmless warning, those variables should be read only and be in the .data.rel.ro section. But for some reason the solaris linker wants to make a copy of it, so you'll end up with the same (read only) variable twice. Kurt From erik at efca.com Sun Aug 14 18:13:23 2016 From: erik at efca.com (Erik Forsberg) Date: Sun, 14 Aug 2016 11:13:23 -0700 Subject: [openssl-dev] weird linker warnings on solaris 11 In-Reply-To: <20160814115950.GA11021@roeckx.be> References: <20160814115950.GA11021@roeckx.be> Message-ID: support for attribute visibility is new in the studio 12.5 compiler so there seems to be some incompatibility between cc and gcc now >-- Original Message -- > >On Sat, Aug 13, 2016 at 08:27:30PM -0700, Erik Forsberg wrote: >> >> just updated to developer studio 12.5 on Solaris 11.3 >> I see lot of warnings when linking OpenSSL 1.1 >> looking like these >> >> link_app.solaris-shared >> LD_LIBRARY_PATH=.: cc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -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 -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/amd64/engines-1.1" -xc99 -m64 -xarch=gen >> eric -xstrconst -DL_ENDIAN -xO5 -xdepend -xbuiltin -D_REENTRANT -DFILIO_H -mt -R /usr/local/lib/amd64 -o apps/openssl apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/c >> rl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/op >> t.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_ser >> ver.o apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o apps/x509.o -L. -lssl -L. -lcrypto -lresolv -lsocket -lnsl -ldl -lpthread >> ld: warning: relocation warning: R_AMD64_COPY: file ./libcrypto.so: symbol PBEPARAM_it: relocation bound to a symbol with STV_PROTECTED visibility >> ld: warning: relocation warning: R_AMD64_COPY: file ./libcrypto.so: symbol PBE2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility >> ld: warning: relocation warning: R_AMD64_COPY: file ./libcrypto.so: symbol PBKDF2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility > >I'm not sure why those symbols are marked as protected. The only >thing we seem to be doing with visibilit is this: >./crypto/sparcv9cap.c:__attribute__ ((visibility("hidden"))) > >And you're not on sparc. > >> seems the common thing here is that libcrypto.num does this, not sure what >> the implied effect is, but seems contradictory to me, one line says export as function >> the other one says ! (export as variable instead) >> >> PBEPARAM_it 1307 1_1_0 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE: >> PBEPARAM_it 1307 1_1_0 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION: > >As far as I know, this is a windows only thing. For ELF files >everything is just a symbol. > >Anyway, from what I understand, it should be a harmless warning, >those variables should be read only and be in the .data.rel.ro >section. But for some reason the solaris linker wants to make a >copy of it, so you'll end up with the same (read only) variable >twice. > > >Kurt > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Sun Aug 14 21:35:22 2016 From: rt at openssl.org (paul.dale@oracle.com via RT) Date: Sun, 14 Aug 2016 21:35:22 +0000 Subject: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc In-Reply-To: <177a4f05-9afe-4cbf-9b7b-09a1208f5ab0@default> References: <177a4f05-9afe-4cbf-9b7b-09a1208f5ab0@default> Message-ID: I believe Intel's C compiler knows about them too. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -----Original Message----- From: Erik Forsberg via RT [mailto:rt at openssl.org] Sent: Saturday, 13 August 2016 5:50 AM To: yoi_no_myoujou at yahoo.co.jp Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc For the time being, I think the atomic function should be GNU GCC only conditional. #if defined(__GNUC__) && defined(__ATOMIC_RELAXED) >-- Original Message -- > >Hello, > >% ./Configure solaris-x86-cc >% make >?? : >Undefined?????????????????????? first referenced >?symbol???????????????????????????? in file __atomic_add_fetch????????????????? >./libcrypto.so >ld: fatal: symbol referencing errors. No output written to >fuzz/asn1parse-test > > >% ./Configure solaris64-x86_64-cc >% make >has the same error. > >Tested on Solaris10 x86/64, with Solaris developerstudio12.5. > > >This is caused because __ATOMIC_RELAXED is #defined as 0 in >/opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h > > >Sample patch: >--- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c >+++ ./crypto/threads_pthread.c >@@ -109,7 +109,7 @@ >? >?int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK >*lock) >?{ >-#ifdef __ATOMIC_RELAXED >+#if??? __ATOMIC_RELAXED >???? *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED); >?#else >???? if (!CRYPTO_THREAD_write_lock(lock)) > > >With this patch, >% ./Configure solaris-x86-cc >% make >% make test >passes. > >% ./Configure solaris64-x86_64-cc >% make >passes but >% make test >stops. >This is another problem, which seems to be the same as bug #4641. > > >Regards, > >--- Kiyoshi > > > >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 >Please log in as guest with password guest if prompted > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 Please log in as guest with password guest if prompted From erik at efca.com Mon Aug 15 01:31:30 2016 From: erik at efca.com (Erik Forsberg) Date: Sun, 14 Aug 2016 18:31:30 -0700 Subject: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc In-Reply-To: References: Message-ID: Until everyone will agree on the C11 standard name, maybe we should avoid the issue, doesnt seem very important in OpenSSL usage. >-- Original Message -- > >I believe Intel's C compiler knows about them too. > > >Pauli > >-- >Oracle >Dr Paul Dale | Cryptographer | Network Security & Encryption >Phone +61 7 3031 7217 >Oracle Australia > >-----Original Message----- >From: Erik Forsberg via RT [mailto:rt at openssl.org] >Sent: Saturday, 13 August 2016 5:50 AM >To: yoi_no_myoujou at yahoo.co.jp >Cc: openssl-dev at openssl.org >Subject: Re: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc > >For the time being, I think the atomic function should be GNU GCC only conditional. >#if defined(__GNUC__) && defined(__ATOMIC_RELAXED) > >>-- Original Message -- >> >>Hello, >> >>% ./Configure solaris-x86-cc >>% make >>?? : >>Undefined?????????????????????? first referenced >>?symbol???????????????????????????? in file __atomic_add_fetch????????????????? >>./libcrypto.so >>ld: fatal: symbol referencing errors. No output written to >>fuzz/asn1parse-test >> >> >>% ./Configure solaris64-x86_64-cc >>% make >>has the same error. >> >>Tested on Solaris10 x86/64, with Solaris developerstudio12.5. >> >> >>This is caused because __ATOMIC_RELAXED is #defined as 0 in >>/opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h >> >> >>Sample patch: >>--- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c >>+++ ./crypto/threads_pthread.c >>@@ -109,7 +109,7 @@ >>? >>?int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK >>*lock) >>?{ >>-#ifdef __ATOMIC_RELAXED >>+#if??? __ATOMIC_RELAXED >>???? *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED); >>?#else >>???? if (!CRYPTO_THREAD_write_lock(lock)) >> >> >>With this patch, >>% ./Configure solaris-x86-cc >>% make >>% make test >>passes. >> >>% ./Configure solaris64-x86_64-cc >>% make >>passes but >>% make test >>stops. >>This is another problem, which seems to be the same as bug #4641. >> >> >>Regards, >> >>--- Kiyoshi >> >> >> >>-- >>Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 >>Please log in as guest with password guest if prompted >> >>-- >>openssl-dev mailing list >>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 >Please log in as guest with password guest if prompted > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 >Please log in as guest with password guest if prompted > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Mon Aug 15 01:31:39 2016 From: rt at openssl.org (Erik Forsberg via RT) Date: Mon, 15 Aug 2016 01:31:39 +0000 Subject: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc In-Reply-To: References: Message-ID: Until everyone will agree on the C11 standard name, maybe we should avoid the issue, doesnt seem very important in OpenSSL usage. >-- Original Message -- > >I believe Intel's C compiler knows about them too. > > >Pauli > >-- >Oracle >Dr Paul Dale | Cryptographer | Network Security & Encryption >Phone +61 7 3031 7217 >Oracle Australia > >-----Original Message----- >From: Erik Forsberg via RT [mailto:rt at openssl.org] >Sent: Saturday, 13 August 2016 5:50 AM >To: yoi_no_myoujou at yahoo.co.jp >Cc: openssl-dev at openssl.org >Subject: Re: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc > >For the time being, I think the atomic function should be GNU GCC only conditional. >#if defined(__GNUC__) && defined(__ATOMIC_RELAXED) > >>-- Original Message -- >> >>Hello, >> >>% ./Configure solaris-x86-cc >>% make >>?? : >>Undefined?????????????????????? first referenced >>?symbol???????????????????????????? in file __atomic_add_fetch????????????????? >>./libcrypto.so >>ld: fatal: symbol referencing errors. No output written to >>fuzz/asn1parse-test >> >> >>% ./Configure solaris64-x86_64-cc >>% make >>has the same error. >> >>Tested on Solaris10 x86/64, with Solaris developerstudio12.5. >> >> >>This is caused because __ATOMIC_RELAXED is #defined as 0 in >>/opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h >> >> >>Sample patch: >>--- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c >>+++ ./crypto/threads_pthread.c >>@@ -109,7 +109,7 @@ >>? >>?int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK >>*lock) >>?{ >>-#ifdef __ATOMIC_RELAXED >>+#if??? __ATOMIC_RELAXED >>???? *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED); >>?#else >>???? if (!CRYPTO_THREAD_write_lock(lock)) >> >> >>With this patch, >>% ./Configure solaris-x86-cc >>% make >>% make test >>passes. >> >>% ./Configure solaris64-x86_64-cc >>% make >>passes but >>% make test >>stops. >>This is another problem, which seems to be the same as bug #4641. >> >> >>Regards, >> >>--- Kiyoshi >> >> >> >>-- >>Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 >>Please log in as guest with password guest if prompted >> >>-- >>openssl-dev mailing list >>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 >Please log in as guest with password guest if prompted > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 >Please log in as guest with password guest if prompted > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 Please log in as guest with password guest if prompted From erik at efca.com Mon Aug 15 01:43:33 2016 From: erik at efca.com (Erik Forsberg) Date: Sun, 14 Aug 2016 18:43:33 -0700 Subject: [openssl-dev] weird linker warnings on solaris 11 In-Reply-To: References: Message-ID: <52qMtolNYRtX6Qi@srv.efca.com> the issue appears to be not in the compiler, but the newer Soalris linker (ld) I switched back to using 12.4 compiler, issue went away BUT now the issue surfaces if building OpenSSL using GCC. Some examples during the test suite ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol PKCS7_SIGNED_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol PKCS7_SIGN_ENVELOPE_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol PKCS7_SIGNER_INFO_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol PKCS8_PRIV_KEY_INFO_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol PKEY_USAGE_PERIOD_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol POLICY_CONSTRAINTS_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol POLICYINFO_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol POLICY_MAPPING_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol POLICY_MAPPINGS_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol POLICYQUALINFO_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol PROXY_CERT_INFO_EXTENSION_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol PROXY_POLICY_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol RSA_OAEP_PARAMS_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol RSAPrivateKey_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol RSA_PSS_PARAMS_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol RSAPublicKey_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol SXNET_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol SXNETID_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol USERNOTICE_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_ALGOR_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_ALGORS_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_ATTRIBUTE_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_CERT_AUX_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_CINF_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_CRL_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_CRL_INFO_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_EXTENSION_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_EXTENSIONS_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_NAME_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_NAME_ENTRY_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_PUBKEY_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_REQ_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_REQ_INFO_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_REVOKED_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_SIG_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol X509_VAL_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_386_COPY: file ./libcrypto.so: symbol ZLONG_it: relocation bound to a symbol with STV_PROTECTED visibility >-- Original Message -- > >support for attribute visibility is new in the studio 12.5 compiler >so there seems to be some incompatibility between cc and gcc now > >>-- Original Message -- >> >>On Sat, Aug 13, 2016 at 08:27:30PM -0700, Erik Forsberg wrote: >>> >>> just updated to developer studio 12.5 on Solaris 11.3 >>> I see lot of warnings when linking OpenSSL 1.1 >>> looking like these >>> >>> link_app.solaris-shared >>> LD_LIBRARY_PATH=.: cc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -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 -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/amd64/engines-1.1" -xc99 -m64 -xarch=gen >>> eric -xstrconst -DL_ENDIAN -xO5 -xdepend -xbuiltin -D_REENTRANT -DFILIO_H -mt -R /usr/local/lib/amd64 -o apps/openssl apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/c >>> rl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/op >>> t.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_ser >>> ver.o apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o apps/x509.o -L. -lssl -L. -lcrypto -lresolv -lsocket -lnsl -ldl -lpthread >>> ld: warning: relocation warning: R_AMD64_COPY: file ./libcrypto.so: symbol PBEPARAM_it: relocation bound to a symbol with STV_PROTECTED visibility >>> ld: warning: relocation warning: R_AMD64_COPY: file ./libcrypto.so: symbol PBE2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility >>> ld: warning: relocation warning: R_AMD64_COPY: file ./libcrypto.so: symbol PBKDF2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility >> >>I'm not sure why those symbols are marked as protected. The only >>thing we seem to be doing with visibilit is this: >>./crypto/sparcv9cap.c:__attribute__ ((visibility("hidden"))) >> >>And you're not on sparc. >> >>> seems the common thing here is that libcrypto.num does this, not sure what >>> the implied effect is, but seems contradictory to me, one line says export as function >>> the other one says ! (export as variable instead) >>> >>> PBEPARAM_it 1307 1_1_0 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE: >>> PBEPARAM_it 1307 1_1_0 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION: >> >>As far as I know, this is a windows only thing. For ELF files >>everything is just a symbol. >> >>Anyway, from what I understand, it should be a harmless warning, >>those variables should be read only and be in the .data.rel.ro >>section. But for some reason the solaris linker wants to make a >>copy of it, so you'll end up with the same (read only) variable >>twice. >> >> >>Kurt >> >>-- >>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 rt at openssl.org Mon Aug 15 02:51:29 2016 From: rt at openssl.org (paul.dale@oracle.com via RT) Date: Mon, 15 Aug 2016 02:51:29 +0000 Subject: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc In-Reply-To: References: Message-ID: Based on the testing we did, using atomic operations to adjust reference counts provides a significant performance boost to the TLS stack (when measuring connections per second). Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -----Original Message----- From: Erik Forsberg via RT [mailto:rt at openssl.org] Sent: Monday, 15 August 2016 11:32 AM To: yoi_no_myoujou at yahoo.co.jp Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc Until everyone will agree on the C11 standard name, maybe we should avoid the issue, doesnt seem very important in OpenSSL usage. >-- Original Message -- > >I believe Intel's C compiler knows about them too. > > >Pauli > >-- >Oracle >Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 >7 3031 7217 Oracle Australia > >-----Original Message----- >From: Erik Forsberg via RT [mailto:rt at openssl.org] >Sent: Saturday, 13 August 2016 5:50 AM >To: yoi_no_myoujou at yahoo.co.jp >Cc: openssl-dev at openssl.org >Subject: Re: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] >make failes with solaris-x86-cc & solaris64-x86_64-cc > >For the time being, I think the atomic function should be GNU GCC only conditional. >#if defined(__GNUC__) && defined(__ATOMIC_RELAXED) > >>-- Original Message -- >> >>Hello, >> >>% ./Configure solaris-x86-cc >>% make >>?? : >>Undefined?????????????????????? first referenced >>?symbol???????????????????????????? in file __atomic_add_fetch >>./libcrypto.so >>ld: fatal: symbol referencing errors. No output written to >>fuzz/asn1parse-test >> >> >>% ./Configure solaris64-x86_64-cc >>% make >>has the same error. >> >>Tested on Solaris10 x86/64, with Solaris developerstudio12.5. >> >> >>This is caused because __ATOMIC_RELAXED is #defined as 0 in >>/opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h >> >> >>Sample patch: >>--- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c >>+++ ./crypto/threads_pthread.c >>@@ -109,7 +109,7 @@ >>? >>?int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK >>*lock) >>?{ >>-#ifdef __ATOMIC_RELAXED >>+#if??? __ATOMIC_RELAXED >>???? *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED); >>?#else >>???? if (!CRYPTO_THREAD_write_lock(lock)) >> >> >>With this patch, >>% ./Configure solaris-x86-cc >>% make >>% make test >>passes. >> >>% ./Configure solaris64-x86_64-cc >>% make >>passes but >>% make test >>stops. >>This is another problem, which seems to be the same as bug #4641. >> >> >>Regards, >> >>--- Kiyoshi >> >> >> >>-- >>Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 >>Please log in as guest with password guest if prompted >> >>-- >>openssl-dev mailing list >>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 >Please log in as guest with password guest if prompted > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 >Please log in as guest with password guest if prompted > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 Please log in as guest with password guest if prompted From appro at openssl.org Mon Aug 15 08:24:49 2016 From: appro at openssl.org (Andy Polyakov) Date: Mon, 15 Aug 2016 10:24:49 +0200 Subject: [openssl-dev] weird linker warnings on solaris 11 In-Reply-To: <52qMtolNYRtX6Qi@srv.efca.com> References: <52qMtolNYRtX6Qi@srv.efca.com> Message-ID: <89d01b45-d1fc-5129-f70e-0b83216ac44e@openssl.org> > the issue appears to be not in the compiler, but the newer Soalris linker (ld) > I switched back to using 12.4 compiler, issue went away BUT now the issue surfaces > if building OpenSSL using GCC. Some examples during the test suite What I was going to comment before I've read this message was that there used to be only one linker on Solaris. I.e. both gnu and vendor compilers use same linker, so that you can't formally say "there seems to be incompatibility between cc and gcc" implying that they use own linkers. It's just one or another drives same linker crazy. In either case. There seem to be Solaris issues popping up that I can't reproduce. My installation is not fancy (for example I don't have vendor compiler), but it worked at every occasion I've tested. As there apparently are Oracle people on the list, I'd suggest they step up and give us a hand sorting out things. From dwmw2 at infradead.org Mon Aug 15 12:39:20 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 15 Aug 2016 13:39:20 +0100 Subject: [openssl-dev] [PATCH] crypto/ui/ui_openssl.c: let new-line through after query in Windows path. Message-ID: <1471264760.61594.230.camel@infradead.org> On Mon, 2016-08-01 at 10:48 +0200, Andy Polyakov wrote: > Originally new-line was suppressed, because double new-line was > observed under wine. But it appears rather to be a wine bug, > because on real Windows new-line is much needed. > > Reviewed-by: Richard Levitte Hm, this commit comment needs an explicit reference to the mentioned bug in bugs.winehq.org. I can't find it. Is it related to? https://bugs.winehq.org/show_bug.cgi?id=27229?? -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From appro at openssl.org Mon Aug 15 18:39:14 2016 From: appro at openssl.org (Andy Polyakov) Date: Mon, 15 Aug 2016 20:39:14 +0200 Subject: [openssl-dev] [PATCH] crypto/ui/ui_openssl.c: let new-line through after query in Windows path. In-Reply-To: <1471264760.61594.230.camel@infradead.org> References: <1471264760.61594.230.camel@infradead.org> Message-ID: >> Originally new-line was suppressed, because double new-line was >> observed under wine. But it appears rather to be a wine bug, >> because on real Windows new-line is much needed. >> >> Reviewed-by: Richard Levitte > > Hm, this commit comment needs an explicit reference to the mentioned > bug in bugs.winehq.org. > > I can't find it. Is it related to > https://bugs.winehq.org/show_bug.cgi?id=27229 ? Well, the commit message is based on empirical findings. I mean it simply reflects the fact that code was originally debugged under wine, but then it was found that on actual Windows console prompts appear on the same line. And since we have to accept that Windows is right, workaround for double new-line under wine was disengaged. From appro at openssl.org Mon Aug 15 20:24:51 2016 From: appro at openssl.org (Andy Polyakov) Date: Mon, 15 Aug 2016 22:24:51 +0200 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: References: Message-ID: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> > Note in particular that, IIUC, ecp_nistz256_neg will never get an > unreduced input when applied to the the based point multiples, because > those are already fully reduced. But, when it is used in > ecp_nistz256_windowed_mul, it isn't clear whether or how the input Y > coordinate is fully reduced mod P before passed to ecp_nistz256_neg. Is it correctly understood that concern is that input to ecp_nistz256_windowed_mul, which in turn can be *user* input, would be not fully reduced? I mean that user would supply such input for a gain, obviously with malicious intent. In such case one can probably argue that it would be more appropriate to *reject* such input rather than to play along and reduce it. Just for reference, conditional reduction can be done by simply subtracting modulus, i.e. one doesn't need special subroutine. Attempt to subtract modulus from fully reduced value results in adding it back. > More generally, I'm think it might be a good idea to unit test all of > the primitive operations in ecp_nistz256, with particular emphasis > placed on whether unreduced inputs are supposed to be accepted for > certain functions and, if so, whether unreduced inputs are handled > correctly. But primitives are private and don't have to work in most general cases, only in specific context. In other words it's not unreasonable to expect/demand that inputs are fully reduced. Well, except when we are looking at user input. But then, as just mentioned, question is if silent reductions is actually appropriate. > And also, since many of the ecp_nistz256 field arithmetic functions > are inlined into the ecp_nistz256_point functions, I think it would be > worthwhile to review that the inlined versions of those functions > actually are operating in the same way as the analogous standalone > (C-callable) ecp_nistz256_* functions. C-callables are wrappers around inlined subroutines. The only thing they do is load input into designated registers and call inlines, those used in point functions. From brian at briansmith.org Mon Aug 15 20:52:49 2016 From: brian at briansmith.org (Brian Smith) Date: Mon, 15 Aug 2016 10:52:49 -1000 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> References: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> Message-ID: Andy Polyakov wrote: >> Note in particular that, IIUC, ecp_nistz256_neg will never get an >> unreduced input when applied to the the based point multiples, because >> those are already fully reduced. But, when it is used in >> ecp_nistz256_windowed_mul, it isn't clear whether or how the input Y >> coordinate is fully reduced mod P before passed to ecp_nistz256_neg. > > Is it correctly understood that concern is that input to > ecp_nistz256_windowed_mul, which in turn can be *user* input, would be > not fully reduced? Let's assume, for the purpose of this discussion, that the coordinates of the user input point `p` is already reduced, or that we will reject it or reduce it. Given that input point, we calculate multiples 1*p, 2*p, ... 16*p using ecp_nistz256_point_double and ecp_nistz256_point_add. Let's look at how ecp_nistz256_point_double and ecp_nistz256_point_add calculates the Y coordinate: double: ... ecp_nistz256_mul_mont(S, S, M); ecp_nistz256_sub(res_y, S, res_y); add: ... ecp_nistz256_mul_mont(res_y, R, res_y); ecp_nistz256_sub(res_y, res_y, S2); memcpy(r->Y, res_y, sizeof(res_y)); Now, I was told by one of the authors of the original code that all the ecp_nistz256_* field operations return a result in the range [0, 2**256), not [0, P). This can be seen in the reduction code, e.g. in ecp_nistz256_sub. It uses the result of "sbb \$0, $t4" to determine if the result is larger than 2**256 - 1. If the result is larger than 2**256 - 1 then it subtracts P. Otherwise, it returns the result. But, in the case where it doesn't subtract P, the result might be in the range [P, 2**256); i.e. not fully reduced. NOTE: I may not be understanding it correctly! It's a very real possibility. But, my understanding seems to match what I was told, which is that the results of all the field operations are not fully reduced. Cheers, Brian From appro at openssl.org Mon Aug 15 21:47:55 2016 From: appro at openssl.org (Andy Polyakov) Date: Mon, 15 Aug 2016 23:47:55 +0200 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> References: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> Message-ID: <063f166c-9f7c-a7fb-ccaf-5edc1c8d3801@openssl.org> > C-callables are wrappers around inlined subroutines. The only thing they > do is load input into designated registers and call inlines, those used > in point functions. It's true for modules other than x86_64, but not x86_64 one. Sorry about confusion. From appro at openssl.org Mon Aug 15 22:17:48 2016 From: appro at openssl.org (Andy Polyakov) Date: Tue, 16 Aug 2016 00:17:48 +0200 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: References: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> Message-ID: <81fdfb0a-c7b2-81e4-a5bd-069d33256927@openssl.org> >>> Note in particular that, IIUC, ecp_nistz256_neg will never get an >>> unreduced input when applied to the the based point multiples, because >>> those are already fully reduced. But, when it is used in >>> ecp_nistz256_windowed_mul, it isn't clear whether or how the input Y >>> coordinate is fully reduced mod P before passed to ecp_nistz256_neg. >> >> Is it correctly understood that concern is that input to >> ecp_nistz256_windowed_mul, which in turn can be *user* input, would be >> not fully reduced? > > Let's assume, for the purpose of this discussion, that the coordinates > of the user input point `p` is already reduced, or that we will reject > it or reduce it. > > Given that input point, we calculate multiples 1*p, 2*p, ... 16*p > using ecp_nistz256_point_double and ecp_nistz256_point_add. Let's look > at how ecp_nistz256_point_double and ecp_nistz256_point_add calculates > the Y coordinate: > > double: > ... > ecp_nistz256_mul_mont(S, S, M); > ecp_nistz256_sub(res_y, S, res_y); > > add: > ... > ecp_nistz256_mul_mont(res_y, R, res_y); > ecp_nistz256_sub(res_y, res_y, S2); > memcpy(r->Y, res_y, sizeof(res_y)); > > Now, I was told by one of the authors of the original code that all > the ecp_nistz256_* field operations return a result in the range [0, > 2**256), not [0, P). This can be seen in the reduction code, e.g. in > ecp_nistz256_sub. It uses the result of "sbb \$0, $t4" to determine if > the result is larger than 2**256 - 1. If the result is larger than > 2**256 - 1 then it subtracts P. Otherwise, it returns the result. But, > in the case where it doesn't subtract P, the result might be in the > range [P, 2**256); i.e. not fully reduced. No, it subtraction subroutine uses *borrow* to determine if modulus is to be added. I.e. (a >= b) ? (a - b) : (P - (b - a)). If both a and b are less than P, then result is less than P. From brian at briansmith.org Mon Aug 15 22:25:28 2016 From: brian at briansmith.org (Brian Smith) Date: Mon, 15 Aug 2016 12:25:28 -1000 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: <81fdfb0a-c7b2-81e4-a5bd-069d33256927@openssl.org> References: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> <81fdfb0a-c7b2-81e4-a5bd-069d33256927@openssl.org> Message-ID: Andy Polyakov wrote: > No, it subtraction subroutine uses *borrow* to determine if modulus is > to be added. I.e. (a >= b) ? (a - b) : (P - (b - a)). If both a and b > are less than P, then result is less than P. Consider the case where a > P and a >= b and b is very small (e.g. 1). For example, a == P + 2 and b == 1, so a >= b, and a - b == P + 2 - 1 == P + 1. Of course, this reduces the question of whether the multiplication that precedes the subtraction can ever have a result in [P, 2**256 - 1). Cheers, Brian -- https://briansmith.org/ From appro at openssl.org Mon Aug 15 22:51:43 2016 From: appro at openssl.org (Andy Polyakov) Date: Tue, 16 Aug 2016 00:51:43 +0200 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: References: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> <81fdfb0a-c7b2-81e4-a5bd-069d33256927@openssl.org> Message-ID: <5a6a9472-1c3c-f78d-4ec7-380bb9a90d38@openssl.org> >> No, it subtraction subroutine uses *borrow* to determine if modulus is >> to be added. I.e. (a >= b) ? (a - b) : (P - (b - a)). If both a and b >> are less than P, then result is less than P. > > Consider the case where a > P and a >= b and b is very small (e.g. 1). > For example, a == P + 2 and b == 1, so a >= b, and a - b == P + 2 - 1 > == P + 1. But assertion was "if *both* a and b are less than P". I can also tell that multiplication result is fully reduced. So that if we consider referred snippets, one from *your* previous message, then we'll see that if we assume that inputs to subtraction subroutines are reduced, then result of subtraction is too. You also established that negate for fully reduced input works correctly. And then it all boils down to initial user input, right? Off for today... From doctor at doctor.nl2k.ab.ca Tue Aug 16 06:35:18 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 16 Aug 2016 00:35:18 -0600 Subject: [openssl-dev] openssl 1.0.2 20160816 snap Message-ID: <20160816063518.7ftjgolh4odgscny@doctor.nl2k.ab.ca> This error showed up /usr/local/bin/clang38 -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 -Wall -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -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 pvkfmt.c -o pvkfmt.o pvkfmt.c:279:34: error: use of undeclared identifier 'PEM_R_HEADER_TOO_LONG' PEMerr(PEM_F_DO_B2I_BIO, PEM_R_HEADER_TOO_LONG); ^ 1 error generated. in FreeBSD 10.3 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 Time for the USA to hold a referendum on its republic and vote to dissolve!! From rt at openssl.org Tue Aug 16 08:00:27 2016 From: rt at openssl.org (Simon Richter via RT) Date: Tue, 16 Aug 2016 08:00:27 +0000 Subject: [openssl-dev] [openssl.org #4646] [1.0.2 stable branch] .\crypto\pem\pvkfmt.c(279): error C2065: 'PEM_R_HEADER_TOO_LONG': undeclared identifier In-Reply-To: <92be48f8-2569-299a-9a69-28cf29611099@hogyros.de> References: <92be48f8-2569-299a-9a69-28cf29611099@hogyros.de> Message-ID: Hi, the 1.0.2 stable branch fails to compile on VC-WIN32 with no-asm, with the error .\crypto\pem\pvkfmt.c(279): error C2065: 'PEM_R_HEADER_TOO_LONG': undeclared identifier Full build log can be found at http://ci.kicad-pcb.org/view/Windows/job/windows-openssl-msvc/build=release,cpu=x86,label=windows/454/consoleFull Simon -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4646 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From rt at openssl.org Tue Aug 16 08:05:07 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 16 Aug 2016 08:05:07 +0000 Subject: [openssl-dev] [openssl.org #4584] Self test failures under X32 In-Reply-To: References: <578E32A8.5090900@openssl.org> <61f85ebe-291e-da20-f24a-238708503cc9@openssl.org> <51884590-ccd1-fb10-0c91-0d450888be72@openssl.org> Message-ID: On Thu Aug 11 16:36:42 2016, matt wrote: > Could be this: > > https://github.com/openssl/openssl/pull/1432 That MR has now been merged. Jeff - please can you confirm that it resolves the issue for this ticket? Thanks Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584 Please log in as guest with password guest if prompted From appro at openssl.org Tue Aug 16 09:44:20 2016 From: appro at openssl.org (Andy Polyakov) Date: Tue, 16 Aug 2016 11:44:20 +0200 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: <5a6a9472-1c3c-f78d-4ec7-380bb9a90d38@openssl.org> References: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> <81fdfb0a-c7b2-81e4-a5bd-069d33256927@openssl.org> <5a6a9472-1c3c-f78d-4ec7-380bb9a90d38@openssl.org> Message-ID: >>> No, it subtraction subroutine uses *borrow* to determine if modulus is >>> to be added. I.e. (a >= b) ? (a - b) : (P - (b - a)). If both a and b >>> are less than P, then result is less than P. >> >> Consider the case where a > P and a >= b and b is very small (e.g. 1). >> For example, a == P + 2 and b == 1, so a >= b, and a - b == P + 2 - 1 >> == P + 1. > > But assertion was "if *both* a and b are less than P". I can also tell > that multiplication result is fully reduced. And it's not only that multiplication (and squaring) result is fully reduced, it, multiplication (ans squaring) subroutine can actually manage partially reduced input. On related note one can point out that result of addition (and mul_by_[2|3]) is partially reduced. But it's multiplication's ability to handle it that ties things up. One should also remember that it always ends with multiplication when result is converted from Montgomery representation. As well as that it starts with multiplication when input is converted to Montgomery representation... From rt at openssl.org Tue Aug 16 11:53:26 2016 From: rt at openssl.org (sandeep umesh via RT) Date: Tue, 16 Aug 2016 11:53:26 +0000 Subject: [openssl-dev] [openssl.org #4647] bug report: OpenSSL 1.0.2h: Segment fault on AIX Power8 using optimization code In-Reply-To: References: Message-ID: Hello We are using libcurl for REST programming, which internally uses openssl and libcrypto. curl suggested to implement few callbacks related to locking, which would be needed for openssl below 1.1 version(which is still in beta). The following callbacks were implemented: https://curl.haxx.se/libcurl/c/threaded-ssl.html lock_callback, thread_id, init_locks, kill_locks With these modifications we are facing a crash in openssl library when used on a Power8 Hardware (with optimizations). It works fine if we use the unoptimized code (without using ppc32_asm or ppc64_asm during Configure) Segment fault is seen as below: Segmentation fault in sha1-ppc.sha1_block_data_order at 0xd4feb8b8 ($t13) 0xd4feb8b8 (sha1_block_data_order+0xb8) 8a440002 lbz r18,0x2(r4) (dbx) where sha1-ppc.sha1_block_data_order(??, ??, ??) at 0xd4feb8b8 .() at 0x0 m_sha1.update() at 0xd5001ef8 digest.EVP_DigestUpdate() at 0xd4ff93dc md_rand.ssleay_rand_bytes() at 0xd50009a0 ssleay_rand_nopseudo_bytes() at 0xd50005ec rand_lib.RAND_bytes() at 0xd4ffffb4 bn_rand.bnrand() at 0xd50046b4 bn_rand.bn_rand_range() at 0xd50042a4 EC_KEY_generate_key() at 0xd501e9d0 ssl3_send_client_key_exchange() at 0xd53cb654 ssl3_connect() at 0xd53cf4fc SSL_connect() at 0xd5396b3c ssl23_get_server_hello() at 0xd53c20c0 ssl23_connect() at 0xd53c2f84 SSL_connect() at 0xd5396b3c ossl_connect_step2() at 0x1021ddc8 ossl_connect_common() at 0x1021bcb0 Curl_ossl_connect_nonblocking() at 0x10220ff4 Curl_ssl_connect_nonblocking() at 0x1021af80 https_connecting() at 0x1020da3c Curl_protocol_connecting at AF72_46() at 0x1020acf8 multi_runsingle() at 0x101fb0cc curl_multi_perform() at 0x101fd914 easy_transfer() at 0x101f5ffc easy_perform() at 0x101f5de8 Please let me know if you need further information and a solution to fix this. Thanks Regards Sandeep -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4647 Please log in as guest with password guest if prompted From rt at openssl.org Tue Aug 16 13:20:11 2016 From: rt at openssl.org (ycollette.nospam@free.fr via RT) Date: Tue, 16 Aug 2016 13:20:11 +0000 Subject: [openssl-dev] [openssl.org #4648] openssl doesn't work on mingw In-Reply-To: <469814016.529512023.1471353437281.JavaMail.root@zimbra35-e6.priv.proxad.net> References: <1874087882.529498635.1471353160945.JavaMail.root@zimbra35-e6.priv.proxad.net> <469814016.529512023.1471353437281.JavaMail.root@zimbra35-e6.priv.proxad.net> Message-ID: I tested the following command on fedora 24 and mingw64 (mingw64 installed via git for windows): openssl genrsa -des3 -out server.key 1024 On fedora, it's instantaneous. On mingw64, it's stuck before asking the key: Generating RSA private key, 1024 bit long modulus ..................++++++ ....................++++++ On cygwin32, it's instantaneous too. Best regards, YC -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4648 Please log in as guest with password guest if prompted From rt at openssl.org Tue Aug 16 14:03:21 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Tue, 16 Aug 2016 14:03:21 +0000 Subject: [openssl-dev] [openssl.org #4648] openssl doesn't work on mingw In-Reply-To: <8749f461-a044-3ca0-57d2-88f9c9dbc8c7@openssl.org> References: <1874087882.529498635.1471353160945.JavaMail.root@zimbra35-e6.priv.proxad.net> <469814016.529512023.1471353437281.JavaMail.root@zimbra35-e6.priv.proxad.net> <8749f461-a044-3ca0-57d2-88f9c9dbc8c7@openssl.org> Message-ID: > I tested the following command on fedora 24 and mingw64 (mingw64 installed via git for windows): > > openssl genrsa -des3 -out server.key 1024 > > On fedora, it's instantaneous. > On mingw64, it's stuck before asking the key: > > Generating RSA private key, 1024 bit long modulus > ..................++++++ > ....................++++++ There is certain ambiguity in problem description... I mean I don't quite grasp what exactly was attempted. Thing is that it's possible to cross-compile openssl with mingw compiler on Linux, and it's even possible to execute Windows binaries on Linux transparently, i.e. directly at Linux command prompt as if it was normal Linux command, under wine. This is actually what is regularly tested and if this is your case, then I can't say that I can reproduce the problem. But at the same time that's what is likely to make me fail to grasp the problem description:-) Anyway. What I can imagine to be problematic is that you run windows binary in msys shell window. Thing is that even though you'd use msys shell to compile openssl binary, resulting binary is plain windows one, and it's not given that it can inter-operate with msys shell window. Rather contrary actually. To verify if this is the case, just start plain cmd session and attempt the command in question there. If goal actually is to execute openssl at msys command prompt, then openssl should be compiled *for* msys, but we don't actually support this configuration. In either case, question is if you could elaborate more on conditions under which this happens. And what openssl version is it? Reference to "installed via git for windows" suggests that it's development master branch, but you'd need to be more specific. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4648 Please log in as guest with password guest if prompted From rt at openssl.org Tue Aug 16 18:23:05 2016 From: rt at openssl.org (Perrow, Graeme via RT) Date: Tue, 16 Aug 2016 18:23:05 +0000 Subject: [openssl-dev] [openssl.org #4649] [PATCH] BIO_debug_callback could write before the beginning of a buffer In-Reply-To: <2040f25e62d641deafb5d681742565ba@dewdfe13de43.global.corp.sap> References: <2040f25e62d641deafb5d681742565ba@dewdfe13de43.global.corp.sap> Message-ID: In the BIO_debug_callback function, we call BIO_snprintf which could return -1 in the case of an error. However, there is no check for this condition, and so the subsequent code would subtract one from buf and write data there, overwriting the byte immediately before the static buffer. This patch fixes the problem by checking for a negative return code from the first BIO_sprintf. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4649 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: BIO_debug_callback.patch Type: application/octet-stream Size: 453 bytes Desc: not available URL: From rt at openssl.org Tue Aug 16 18:54:40 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 16 Aug 2016 18:54:40 +0000 Subject: [openssl-dev] [openssl.org #4649] [PATCH] BIO_debug_callback could write before the beginning of a buffer In-Reply-To: <2040f25e62d641deafb5d681742565ba@dewdfe13de43.global.corp.sap> References: <2040f25e62d641deafb5d681742565ba@dewdfe13de43.global.corp.sap> Message-ID: Probably better to do what we is done in master: "if (len<0)len=0;" and proceed to try more output. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4649 Please log in as guest with password guest if prompted From brian at briansmith.org Tue Aug 16 19:41:30 2016 From: brian at briansmith.org (Brian Smith) Date: Tue, 16 Aug 2016 09:41:30 -1000 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: References: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> <81fdfb0a-c7b2-81e4-a5bd-069d33256927@openssl.org> <5a6a9472-1c3c-f78d-4ec7-380bb9a90d38@openssl.org> Message-ID: Andy Polyakov wrote: > And it's not only that multiplication (and squaring) result is fully > reduced, it, multiplication (ans squaring) subroutine can actually > manage partially reduced input. On related note one can point out that > result of addition (and mul_by_[2|3]) is partially reduced. But it's > multiplication's ability to handle it that ties things up. One should > also remember that it always ends with multiplication when result is > converted from Montgomery representation. As well as that it starts with > multiplication when input is converted to Montgomery representation... Andy, thanks! Let's rewind a bit: Originally I was writing tests and the first function I tested the reduction for was ecp_nistz256_add. I was surprised to find that the result is not necessarily unreduced. I emailed the original authors from Intel (Vlad and Shay) asking if this was expected and whether any other functions return unreduced results. Vlad's reply was that *all* of the functions are expected/assumed to return unreduced inputs. I then followed up asking specifically about whether the result of the multiplication could be only partially reduced. I received another reply that the result of the multiplication could be only partially reduced and that some code I'd written for BoringSSL that assumes that the multiplication result was always fully reduced was wrong. After that, I re-read the code for the conditional subtraction at the end of ecp_nistz256_mul_mont (__ecp_nistz256_mul_montq, actually) and I couldn't convince myself that the result was always fully reduced. My concern is that what you say and what Vlad said is contradictory. You both understand the code way better than me, so I feel like I'm not so useful in resolving the contradiction. But, I will try anyway: sbb $poly3, $acc1 # .Lpoly[3] sbb \$0, $acc2 cmovc $t0, $acc4 cmovc $t1, $acc5 My understand after talking with Vlad that the "sbb \$0, $acc2" makes this equivalent to (r >= 2**256) ? (r - q) : r. If the "sbb \$0, $acc2" line were removed then it would be equivalent to (r >= q) ? (r - q) : r. My understanding is that the difference in semantics is exactly the difference between partially reduced results and fully reduced results. Another way to see this is that there are 5 sbb instructions issued for the conditional subtraction, which means 5 limbs are involved. But, a full reduction mod q should only have 4 sbb instructions, right? Again, I could very well be horrifically misunderstanding things. Perhaps it would be a good idea to ask Vlad to weigh in again? Cheers, Brian -- https://briansmith.org/ From appro at openssl.org Tue Aug 16 20:56:39 2016 From: appro at openssl.org (Andy Polyakov) Date: Tue, 16 Aug 2016 22:56:39 +0200 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: References: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> <81fdfb0a-c7b2-81e4-a5bd-069d33256927@openssl.org> <5a6a9472-1c3c-f78d-4ec7-380bb9a90d38@openssl.org> Message-ID: > ... I re-read the code for the conditional subtraction at the > end of ecp_nistz256_mul_mont (__ecp_nistz256_mul_montq, actually) and > I couldn't convince myself that the result was always fully reduced. > > My concern is that what you say and what Vlad said is contradictory. > You both understand the code way better than me, so I feel like I'm > not so useful in resolving the contradiction. But, I will try anyway: > > sbb $poly3, $acc1 # .Lpoly[3] > sbb \$0, $acc2 > > cmovc $t0, $acc4 > cmovc $t1, $acc5 > > My understand after talking with Vlad that the "sbb \$0, $acc2" makes > this equivalent to (r >= 2**256) ? (r - q) : r. If the "sbb \$0, > $acc2" line were removed then it would be equivalent to (r >= q) ? (r > - q) : r. My understanding is that the difference in semantics is > exactly the difference between partially reduced results and fully > reduced results. Let's recall that result of multiplication prior final reduction is actually n+1-limb value, with +1 limb being single bit, that's $acc2, 5th limb in the context. So that the $0 in last 'sbb \$0,$acc2' represents 5th ("imaginary") limb of modulus[!]. And since we're looking at borrow from this 5-limb subtraction, outcome is actually if (ret > P) ret -= P' Effectively that is. As reality is rather temp = ret; ret -= P; if (borrow, i.e. ret < P) ret = temp For reference, if one wanted to compare result of multiplication to 2^256 it would be sufficient to check for $acc2 being non-zero, but that doesn't actually work. > Another way to see this is that there are 5 sbb instructions I assume that "5 sbb" actually means "1 sub + 4 sbb". > issued > for the conditional subtraction, which means 5 limbs are involved. > But, a full reduction mod q should only have 4 sbb instructions, > right? If you checked for $acc2 being non-zero, i.e. compare to 2^256, chain of four subtraction instructions would suffice, yes. But that's not what we aim for. From appro at openssl.org Tue Aug 16 21:56:18 2016 From: appro at openssl.org (Andy Polyakov) Date: Tue, 16 Aug 2016 23:56:18 +0200 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: References: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> <81fdfb0a-c7b2-81e4-a5bd-069d33256927@openssl.org> <5a6a9472-1c3c-f78d-4ec7-380bb9a90d38@openssl.org> Message-ID: <96d10f23-3b04-5274-a198-bd12ec498512@openssl.org> > Let's recall that result of multiplication prior final reduction is > actually n+1-limb value, with +1 limb being single bit, This came out wrong. Result is N+1 *bits* wide, it's just in this particular case you have to spend additional limb on the the additional bit. It's just that particular cases are most common ones, that's why you'd tend to put it as wrong as above :-) From erik at efca.com Tue Aug 16 22:00:59 2016 From: erik at efca.com (Erik Forsberg) Date: Tue, 16 Aug 2016 15:00:59 -0700 Subject: [openssl-dev] weird linker warnings on solaris 11 In-Reply-To: <89d01b45-d1fc-5129-f70e-0b83216ac44e@openssl.org> References: <89d01b45-d1fc-5129-f70e-0b83216ac44e@openssl.org> Message-ID: I went back to the 12.4 compiler which works very well, waste of my time to debug Oracle compiler, as we wont see any patches released anyway (no support here) >-- Original Message -- > >> the issue appears to be not in the compiler, but the newer Soalris linker (ld) >> I switched back to using 12.4 compiler, issue went away BUT now the issue surfaces >> if building OpenSSL using GCC. Some examples during the test suite > >What I was going to comment before I've read this message was that there >used to be only one linker on Solaris. I.e. both gnu and vendor >compilers use same linker, so that you can't formally say "there seems >to be incompatibility between cc and gcc" implying that they use own >linkers. It's just one or another drives same linker crazy. > >In either case. There seem to be Solaris issues popping up that I can't >reproduce. My installation is not fancy (for example I don't have vendor >compiler), but it worked at every occasion I've tested. As there >apparently are Oracle people on the list, I'd suggest they step up and >give us a hand sorting out things. > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From richmoore44 at gmail.com Tue Aug 16 22:26:16 2016 From: richmoore44 at gmail.com (Richard Moore) Date: Tue, 16 Aug 2016 23:26:16 +0100 Subject: [openssl-dev] Missing API- SSL_CIPHER_get_mac_nid Message-ID: I noticed that we have: __owur int SSL_CIPHER_get_bits(const SSL_CIPHER *c, int *alg_bits); __owur const char *SSL_CIPHER_get_version(const SSL_CIPHER *c); __owur const char *SSL_CIPHER_get_name(const SSL_CIPHER *c); __owur uint32_t SSL_CIPHER_get_id(const SSL_CIPHER *c); __owur int SSL_CIPHER_get_kx_nid(const SSL_CIPHER *c); __owur int SSL_CIPHER_get_auth_nid(const SSL_CIPHER *c); __owur int SSL_CIPHER_is_aead(const SSL_CIPHER *c); which is great, but we seem to be missing an accessor to get the MAC. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at briansmith.org Tue Aug 16 22:26:57 2016 From: brian at briansmith.org (Brian Smith) Date: Tue, 16 Aug 2016 12:26:57 -1000 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: References: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> <81fdfb0a-c7b2-81e4-a5bd-069d33256927@openssl.org> <5a6a9472-1c3c-f78d-4ec7-380bb9a90d38@openssl.org> Message-ID: Andy Polyakov wrote: >> My understand after talking with Vlad that the "sbb \$0, $acc2" makes >> this equivalent to (r >= 2**256) ? (r - q) : r. If the "sbb \$0, >> $acc2" line were removed then it would be equivalent to (r >= q) ? (r >> - q) : r. My understanding is that the difference in semantics is >> exactly the difference between partially reduced results and fully >> reduced results. > > Let's recall that result of multiplication prior final reduction is > actually n+1-limb value, with +1 limb being single bit, that's $acc2, > 5th limb in the context. So that the $0 in last 'sbb \$0,$acc2' > represents 5th ("imaginary") limb of modulus[!]. And since we're looking > at borrow from this 5-limb subtraction, outcome is actually > > if (ret > P) ret -= P' OK, let's agree on that. I think you are assuming that ret is in the range [0, 2P), so that if you subtract P, the result would be in the range [0, P). That is the case in normal Montgomery multiplication, where the inputs are in the range [0, P). But, my understanding is that if the inputs are in the range [P, 2**256), e.g. they are the result of ecp_nistz256_add, then that assumption doesn't necessarily hold. I understand Almost Montgomery Multiplication (AMM) as described in [1], where one accepts inputs in the range [0, 2**n] and returns a result in the range [0, 2**n), not [0, P). I also read the original paper on the ecp_nistz256 implementation [2], which has "0 ? a, b < p" as a precondition for the Montgomery multiplication. To put my concern another way: Earlier in the thread, you said the function can take inputs that aren't fully reduced--i.e. are in in the range [0, 2**n)--and returns outputs that are fully reduced--i.e. in the range [0, P)--but it isn't clear how that is achieved. My understanding is that the domain and range of the function are the same. [1] https://eprint.iacr.org/2011/239.pdf [2] https://eprint.iacr.org/2013/816.pdf Cheers, Brian From appro at openssl.org Tue Aug 16 22:39:19 2016 From: appro at openssl.org (Andy Polyakov) Date: Wed, 17 Aug 2016 00:39:19 +0200 Subject: [openssl-dev] weird linker warnings on solaris 11 In-Reply-To: References: <89d01b45-d1fc-5129-f70e-0b83216ac44e@openssl.org> Message-ID: <238d99be-d9d3-16d8-8056-84777b4186fe@openssl.org> > I went back to the 12.4 compiler which works very well, waste of my time > to debug Oracle compiler, as we wont see any patches released anyway (no support here) And I installed vendor compiler, 12.5, and I don't observe linker warnings... On related note one should probably point out that x86[_64] compilation with vendor compiler leaves out AVX and Broadwell code paths. This means that you won't get adequate performance on latest hardware. But gcc build should work with application compiled with vendor compiler, so why not adhere to just that? I mean build OpenSSL with gcc and your application with compiler of your choice, be it gcc or any particular vendor compiler version. From erik at efca.com Tue Aug 16 23:02:18 2016 From: erik at efca.com (Erik Forsberg) Date: Tue, 16 Aug 2016 16:02:18 -0700 Subject: [openssl-dev] weird linker warnings on solaris 11 In-Reply-To: <238d99be-d9d3-16d8-8056-84777b4186fe@openssl.org> References: <238d99be-d9d3-16d8-8056-84777b4186fe@openssl.org> Message-ID: >-- Original Message -- > >> I went back to the 12.4 compiler which works very well, waste of my time >> to debug Oracle compiler, as we wont see any patches released anyway (no support here) > >And I installed vendor compiler, 12.5, and I don't observe linker >warnings... interesting, can I ask which Solaris version you were running ? I was running 11.3 (no SRU's), so still concerned this might come back when Solaris 12 ships > >On related note one should probably point out that x86[_64] compilation >with vendor compiler leaves out AVX and Broadwell code paths. This means >that you won't get adequate performance on latest hardware. But gcc >build should work with application compiled with vendor compiler, so why >not adhere to just that? I mean build OpenSSL with gcc and your >application with compiler of your choice, be it gcc or any particular >vendor compiler version. > I may do that. I wasnt aware that AVX/Broadwell didnt build with cc (64-bit) I was aware of lack of 32-bit asm support, so my 32-bit builds were using gcc Thanks for looking. From matt at openssl.org Wed Aug 17 08:39:28 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 17 Aug 2016 09:39:28 +0100 Subject: [openssl-dev] Missing API- SSL_CIPHER_get_mac_nid In-Reply-To: References: Message-ID: <074018d8-c101-5901-949c-f787883f4a45@openssl.org> On 16/08/16 23:26, Richard Moore wrote: > I noticed that we have: > > __owur int SSL_CIPHER_get_bits(const SSL_CIPHER *c, int *alg_bits); > __owur const char *SSL_CIPHER_get_version(const SSL_CIPHER *c); > __owur const char *SSL_CIPHER_get_name(const SSL_CIPHER *c); > __owur uint32_t SSL_CIPHER_get_id(const SSL_CIPHER *c); > __owur int SSL_CIPHER_get_kx_nid(const SSL_CIPHER *c); > __owur int SSL_CIPHER_get_auth_nid(const SSL_CIPHER *c); > __owur int SSL_CIPHER_is_aead(const SSL_CIPHER *c); > > which is great, but we seem to be missing an accessor to get the MAC. If you fancy raising a github PR to add it then I will review it. Matt From appro at openssl.org Wed Aug 17 09:01:32 2016 From: appro at openssl.org (Andy Polyakov) Date: Wed, 17 Aug 2016 11:01:32 +0200 Subject: [openssl-dev] weird linker warnings on solaris 11 In-Reply-To: References: <238d99be-d9d3-16d8-8056-84777b4186fe@openssl.org> Message-ID: <57db8330-a22b-bffa-fbe4-13173179edcd@openssl.org> >>> I went back to the 12.4 compiler which works very well, waste of my time >>> to debug Oracle compiler, as we wont see any patches released anyway (no support here) >> >> And I installed vendor compiler, 12.5, and I don't observe linker >> warnings... > > interesting, can I ask which Solaris version you were running ? > I was running 11.3 (no SRU's), so still concerned this might > come back when Solaris 12 ships 11.3 too. But probably more relevant question is what is your *linker* version. Question is more or less rhetorical, because I'm not in position to draw any conclusions based on particular version number. I can only state that I myself get 5.11-1.2458 in reply to 'ld -V'. Though it might be worth noting that cc calls /usr/ccs/bin/ld, while gcc - /usr/bin/ld. But in my case these two are identical (though not hard- or sym-linked). >> On related note one should probably point out that x86[_64] compilation >> with vendor compiler leaves out AVX and Broadwell code paths. This means >> that you won't get adequate performance on latest hardware. But gcc >> build should work with application compiled with vendor compiler, so why >> not adhere to just that? I mean build OpenSSL with gcc and your >> application with compiler of your choice, be it gcc or any particular >> vendor compiler version. >> > > I may do that. I wasnt aware that AVX/Broadwell didnt build with cc (64-bit) > I was aware of lack of 32-bit asm support, so my 32-bit builds were using gcc > Thanks for looking. To be completely accurate it boils down to *assembler* rather than compiler. If gcc used vendor assembler, /usr/ccs/bin/as, then AVX/Broadwell code would be left out too. But fortunately gcc available from Oracle repository uses /usr/gnu/bin/as, and version I have is 2.23.1, which is sufficient for AVX1, AVX2 and Broadwell. From appro at openssl.org Wed Aug 17 09:50:48 2016 From: appro at openssl.org (Andy Polyakov) Date: Wed, 17 Aug 2016 11:50:48 +0200 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: References: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> <81fdfb0a-c7b2-81e4-a5bd-069d33256927@openssl.org> <5a6a9472-1c3c-f78d-4ec7-380bb9a90d38@openssl.org> Message-ID: <777df38b-b979-4d24-ebf5-a91ecd1e2a9c@openssl.org> >>> My understand after talking with Vlad that the "sbb \$0, $acc2" makes >>> this equivalent to (r >= 2**256) ? (r - q) : r. If the "sbb \$0, >>> $acc2" line were removed then it would be equivalent to (r >= q) ? (r >>> - q) : r. My understanding is that the difference in semantics is >>> exactly the difference between partially reduced results and fully >>> reduced results. >> >> Let's recall that result of multiplication prior final reduction is >> actually n+1-limb value, with +1 limb being single bit, that's $acc2, >> 5th limb in the context. So that the $0 in last 'sbb \$0,$acc2' >> represents 5th ("imaginary") limb of modulus[!]. And since we're looking >> at borrow from this 5-limb subtraction, outcome is actually >> >> if (ret > P) ret -= P' > > OK, let's agree on that. Actually correct expression is 'if (ret >= P) ret -= P'. > I think you are assuming that ret is in the range [0, 2P), so that if > you subtract P, the result would be in the range [0, P). That is the > case in normal Montgomery multiplication, where the inputs are in the > range [0, P). But, my understanding is that if the inputs are in the > range [P, 2**256), e.g. they are the result of ecp_nistz256_add, then > that assumption doesn't necessarily hold. Looks like you are right. I mean it indeed appears to be possible for multiplication (and squaring) subroutine to return partially reduced result. But *only* if input was partially reduced. I.e. if input is fully reduced, the output *shall* be too. And if input is not fully reduced, then output *can* be. And condition for "can" appears somewhat tricky. If not fully reduced input was force-reduced and final condition in 'if (ret >= P) ret -= P' was true, then output would be not fully reduced. > I understand Almost Montgomery Multiplication (AMM) as described in > [1], where one accepts inputs in the range [0, 2**n] and returns a > result in the range [0, 2**n), not [0, P). And that one checks only the top bit. This means that partially reduced output is possible even for fully reduced input. > I also read the original paper on the ecp_nistz256 implementation [2], > which has "0 ? a, b < p" as a precondition for the Montgomery > multiplication. > > To put my concern another way: Earlier in the thread, you said the > function can take inputs that aren't fully reduced--i.e. are in in the > range [0, 2**n)--and returns outputs that are fully reduced--i.e. in > the range [0, P) I was wrong, sorry about confusion. From rt at openssl.org Wed Aug 17 10:07:26 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 17 Aug 2016 10:07:26 +0000 Subject: [openssl-dev] [openssl.org #4644] bug: cert verification always examining entire chain In-Reply-To: References: Message-ID: Closing this - "working as designed". Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4644 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 17 10:08:15 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 17 Aug 2016 10:08:15 +0000 Subject: [openssl-dev] [openssl.org #4646] [1.0.2 stable branch] .\crypto\pem\pvkfmt.c(279): error C2065: 'PEM_R_HEADER_TOO_LONG': undeclared identifier In-Reply-To: <92be48f8-2569-299a-9a69-28cf29611099@hogyros.de> References: <92be48f8-2569-299a-9a69-28cf29611099@hogyros.de> Message-ID: This should be fixed now. Closing. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4646 Please log in as guest with password guest if prompted From andrea.grandi at intel.com Wed Aug 17 10:40:28 2016 From: andrea.grandi at intel.com (Grandi, Andrea) Date: Wed, 17 Aug 2016 10:40:28 +0000 Subject: [openssl-dev] Error with async speed in OpenSSL 1.1.0-pre6 Message-ID: <02DF9A39E1EE92419A8C5BBE62973A231A59BDA2@IRSMSX108.ger.corp.intel.com> Hello! We observed a failure when running speed with async jobs in the latest beta release. > openssl speed -elapsed -async_jobs 1 dsa512 You have chosen to measure elapsed time instead of user CPU time. Doing 512 bit sign dsa's for 10s: 70486 512 bit DSA signs in 10.00s DSA verify failure. No DSA verify will be done. OpenSSL 1.1.0-pre6 (beta) 4 Aug 2016 built on: reproducible build, date unspecified options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -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 -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib64/engines-1.1\"" -Wa,--noexecstack I believe that this is caused by the following commit: https://github.com/openssl/openssl/commit/0930e07d1eb522e663abe543ee865a508749946e The changes were not necessary and the allocation of siglen in a separate buffer is actually required for the async jobs to work correctly. After this commit the siglen is stored directly in tempargs. When we start the ASYNC_JOB the struct is copied into the new execution context and all the changes done to siglen are visible only inside the ASYNC_JOB. When the ASYNC_JOB finishes the async infrastructure does not copy the struct back in speed. This is a design decision and not a bug in the async code. In order to solve the error we need to pass siglen as a pointer so that the correct value is visible also from the caller (i.e. speed) and the verify operation can complete successfully. Reverting the commit solves the problem: git revert 0930e07d1eb522e663abe543ee865a508749946e > openssl speed -elapsed -async_jobs 1 dsa512 You have chosen to measure elapsed time instead of user CPU time. Doing 512 bit sign dsa's for 10s: 70485 512 bit DSA signs in 9.99s Doing 512 bit verify dsa's for 10s: 119001 512 bit DSA verify in 10.00s OpenSSL 1.1.0-pre6 (beta) 4 Aug 2016 built on: reproducible build, date unspecified options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -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 -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib64/engines-1.1\"" -Wa,--noexecstack sign verify sign/s verify/s dsa 512 bits 0.000142s 0.000084s 7055.6 11900.1 Here is the link to the pull request: https://github.com/openssl/openssl/pull/1462 What do you think? Kind regards, Andrea -------------------------------------------------------------- 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 rt at openssl.org Wed Aug 17 11:14:38 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Wed, 17 Aug 2016 11:14:38 +0000 Subject: [openssl-dev] [openssl.org #4590] accessors without const return arguments In-Reply-To: References: <576EF43A.7010104@roumenpetrov.info> <57A25364.8050409@roumenpetrov.info> Message-ID: On Wed Aug 03 21:13:08 2016, openssl at roumenpetrov.info wrote: > > Please update documentation (status of 3.8.2016): > 1) DSA_SIG_new.pod > DSA_SIG_new() allocates and initializes a B structure. > > So now function only allocates signature. > > > 2) ECDSA_SIG_new.pod > ECDSA_SIG_new() allocates a new B structure (note: this > function also allocates the BIGNUMs) and initializes it. > > Same here, but please indicate that this is changed in 1.1. > The documentation has now been fixed, thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4590 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 17 16:15:58 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 17 Aug 2016 16:15:58 +0000 Subject: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc In-Reply-To: <838859.23452.qm@web101209.mail.kks.yahoo.co.jp> References: <838859.23452.qm@web101209.mail.kks.yahoo.co.jp> Message-ID: To only allow the use of __atomic_add_fetch when __ATOMIC_RELAXED is non-zero isn't the right move here. So it seems that different compilers either only implement a subset of the __atomic builtins, or name them differently. What was the macro defined by the DeveloperStudio compiler? __SUNPRO_C or something else? In that case, the correct method might be to exclude it, like this: #if defined(__ATOMIC_RELAXED) && !defined(__SUNPRO_C) On Mon Aug 08 08:33:34 2016, yoi_no_myoujou at yahoo.co.jp wrote: > Hello, > > % ./Configure solaris-x86-cc > % make > : > Undefined first referenced > symbol in file > __atomic_add_fetch ./libcrypto.so > ld: fatal: symbol referencing errors. No output written to > fuzz/asn1parse-test > > > % ./Configure solaris64-x86_64-cc > % make > has the same error. > > Tested on Solaris10 x86/64, with Solaris developerstudio12.5. > > > This is caused because __ATOMIC_RELAXED is #defined as 0 > in /opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h > > > Sample patch: > --- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c > +++ ./crypto/threads_pthread.c > @@ -109,7 +109,7 @@ > > int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK > *lock) > { > -#ifdef __ATOMIC_RELAXED > +#if __ATOMIC_RELAXED > *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED); > #else > if (!CRYPTO_THREAD_write_lock(lock)) > > > With this patch, > % ./Configure solaris-x86-cc > % make > % make test > passes. > > % ./Configure solaris64-x86_64-cc > % make > passes but > % make test > stops. > This is another problem, which seems to be the same as bug #4641. > > > Regards, > > --- Kiyoshi -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 17 16:18:26 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 17 Aug 2016 16:18:26 +0000 Subject: [openssl-dev] [openssl.org #4609] Configure does not honor requests for ld.gold In-Reply-To: References: Message-ID: On Fri Jul 08 09:36:42 2016, levitte wrote: > On Fri Jul 08 09:33:01 2016, noloader at gmail.com wrote: > > Hmmm... If I want to use ld.gold as my linker, the easiest path is to > > set LD=ld.gold. It makes perfect sense to some.... > > Did it work for you when doing this? > > ./config -fuse-ld=gold Jeff, please respond. -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609 Please log in as guest with password guest if prompted From erik at efca.com Wed Aug 17 16:38:35 2016 From: erik at efca.com (Erik Forsberg) Date: Wed, 17 Aug 2016 09:38:35 -0700 Subject: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc In-Reply-To: References: Message-ID: as __atomic_* is non-standard, I propose guarding with __GNUC__ The C11 standard names are atomic_* Would be nice if they could be supported ? >-- Original Message -- > >To only allow the use of __atomic_add_fetch when __ATOMIC_RELAXED is non-zero >isn't the right move here. So it seems that different compilers either only >implement a subset of the __atomic builtins, or name them differently. > >What was the macro defined by the DeveloperStudio compiler? __SUNPRO_C or >something else? In that case, the correct method might be to exclude it, like >this: > >#if defined(__ATOMIC_RELAXED) && !defined(__SUNPRO_C) > >On Mon Aug 08 08:33:34 2016, yoi_no_myoujou at yahoo.co.jp wrote: >> Hello, >> >> % ./Configure solaris-x86-cc >> % make >> : >> Undefined first referenced >> symbol in file >> __atomic_add_fetch ./libcrypto.so >> ld: fatal: symbol referencing errors. No output written to >> fuzz/asn1parse-test >> >> >> % ./Configure solaris64-x86_64-cc >> % make >> has the same error. >> >> Tested on Solaris10 x86/64, with Solaris developerstudio12.5. >> >> >> This is caused because __ATOMIC_RELAXED is #defined as 0 >> in /opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h >> >> >> Sample patch: >> --- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c >> +++ ./crypto/threads_pthread.c >> @@ -109,7 +109,7 @@ >> >> int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK >> *lock) >> { >> -#ifdef __ATOMIC_RELAXED >> +#if __ATOMIC_RELAXED >> *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED); >> #else >> if (!CRYPTO_THREAD_write_lock(lock)) >> >> >> With this patch, >> % ./Configure solaris-x86-cc >> % make >> % make test >> passes. >> >> % ./Configure solaris64-x86_64-cc >> % make >> passes but >> % make test >> stops. >> This is another problem, which seems to be the same as bug #4641. >> >> >> Regards, >> >> --- Kiyoshi > > >-- >Richard Levitte >levitte at openssl.org > >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 >Please log in as guest with password guest if prompted > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Wed Aug 17 17:27:06 2016 From: rt at openssl.org (Mark Csaba via RT) Date: Wed, 17 Aug 2016 17:27:06 +0000 Subject: [openssl-dev] [openssl.org #4650] BUG: parsing CRL with openssl In-Reply-To: References: Message-ID: Hello, ? I have a large CRL. It is 4503899 bytes long in DER format. ? If I try to dump it with: openssl crl -inform DER -text -noout -in /tmp/user.crl I got an error: unable to load CRL 139981611914920:error:0D09E09B:asn1 encoding routines:X509_NAME_EX_D2I:too long:x_name.c:203: 139981611914920:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:697:Field=issuer, Type=X509_CRL_INFO 139981611914920:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:697:Field=crl, Type=X509_CRL ? I tried this with: -????????? OpenSSL 1.0.2h-fips -????????? OpenSSL 1.0.1t -????????? OpenSSL 1.0.1e-fips Only OpenSSL 1.0.1e-fips ran without error and dumped the CRL. Since one version ran smoothly I suppose the command is correct. ? Is it really a bug in 1.0.2h or 1.0.2h needs different parameters? ? Cheers Csaba -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4650 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 6897 bytes Desc: not available URL: From rt at openssl.org Wed Aug 17 17:27:06 2016 From: rt at openssl.org (Brian Morton via RT) Date: Wed, 17 Aug 2016 17:27:06 +0000 Subject: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file In-Reply-To: References: Message-ID: Attempting to decrypt/decode a large smime encoded file created with openssl fails regardless of the amount of OS memory available. OpenSSL version 1.0.2d Ubuntu 15.10 Linux 4.2.0-41 x86_64 Create keypair: openssl req -x509 -nodes -newkey rsa:2048 \ -keyout mysqldump-secure.priv.pem \ -out mysqldump-secure.pub.pem To create such a file on Linux: dd if=/dev/urandom of=sample.txt bs=2G count=1 Encrypt/encode openssl smime -encrypt -binary -text -aes256 -in sample.txt -out sample.txt.enc -outform DER mysqldump-secure.pub.pem Now decrypt/decode: openssl smime -decrypt -binary -inkey mysqldump-secure.priv.pem -inform DEM -in sample.txt.enc -out sample.txt.restored *Error reading S/MIME message* *140081024444064:error:07069041:memory buffer routines:BUF_MEM_grow_clean:malloc failure:buffer.c:159:* *140081024444064:error:0D06B041:asn1 encoding routines:ASN1_D2I_READ_BIO:malloc failure:a_d2i_fp.c:255:* Note that this problem occurs even on a system with 30GB+ of memory free. Glad to take a stab at a patch if someone can point me in the right direction as to the internal limitation. Thank you, Brian Morton -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651 Please log in as guest with password guest if prompted From rt at openssl.org Thu Aug 11 16:56:11 2016 From: rt at openssl.org (Gueron, Shay via RT) Date: Thu, 11 Aug 2016 16:56:11 +0000 Subject: [openssl-dev] [openssl.org #4645] Multi Block (MB) SHA384 for x86_64 architectures that support AVX2/AVX512 instructions set In-Reply-To: <3DE91BD01FD68540858FC917201D9B995C1506B6@hasmsx107.ger.corp.intel.com> References: <3DE91BD01FD68540858FC917201D9B995C1506B6@hasmsx107.ger.corp.intel.com> Message-ID: Hello all, This patch is a contribution to OpenSSL. It includes a Multi Block (MB) SHA384 implementation. The patch adds Multi Block feature for SHA384 Hashing as a standalone. The patch includes SHA384 Multi Block implementation for x86_64 architecture that support AVX2 & AVX512. This patch enhances the performance of parallelized hashing on SHA384, and adds the feature of standalone Multi Block using the OpenSSL API. The performance gains can be observed by invoking "openssl speed -mb -evp sha384", which was also added to "speed". This patch extends over the previous patches [1,[2],[3], and incorporates them as well. The patch requires updated binutils (tested with binutils version 2.25) and gcc (tested with gcc 5.2.0). Results: using "speed" on 8192 bytes buffers input(in cycles/byte) SHA384 One Buffer SHA384 - Multi Block HSW: 5.90 3.85 BDW: 5.43 3.62 SKL: 5.29 3.38 Speedup of SHA384 Multi Block compared to one buffer (8192 bytes input): SHA384 - Multi Block HSW: 1.53x BDW: 1.5x SKL: 1.56x [1] Patch #3850 - Improved performance Multi Block CBC-SHA1 and CBC-SHA256. https://mta.openssl.org/pipermail/openssl-dev/2015-May/001417.html [2] Patch #4221 - Accelerating Multi Block (MB) CBC SHA256 on architectures that support AVX512 instructions set http://openssl.6102.n7.nabble.com/openssl-org-4221-PATCH-Accelerating-Multi-Block-MB-CBC-SHA256-on-architectures-that-support-AVX512-it-td62058.html [3] Patch #4307 - Multi Block (MB) SHA512 for x86_64 architectures that support AVX2/AVX512 instructions set http://openssl.6102.n7.nabble.com/openssl-org-4307-PATCH-Multi-Block-MB-SHA512-for-x86-64-Architectures-that-support-AVX2-AVX512-instrt-td63716.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. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4645 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: sha_mb_iv_FINAL.PATCH Type: application/octet-stream Size: 307702 bytes Desc: not available URL: From rt at openssl.org Wed Aug 17 17:28:53 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 17 Aug 2016 17:28:53 +0000 Subject: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file In-Reply-To: References: Message-ID: You'll need to move to a machine with bigger int's. The code currently uses int, not size_t. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 17 18:01:47 2016 From: rt at openssl.org (Brian Morton via RT) Date: Wed, 17 Aug 2016 18:01:47 +0000 Subject: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file In-Reply-To: References: Message-ID: Hi Rich, This is a 64 bit kernel on AMD64 architecture. Do I need ints bigger than that? Any reason not to patch the code with size_t? I could craft such a change for a ticket if desired. Thanks, Brian On Wed, Aug 17, 2016 at 1:28 PM, Rich Salz via RT wrote: > You'll need to move to a machine with bigger int's. The code currently uses > int, not size_t. > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651 > Please log in as guest with password guest if prompted > > -- Brian Morton Morton Software Insights 404-667-1095 bmorton at mortoninsights.com -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651 Please log in as guest with password guest if prompted From rsalz at akamai.com Wed Aug 17 18:02:30 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 17 Aug 2016 18:02:30 +0000 Subject: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file In-Reply-To: References: Message-ID: Try it, it will be a huge invasive change. From rt at openssl.org Wed Aug 17 18:02:33 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 17 Aug 2016 18:02:33 +0000 Subject: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file In-Reply-To: References: Message-ID: Try it, it will be a huge invasive change. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 17 18:16:42 2016 From: rt at openssl.org (Brian Morton via RT) Date: Wed, 17 Aug 2016 18:16:42 +0000 Subject: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file In-Reply-To: References: Message-ID: That doesn't sound like an ideal case for a bugfix. Any other creative ideas on how to fix this one? Some suggestions I read previously included adding support for streaming decode to avoid such a large memory allocation. This may not easily be feasible because of needing to verify signatures on the message. If not, I'll try out the size_t change. On Wed, Aug 17, 2016 at 2:02 PM, Salz, Rich via RT wrote: > Try it, it will be a huge invasive change. > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651 > Please log in as guest with password guest if prompted > > -- Brian Morton Morton Software Insights 404-667-1095 bmorton at mortoninsights.com -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 17 21:21:34 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Wed, 17 Aug 2016 21:21:34 +0000 Subject: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc In-Reply-To: <2793.4468.qm@web101201.mail.kks.yahoo.co.jp> References: <838859.23452.qm@web101209.mail.kks.yahoo.co.jp> <2793.4468.qm@web101201.mail.kks.yahoo.co.jp> Message-ID: Yes, __SUNPRO_C is defined by DeveloperStudio compiler. > To only allow the use of __atomic_add_fetch when __ATOMIC_RELAXED is non-zero > isn't the right move here. So it seems that different compilers either only > implement a subset of the __atomic builtins, or name them differently. > > What was the macro defined by the DeveloperStudio compiler? __SUNPRO_C or > something else? In that case, the correct method might be to exclude it, like > this: > > #if defined(__ATOMIC_RELAXED) && !defined(__SUNPRO_C) > > On Mon Aug 08 08:33:34 2016, yoi_no_myoujou at yahoo.co.jp wrote: >> Hello, >> >> % ./Configure solaris-x86-cc >> % make >> : >> Undefined first referenced >> symbol in file >> __atomic_add_fetch ./libcrypto.so >> ld: fatal: symbol referencing errors. No output written to >> fuzz/asn1parse-test >> >> >> % ./Configure solaris64-x86_64-cc >> % make >> has the same error. >> >> Tested on Solaris10 x86/64, with Solaris developerstudio12.5. >> >> >> This is caused because __ATOMIC_RELAXED is #defined as 0 >> in /opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h >> >> >> Sample patch: >> --- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c >> +++ ./crypto/threads_pthread.c >> @@ -109,7 +109,7 @@ >> >> int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK >> *lock) >> { >> -#ifdef __ATOMIC_RELAXED >> +#if __ATOMIC_RELAXED >> *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED); >> #else >> if (!CRYPTO_THREAD_write_lock(lock)) >> >> >> With this patch, >> % ./Configure solaris-x86-cc >> % make >> % make test >> passes. >> >> % ./Configure solaris64-x86_64-cc >> % make >> passes but >> % make test >> stops. >> This is another problem, which seems to be the same as bug #4641. >> >> >> Regards, >> >> --- Kiyoshi > > > -- > Richard Levitte > levitte at openssl.org > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 > Please log in as guest with password guest if prompted > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 Please log in as guest with password guest if prompted From amdeich at gmail.com Wed Aug 17 22:17:04 2016 From: amdeich at gmail.com (Andrey Kulikov) Date: Thu, 18 Aug 2016 01:17:04 +0300 Subject: [openssl-dev] Multithreading performance patches In-Reply-To: <507834FD.4000909@openssl.org> References: <507834FD.4000909@openssl.org> Message-ID: Hi! > The reason is that so far it was > reserved for occasion like this, i.e. when somebody requests it and puts > effort into testing it in real-life application:-) Can we do that? I did it. Added to crypto/cryptlib.c: # ifndef OPENSSL_DISABLE_ATOMIC_ADD_INTERNAL int OPENSSL_atomic_add(int *, int, int, const char *, int); # endif and insert at the end of void OPENSSL_cpuid_setup(void) # ifndef OPENSSL_DISABLE_ATOMIC_ADD_INTERNAL CRYPTO_set_add_lock_callback(OPENSSL_atomic_add); # endif So one could disable this feature by defining OPENSSL_DISABLE_ATOMIC_ADD_INTERNAL macro at compile time. Tested on Linux x86 and x64 during last 4 years on different high-load SSL-servers. Tested on Linux x86 and x64, Windows x86 and x64 in different SSL-client applications. No issues observed. Cheers, Andrey. On 12 October 2012 at 18:19, Andy Polyakov wrote: > > I'm working on fast multithreaded TLS server for node.js, and I've > > encountered few problems with openssl threading support which I would > > like to address with attached patches. > > > > Please ask me if you have any questions or comments. > > As for 1st patch. Note that the section in question is guarded by 'if > (add_lock_callback)'. add_lock_callback can be set by application and > perform operation to its liking. In addition, on platforms with > OPENSSL_CPUID_OBJ defined there is OPENSSL_atomic_add that can be used > as callback, so that all you need to do then is > CRYPTO_set_add_lock_callback(OPENSSL_atomic_add) in application code. > Well, you'll surely get into trouble compiling this line, because > OPENSSL_atomic_add is not declared. The reason is that so far it was > reserved for occasion like this, i.e. when somebody requests it and puts > effort into testing it in real-life application:-) Can we do that? > Original idea behind OPENSSL_atomic_add was even to enable it > automatically. On related note one can also add pointer manipulation > subroutines so that one can maintain linked lists in lock-free manner... > > I'll have closer look at second patch and comment later on. > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev at openssl.org > Automated List Manager majordomo at openssl.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Aug 17 22:42:01 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Wed, 17 Aug 2016 22:42:01 +0000 Subject: [openssl-dev] [openssl.org #4650] BUG: parsing CRL with openssl In-Reply-To: References: Message-ID: It's a bug that is fixed in the current stable versions of OpenSSL and will be in the next releases. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4650 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 17 22:54:59 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Wed, 17 Aug 2016 22:54:59 +0000 Subject: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file In-Reply-To: References: Message-ID: On Wed Aug 17 18:16:41 2016, bmorton at mortoninsights.com wrote: > That doesn't sound like an ideal case for a bugfix. Any other creative > ideas on how to fix this one? Some suggestions I read previously included > adding support for streaming decode to avoid such a large memory > allocation. This may not easily be feasible because of needing to verify > signatures on the message. > A streaming decode is one option but this is far from a trivial undertaking, Verifying signatures would be handled on the fly but you'll only know the signature is valid after all content has been processed of course. > If not, I'll try out the size_t change. > This is a significant job too. There is a major knock on effect with several APIs so it's not just a case of changing a few structures or we'd have done it already. It is planned for a future release though. As RIch mentioned one of the key structures has a dependency on int which is often 32 bits even on 64 bit systems. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651 Please log in as guest with password guest if prompted From rt at openssl.org Thu Aug 18 00:40:21 2016 From: rt at openssl.org (Brian Morton via RT) Date: Thu, 18 Aug 2016 00:40:21 +0000 Subject: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file In-Reply-To: References: Message-ID: Thank you Steve (and Rich) for your insights so far. It looks like BUF_MEM is the structure in question? If so, that might also explain the odd behavior with smime encrypting which makes this issue sort of moot. Even if I could fix this, the encrypted files I've created so far would be truncated I think. I guess the safety check is to ensure that the structure works correctly with other functions that put the result into an int type internally? https://github.com/openssl/openssl/blob/3ce2fdabe6e33952bf3011acf5b68107e6352603/crypto/buffer/buffer.c#L19 Regardless of input size (2GB or 30GB) to the smime application, the resulting encrypted file is only 1.9GB on disk. Unless smime format has some very serious compression, it looks like it is silently truncating input. A 32 bit integer dependency in the read buffer might explain that. Is it related, or should I file that separately? Brian On Wed, Aug 17, 2016 at 6:54 PM, Stephen Henson via RT wrote: > On Wed Aug 17 18:16:41 2016, bmorton at mortoninsights.com wrote: > > That doesn't sound like an ideal case for a bugfix. Any other creative > > ideas on how to fix this one? Some suggestions I read previously included > > adding support for streaming decode to avoid such a large memory > > allocation. This may not easily be feasible because of needing to verify > > signatures on the message. > > > > A streaming decode is one option but this is far from a trivial > undertaking, > Verifying signatures would be handled on the fly but you'll only know the > signature is valid after all content has been processed of course. > > > If not, I'll try out the size_t change. > > > > This is a significant job too. There is a major knock on effect with > several > APIs so it's not just a case of changing a few structures or we'd have > done it > already. It is planned for a future release though. > > As RIch mentioned one of the key structures has a dependency on int which > is > often 32 bits even on 64 bit systems. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651 > Please log in as guest with password guest if prompted > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651 Please log in as guest with password guest if prompted From appro at openssl.org Thu Aug 18 11:12:50 2016 From: appro at openssl.org (Andy Polyakov) Date: Thu, 18 Aug 2016 13:12:50 +0200 Subject: [openssl-dev] ecp_nistz256 is_one is too liberal with what it considers to be one In-Reply-To: References: Message-ID: > Please see the attached program and consider the following change: > > ``` > if (P256_LIMBS == 8) { > res |= a[4] ^ ONE[4]; > res |= a[5] ^ ONE[5]; > res |= a[6] ^ ONE[6]; > + res |= a[7] ^ ONE[7]; > } It's not actually a coincidence that it ends with a[6]. If you have close look at ecp_nistz256_is_affine_G, you'll see that it also check for generator->Z.top being P256_LIMBS - P256_LIMBS / 8, or 7[!] on 32-bit platform. I.e. we can't assume that a[7] is actually an initialized value. Quite contrary actually, because there is configuration flag that will put some junk there on purpose. But yes, it contradicts second usage case of is_one... Which should be complemented with additional if (P256_LIMBS == 8 && r->Z_is_one) r->Z_is_one = (bn_get_top(r->Z) == 7); From rt at openssl.org Thu Aug 18 11:58:35 2016 From: rt at openssl.org (=?UTF-8?B?77+977+977+977+977+977+9?= via RT) Date: Thu, 18 Aug 2016 11:58:35 +0000 Subject: [openssl-dev] [openssl.org #4652] [consultation] SSL_get_error returns SSL_ERROR_SSL if read() returns -1 / EAGAIN In-Reply-To: References: Message-ID: This transaction appears to have no content -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4652 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 459 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 1072 bytes Desc: not available URL: From rt at openssl.org Thu Aug 18 12:04:42 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 18 Aug 2016 12:04:42 +0000 Subject: [openssl-dev] [openssl.org #4652] [consultation] SSL_get_error returns SSL_ERROR_SSL if read() returns -1 / EAGAIN In-Reply-To: References: Message-ID: need more content here. or post to openssl-users if you are just asking a question. https://mta.openssl.org for list information. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4652 Please log in as guest with password guest if prompted From rt at openssl.org Thu Aug 18 13:36:41 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Thu, 18 Aug 2016 13:36:41 +0000 Subject: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file In-Reply-To: References: Message-ID: On Thu Aug 18 00:40:21 2016, bmorton at mortoninsights.com wrote: > > Regardless of input size (2GB or 30GB) to the smime application, the > resulting encrypted file is only 1.9GB on disk. Unless smime format > has > some very serious compression, it looks like it is silently truncating > input. A 32 bit integer dependency in the read buffer might explain > that. > Is it related, or should I file that separately? > That's strange. It shouldn't do that. The encoding operations should work with (almost) arbitrary size input when streaming as there is no int dependency and no need to hold the complete structure in memory. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651 Please log in as guest with password guest if prompted From rt at openssl.org Thu Aug 18 14:01:03 2016 From: rt at openssl.org (Brian Morton via RT) Date: Thu, 18 Aug 2016 14:01:03 +0000 Subject: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file In-Reply-To: References: Message-ID: Ok, so this might be a separate issue. Please let me know what you think and I can file. The issue is pretty much irrelevant since you can't decrypt anything over 1.5G. Try this: bmorton at athens:~$ dd if=/dev/urandom of=sample.txt bs=512K count=6144 6144+0 records in 6144+0 records out 3221225472 bytes (3.2 GB) copied, 205.387 s, 15.7 MB/s bmorton at athens:~$ openssl smime -encrypt -binary -text -aes256 -in sample.txt -out sample.txt.enc -outform DER mysqldump-secure.pub.pem bmorton at athens:~$ ls -lh | grep sample -rw-rw-r-- 1 bmorton bmorton 3.0G Aug 18 09:48 sample.txt -rw-rw-r-- 1 bmorton bmorton 1.9G Aug 18 09:56 sample.txt.enc bmorton at athens:~$ cat sample.txt | openssl smime -encrypt -binary -text -aes256 -out sample.txt.enc -outform DER mysqldump-secure.pub.pem bmorton at athens:~$ ls -lh | grep sample -rw-rw-r-- 1 bmorton bmorton 3.0G Aug 18 09:48 sample.txt -rw-rw-r-- 1 bmorton bmorton 1.9G Aug 18 09:59 sample.txt.enc On Thu, Aug 18, 2016 at 9:36 AM, Stephen Henson via RT wrote: > On Thu Aug 18 00:40:21 2016, bmorton at mortoninsights.com wrote: > > > > Regardless of input size (2GB or 30GB) to the smime application, the > > resulting encrypted file is only 1.9GB on disk. Unless smime format > > has > > some very serious compression, it looks like it is silently truncating > > input. A 32 bit integer dependency in the read buffer might explain > > that. > > Is it related, or should I file that separately? > > > > That's strange. It shouldn't do that. The encoding operations should work > with > (almost) arbitrary size input when streaming as there is no int dependency > and > no need to hold the complete structure in memory. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651 > Please log in as guest with password guest if prompted > > -- Brian Morton Morton Software Insights 404-667-1095 bmorton at mortoninsights.com -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651 Please log in as guest with password guest if prompted From appro at openssl.org Thu Aug 18 14:24:56 2016 From: appro at openssl.org (Andy Polyakov) Date: Thu, 18 Aug 2016 16:24:56 +0200 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: <777df38b-b979-4d24-ebf5-a91ecd1e2a9c@openssl.org> References: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> <81fdfb0a-c7b2-81e4-a5bd-069d33256927@openssl.org> <5a6a9472-1c3c-f78d-4ec7-380bb9a90d38@openssl.org> <777df38b-b979-4d24-ebf5-a91ecd1e2a9c@openssl.org> Message-ID: <6e7a4e9c-abbc-d59c-f2a8-a90075326ea4@openssl.org> >> I think you are assuming that ret is in the range [0, 2P), so that if >> you subtract P, the result would be in the range [0, P). That is the >> case in normal Montgomery multiplication, where the inputs are in the >> range [0, P). But, my understanding is that if the inputs are in the >> range [P, 2**256), e.g. they are the result of ecp_nistz256_add, then >> that assumption doesn't necessarily hold. > > Looks like you are right. I mean it indeed appears to be possible for > multiplication (and squaring) subroutine to return partially reduced > result. But *only* if input was partially reduced. I.e. if input is > fully reduced, the output *shall* be too. And if input is not fully > reduced, then output *can* be. It appears to me that with multiplication, squaring, subtraction, negation, halving *preserving* property of being fully reduced (i.e. if inputs are fully reduced, then output is too), we only have to watch out for mul_by_[23], i.e. ensure that their outputs are fully reduced. This would ensure that output will always be fully reduced. In this and RT#4621 combined context one can conclude that *as long as* inputs to ecp_nistz256_point_add are fully reduced, is_equal calls work correctly, because there are no non-full-reduction-preserving calls prior them. Would you agree? From rt at openssl.org Thu Aug 18 16:15:45 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Thu, 18 Aug 2016 16:15:45 +0000 Subject: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file In-Reply-To: References: Message-ID: On Thu Aug 18 14:01:03 2016, bmorton at mortoninsights.com wrote: > Ok, so this might be a separate issue. Please let me know what you think > and I can file. The issue is pretty much irrelevant since you can't > decrypt anything over 1.5G. > > Try this: > > bmorton at athens:~$ dd if=/dev/urandom of=sample.txt bs=512K count=6144 > 6144+0 records in > 6144+0 records out > 3221225472 bytes (3.2 GB) copied, 205.387 s, 15.7 MB/s > bmorton at athens:~$ openssl smime -encrypt -binary -text -aes256 -in > sample.txt -out sample.txt.enc -outform DER mysqldump-secure.pub.pem > bmorton at athens:~$ ls -lh | grep sample > -rw-rw-r-- 1 bmorton bmorton 3.0G Aug 18 09:48 sample.txt > -rw-rw-r-- 1 bmorton bmorton 1.9G Aug 18 09:56 sample.txt.enc > bmorton at athens:~$ cat sample.txt | openssl smime -encrypt -binary -text > -aes256 -out sample.txt.enc -outform DER mysqldump-secure.pub.pem > bmorton at athens:~$ ls -lh | grep sample > -rw-rw-r-- 1 bmorton bmorton 3.0G Aug 18 09:48 sample.txt > -rw-rw-r-- 1 bmorton bmorton 1.9G Aug 18 09:59 sample.txt.enc > Try it with the -stream option. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651 Please log in as guest with password guest if prompted From kurt at roeckx.be Thu Aug 18 17:38:48 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 18 Aug 2016 19:38:48 +0200 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: <6e7a4e9c-abbc-d59c-f2a8-a90075326ea4@openssl.org> References: <81fdfb0a-c7b2-81e4-a5bd-069d33256927@openssl.org> <5a6a9472-1c3c-f78d-4ec7-380bb9a90d38@openssl.org> <777df38b-b979-4d24-ebf5-a91ecd1e2a9c@openssl.org> <6e7a4e9c-abbc-d59c-f2a8-a90075326ea4@openssl.org> Message-ID: <20160818173847.46co2dcp75karvlc@roeckx.be> On Thu, Aug 18, 2016 at 04:24:56PM +0200, Andy Polyakov wrote: > >> I think you are assuming that ret is in the range [0, 2P), so that if > >> you subtract P, the result would be in the range [0, P). That is the > >> case in normal Montgomery multiplication, where the inputs are in the > >> range [0, P). But, my understanding is that if the inputs are in the > >> range [P, 2**256), e.g. they are the result of ecp_nistz256_add, then > >> that assumption doesn't necessarily hold. > > > > Looks like you are right. I mean it indeed appears to be possible for > > multiplication (and squaring) subroutine to return partially reduced > > result. But *only* if input was partially reduced. I.e. if input is > > fully reduced, the output *shall* be too. And if input is not fully > > reduced, then output *can* be. > > It appears to me that with multiplication, squaring, subtraction, > negation, halving *preserving* property of being fully reduced (i.e. if > inputs are fully reduced, then output is too), we only have to watch out > for mul_by_[23], i.e. ensure that their outputs are fully reduced. This > would ensure that output will always be fully reduced. Can you document some of those things? Kurt From brian at briansmith.org Thu Aug 18 20:42:01 2016 From: brian at briansmith.org (Brian Smith) Date: Thu, 18 Aug 2016 10:42:01 -1000 Subject: [openssl-dev] ecp_nistz256 is_one is too liberal with what it considers to be one In-Reply-To: References: Message-ID: Andy Polyakov wrote: >> if (P256_LIMBS == 8) { >> res |= a[4] ^ ONE[4]; >> res |= a[5] ^ ONE[5]; >> res |= a[6] ^ ONE[6]; >> + res |= a[7] ^ ONE[7]; >> } > > It's not actually a coincidence that it ends with a[6]. If you have > close look at ecp_nistz256_is_affine_G, you'll see that it also check > for generator->Z.top being P256_LIMBS - P256_LIMBS / 8, or 7[!] on > 32-bit platform. I.e. we can't assume that a[7] is actually an > initialized value. Quite contrary actually, because there is > configuration flag that will put some junk there on purpose. But yes, it > contradicts second usage case of is_one... Which should be complemented > with additional > > if (P256_LIMBS == 8 && r->Z_is_one) > r->Z_is_one = (bn_get_top(r->Z) == 7); 1. The is_one function should work like is_zero and look at all the limbs. Clearly, that's what people expected it to do, given the current bug. If ecp_nistz256_is_affine_G needs different logic then that different logic should be inlined into it. Note that the use in ecp_nistz256_is_affine_G doesn't need to be constant-time so there are lots of options for changing it. 2. The Z_is_one member isn't very useful and is error-prone in general. It can be removed relatively easily. See [1]. So, I recommend removing Z_is_one, and then inlining the is_one function into ecp_nistz256_is_affine_G so that nobody misuses it in the future for something else. [1] https://boringssl.googlesource.com/boringssl/+/081e3f34a2b324edce50b7a5df9b2e283781af7b%5E%21/ Cheers, Brian -- https://briansmith.org/ From brian at briansmith.org Thu Aug 18 23:34:34 2016 From: brian at briansmith.org (Brian Smith) Date: Thu, 18 Aug 2016 13:34:34 -1000 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: <6e7a4e9c-abbc-d59c-f2a8-a90075326ea4@openssl.org> References: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> <81fdfb0a-c7b2-81e4-a5bd-069d33256927@openssl.org> <5a6a9472-1c3c-f78d-4ec7-380bb9a90d38@openssl.org> <777df38b-b979-4d24-ebf5-a91ecd1e2a9c@openssl.org> <6e7a4e9c-abbc-d59c-f2a8-a90075326ea4@openssl.org> Message-ID: Andy Polyakov wrote: > It appears to me that with multiplication, squaring, subtraction, > negation, halving *preserving* property of being fully reduced (i.e. if > inputs are fully reduced, then output is too), we only have to watch out > for mul_by_[23], i.e. ensure that their outputs are fully reduced. This > would ensure that output will always be fully reduced. Let me state thing in a different way, and see if this is what you meant: Every function will have as a prerequisite that its inputs are fully reduced and will have a postcondition that its output is fully reduced. We know that ecp_nistz256_add doesn't fully reduce its output even if the input is fully reduced, and we know that ecp_nistz256_mul_by_[23] are implemented in terms of ecp_nistz256_add (or equivalent logic, in the case of some of the ASM stuff). Accordingly, the plan of action is: * Fix ecp_nistz256_mul_by_2 and ecp_nistz256_mul_by_3 to fully reduce their outputs. * Fix ecp_nistz256_add to fully reduce its output. * Ensure in ecp_nistz256_points_mul that all the input coordinates are fully reduced. After all of this, we won't have to worry about the handling of partially-reduced values anywhere. Is that correct? In particular, you said "we only have to watch out for mul_by_[23]" but you didn't mention ecp_nistz256_add, which *is* used directly in ecp_nistz256_point_double, according to the reference C implementation. I think that is a reasonable course of action. I'd like to suggest the following additional steps: * Verify with Vlad that he agrees with our assessment of the current state of the code and the plan. In particular, I still worry that what we agreed on here doesn't match what Vlad told me before. Maybe Vlad was thinking about some other code he wrote that uses the Almost Montgomery math instead of regular Montgomery math. But maybe he knows something we are overlooking. In particular, we should ask him and Shay whether they intentionally made ecp_nistz256_add (et al.) return partially-reduced results because they'd proven that full reduction isn't necessary given the subsequent statements. * Document in the top of ecp_nistz256.c the input and output bounds are [0, P256) for all field operations. * Test some interesting edge cases of all the functions to verify that they generate the correct output. (This series of bug reports started by me doing this, starting with ecp_nistz256_add.) * Because we can't easily test it, audit the inlined code inside the assembly langauge implementations of ecp_nistz256_{double, add, add_affine} to ensure that it matches the logic within the standalone functions that we can write tests for. (As you noted, in many cases, the standalone field arithmetic functions and the inline variants actually share code; in some cases, however, they don't.) > In this and RT#4621 combined context one can conclude that *as long as* > inputs to ecp_nistz256_point_add are fully reduced, is_equal calls work > correctly, because there are no non-full-reduction-preserving calls > prior them. Would you agree? If all functions have the postcondition that they always fully reduce their outputs then I agree that the is_equal calls are correct, and also that the ecp_nistz256_neg function seems to be correct since it gives the expected results when given fully reduced inputs. Cheers, Brian -- https://briansmith.org/ From rt at openssl.org Fri Aug 19 00:55:55 2016 From: rt at openssl.org (Brian Morton via RT) Date: Fri, 19 Aug 2016 00:55:55 +0000 Subject: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file In-Reply-To: References: Message-ID: Very helpful, thanks! So that's not an actual issue. Which do you think is more pressing from your project's perspective: removing BUF_MEM dependency on int, or streaming decode for smime? While certainly non-trivial, the latter is certainly more isolated for a newcomer. On the other hand, the former may be more pressing overall. I don't know what kind of challenges it presents in other tools to have a 32 bit mem buffer size limit. On Thu, Aug 18, 2016 at 12:15 PM, Stephen Henson via RT wrote: > On Thu Aug 18 14:01:03 2016, bmorton at mortoninsights.com wrote: > > Ok, so this might be a separate issue. Please let me know what you think > > and I can file. The issue is pretty much irrelevant since you can't > > decrypt anything over 1.5G. > > > > Try this: > > > > bmorton at athens:~$ dd if=/dev/urandom of=sample.txt bs=512K count=6144 > > 6144+0 records in > > 6144+0 records out > > 3221225472 bytes (3.2 GB) copied, 205.387 s, 15.7 MB/s > > bmorton at athens:~$ openssl smime -encrypt -binary -text -aes256 -in > > sample.txt -out sample.txt.enc -outform DER mysqldump-secure.pub.pem > > bmorton at athens:~$ ls -lh | grep sample > > -rw-rw-r-- 1 bmorton bmorton 3.0G Aug 18 09:48 sample.txt > > -rw-rw-r-- 1 bmorton bmorton 1.9G Aug 18 09:56 sample.txt.enc > > bmorton at athens:~$ cat sample.txt | openssl smime -encrypt -binary -text > > -aes256 -out sample.txt.enc -outform DER mysqldump-secure.pub.pem > > bmorton at athens:~$ ls -lh | grep sample > > -rw-rw-r-- 1 bmorton bmorton 3.0G Aug 18 09:48 sample.txt > > -rw-rw-r-- 1 bmorton bmorton 1.9G Aug 18 09:59 sample.txt.enc > > > > Try it with the -stream option. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651 > Please log in as guest with password guest if prompted > > -- Brian Morton Morton Software Insights 404-667-1095 bmorton at mortoninsights.com -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651 Please log in as guest with password guest if prompted From rt at openssl.org Fri Aug 19 01:52:31 2016 From: rt at openssl.org (=?UTF-8?B?77+977+977+977+977+977+9?= via RT) Date: Fri, 19 Aug 2016 01:52:31 +0000 Subject: [openssl-dev] reply: [openssl.org #4652] [consultation] SSL_get_error returns SSL_ERROR_SSL if read() returns -1 / EAGAIN In-Reply-To: References: Message-ID: This transaction appears to have no content -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4652 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 1024 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 3673 bytes Desc: not available URL: From rt at openssl.org Fri Aug 19 02:11:01 2016 From: rt at openssl.org (=?UTF-8?B?77+977+977+977+977+977+9?= via RT) Date: Fri, 19 Aug 2016 02:11:01 +0000 Subject: [openssl-dev] reply: [openssl.org #4652] [consultation] SSL_get_error returns SSL_ERROR_SSL if read() returns -1 / EAGAIN In-Reply-To: References: Message-ID: This transaction appears to have no content -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4652 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 387 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 1801 bytes Desc: not available URL: From rt at openssl.org Fri Aug 19 02:22:34 2016 From: rt at openssl.org (xiaoma huang via RT) Date: Fri, 19 Aug 2016 02:22:34 +0000 Subject: [openssl-dev] reply: [openssl.org #4652] [consultation] SSL_get_error returns SSL_ERROR_SSL if read() returns -1 / EAGAIN In-Reply-To: References: Message-ID: I've met a similar problem as Sami Farin described in the following ticket: https://rt.openssl.org/Ticket/Display.html?id=1608 SSL_get_error reports SSL_ERROR_SSL and I get errno 11 (i.e. EAGAIN) after calling SSL_read. And I have OpenSSL version 1.0.1h. How can I avoid this problem? I am looking forwards to your help. Thanks! Sinserely yours Davy Huang -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4652 Please log in as guest with password guest if prompted From appro at openssl.org Fri Aug 19 09:03:51 2016 From: appro at openssl.org (Andy Polyakov) Date: Fri, 19 Aug 2016 11:03:51 +0200 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: References: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> <81fdfb0a-c7b2-81e4-a5bd-069d33256927@openssl.org> <5a6a9472-1c3c-f78d-4ec7-380bb9a90d38@openssl.org> <777df38b-b979-4d24-ebf5-a91ecd1e2a9c@openssl.org> <6e7a4e9c-abbc-d59c-f2a8-a90075326ea4@openssl.org> Message-ID: <11a1fcfd-798f-f0a7-c1e0-dd5fe94773c5@openssl.org> >> It appears to me that with multiplication, squaring, subtraction, >> negation, halving *preserving* property of being fully reduced (i.e. if >> inputs are fully reduced, then output is too), we only have to watch out >> for mul_by_[23], i.e. ensure that their outputs are fully reduced. This >> would ensure that output will always be fully reduced. > > Let me state thing in a different way, and see if this is what you > meant: Every function will have as a prerequisite that its inputs are > fully reduced and will have a postcondition that its output is fully > reduced. Assertion is that every function but addition and mul_by_[23] *has* (not "will have", but "has") such postcondition that their outputs are fully reduced as long as inputs are. Not to mention that multiplication (and squaring) *can* (or should we say "is likely to") produce fully reduced output even if inputs are not fully reduced. > We know that ecp_nistz256_add doesn't fully reduce its output > even if the input is fully reduced, and we know that > ecp_nistz256_mul_by_[23] are implemented in terms of ecp_nistz256_add > (or equivalent logic, in the case of some of the ASM stuff). > Accordingly, the plan of action is: > > * Fix ecp_nistz256_mul_by_2 and ecp_nistz256_mul_by_3 to fully reduce > their outputs. > > * Fix ecp_nistz256_add to fully reduce its output. As for specifically addition see below. As for fixing mul_by_[23] and the fact that they use addition. There are two ways. a) Modify addition so that it *preserves* property of being fully reduced and leave mul_by_[23] as is. b) Let addition as is and add additional step to mul_by_[23]. The choice of approach can be platform-specific. For example on x86_64 a) is simpler and appears more efficient. But on some platforms b) could be better option. > * Ensure in ecp_nistz256_points_mul that all the input coordinates are > fully reduced. I didn't mean to add any additional steps, but simply see that inputs should be fully reduced. Simply put question is if output from conversion to Montgomery representation is fully reduced. And then as all involved subroutines would *preserve* the property, everything remains fully reduced throughout the complete course. > After all of this, we won't have to worry about the handling of > partially-reduced values anywhere. > > Is that correct? In particular, you said "we only have to watch out > for mul_by_[23]" but you didn't mention ecp_nistz256_add, which *is* > used directly in ecp_nistz256_point_double, according to the reference > C implementation. Rationale behind not explicitly mentioning addition is following sequence from ecp_nistz256_point_double: ecp_nistz256_add(M, in_x, Zsqr); ecp_nistz256_mul_mont(M, M, Zsqr); ecp_nistz256_mul_by_3(M, M); ecp_nistz256_sqr_mont(res_x, M); It doesn't matter if addition returns partially reduced result, as long as mul_by_3 ties it up. From rt at openssl.org Fri Aug 19 11:50:43 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 19 Aug 2016 11:50:43 +0000 Subject: [openssl-dev] [openssl.org #4652] [consultation] SSL_get_error returns SSL_ERROR_SSL if read() returns -1 / EAGAIN In-Reply-To: References: Message-ID: Same situation, please use a current/modern release; 1.0.1 is only getting security fixes. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4652 Please log in as guest with password guest if prompted From rt at openssl.org Fri Aug 19 14:20:21 2016 From: rt at openssl.org (Simon Richter via RT) Date: Fri, 19 Aug 2016 14:20:21 +0000 Subject: [openssl-dev] [openssl.org #4653] [1.0.2] fails to compile on VC-WIN32 In-Reply-To: References: Message-ID: Hi, the 1.0.2 branch fails to compile for me: link /nologo /subsystem:console /opt:ref /debug /out:out32dll\dtlstest.exe @C:\Windows\TEMP\nm8D73.tmp Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_ctx_pair referenced in function _test_dtls_unprocessed dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_objects referenced in function _test_dtls_unprocessed dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_connection referenced in function _test_dtls_unprocessed dtlstest.obj : error LNK2019: unresolved external symbol _bio_f_tls_dump_filter referenced in function _test_dtls_unprocessed dtlstest.obj : error LNK2019: unresolved external symbol _mempacket_test_inject referenced in function _test_dtls_unprocessed out32dll\dtlstest.exe : fatal error LNK1120: 5 unresolved externals Changes in this build: http://ci.kicad-pcb.org/job/windows-openssl-msvc/build=release,cpu=x86,label=windows/458/changes' Full build log: http://ci.kicad-pcb.org/job/windows-openssl-msvc/build=release,cpu=x86,label=windows/458/consoleFull Simon -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4653 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From rt at openssl.org Fri Aug 19 14:40:02 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Fri, 19 Aug 2016 14:40:02 +0000 Subject: [openssl-dev] [openssl.org #4653] [1.0.2] fails to compile on VC-WIN32 In-Reply-To: References: Message-ID: We totally missed out on adapting util/mk1mf.pl. Fix on its way. On Fri Aug 19 14:20:20 2016, Simon.Richter at hogyros.de wrote: > Hi, > > the 1.0.2 branch fails to compile for me: > > link /nologo /subsystem:console /opt:ref /debug > /out:out32dll\dtlstest.exe @C:\Windows\TEMP\nm8D73.tmp > Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp > dtlstest.obj : error LNK2019: unresolved external symbol > _create_ssl_ctx_pair referenced in function _test_dtls_unprocessed > dtlstest.obj : error LNK2019: unresolved external symbol > _create_ssl_objects referenced in function _test_dtls_unprocessed > dtlstest.obj : error LNK2019: unresolved external symbol > _create_ssl_connection referenced in function _test_dtls_unprocessed > dtlstest.obj : error LNK2019: unresolved external symbol > _bio_f_tls_dump_filter referenced in function _test_dtls_unprocessed > dtlstest.obj : error LNK2019: unresolved external symbol > _mempacket_test_inject referenced in function _test_dtls_unprocessed > out32dll\dtlstest.exe : fatal error LNK1120: 5 unresolved externals > > Changes in this build: > > http://ci.kicad-pcb.org/job/windows-openssl- > msvc/build=release,cpu=x86,label=windows/458/changes' > > Full build log: > > http://ci.kicad-pcb.org/job/windows-openssl- > msvc/build=release,cpu=x86,label=windows/458/consoleFull > > Simon -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4653 Please log in as guest with password guest if prompted From rt at openssl.org Fri Aug 19 14:45:30 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 19 Aug 2016 14:45:30 +0000 Subject: [openssl-dev] [openssl.org #4386] [PATCH] Add sanity checks for BN_new() in OpenSSL-1.0.2g In-Reply-To: References: Message-ID: Fixed with commit a03f81f, will be part of next 1.0.2 release. Thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4386 Please log in as guest with password guest if prompted From rt at openssl.org Fri Aug 19 14:46:12 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 19 Aug 2016 14:46:12 +0000 Subject: [openssl-dev] [openssl.org #4384] [PATCH] Missing Sanity Check plus potential NULL pointer deref (CWE-476) In-Reply-To: References: Message-ID: Fixed with commit a03f81f, will be part of next 1.0.2 release. Thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4384 Please log in as guest with password guest if prompted From rt at openssl.org Fri Aug 19 14:46:43 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 19 Aug 2016 14:46:43 +0000 Subject: [openssl-dev] [openssl.org #4383] [PATCH] Add error checking for bn2_expand()/BN_new()/RSA_new_method() in file 'e_chil.c' for OpenSSL-1.0.2g In-Reply-To: References: Message-ID: Fixed with commit a03f81f, will be part of next 1.0.2 release. Thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4383 Please log in as guest with password guest if prompted From rt at openssl.org Fri Aug 19 14:47:03 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 19 Aug 2016 14:47:03 +0000 Subject: [openssl-dev] [openssl.org #4370] [PATCH] Potential for NULL pointer dereferences in OpenSSL-1.0.2g (CWE-476) In-Reply-To: References: Message-ID: Fixed with commit a03f81f, will be part of next 1.0.2 release. Thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4370 Please log in as guest with password guest if prompted From rt at openssl.org Fri Aug 19 14:47:25 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 19 Aug 2016 14:47:25 +0000 Subject: [openssl-dev] [openssl.org #4371] [PATCH] Missing Sanity Check for malloc() in openssl-1.0.2g for 'apps/speed.c' In-Reply-To: References: Message-ID: Fixed with commit a03f81f, will be part of next 1.0.2 release. Thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4371 Please log in as guest with password guest if prompted From rt at openssl.org Fri Aug 19 14:47:46 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 19 Aug 2016 14:47:46 +0000 Subject: [openssl-dev] [openssl.org #4374] [PATCH] Potential for NULL pointer dereferences in OpenSSL-1.0.2g (CWE-476) In-Reply-To: References: Message-ID: Fixed with commit a03f81f, will be part of next 1.0.2 release. Thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4374 Please log in as guest with password guest if prompted From rt at openssl.org Fri Aug 19 14:48:14 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 19 Aug 2016 14:48:14 +0000 Subject: [openssl-dev] [openssl.org #4385] [PATCH] Missing Sanity Checks for RSA_new_method() in OpenSSL-1.0.2g In-Reply-To: References: Message-ID: Fixed with commit a03f81f, will be part of next 1.0.2 release. Thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4385 Please log in as guest with password guest if prompted From rt at openssl.org Fri Aug 19 14:49:13 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 19 Aug 2016 14:49:13 +0000 Subject: [openssl-dev] [openssl.org #4375] [PATCH] Missing Sanity Checks for OPENSSL_malloc() in OpenSSL-1.0.2g In-Reply-To: References: Message-ID: Fixed with commit a03f81f, will be part of next 1.0.2 release. Thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4375 Please log in as guest with password guest if prompted From rt at openssl.org Fri Aug 19 14:49:34 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 19 Aug 2016 14:49:34 +0000 Subject: [openssl-dev] [openssl.org #4382] [PATCH] Missing Sanity Check(s) for BUF_strdup() in OpenSSL-1.0.2g In-Reply-To: References: Message-ID: Fixed with commit a03f81f, will be part of next 1.0.2 release. Thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4382 Please log in as guest with password guest if prompted From rt at openssl.org Fri Aug 19 14:49:53 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 19 Aug 2016 14:49:53 +0000 Subject: [openssl-dev] [openssl.org #4377] Prevent potential NULL pointer dereference in OpenSSL-1.0.2g (CWE-476) In-Reply-To: References: Message-ID: Fixed with commit a03f81f, will be part of next 1.0.2 release. Thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4377 Please log in as guest with password guest if prompted From rt at openssl.org Fri Aug 19 14:50:13 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 19 Aug 2016 14:50:13 +0000 Subject: [openssl-dev] [openssl.org #4380] [PATCH] Missing Sanity Checks for EVP_PKEY_new() in OpenSSL-1.0.2g In-Reply-To: References: Message-ID: Fixed with commit a03f81f, will be part of next 1.0.2 release. Thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4380 Please log in as guest with password guest if prompted From rt at openssl.org Fri Aug 19 15:08:29 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Fri, 19 Aug 2016 15:08:29 +0000 Subject: [openssl-dev] [openssl.org #4653] [1.0.2] fails to compile on VC-WIN32 In-Reply-To: References: Message-ID: Please try out this github pull request: https://github.com/openssl/openssl/pull/1470 Cheers, Richard On Fri Aug 19 14:40:02 2016, levitte wrote: > We totally missed out on adapting util/mk1mf.pl. Fix on its way. > > On Fri Aug 19 14:20:20 2016, Simon.Richter at hogyros.de wrote: > > Hi, > > > > the 1.0.2 branch fails to compile for me: > > > > link /nologo /subsystem:console /opt:ref /debug > > /out:out32dll\dtlstest.exe @C:\Windows\TEMP\nm8D73.tmp > > Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp > > dtlstest.obj : error LNK2019: unresolved external symbol > > _create_ssl_ctx_pair referenced in function _test_dtls_unprocessed > > dtlstest.obj : error LNK2019: unresolved external symbol > > _create_ssl_objects referenced in function _test_dtls_unprocessed > > dtlstest.obj : error LNK2019: unresolved external symbol > > _create_ssl_connection referenced in function _test_dtls_unprocessed > > dtlstest.obj : error LNK2019: unresolved external symbol > > _bio_f_tls_dump_filter referenced in function _test_dtls_unprocessed > > dtlstest.obj : error LNK2019: unresolved external symbol > > _mempacket_test_inject referenced in function _test_dtls_unprocessed > > out32dll\dtlstest.exe : fatal error LNK1120: 5 unresolved externals > > > > Changes in this build: > > > > http://ci.kicad-pcb.org/job/windows-openssl- > > msvc/build=release,cpu=x86,label=windows/458/changes' > > > > Full build log: > > > > http://ci.kicad-pcb.org/job/windows-openssl- > > msvc/build=release,cpu=x86,label=windows/458/consoleFull > > > > Simon > > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4653 Please log in as guest with password guest if prompted From rt at openssl.org Fri Aug 19 15:47:38 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 19 Aug 2016 15:47:38 +0000 Subject: [openssl-dev] [openssl.org #3940] Missing CRL checks in cms/smime cmdline utilities In-Reply-To: References: Message-ID: For now we just added a comment to master, 1.0.2, 1.0.1 in the cms.pod and smime.pod files: Note that no revocation check is done for the recipient cert, so if that key has been compromised, others may be able to decrypt the text. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3940 Please log in as guest with password guest if prompted From beldmit at gmail.com Fri Aug 19 16:18:47 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 19 Aug 2016 19:18:47 +0300 Subject: [openssl-dev] [openssl.org #3940] Missing CRL checks in cms/smime cmdline utilities In-Reply-To: References: Message-ID: Thank you very much! 19 ???. 2016 ?. 6:47 PM ???????????? "Rich Salz via RT" ???????: > For now we just added a comment to master, 1.0.2, 1.0.1 in the cms.pod and > smime.pod files: > > Note that no revocation check is done for the recipient cert, so if that > key has been compromised, others may be able to decrypt the text. > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3940 > Please log in as guest with password guest if prompted > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Aug 19 16:19:01 2016 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Fri, 19 Aug 2016 16:19:01 +0000 Subject: [openssl-dev] [openssl.org #3940] Missing CRL checks in cms/smime cmdline utilities In-Reply-To: References: Message-ID: Thank you very much! 19 ???. 2016 ?. 6:47 PM ???????????? "Rich Salz via RT" ???????: > For now we just added a comment to master, 1.0.2, 1.0.1 in the cms.pod and > smime.pod files: > > Note that no revocation check is done for the recipient cert, so if that > key has been compromised, others may be able to decrypt the text. > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3940 > Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3940 Please log in as guest with password guest if prompted From appro at openssl.org Sat Aug 20 10:06:29 2016 From: appro at openssl.org (Andy Polyakov) Date: Sat, 20 Aug 2016 12:06:29 +0200 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: <11a1fcfd-798f-f0a7-c1e0-dd5fe94773c5@openssl.org> References: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> <81fdfb0a-c7b2-81e4-a5bd-069d33256927@openssl.org> <5a6a9472-1c3c-f78d-4ec7-380bb9a90d38@openssl.org> <777df38b-b979-4d24-ebf5-a91ecd1e2a9c@openssl.org> <6e7a4e9c-abbc-d59c-f2a8-a90075326ea4@openssl.org> <11a1fcfd-798f-f0a7-c1e0-dd5fe94773c5@openssl.org> Message-ID: <5dccf6ab-1342-be67-d754-57731c6ae23d@openssl.org> >> * Fix ecp_nistz256_mul_by_2 and ecp_nistz256_mul_by_3 to fully reduce >> their outputs. >> >> * Fix ecp_nistz256_add to fully reduce its output. > > As for specifically addition see below. As for fixing mul_by_[23] and > the fact that they use addition. There are two ways. a) Modify addition > so that it *preserves* property of being fully reduced and leave > mul_by_[23] as is. b) Let addition as is and add additional step to > mul_by_[23]. The choice of approach can be platform-specific. For > example on x86_64 a) is simpler and appears more efficient. Consider attached diff. -------------- next part -------------- A non-text attachment was scrubbed... Name: ecp_nistz256-x86_64.diff Type: text/x-patch Size: 5717 bytes Desc: not available URL: From doctor at doctor.nl2k.ab.ca Sat Aug 20 12:44:49 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 20 Aug 2016 06:44:49 -0600 Subject: [openssl-dev] openssl 1.0.2 Daily Snapshot issue Message-ID: <20160820124449.o67af6cks45dmt5v@doctor.nl2k.ab.ca> /usr/local/bin/clang39 -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 -Wall -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -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 jpake.c -o jpake.o jpake.c:157:9: error: void function 'hashbn' should not return a value [-Wreturn-type] return NULL; ^ ~~~~ 1 error generated. 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 Time for the USA to hold a referendum on its republic and vote to dissolve!! From rt at openssl.org Sun Aug 21 04:04:40 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Sun, 21 Aug 2016 04:04:40 +0000 Subject: [openssl-dev] [openssl.org #4654] Failed OpenSSL 1.0.2 compile on Debian 8 with shared config option In-Reply-To: References: Message-ID: I'm working from the 1.0.2h tarball. The platform is Debian 8 (booted with syscall.x32=y, but the X32 chroot was not entered). GCC is 5.2.1. '-fPIC' was manually added after 'shared' caused the initial "relocation R_X86_64_32 ..." error. Omitting 'shared' does not witness an error. $ reset && ./config shared -fPIC no-ssl2 no-ssl3 no-comp -Wl,-rpath=/usr/local/ssl/lib --prefix=/usr/local/ssl Operating system: x86_64-whatever-linux2 Configuring for linux-x86_64 Configuring for linux-x86_64 no-comp [option] OPENSSL_NO_COMP (skip dir) no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-gmp [default] OPENSSL_NO_GMP (skip dir) no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-ssl2 [option] OPENSSL_NO_SSL2 (skip dir) no-ssl3 [option] OPENSSL_NO_SSL3 (skip dir) no-store [experimental] OPENSSL_NO_STORE (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) no-zlib [default] no-zlib-dynamic [default] IsMK1MF=0 CC =gcc CFLAG =-fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fPIC -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -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 EX_LIBS =-Wl,-rpath=/usr/local/ssl/lib -ldl CPUID_OBJ =x86_64cpuid.o BN_ASM =x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o EC_ASM =ecp_nistz256.o ecp_nistz256-x86_64.o DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o BF_ENC =bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM =md5-x86_64.o SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o RMD160_OBJ_ASM= CMLL_ENC =cmll-x86_64.o cmll_misc.o MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o ENGINES_OBJ = PROCESSOR = RANLIB =/usr/bin/ranlib ARFLAGS = PERL =/usr/bin/perl SIXTY_FOUR_BIT_LONG mode $ make depend && make ... make[2]: Entering directory '/home/openssl-1.0.2h' [ -z "" ] || gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fPIC -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -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 -Iinclude \ -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso \ fips_premain.c fipscanister.o \ libcrypto.a -Wl,-rpath=/usr/local/ssl/lib -ldl make[3]: Entering directory '/home/openssl-1.0.2h' make[4]: Entering directory '/home/openssl-1.0.2h' /usr/bin/ld: libcrypto.a(rsaz_exp.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC libcrypto.a(rsaz_exp.o): error adding symbols: Bad value collect2: error: ld returned 1 exit status Makefile.shared:169: recipe for target 'link_a.gnu' failed make[4]: *** [link_a.gnu] Error 1 make[4]: Leaving directory '/home/openssl-1.0.2h' Makefile:354: recipe for target 'do_linux-shared' failed make[3]: *** [do_linux-shared] Error 2 make[3]: Leaving directory '/home/openssl-1.0.2h' Makefile:307: recipe for target 'libcrypto.so.1.0.0' failed make[2]: *** [libcrypto.so.1.0.0] Error 2 make[2]: Leaving directory '/home/openssl-1.0.2h' Makefile:109: recipe for target 'shared' failed make[1]: *** [shared] Error 2 make[1]: Leaving directory '/home/openssl-1.0.2h/crypto' Makefile:284: recipe for target 'build_crypto' failed make: *** [build_crypto] Error 1 $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 5.2.1-20' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.2.1 20151002 (Debian 5.2.1-20) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4654 Please log in as guest with password guest if prompted From doctor at doctor.nl2k.ab.ca Sun Aug 21 11:33:58 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sun, 21 Aug 2016 05:33:58 -0600 Subject: [openssl-dev] openssl-1.0.2-stable-SNAP-20160821 issue Message-ID: <20160821113358.ywkueicjilwyraym@doctor.nl2k.ab.ca> This still exists from Opensl 1.0.2 SNAP 20160821 making all in crypto/jpake... /usr/local/bin/clang39 -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 -Wall -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -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 jpake.c -o jpake.o jpake.c:157:9: error: void function 'hashbn' should not return a value [-Wreturn-type] return NULL; ^ ~~~~ 1 error generated. *** Error code 1 Stop. make[2]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20160821/crypto/jpake *** Error code 1 Stop. make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20160821/crypto *** Error code 1 Stop. make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20160821 root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20160821 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 Time for the USA to hold a referendum on its republic and vote to dissolve!! From rt at openssl.org Sun Aug 21 15:06:55 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 21 Aug 2016 15:06:55 +0000 Subject: [openssl-dev] [openssl.org #4636] Re: [openssl.org #4625] Re: Are the point-at-infinity checks in ecp_nistz256 correct? In-Reply-To: <1cf1e041-d4ed-8111-3fa3-97b821db24f9@openssl.org> References: <1cf1e041-d4ed-8111-3fa3-97b821db24f9@openssl.org> Message-ID: Consider attached diff. > The issue is particularly clear when we multiply the generator by > zero. Note that in general, an application shouldn't multiply the > generator by zero since there's no useful cryptographic purpose for > doing so. But, this is a convenient example. > > In the code we have, > > ecp_nistz256_gather_w7(&p.a, preComputedTable[0], wvalue >> 1); > ecp_nistz256_neg(p.p.Z, p.p.Y); > copy_conditional(p.p.Y, p.p.Z, wvalue & 1); > memcpy(p.p.Z, ONE, sizeof(ONE)); > > The generator is all zeros, so we'll start off with the point (0, 0, > 1). Then we add the point at infinity over and over again, leaving > that point unchanged each time. Thus, we'll end with (0, 0, 1). Then: > > r->Z_is_one = is_one(p.p.Z) & 1; > > Thus, the resulting point will be (0, 0, 1). > > After the memcpy quoted above, we need to do a copy_conditional(p.p.Z, > is_infinity, ZERO) or equivalent, where ZERO is all-zeros and where > is_infinity is the result of checking if (x, y) == (0, 0). > > This is just one example of an edge case that is handled in a > surprising way. I think there are more, as described in the quoted > message below. > > Cheers, > Brian > > > Brian Smith wrote: >> >> Brian Smith wrote: >>> >>> When doing math on short Weierstrass curves like P-256, we have to >>> special case points at infinity. In Jacobian coordinates (X, Y, Z), >>> points at infinity have Z == 0. However, instead of checking for Z == >>> 0, p256-x86-64 instead checks for (X, Y) == (0, 0). In other words, it >>> does, in some sense, the opposite of what I expect it to do. >> >> >> I exchanged email with both of the original authors of the code, Shay and Vlad. He that the ecp_nistz256_point_* functions indeed intend to represent the point at infinity as (0, 0) and it is expected (but I did not verify) that those functions should work when the point at infinity is encoded as (0, 0, _). >> >>> The authors >>> instead decided to encode the point at infinity as (0, 0), since the >>> affine point (0, 0) isn't on the P-256 curve. It isn't clear why the >>> authors chose to do that though, since the point at infinity doesn't >>> (can't, logically) appear in the table of precomputed multiples of G >>> anyway. >> >> >> Actually, as the code says, the point at infinity implicitly occurs in the table implicitly. Obviously the accumulator point will be at infinity until at least a one bit is found in the scalar. >> >>> >>> But, it seems like the functions that do the computations, like >>> >>> ecp_nistz256_point_add and ecp_nistz256_point_add_affine, output the >>> point at infinity as (_, _, 0), not necessarily (0, 0, _). Also, >>> ecp_nistz256's EC_METHOD uses ec_GFp_simple_is_at_infinity and >>> ec_GFp_simple_point_set_to_infinity, which represent the point at >>> infinity with z == 0, not (x, y) == 0. Further ecp_nistz256_get_affine >>> uses EC_POINT_is_at_infinity, which checks z == 0, not (x, y) == 0. >>> This inconsistency is confusing, if not wrong. Given this, it seems >>> like the point-at-infinity checks in the ecp_nistz256_point_add and >>> ecp_nistz256_point_add_affine code should also be checking that z == 0 >>> instead of (x, y) == (0, 0). >> >> >> Instead, when we convert a point from EC_POINT to P256_POINT or P256_POINT_AFFINE, we should translate the (_, _, 0) form into the (0, 0, 0) form. And/or reject points at infinity as inputs to the function. Similarly, when we convert the resultant P256_POINT to an EC_POINT, we chould translate the (0, 0) encoding of the point at infinity to the (0, 0, 0) form or at least the (_, _, 0) form. >> >> In particular, consider the case where you have an EC_POINT that isn't at infinity, e.g. (x, y, 1). Then you call EC_POINT_set_to_infinity on it. Then it is (x, y, 0). Then you pass it to EC_POINT_mul/EC_POINTs_mul even though you shouldn't. >> >> Maybe the precondition of EC_POINT_mul/EC_POINTs_mul is that none of the input points are at infinity, in which case it doesn't matter. (But if so, maybe these functions should do a point-at-infinity check.) But if it is allowed to pass in the point at infinity, then the ecp_nistz256 code should translate the input point from (_, _, 0) form to (0, 0, _) form before doing the computation. It can use is_zero and copy_conditional and friends to do this. >> >> Similarly, after the computation, it should translate the (0, 0, _) form to (_, _, 0) form. In particular, it should do such a translation before the code sets Z_is_one, AFAICT. Note that the nistz256 code might be using the form (0, 0, 0) instead of (0, 0, _) in which case this translation might not be necessary. >> >> Regardless, it would be useful to write tests for these cases: >> 1. Verify that the result is correct when any of the input points are (0, 0, 0) >> 2. Verify that the result is correct when any of the input points are (_, _, 0). >> 3. Verify that the result is correct, and in particular that Z_is_one is set correctly on the result, when the final result is at infinity, especially for the cases where neither the input points are at infinity, e.g. when adding (n-1)G to 1G. >> >> Note that all of the above cases have interesting sub-cases: the G scalar is NULL, the G scalar is non-NULL and zero-valued, G scalar is a multiple of G, G scalar is larger than G. And same for the P scalars. >> >> Cheers, >> Brian >> -- >> https://briansmith.org/ >> > > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4636 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ec-ecp_nistz256-harmonize-is_infinity-with-ec_GFp_si.patch Type: text/x-patch Size: 6393 bytes Desc: not available URL: From rsalz at akamai.com Sun Aug 21 16:45:36 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 21 Aug 2016 16:45:36 +0000 Subject: [openssl-dev] openssl-1.0.2-stable-SNAP-20160821 issue In-Reply-To: <20160821113358.ywkueicjilwyraym@doctor.nl2k.ab.ca> References: <20160821113358.ywkueicjilwyraym@doctor.nl2k.ab.ca> Message-ID: <5339acd3dc4948b283267b69aa5b8a19@usma1ex-dag1mb1.msg.corp.akamai.com> It's the weekend :) > This still exists from Opensl 1.0.2 SNAP 20160821 It will be fixed soon :) From rsalz at akamai.com Sun Aug 21 16:53:08 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 21 Aug 2016 16:53:08 +0000 Subject: [openssl-dev] openssl-1.0.2-stable-SNAP-20160821 issue References: <20160821113358.ywkueicjilwyraym@doctor.nl2k.ab.ca> Message-ID: <3cf4bc069d1c4330aa34a24ecdbe5cd6@usma1ex-dag1mb1.msg.corp.akamai.com> Fixed with commit 71da19b050ba67c489b6c5f2543bf239c1947543 which should show up in the next snapshot. Thanks. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From appro at openssl.org Sun Aug 21 20:23:04 2016 From: appro at openssl.org (Andy Polyakov) Date: Sun, 21 Aug 2016 22:23:04 +0200 Subject: [openssl-dev] ecp_nistz256 is_one is too liberal with what it considers to be one In-Reply-To: References: Message-ID: >>> if (P256_LIMBS == 8) { >>> res |= a[4] ^ ONE[4]; >>> res |= a[5] ^ ONE[5]; >>> res |= a[6] ^ ONE[6]; >>> + res |= a[7] ^ ONE[7]; >>> } >> >> It's not actually a coincidence that it ends with a[6]. If you have >> close look at ecp_nistz256_is_affine_G, you'll see that it also check >> for generator->Z.top being P256_LIMBS - P256_LIMBS / 8, or 7[!] on >> 32-bit platform. I.e. we can't assume that a[7] is actually an >> initialized value. Quite contrary actually, because there is >> configuration flag that will put some junk there on purpose. But yes, it >> contradicts second usage case of is_one... Which should be complemented >> with additional >> >> if (P256_LIMBS == 8 && r->Z_is_one) >> r->Z_is_one = (bn_get_top(r->Z) == 7); > > 1. The is_one function should work like is_zero and look at all the > limbs. Clearly, that's what people expected it to do, given the > current bug. If ecp_nistz256_is_affine_G needs different logic then > that different logic should be inlined into it. Note that the use in > ecp_nistz256_is_affine_G doesn't need to be constant-time so there are > lots of options for changing it. > > 2. The Z_is_one member isn't very useful and is error-prone in > general. It can be removed relatively easily. See [1]. > > So, I recommend removing Z_is_one, and then inlining the is_one > function into ecp_nistz256_is_affine_G so that nobody misuses it in > the future for something else. While this is viable option, it's hardly appropriate moment to do that. It will have to wait till after 1.1.0. Otherwise problem is addressed in https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=2e929e538caee6be857ae78ed4e03404857a074a. Thanks for report. From rt at openssl.org Sun Aug 21 20:39:34 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 21 Aug 2016 20:39:34 +0000 Subject: [openssl-dev] [openssl.org #4654] Failed OpenSSL 1.0.2 compile on Debian 8 with shared config option In-Reply-To: References: Message-ID: > I'm working from the 1.0.2h tarball. The platform is Debian 8 (booted > with syscall.x32=y, but the X32 chroot was not entered). GCC is 5.2.1. > > '-fPIC' was manually added after 'shared' caused the initial > "relocation R_X86_64_32 ..." error. Omitting 'shared' does not witness > an error. 32 in R_X86_64_32 is not reference to X32. 64-bit objects use this kind of relocation fluently. Though in PIC context it should be R_X86_64_PC32. > $ reset && ./config shared -fPIC no-ssl2 no-ssl3 no-comp > -Wl,-rpath=/usr/local/ssl/lib --prefix=/usr/local/ssl > CC =gcc > CFLAG =-fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT > -DDSO_DLFCN -DHAVE_DLFCN_H -fPIC -Wa,--noexecstack -m64 -DL_ENDIAN -O3 > -Wall -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 Note that now you have two -fPIC options on compiler command line. I'm not saying that two option would be harmful, only that you seem to be looking in wrong place, lack of -fPIC option is not the problem. At the same time I'm not saying that I know what would be the right place to look in, as I don't. Can you actually confirm that if you 'rm crypto/bn/rsaz_exp.o' and re-run 'make' still fails? On the other hand even if you can, rsaz_exp is a C module and if it being compiled with -fPIC doesn't come out right, there is nothing we can do about it. As we already did our part, passed -fPIC... > /usr/bin/ld: libcrypto.a(rsaz_exp.o): relocation R_X86_64_32 against > `.rodata' can not be used when making a shared object; recompile with > -fPIC > libcrypto.a(rsaz_exp.o): error adding symbols: Bad value > collect2: error: ld returned 1 exit status -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4654 Please log in as guest with password guest if prompted From rt at openssl.org Sun Aug 21 20:50:19 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 21 Aug 2016 20:50:19 +0000 Subject: [openssl-dev] [openssl.org #4648] openssl doesn't work on mingw In-Reply-To: <3b4604f4-14f1-395c-a5fe-a16bc0465020@openssl.org> References: <1874087882.529498635.1471353160945.JavaMail.root@zimbra35-e6.priv.proxad.net> <469814016.529512023.1471353437281.JavaMail.root@zimbra35-e6.priv.proxad.net> <8749f461-a044-3ca0-57d2-88f9c9dbc8c7@openssl.org> <3b4604f4-14f1-395c-a5fe-a16bc0465020@openssl.org> Message-ID: > If goal actually is to execute openssl at msys command prompt, then > openssl should be compiled *for* msys, but we don't actually support > this configuration. On related note it appears that reason for why the question about msys support wasn't risen so far is because prior Windows 10, prompting from plain Windows console applications such as openssl.exe was working in msys window. In Windows 10 it apparently doesn't anymore, with symptoms similar to ones reported here. The problem is not specific to master branch (where prompting was modified to handle non-ASCII characters), 1.0.2 suffers from same problem too. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4648 Please log in as guest with password guest if prompted From rt at openssl.org Sun Aug 21 21:06:31 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 21 Aug 2016 21:06:31 +0000 Subject: [openssl-dev] [openssl.org #4647] bug report: OpenSSL 1.0.2h: Segment fault on AIX Power8 using optimization code In-Reply-To: <072e0c9e-338c-f823-3543-24edf4cf06e4@openssl.org> References: <072e0c9e-338c-f823-3543-24edf4cf06e4@openssl.org> Message-ID: Hi, > We are using libcurl for REST programming, which internally uses openssl > and libcrypto. > curl suggested to implement few callbacks related to locking, which would > be needed for openssl below 1.1 version(which is still in beta). > > The following callbacks were implemented: > > https://curl.haxx.se/libcurl/c/threaded-ssl.html > > lock_callback, thread_id, init_locks, kill_locks > > With these modifications we are facing a crash in openssl library when used > on a Power8 Hardware (with optimizations). The fact that it's affected by optimizations is likely to be circumstantial. I'm not convinced that it's not MT problem with your application, and whether or not crash is triggered is question of delicate yet unfortunate timing. And that's what is affected by optimizations, timing. Questions are. You say you implement the callbacks, but are they actually engaged? Is your openssl actually compiled with threads support? Which configuration target/config line was used to compile it? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4647 Please log in as guest with password guest if prompted From rt at openssl.org Sun Aug 21 21:57:43 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 21 Aug 2016 21:57:43 +0000 Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check In-Reply-To: <0338cef2-698c-1684-241e-42876258092b@openssl.org> References: <57963956.2060809@mit.edu> <006801d1f285$06ac6ab0$14054010$@sales@free.fr> <0338cef2-698c-1684-241e-42876258092b@openssl.org> Message-ID: There are two commits, one that addresses bio_enc problems and one adding test. Please double-check. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628 Please log in as guest with password guest if prompted From rt at openssl.org Mon Aug 22 04:25:53 2016 From: rt at openssl.org (Greg Hudson via RT) Date: Mon, 22 Aug 2016 04:25:53 +0000 Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check In-Reply-To: <57BA7EBF.5030504@mit.edu> References: <57963956.2060809@mit.edu> <006801d1f285$06ac6ab0$14054010$@sales@free.fr> <0338cef2-698c-1684-241e-42876258092b@openssl.org> <57BA7EBF.5030504@mit.edu> Message-ID: The krb5 PKINIT tests still pass. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628 Please log in as guest with password guest if prompted From rschm2 at unh.newhaven.edu Mon Aug 22 04:16:22 2016 From: rschm2 at unh.newhaven.edu (Schmicker, Robert) Date: Mon, 22 Aug 2016 04:16:22 +0000 Subject: [openssl-dev] Crypto Module Config Message-ID: <42BCB3FD-F5E2-404E-8981-E5CD304F473D@unh.newhaven.edu> Hello, I am working on building a new crypto module that works with openssl. I have looked through the source code and found the /crypto/ folder which would be where this module would reside. However, if I duplicate a folder such as md5 within the /crypto/ folder and rename it to say ?helloworld?, helloworld does not show up to be compiled in the makefile. I edited line 856 to include ?helloworld? in the config file. What is the proper way for the config file, in the root directory, to add ?helloworld? into the makefile. Any guidance would be much appreciated. Best, Rob Schmicker -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Aug 22 08:40:50 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 22 Aug 2016 10:40:50 +0200 (CEST) Subject: [openssl-dev] Crypto Module Config In-Reply-To: <42BCB3FD-F5E2-404E-8981-E5CD304F473D@unh.newhaven.edu> References: <42BCB3FD-F5E2-404E-8981-E5CD304F473D@unh.newhaven.edu> Message-ID: <20160822.104050.435853627205122219.levitte@openssl.org> In message <42BCB3FD-F5E2-404E-8981-E5CD304F473D at unh.newhaven.edu> on Mon, 22 Aug 2016 04:16:22 +0000, "Schmicker, Robert" said: rschm2> Hello, rschm2> rschm2> I am working on building a new crypto module that works with openssl. rschm2> I have looked through the source code and found the /crypto/ folder rschm2> which would be where this module would reside. However, if I duplicate rschm2> a folder such as md5 within the /crypto/ folder and rename it to say rschm2> ?helloworld?, helloworld does not show up to be compiled in the rschm2> makefile. I edited line 856 to include ?helloworld? in the config rschm2> file. What is the proper way for the config file, in the root rschm2> directory, to add ?helloworld? into the makefile. rschm2> rschm2> Any guidance would be much appreciated. Assuming we're talking about the master branch (i.e. upcoming version 1.1), then you need to add "helloworld" to the 'sdirs' configuration. In line 250 in Configure, you will find this line: $config{sdirs} = [ Simply add "helloworld" to the values you find following that line. Assuming we're talking about the version 1.0.2 series, then the procedure is approximately the same. There, you have to look up this line in Makefile.org: SDIRS= \ ... and add helloworld to its values. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From appro at openssl.org Mon Aug 22 10:15:48 2016 From: appro at openssl.org (Andy Polyakov) Date: Mon, 22 Aug 2016 12:15:48 +0200 Subject: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg In-Reply-To: <5dccf6ab-1342-be67-d754-57731c6ae23d@openssl.org> References: <084dcb14-aa85-4193-f5b6-9e121be52b08@openssl.org> <81fdfb0a-c7b2-81e4-a5bd-069d33256927@openssl.org> <5a6a9472-1c3c-f78d-4ec7-380bb9a90d38@openssl.org> <777df38b-b979-4d24-ebf5-a91ecd1e2a9c@openssl.org> <6e7a4e9c-abbc-d59c-f2a8-a90075326ea4@openssl.org> <11a1fcfd-798f-f0a7-c1e0-dd5fe94773c5@openssl.org> <5dccf6ab-1342-be67-d754-57731c6ae23d@openssl.org> Message-ID: <97acd587-1fc2-d3e0-b44e-f7c1459fa60e@openssl.org> >>> * Fix ecp_nistz256_mul_by_2 and ecp_nistz256_mul_by_3 to fully reduce >>> their outputs. >>> >>> * Fix ecp_nistz256_add to fully reduce its output. >> >> As for specifically addition see below. As for fixing mul_by_[23] and >> the fact that they use addition. There are two ways. a) Modify addition >> so that it *preserves* property of being fully reduced and leave >> mul_by_[23] as is. b) Let addition as is and add additional step to >> mul_by_[23]. The choice of approach can be platform-specific. For >> example on x86_64 a) is simpler and appears more efficient. After considering other ecp_nistz256-enabled platforms a) appears better choice on all of them. It probably holds universally true, but I would still mention b) in commentary... From rt at openssl.org Mon Aug 22 12:33:47 2016 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Mon, 22 Aug 2016 12:33:47 +0000 Subject: [openssl-dev] [openssl.org #4655] Openssl req seems not to work with precreated key In-Reply-To: References: Message-ID: Hello openssl team, I experience problems with openssl version OpenSSL 1.1.0-pre7-dev I use Debian GNU Linux, the version is 8.5 The kernel version is Linux vr-dev 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux I have created a private key with a command LD_LIBRARY_PATH=. apps/openssl genrsa -out rsa2048.pem 2048 in the build directory. When I execute the command OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req -x509 -key rsa2048.pem -keyform PEM -out cert.pem in the build directory, it seems to hang and does not print any prompt. The command line OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req -x509 -newkey rsa:2048 -keyout key.pem -out req.pem -nodes works ok. What's done wrong by me? -- SY, Dmitry Belyavsky -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4655 Please log in as guest with password guest if prompted From rt at openssl.org Mon Aug 22 13:00:05 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 22 Aug 2016 13:00:05 +0000 Subject: [openssl-dev] [openssl.org #4655] Openssl req seems not to work with precreated key In-Reply-To: References: Message-ID: The issue isn't with the pre-created key, but because '-x509' doesn't fully flag that something new is to be created. The freeze is because 'openssl req' tries to read a csr... '-newkey', however, does flag the creation of a csr / x509, that's why the alternative command works. Fix in https://github.com/openssl/openssl/pull/1479 Cheers, Richard On Mon Aug 22 12:33:47 2016, beldmit at gmail.com wrote: > Hello openssl team, > > I experience problems with openssl version OpenSSL 1.1.0-pre7-dev > > I use Debian GNU Linux, the version is 8.5 > The kernel version is > Linux vr-dev 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) > x86_64 GNU/Linux > > I have created a private key with a command > > LD_LIBRARY_PATH=. apps/openssl genrsa -out rsa2048.pem 2048 > > in the build directory. > > When I execute the command > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req -x509 -key > rsa2048.pem -keyform PEM -out cert.pem > > in the build directory, it seems to hang and does not print any prompt. > > The command line > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req -x509 > -newkey rsa:2048 -keyout key.pem -out req.pem -nodes > > works ok. > > What's done wrong by me? > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4655 Please log in as guest with password guest if prompted From beldmit at gmail.com Mon Aug 22 13:12:49 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 22 Aug 2016 16:12:49 +0300 Subject: [openssl-dev] [openssl.org #4655] Openssl req seems not to work with precreated key In-Reply-To: References: Message-ID: Dear Richard, Thank you, it works. On Mon, Aug 22, 2016 at 4:00 PM, Richard Levitte via RT wrote: > The issue isn't with the pre-created key, but because '-x509' doesn't fully > flag that something new is to be created. The freeze is because 'openssl > req' > tries to read a csr... '-newkey', however, does flag the creation of a csr > / > x509, that's why the alternative command works. > > Fix in https://github.com/openssl/openssl/pull/1479 > > Cheers, > Richard > > On Mon Aug 22 12:33:47 2016, beldmit at gmail.com wrote: > > Hello openssl team, > > > > I experience problems with openssl version OpenSSL 1.1.0-pre7-dev > > > > I use Debian GNU Linux, the version is 8.5 > > The kernel version is > > Linux vr-dev 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) > > x86_64 GNU/Linux > > > > I have created a private key with a command > > > > LD_LIBRARY_PATH=. apps/openssl genrsa -out rsa2048.pem 2048 > > > > in the build directory. > > > > When I execute the command > > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req -x509 > -key > > rsa2048.pem -keyform PEM -out cert.pem > > > > in the build directory, it seems to hang and does not print any prompt. > > > > The command line > > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req -x509 > > -newkey rsa:2048 -keyout key.pem -out req.pem -nodes > > > > works ok. > > > > What's done wrong by me? > > > > > -- > Richard Levitte > levitte at openssl.org > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4655 > Please log in as guest with password guest if prompted > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Aug 22 13:12:58 2016 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Mon, 22 Aug 2016 13:12:58 +0000 Subject: [openssl-dev] [openssl.org #4655] Openssl req seems not to work with precreated key In-Reply-To: References: Message-ID: Dear Richard, Thank you, it works. On Mon, Aug 22, 2016 at 4:00 PM, Richard Levitte via RT wrote: > The issue isn't with the pre-created key, but because '-x509' doesn't fully > flag that something new is to be created. The freeze is because 'openssl > req' > tries to read a csr... '-newkey', however, does flag the creation of a csr > / > x509, that's why the alternative command works. > > Fix in https://github.com/openssl/openssl/pull/1479 > > Cheers, > Richard > > On Mon Aug 22 12:33:47 2016, beldmit at gmail.com wrote: > > Hello openssl team, > > > > I experience problems with openssl version OpenSSL 1.1.0-pre7-dev > > > > I use Debian GNU Linux, the version is 8.5 > > The kernel version is > > Linux vr-dev 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) > > x86_64 GNU/Linux > > > > I have created a private key with a command > > > > LD_LIBRARY_PATH=. apps/openssl genrsa -out rsa2048.pem 2048 > > > > in the build directory. > > > > When I execute the command > > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req -x509 > -key > > rsa2048.pem -keyform PEM -out cert.pem > > > > in the build directory, it seems to hang and does not print any prompt. > > > > The command line > > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req -x509 > > -newkey rsa:2048 -keyout key.pem -out req.pem -nodes > > > > works ok. > > > > What's done wrong by me? > > > > > -- > Richard Levitte > levitte at openssl.org > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4655 > Please log in as guest with password guest if prompted > > -- SY, Dmitry Belyavsky -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4655 Please log in as guest with password guest if prompted From rt at openssl.org Mon Aug 22 13:30:02 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 22 Aug 2016 13:30:02 +0000 Subject: [openssl-dev] [openssl.org #4655] Openssl req seems not to work with precreated key In-Reply-To: References: Message-ID: Perfect. Fix has been merged into master, but I'll wait with closing this until I get a yay or nay about the corresponding 1.0.2 fix. Cheers, Richard On Mon Aug 22 13:12:58 2016, beldmit at gmail.com wrote: > Dear Richard, > > Thank you, it works. > > On Mon, Aug 22, 2016 at 4:00 PM, Richard Levitte via RT > > wrote: > > > The issue isn't with the pre-created key, but because '-x509' doesn't > > fully > > flag that something new is to be created. The freeze is because > > 'openssl > > req' > > tries to read a csr... '-newkey', however, does flag the creation of > > a csr > > / > > x509, that's why the alternative command works. > > > > Fix in https://github.com/openssl/openssl/pull/1479 > > > > Cheers, > > Richard > > > > On Mon Aug 22 12:33:47 2016, beldmit at gmail.com wrote: > > > Hello openssl team, > > > > > > I experience problems with openssl version OpenSSL 1.1.0-pre7-dev > > > > > > I use Debian GNU Linux, the version is 8.5 > > > The kernel version is > > > Linux vr-dev 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04- > > > 08) > > > x86_64 GNU/Linux > > > > > > I have created a private key with a command > > > > > > LD_LIBRARY_PATH=. apps/openssl genrsa -out rsa2048.pem 2048 > > > > > > in the build directory. > > > > > > When I execute the command > > > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req > > > -x509 > > -key > > > rsa2048.pem -keyform PEM -out cert.pem > > > > > > in the build directory, it seems to hang and does not print any > > > prompt. > > > > > > The command line > > > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req > > > -x509 > > > -newkey rsa:2048 -keyout key.pem -out req.pem -nodes > > > > > > works ok. > > > > > > What's done wrong by me? > > > > > > > > > -- > > Richard Levitte > > levitte at openssl.org > > > > -- > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4655 > > Please log in as guest with password guest if prompted > > > > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4655 Please log in as guest with password guest if prompted From rt at openssl.org Mon Aug 22 13:56:18 2016 From: rt at openssl.org (Perrow, Graeme via RT) Date: Mon, 22 Aug 2016 13:56:18 +0000 Subject: [openssl-dev] [openssl.org #4656] [BUG] print_bin could access memory off the end of a buffer In-Reply-To: <5e92d14ac5d2488cb15c74098a16de99@dewdfe13de43.global.corp.sap> References: <5e92d14ac5d2488cb15c74098a16de99@dewdfe13de43.global.corp.sap> Message-ID: In file crypto/ec/eck_prn.c, if the function print_bin is called with len >= 15 and off >= 124, we would eventually hit line 261: memset( &(str[1]), ' ', off + 4 ); which would write >= 128 bytes into a 127-byte buffer. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4656 Please log in as guest with password guest if prompted From rt at openssl.org Mon Aug 22 13:56:18 2016 From: rt at openssl.org (Nomalatha Aerampu via RT) Date: Mon, 22 Aug 2016 13:56:18 +0000 Subject: [openssl-dev] [openssl.org #4657] Bug - SSL Library Error - BUF_MEM_grow:malloc failure In-Reply-To: References: Message-ID: Hi, Our product (32-bit process) uses OpenSSL third-party libraries for EAP protocols. During the debugging of a customer issue in PEAP protocol, we got to understand that SSL_Accept has returned failure. STATE_HANDSHAKE SSL_ERROR_SSL error retrun code [1] and peak error translate code [39] and err_get_reason [1048] // Error code, Error cases(Reason) 8900:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:.\ssl\s3_pkt.c:1235:SSL alert number 48 // Error Queue SSL_ERROR_SSL Handshake failure On further analyzing, we found that handshake failure is due to the "BUF_MEM_grow : malloc failure" in the server after the 'n' number of authentications. The memory buffer gets completely allocated and handshake is failed when we tried to allocate the memory. STATE_HANDSHAKE SSL_ERROR_SSL error retrun code [1] and peak error translate code [2] and err_get_reason [65] 7820:error:07064041:memory buffer routines:BUF_MEM_grow:malloc failure:.\crypto\buffer\buffer.c:122: SSL_ERROR_SSL Handshake failure Total memory that is installed on the server: 4GB Process memory size when the issue occurs: 360 ~ 370 MB Operating System Version - Windows Server 2008 OpenSSL version - 0.9.7e, 1.0.0s Please let us know if there are known issues related to the same or let us know if you require further information for your debugging. Regards, Nomalatha A -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4657 Please log in as guest with password guest if prompted From rt at openssl.org Mon Aug 22 14:04:26 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 22 Aug 2016 14:04:26 +0000 Subject: [openssl-dev] [openssl.org #4655] Openssl req seems not to work with precreated key In-Reply-To: References: Message-ID: All merged now, closing ticket. On Mon Aug 22 13:30:02 2016, levitte wrote: > Perfect. > > Fix has been merged into master, but I'll wait with closing this until > I get a > yay or nay about the corresponding 1.0.2 fix. > > Cheers, > Richard > > On Mon Aug 22 13:12:58 2016, beldmit at gmail.com wrote: > > Dear Richard, > > > > Thank you, it works. > > > > On Mon, Aug 22, 2016 at 4:00 PM, Richard Levitte via RT > > > > wrote: > > > > > The issue isn't with the pre-created key, but because '-x509' > > > doesn't > > > fully > > > flag that something new is to be created. The freeze is because > > > 'openssl > > > req' > > > tries to read a csr... '-newkey', however, does flag the creation > > > of > > > a csr > > > / > > > x509, that's why the alternative command works. > > > > > > Fix in https://github.com/openssl/openssl/pull/1479 > > > > > > Cheers, > > > Richard > > > > > > On Mon Aug 22 12:33:47 2016, beldmit at gmail.com wrote: > > > > Hello openssl team, > > > > > > > > I experience problems with openssl version OpenSSL 1.1.0-pre7-dev > > > > > > > > I use Debian GNU Linux, the version is 8.5 > > > > The kernel version is > > > > Linux vr-dev 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016- > > > > 04- > > > > 08) > > > > x86_64 GNU/Linux > > > > > > > > I have created a private key with a command > > > > > > > > LD_LIBRARY_PATH=. apps/openssl genrsa -out rsa2048.pem 2048 > > > > > > > > in the build directory. > > > > > > > > When I execute the command > > > > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req > > > > -x509 > > > -key > > > > rsa2048.pem -keyform PEM -out cert.pem > > > > > > > > in the build directory, it seems to hang and does not print any > > > > prompt. > > > > > > > > The command line > > > > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req > > > > -x509 > > > > -newkey rsa:2048 -keyout key.pem -out req.pem -nodes > > > > > > > > works ok. > > > > > > > > What's done wrong by me? > > > > > > > > > > > > > -- > > > Richard Levitte > > > levitte at openssl.org > > > > > > -- > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4655 > > > Please log in as guest with password guest if prompted > > > > > > > > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4655 Please log in as guest with password guest if prompted From rt at openssl.org Mon Aug 22 15:05:17 2016 From: rt at openssl.org (David Benjamin via RT) Date: Mon, 22 Aug 2016 15:05:17 +0000 Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check In-Reply-To: References: <57963956.2060809@mit.edu> <0338cef2-698c-1684-241e-42876258092b@openssl.org> Message-ID: I may not have time to fully digest the change before the release date, but I'm not sure this snippet quite works: if (ctx->read_start == ctx->read_end) { /* time to read more data */ ctx->read_end = ctx->read_start = &(ctx->buf[BUF_OFFSET]); ctx->read_end += BIO_read(next, ctx->read_start, ENC_BLOCK_SIZE); } i = ctx->read_end - ctx->read_start; if (i <= 0) { It's kind of an odd error-checking pattern and is only saved from undefined behavior by BUF_OFFSET. (Is a custom BIO allowed to return -1,000,000 on error or must it be -1? There are definitely some OpenSSL APIs which return -2 expecting that the usual error-check patterns don't care.) Anyway, I believe it gets stuck if non-blocking BIO causes BIO_read to fail on a retryable error like EWOULDBLOCK and we try again. I see calls to BIO_should_retry, so I gather this BIO is intended to work in front of a non-blocking BIO. Since the error path should only be reachable when BIO_read fails, maybe move that inside the "read more data" codepath? Then you don't need pointer tricks to avoid duplicating the code. David On Sun, Aug 21, 2016 at 5:57 PM Andy Polyakov via RT wrote: > There are two commits, one that addresses bio_enc problems and one > adding test. Please double-check. > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628 > Please log in as guest with password guest if prompted > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628 Please log in as guest with password guest if prompted From rt at openssl.org Mon Aug 22 15:53:41 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 22 Aug 2016 15:53:41 +0000 Subject: [openssl-dev] [openssl.org #2676] 1.0.1-beta1 issue: RSA exponent 1 is NOT ok In-Reply-To: <4972.84.190.59.221.1325957982.squirrel@www2.informatik.hu-berlin.de> References: <4972.84.190.59.221.1325957982.squirrel@www2.informatik.hu-berlin.de> Message-ID: This is fixed in 1.0.2 (commit 561530d) and master/1.1.0 (commit 464d59a). Thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2676 Please log in as guest with password guest if prompted From foleyj at cisco.com Mon Aug 22 17:12:47 2016 From: foleyj at cisco.com (John Foley) Date: Mon, 22 Aug 2016 13:12:47 -0400 Subject: [openssl-dev] OpenSSL_1_0_2-stable Windows build Message-ID: <262d55f6-6106-a299-7c9e-269df08ffd40@cisco.com> Is anyone seeing the following error when building 1.0.2 stable on Windows: Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp IF EXIST out32dll\sslv2conftest.exe.manifest mt -nologo -manifest out32dll\sslv2conftest.exe.manifest -outputresource:out32dll\sslv2conftest.exe;1 cl /Fotmp32dll\dtlstest.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_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 -IC:\Users\testuser\workspace\CiscoSSL\ciscossl-platform-tests-win32\fips/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_SSL2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_BASE_EC -DOPENSSL_NO_BASE_ECDSA -DOPENSSL_NO_BASE_ECDH -DOPENSSL_NO_GOST -DOPENSSL_FIPS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_WEAK_SSL_CIPHERS -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/app -c .\ssl\dtlstest.c dtlstest.c link /nologo /subsystem:console /opt:ref /debug /out:out32dll\dtlstest.exe @C:\Users\testuser\AppData\Local\Temp\nm6DBA.tmp Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_ctx_pair referenced in function _test_dtls_unprocessed dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_objects referenced in function _test_dtls_unprocessed dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_connection referenced in function _test_dtls_unprocessed dtlstest.obj : error LNK2019: unresolved external symbol _bio_f_tls_dump_filter referenced in function _test_dtls_unprocessed dtlstest.obj : error LNK2019: unresolved external symbol _mempacket_test_inject referenced in function _test_dtls_unprocessed out32dll\dtlstest.exe : fatal error LNK1120: 5 unresolved externals NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\link.EXE"' : return code '0x460' Stop. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Aug 22 18:35:35 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 22 Aug 2016 19:35:35 +0100 Subject: [openssl-dev] OpenSSL_1_0_2-stable Windows build In-Reply-To: <262d55f6-6106-a299-7c9e-269df08ffd40@cisco.com> References: <262d55f6-6106-a299-7c9e-269df08ffd40@cisco.com> Message-ID: On 22/08/16 18:12, John Foley wrote: > Is anyone seeing the following error when building 1.0.2 stable on Windows: > > Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp > IF EXIST out32dll\sslv2conftest.exe.manifest mt -nologo -manifest out32dll\sslv2conftest.exe.manifest -outputresource:out32dll\sslv2conftest.exe;1 > cl /Fotmp32dll\dtlstest.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_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 -IC:\Users\testuser\workspace\CiscoSSL\ciscossl-platform-tests-win32\fips/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_SSL2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_BASE_EC -DOPENSSL_NO_BASE_ECDSA -DOPENSSL_NO_BASE_ECDH -DOPENSSL_NO_GOST -DOPENSSL_FIPS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_WEAK_SSL_CIPHERS -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/app -c .\ssl\dtlstest.c > dtlstest.c > link /nologo /subsystem:console /opt:ref /debug /out:out32dll\dtlstest.exe @C:\Users\testuser\AppData\Local\Temp\nm6DBA.tmp > Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp > dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_ctx_pair referenced in function _test_dtls_unprocessed > dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_objects referenced in function _test_dtls_unprocessed > dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_connection referenced in function _test_dtls_unprocessed > dtlstest.obj : error LNK2019: unresolved external symbol _bio_f_tls_dump_filter referenced in function _test_dtls_unprocessed > dtlstest.obj : error LNK2019: unresolved external symbol _mempacket_test_inject referenced in function _test_dtls_unprocessed > out32dll\dtlstest.exe : fatal error LNK1120: 5 unresolved externals > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\link.EXE"' : return code '0x460' > Stop. Yes. It needs this to be merged: https://github.com/openssl/openssl/pull/1470 Matt From levitte at openssl.org Mon Aug 22 22:10:34 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 23 Aug 2016 00:10:34 +0200 (CEST) Subject: [openssl-dev] OpenSSL_1_0_2-stable Windows build In-Reply-To: References: <262d55f6-6106-a299-7c9e-269df08ffd40@cisco.com> Message-ID: <20160823.001034.1124248679826947644.levitte@openssl.org> In message on Mon, 22 Aug 2016 19:35:35 +0100, Matt Caswell said: matt> matt> matt> On 22/08/16 18:12, John Foley wrote: matt> > Is anyone seeing the following error when building 1.0.2 stable on Windows: matt> > matt> > Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp matt> > IF EXIST out32dll\sslv2conftest.exe.manifest mt -nologo -manifest out32dll\sslv2conftest.exe.manifest -outputresource:out32dll\sslv2conftest.exe;1 matt> > cl /Fotmp32dll\dtlstest.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_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 -IC:\Users\testuser\workspace\CiscoSSL\ciscossl-platform-tests-win32\fips/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_SSL2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_BASE_EC -DOPENSSL_NO_BASE_ECDSA -DOPENSSL_NO_BASE_ECDH -DOPENSSL_NO_GOST -DOPENSSL_FIPS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_WEAK_SSL_CIPHERS -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/app -c .\ssl\dtlstest.c matt> > dtlstest.c matt> > link /nologo /subsystem:console /opt:ref /debug /out:out32dll\dtlstest.exe @C:\Users\testuser\AppData\Local\Temp\nm6DBA.tmp matt> > Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp matt> > dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_ctx_pair referenced in function _test_dtls_unprocessed matt> > dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_objects referenced in function _test_dtls_unprocessed matt> > dtlstest.obj : error LNK2019: unresolved external symbol _create_ssl_connection referenced in function _test_dtls_unprocessed matt> > dtlstest.obj : error LNK2019: unresolved external symbol _bio_f_tls_dump_filter referenced in function _test_dtls_unprocessed matt> > dtlstest.obj : error LNK2019: unresolved external symbol _mempacket_test_inject referenced in function _test_dtls_unprocessed matt> > out32dll\dtlstest.exe : fatal error LNK1120: 5 unresolved externals matt> > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\link.EXE"' : return code '0x460' matt> > Stop. matt> matt> Yes. It needs this to be merged: matt> matt> https://github.com/openssl/openssl/pull/1470 ... which finally happened, just now. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Tue Aug 23 10:06:34 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Tue, 23 Aug 2016 10:06:34 +0000 Subject: [openssl-dev] [openssl.org #4653] [1.0.2] fails to compile on VC-WIN32 In-Reply-To: References: Message-ID: This was merged yesterday. Please try out a new snapshot. Closing this ticket. Cheers, Richard On Fri Aug 19 15:08:29 2016, levitte wrote: > Please try out this github pull request: > https://github.com/openssl/openssl/pull/1470 > > Cheers, > Richard > > On Fri Aug 19 14:40:02 2016, levitte wrote: > > We totally missed out on adapting util/mk1mf.pl. Fix on its way. > > > > On Fri Aug 19 14:20:20 2016, Simon.Richter at hogyros.de wrote: > > > Hi, > > > > > > the 1.0.2 branch fails to compile for me: > > > > > > link /nologo /subsystem:console /opt:ref /debug > > > /out:out32dll\dtlstest.exe @C:\Windows\TEMP\nm8D73.tmp > > > Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp > > > dtlstest.obj : error LNK2019: unresolved external symbol > > > _create_ssl_ctx_pair referenced in function _test_dtls_unprocessed > > > dtlstest.obj : error LNK2019: unresolved external symbol > > > _create_ssl_objects referenced in function _test_dtls_unprocessed > > > dtlstest.obj : error LNK2019: unresolved external symbol > > > _create_ssl_connection referenced in function _test_dtls_unprocessed > > > dtlstest.obj : error LNK2019: unresolved external symbol > > > _bio_f_tls_dump_filter referenced in function _test_dtls_unprocessed > > > dtlstest.obj : error LNK2019: unresolved external symbol > > > _mempacket_test_inject referenced in function _test_dtls_unprocessed > > > out32dll\dtlstest.exe : fatal error LNK1120: 5 unresolved externals > > > > > > Changes in this build: > > > > > > http://ci.kicad-pcb.org/job/windows-openssl- > > > msvc/build=release,cpu=x86,label=windows/458/changes' > > > > > > Full build log: > > > > > > http://ci.kicad-pcb.org/job/windows-openssl- > > > msvc/build=release,cpu=x86,label=windows/458/consoleFull > > > > > > Simon > > > > > > -- > > Richard Levitte > > levitte at openssl.org > > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4653 Please log in as guest with password guest if prompted From rt at openssl.org Tue Aug 23 10:48:46 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Tue, 23 Aug 2016 10:48:46 +0000 Subject: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc In-Reply-To: References: <838859.23452.qm@web101209.mail.kks.yahoo.co.jp> <2793.4468.qm@web101201.mail.kks.yahoo.co.jp> Message-ID: Ok. I'm going with that solution, then. See attached diff. Cheers, Richard On Wed Aug 17 21:21:34 2016, yoi_no_myoujou at yahoo.co.jp wrote: > Yes, __SUNPRO_C is defined by DeveloperStudio compiler. > > > To only allow the use of __atomic_add_fetch when __ATOMIC_RELAXED is > > non-zero > > > isn't the right move here. So it seems that different compilers > > either only > > implement a subset of the __atomic builtins, or name them > > differently. > > > > What was the macro defined by the DeveloperStudio compiler? > > __SUNPRO_C or > > something else? In that case, the correct method might be to exclude > > it, like > > this: > > > > #if defined(__ATOMIC_RELAXED) && !defined(__SUNPRO_C) > > > > On Mon Aug 08 08:33:34 2016, yoi_no_myoujou at yahoo.co.jp wrote: > >> Hello, > >> > >> % ./Configure solaris-x86-cc > >> % make > >> : > >> Undefined first referenced > >> symbol in file > >> __atomic_add_fetch ./libcrypto.so > >> ld: fatal: symbol referencing errors. No output written to > >> fuzz/asn1parse-test > >> > >> > >> % ./Configure solaris64-x86_64-cc > >> % make > >> has the same error. > >> > >> Tested on Solaris10 x86/64, with Solaris developerstudio12.5. > >> > >> > >> This is caused because __ATOMIC_RELAXED is #defined as 0 > >> in /opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h > >> > >> > >> Sample patch: > >> --- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c > >> +++ ./crypto/threads_pthread.c > >> @@ -109,7 +109,7 @@ > >> > >> int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK > >> *lock) > >> { > >> -#ifdef __ATOMIC_RELAXED > >> +#if __ATOMIC_RELAXED > >> *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED); > >> #else > >> if (!CRYPTO_THREAD_write_lock(lock)) > >> > >> > >> With this patch, > >> % ./Configure solaris-x86-cc > >> % make > >> % make test > >> passes. > >> > >> % ./Configure solaris64-x86_64-cc > >> % make > >> passes but > >> % make test > >> stops. > >> This is another problem, which seems to be the same as bug #4641. > >> > >> > >> Regards, > >> > >> --- Kiyoshi > > > > > > -- > > Richard Levitte > > levitte at openssl.org > > > > -- > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 > > Please log in as guest with password guest if prompted > > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: threads_pthread.c.diff Type: text/x-patch Size: 843 bytes Desc: not available URL: From beldmit at gmail.com Tue Aug 23 11:00:23 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Tue, 23 Aug 2016 14:00:23 +0300 Subject: [openssl-dev] object.txt Message-ID: Hello, I try to add a new OID to the objects.h file in my fork of the OpenSSL 1.1.0-pre7-dev. After adding the line to the objects.txt file and running ./config; make the corresponding NIDs do not appear in the files include/openssl/objects.h and include/openssl/obj_mac.h What's the right way to add new OIDs with new build system? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue Aug 23 11:53:32 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 23 Aug 2016 13:53:32 +0200 (CEST) Subject: [openssl-dev] object.txt In-Reply-To: References: Message-ID: <20160823.135332.698039614194854779.levitte@openssl.org> In message on Tue, 23 Aug 2016 14:00:23 +0300, Dmitry Belyavsky said: beldmit> Hello, beldmit> beldmit> I try to add a new OID to the objects.h file in my fork of the OpenSSL beldmit> 1.1.0-pre7-dev. beldmit> beldmit> After adding the line to the objects.txt file and running ./config; beldmit> make the corresponding NIDs do not appear in the files beldmit> include/openssl/objects.h and include/openssl/obj_mac.h beldmit> beldmit> What's the right way to add new OIDs with new build system? There's a manual step to update the corresponding C files: make update Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From beldmit at gmail.com Tue Aug 23 12:04:03 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Tue, 23 Aug 2016 15:04:03 +0300 Subject: [openssl-dev] object.txt In-Reply-To: <20160823.135332.698039614194854779.levitte@openssl.org> References: <20160823.135332.698039614194854779.levitte@openssl.org> Message-ID: Hello Richard, Thank you for clarification! On Tue, Aug 23, 2016 at 2:53 PM, Richard Levitte wrote: > In message Z2_faQhKBjHVA at mail.gmail.com> on Tue, 23 Aug 2016 14:00:23 +0300, Dmitry > Belyavsky said: > > beldmit> Hello, > beldmit> > beldmit> I try to add a new OID to the objects.h file in my fork of the > OpenSSL > beldmit> 1.1.0-pre7-dev. > beldmit> > beldmit> After adding the line to the objects.txt file and running > ./config; > beldmit> make the corresponding NIDs do not appear in the files > beldmit> include/openssl/objects.h and include/openssl/obj_mac.h > beldmit> > beldmit> What's the right way to add new OIDs with new build system? > > There's a manual step to update the corresponding C files: make update > > 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 > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Aug 23 19:25:44 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 23 Aug 2016 19:25:44 +0000 Subject: [openssl-dev] [openssl.org #4584] Self test failures under X32 In-Reply-To: References: Message-ID: On Tue Aug 16 08:05:06 2016, matt wrote: > On Thu Aug 11 16:36:42 2016, matt wrote: > > Could be this: > > > > https://github.com/openssl/openssl/pull/1432 > > > That MR has now been merged. > > Jeff - please can you confirm that it resolves the issue for this ticket? No response, so assuming this is now working. Closing ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584 Please log in as guest with password guest if prompted From rt at openssl.org Tue Aug 23 19:26:56 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 23 Aug 2016 19:26:56 +0000 Subject: [openssl-dev] [openssl.org #4609] Configure does not honor requests for ld.gold In-Reply-To: References: Message-ID: On Wed Aug 17 16:18:26 2016, levitte wrote: > On Fri Jul 08 09:36:42 2016, levitte wrote: > > On Fri Jul 08 09:33:01 2016, noloader at gmail.com wrote: > > > Hmmm... If I want to use ld.gold as my linker, the easiest path is to > > > set LD=ld.gold. It makes perfect sense to some.... > > > > Did it work for you when doing this? > > > > ./config -fuse-ld=gold > > Jeff, please respond. Still, no response so assuming this is an acceptable work around. Closing this ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 24 09:39:13 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 24 Aug 2016 09:39:13 +0000 Subject: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check In-Reply-To: References: Message-ID: On Mon Aug 22 15:05:17 2016, davidben at google.com wrote: > I may not have time to fully digest the change before the release date, but > I'm not sure this snippet quite works: > > if (ctx->read_start == ctx->read_end) { /* time to read more data */ > ctx->read_end = ctx->read_start = &(ctx->buf[BUF_OFFSET]); > ctx->read_end += BIO_read(next, ctx->read_start, ENC_BLOCK_SIZE); > } > i = ctx->read_end - ctx->read_start; > > if (i <= 0) { Fixed in 9e421962e1cd. Closing. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 24 09:40:35 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 24 Aug 2016 09:40:35 +0000 Subject: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files In-Reply-To: References: Message-ID: Resolved by overlapping buffer checks. Closing. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 24 09:42:15 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 24 Aug 2016 09:42:15 +0000 Subject: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc In-Reply-To: References: <593784.48311.qm@web101204.mail.kks.yahoo.co.jp> <952067.71572.qm@web101213.mail.kks.yahoo.co.jp> <9feb5530-ce49-1400-8ef1-fa1206ae1ce2@openssl.org> Message-ID: On Thu Aug 11 17:12:10 2016, appro wrote: > Hi, > > > I have no time to check with debugger now, > > Then no progress will be made. Problem needs to be identified first, and > since similar problem was identified earlier, I'd have to insist on > confirmation whether or not it's the same. > > > but I do not think it is caused by assembler, > > because, > > - gcc-5.4.0 with gas (GNU Binutils) 2.27 > > - cc (Solaris developerstudio12.5) with /usr/ccs/bin/as > > have the same result (see openssl.org #4642 also). > > > > perl version which I use is v5.24.0. > > Well, (assuming for a moment it's the same problem) there is *less* > reason to believe that x86_64cpuid.pl is broken. Because it's used with > a *number* of other toolchains, Linux, BSD, mingw, MSVC, without any > problem. Nor can I reproduce the problem on my Solaris VM. It's not as > fancy as yours, apparently, but it also kind of speak in favour of > suggestion that it's not an OpenSSL problem... > Believed to not be an OpenSSL problem. Closing this ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 24 09:49:06 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 24 Aug 2016 09:49:06 +0000 Subject: [openssl-dev] [openssl.org #4621] BUG: nistz256 point addition check for a = +/-b doesn't work for unreduced values In-Reply-To: References: Message-ID: Fixed in master by b62b2454f and dfde4219f. Still needs cherry-picking to 1.0.2. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4621 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 24 09:58:32 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 24 Aug 2016 09:58:32 +0000 Subject: [openssl-dev] [openssl.org #4636] Are the point-at-infinity checks in ecp_nistz256 correct? In-Reply-To: References: Message-ID: Fixed in master by e3057a57c and c74aea8d6. Still needs cherry-picking to 1.0.2. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4636 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 24 11:32:54 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 24 Aug 2016 11:32:54 +0000 Subject: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc In-Reply-To: References: <838859.23452.qm@web101209.mail.kks.yahoo.co.jp> <2793.4468.qm@web101201.mail.kks.yahoo.co.jp> Message-ID: After much internal deliberation, we ended up checking __GNUC__ rather than dissing __SUBPRO_C. Our hope is that a compiler that implements GNU extensions will also define __GNUC__. Our checks of the Intel compiler (which someone referred to) does so, for example (if I understood correctly). https://github.com/openssl/openssl/pull/1484 Cheers, Richard On Tue Aug 23 10:48:46 2016, levitte wrote: > Ok. I'm going with that solution, then. See attached diff. > > Cheers, > Richard > > On Wed Aug 17 21:21:34 2016, yoi_no_myoujou at yahoo.co.jp wrote: > > Yes, __SUNPRO_C is defined by DeveloperStudio compiler. > > > > > To only allow the use of __atomic_add_fetch when __ATOMIC_RELAXED is > > > non-zero > > > > > isn't the right move here. So it seems that different compilers > > > either only > > > implement a subset of the __atomic builtins, or name them > > > differently. > > > > > > What was the macro defined by the DeveloperStudio compiler? > > > __SUNPRO_C or > > > something else? In that case, the correct method might be to exclude > > > it, like > > > this: > > > > > > #if defined(__ATOMIC_RELAXED) && !defined(__SUNPRO_C) > > > > > > On Mon Aug 08 08:33:34 2016, yoi_no_myoujou at yahoo.co.jp wrote: > > >> Hello, > > >> > > >> % ./Configure solaris-x86-cc > > >> % make > > >> : > > >> Undefined first referenced > > >> symbol in file > > >> __atomic_add_fetch ./libcrypto.so > > >> ld: fatal: symbol referencing errors. No output written to > > >> fuzz/asn1parse-test > > >> > > >> > > >> % ./Configure solaris64-x86_64-cc > > >> % make > > >> has the same error. > > >> > > >> Tested on Solaris10 x86/64, with Solaris developerstudio12.5. > > >> > > >> > > >> This is caused because __ATOMIC_RELAXED is #defined as 0 > > >> in /opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h > > >> > > >> > > >> Sample patch: > > >> --- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c > > >> +++ ./crypto/threads_pthread.c > > >> @@ -109,7 +109,7 @@ > > >> > > >> int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK > > >> *lock) > > >> { > > >> -#ifdef __ATOMIC_RELAXED > > >> +#if __ATOMIC_RELAXED > > >> *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED); > > >> #else > > >> if (!CRYPTO_THREAD_write_lock(lock)) > > >> > > >> > > >> With this patch, > > >> % ./Configure solaris-x86-cc > > >> % make > > >> % make test > > >> passes. > > >> > > >> % ./Configure solaris64-x86_64-cc > > >> % make > > >> passes but > > >> % make test > > >> stops. > > >> This is another problem, which seems to be the same as bug #4641. > > >> > > >> > > >> Regards, > > >> > > >> --- Kiyoshi > > > > > > > > > -- > > > Richard Levitte > > > levitte at openssl.org > > > > > > -- > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 > > > Please log in as guest with password guest if prompted > > > > > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 24 13:51:41 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 24 Aug 2016 13:51:41 +0000 Subject: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc In-Reply-To: References: <838859.23452.qm@web101209.mail.kks.yahoo.co.jp> <2793.4468.qm@web101201.mail.kks.yahoo.co.jp> Message-ID: This has now been merged into the master branch, and will be part of version 1.1.0. Cheers, Richard ( closing ticket ) On Wed Aug 24 11:32:54 2016, levitte wrote: > After much internal deliberation, we ended up checking __GNUC__ rather > than > dissing __SUBPRO_C. Our hope is that a compiler that implements GNU > extensions > will also define __GNUC__. Our checks of the Intel compiler (which > someone > referred to) does so, for example (if I understood correctly). > > https://github.com/openssl/openssl/pull/1484 > > Cheers, > Richard > > On Tue Aug 23 10:48:46 2016, levitte wrote: > > Ok. I'm going with that solution, then. See attached diff. > > > > Cheers, > > Richard > > > > On Wed Aug 17 21:21:34 2016, yoi_no_myoujou at yahoo.co.jp wrote: > > > Yes, __SUNPRO_C is defined by DeveloperStudio compiler. > > > > > > > To only allow the use of __atomic_add_fetch when __ATOMIC_RELAXED > > > > is > > > > non-zero > > > > > > > isn't the right move here. So it seems that different compilers > > > > either only > > > > implement a subset of the __atomic builtins, or name them > > > > differently. > > > > > > > > What was the macro defined by the DeveloperStudio compiler? > > > > __SUNPRO_C or > > > > something else? In that case, the correct method might be to > > > > exclude > > > > it, like > > > > this: > > > > > > > > #if defined(__ATOMIC_RELAXED) && !defined(__SUNPRO_C) > > > > > > > > On Mon Aug 08 08:33:34 2016, yoi_no_myoujou at yahoo.co.jp wrote: > > > >> Hello, > > > >> > > > >> % ./Configure solaris-x86-cc > > > >> % make > > > >> : > > > >> Undefined first referenced > > > >> symbol in file > > > >> __atomic_add_fetch ./libcrypto.so > > > >> ld: fatal: symbol referencing errors. No output written to > > > >> fuzz/asn1parse-test > > > >> > > > >> > > > >> % ./Configure solaris64-x86_64-cc > > > >> % make > > > >> has the same error. > > > >> > > > >> Tested on Solaris10 x86/64, with Solaris developerstudio12.5. > > > >> > > > >> > > > >> This is caused because __ATOMIC_RELAXED is #defined as 0 > > > >> in > > > >> /opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h > > > >> > > > >> > > > >> Sample patch: > > > >> --- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c > > > >> +++ ./crypto/threads_pthread.c > > > >> @@ -109,7 +109,7 @@ > > > >> > > > >> int CRYPTO_atomic_add(int *val, int amount, int *ret, > > > >> CRYPTO_RWLOCK > > > >> *lock) > > > >> { > > > >> -#ifdef __ATOMIC_RELAXED > > > >> +#if __ATOMIC_RELAXED > > > >> *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED); > > > >> #else > > > >> if (!CRYPTO_THREAD_write_lock(lock)) > > > >> > > > >> > > > >> With this patch, > > > >> % ./Configure solaris-x86-cc > > > >> % make > > > >> % make test > > > >> passes. > > > >> > > > >> % ./Configure solaris64-x86_64-cc > > > >> % make > > > >> passes but > > > >> % make test > > > >> stops. > > > >> This is another problem, which seems to be the same as bug > > > >> #4641. > > > >> > > > >> > > > >> Regards, > > > >> > > > >> --- Kiyoshi > > > > > > > > > > > > -- > > > > Richard Levitte > > > > levitte at openssl.org > > > > > > > > -- > > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 > > > > Please log in as guest with password guest if prompted > > > > > > > > > > -- > > Richard Levitte > > levitte at openssl.org > > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642 Please log in as guest with password guest if prompted From c.holper at ades.at Wed Aug 24 18:44:37 2016 From: c.holper at ades.at (c.holper at ades.at) Date: Wed, 24 Aug 2016 20:44:37 +0200 Subject: [openssl-dev] RSA_size crashes Message-ID: Hi! I am looking for a problem with some PEM_key. But on the way I found some behavior I think is strange. Here is a small piece of code. ---------------------------------- #include #include #include // OpenSSL 1.0.1t 3 May 2016 // gcc version 4.9.2 (Debian 4.9.2-10) // g++ x.cpp -lssl -lcrypto int main (void) { setbuf (stdout,NULL); printf ("\ninit=%d", SSL_library_init ()); printf ("\nalgo=%d", OpenSSL_add_ssl_algorithms()); RSA *pk= RSA_new (); printf ("\npk=%d\n",pk); printf ("\ncheckkey=%d\n", RSA_check_key(pk)); printf ("\nsize=%d\n", RSA_size(pk)); printf ("\n------------\n"); return 0; } ---------------------------------- The output. ---------------------------------- init=1 algo=1 pk=25519296 checkkey=0 Segmentation fault ---------------------------------- Why does RSA_size crash? I would expect 0 or -1 or whatever but not a crash. Regards, Chris From rsalz at akamai.com Wed Aug 24 19:16:43 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 24 Aug 2016 19:16:43 +0000 Subject: [openssl-dev] RSA_size crashes In-Reply-To: References: Message-ID: <46af63ae48634fc8a3be250c54eb55f5@usma1ex-dag1mb1.msg.corp.akamai.com> You didn't fully initialize your RSA key, such as by adding the private or public parts. It shouldn't crash, but then again this is like doing an fprintf() without first checking if the fopen() succeeded. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From c.holper at ades.at Wed Aug 24 19:45:48 2016 From: c.holper at ades.at (c.holper at ades.at) Date: Wed, 24 Aug 2016 21:45:48 +0200 Subject: [openssl-dev] RSA_size crashes Message-ID: <54cde658-39fe-8368-1310-0e61d2fba241@ades.at> Well, ok. What is the best way to check a RSA-object is well initialized? I use PEM_read_bio_RSAPrivateKey to read a key into a RSA and all return-values are ok. But I get a crashes when I use it afterwards. Thanks, Chris From rsalz at akamai.com Wed Aug 24 19:50:41 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 24 Aug 2016 19:50:41 +0000 Subject: [openssl-dev] RSA_size crashes In-Reply-To: <54cde658-39fe-8368-1310-0e61d2fba241@ades.at> References: <54cde658-39fe-8368-1310-0e61d2fba241@ades.at> Message-ID: <6d504e13a751475aac93d84afa8ea418@usma1ex-dag1mb1.msg.corp.akamai.com> > I use PEM_read_bio_RSAPrivateKey to read a key into a RSA and all return- > values are ok. That's the first and most important test. One other thing you can do is use the "rsa" tool to print out the contents. > But I get a crashes when I use it afterwards. The code you posted isn't what you just described :) From rt at openssl.org Wed Aug 24 23:17:21 2016 From: rt at openssl.org (Quanah Gibson-Mount via RT) Date: Wed, 24 Aug 2016 23:17:21 +0000 Subject: [openssl-dev] [openssl.org #4658] bug: Abort() in 1.0.2h parsing server cert in ASN.1 routine In-Reply-To: <89871704495BA8B3771170F2@[192.168.1.19]> References: <89871704495BA8B3771170F2@[192.168.1.19]> Message-ID: A customer of ours has a server cert where the CSR was generated with 1.0.2h but was signed with 1.0.0j. When a process (nginx in this case) has this as the server cert, it core dumps with an abort() when clients request the cert: [root at zre-ldap005 q]# gdb /opt/zimbra/common/sbin/nginx core-nginx-sig6-user1004-group1004-pid8084-time1471924181 GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /opt/zimbra/common/sbin/nginx...Reading symbols from /usr/lib/debug/opt/zimbra/common/sbin/nginx.debug...done. done. [New LWP 8084] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `nginx: worker process '. Program terminated with signal 6, Aborted. #0 0x00007f22ba1245f7 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); Missing separate debuginfos, use: debuginfo-install pcre-8.32-15.el7_2.1.x86_64 zimbra-cyrus-sasl-libs-2.1.26-1zimbra8.7b1.el7.x86_64 zlib-1.2.7-15.el7.x86_64 (gdb) bt #0 0x00007f22ba1245f7 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007f22ba125ce8 in __GI_abort () at abort.c:90 #2 0x00007f22ba164327 in __libc_message (do_abort=do_abort at entry=2, fmt=fmt at entry=0x7f22ba26e488 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:196 #3 0x00007f22ba16ada5 in malloc_printerr (ar_ptr=0x7f22ba4aa760 , ptr=, str=0x7f22ba26bb57 "corrupted double-linked list", action=3) at malloc.c:5022 #4 malloc_consolidate (av=av at entry=0x7f22ba4aa760 ) at malloc.c:4169 #5 0x00007f22ba16ced5 in _int_malloc (av=av at entry=0x7f22ba4aa760 , bytes=bytes at entry=1366) at malloc.c:3443 #6 0x00007f22ba16f26c in __GI___libc_malloc (bytes=1366) at malloc.c:2895 #7 0x00007f22bab51048 in CRYPTO_malloc (num=num at entry=1366, file=file at entry=0x7f22bace2220 "tasn_utl.c", line=line at entry=174) at mem.c:342 #8 0x00007f22bac4be94 in asn1_enc_save (pval=pval at entry=0x21302b0, in=0x214c6ce "0\202\005R\240\003\002\001\002\002\002\022x0\r\006\t*\206H\206\367\r\001\001\v\005", inlen=1366, it=it at entry=0x7f22baf35f60 ) at tasn_utl.c:174 #9 0x00007f22bac4b14e in ASN1_item_ex_d2i (pval=, in=0x7ffc53c497e0, len=0, it=0x7f22baf35f60 , tag=, tag at entry=-1, aclass=, opt=0 '\000', ctx=0x7ffc53c49a10) at tasn_dec.c:492 #10 0x00007f22bac4b4f2 in asn1_template_noexp_d2i (val=0x21302b0, in=0x7ffc53c499a0, len=1513, tt=0x7f22baf3cd20 , opt=, ctx=0x7ffc53c49a10) at tasn_dec.c:694 #11 0x00007f22bac4b735 in asn1_template_ex_d2i (val=0x21302b0, in=0x7ffc53c499a0, inlen=1513, tt=0x7f22baf3cd20 , opt=, ctx=) at tasn_dec.c:582 #12 0x00007f22bac4ae9b in ASN1_item_ex_d2i (pval=pval at entry=0x7ffc53c49a00, in=in at entry=0x7ffc53c49a60, len=1513, len at entry=1517, it=it at entry=0x7f22baf35ee0 , tag=, tag at entry=-1, aclass=, aclass at entry=0, opt=opt at entry=0 '\000', ctx=ctx at entry=0x7ffc53c49a10) at tasn_dec.c:445 #13 0x00007f22bac4b294 in ASN1_item_d2i (pval=0x7ffc53c49a00, pval at entry=0x0, in=in at entry=0x7ffc53c49a60, len=len at entry=1517, it=it at entry=0x7f22baf35ee0 ) at tasn_dec.c:146 #14 0x00007f22bac435ec in d2i_X509 (a=a at entry=0x0, in=in at entry=0x7ffc53c49a60, len=len at entry=1517) at x_x509.c:143 #15 0x00007f22baf71da2 in ssl3_get_server_certificate (s=s at entry=0x2167a50) at s3_clnt.c:1228 #16 0x00007f22baf76cee in ssl3_connect (s=0x2167a50) at s3_clnt.c:345 #17 0x00007f22baf8166e in ssl23_get_server_hello (s=0x2167a50) at s23_clnt.c:799 #18 ssl23_connect (s=0x2167a50) at s23_clnt.c:228 #19 0x000000000044a755 in ngx_ssl_handshake (c=0x7f22b8ca0f60) at src/event/ngx_event_openssl.c:791 #20 0x000000000044adbf in ngx_ssl_handshake_handler (ev=0x7f22b8b99640) at src/event/ngx_event_openssl.c:939 #21 0x000000000043a8da in ngx_event_process_posted (cycle=0x1e86db0, posted=0x73d4e8 ) at src/event/ngx_event_posted.c:40 #22 0x000000000043843a in ngx_process_events_and_timers (cycle=0x1e86db0) at src/event/ngx_event.c:275 #23 0x0000000000445dad in ngx_worker_process_cycle (cycle=0x1e86db0, data=0x1) at src/os/unix/ngx_process_cycle.c:879 #24 0x00000000004423cb in ngx_spawn_process (cycle=0x1e86db0, proc=0x445bca , data=0x1, name=0x4ff02f "worker process", respawn=1) at src/os/unix/ngx_process.c:198 #25 0x000000000044579d in ngx_reap_children (cycle=0x1e86db0) at src/os/unix/ngx_process_cycle.c:688 #26 0x0000000000444443 in ngx_master_process_cycle (cycle=0x1e86db0) at src/os/unix/ngx_process_cycle.c:241 #27 0x00000000004075fb in main (argc=3, argv=0x7ffc53c4a278) at src/core/nginx.c:407 Let me know what further information I can provide. --Quanah -- Quanah Gibson-Mount -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4658 Please log in as guest with password guest if prompted From openssl-users at dukhovni.org Wed Aug 24 23:36:37 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 24 Aug 2016 23:36:37 +0000 Subject: [openssl-dev] [openssl.org #4658] bug: Abort() in 1.0.2h parsing server cert in ASN.1 routine In-Reply-To: References: <89871704495BA8B3771170F2@[192.168.1.19]> Message-ID: <20160824233637.GN4670@mournblade.imrryr.org> On Wed, Aug 24, 2016 at 11:17:21PM +0000, Quanah Gibson-Mount via RT wrote: > When a process (nginx in this case) has this as the server cert, it core > dumps with an abort() when clients request the cert: You say the server dumps core, and yet: > #1 0x00007f22ba125ce8 in __GI_abort () at abort.c:90 > [...] > #14 0x00007f22bac435ec in d2i_X509 (a=a at entry=0x0, > in=in at entry=0x7ffc53c49a60, len=len at entry=1517) at x_x509.c:143 > #15 0x00007f22baf71da2 in ssl3_get_server_certificate (s=s at entry=0x2167a50) > at s3_clnt.c:1228 > #16 0x00007f22baf76cee in ssl3_connect (s=0x2167a50) at s3_clnt.c:345 > #17 0x00007f22baf8166e in ssl23_get_server_hello (s=0x2167a50) at > s23_clnt.c:799 > #18 ssl23_connect (s=0x2167a50) at s23_clnt.c:228 this is clearly a TLS client-side stack trace. Why is nginx acting as an SSL/TLS client? > #19 0x000000000044a755 in ngx_ssl_handshake (c=0x7f22b8ca0f60) at > src/event/ngx_event_openssl.c:791 > #20 0x000000000044adbf in ngx_ssl_handshake_handler (ev=0x7f22b8b99640) at > src/event/ngx_event_openssl.c:939 > #21 0x000000000043a8da in ngx_event_process_posted (cycle=0x1e86db0, > posted=0x73d4e8 ) at src/event/ngx_event_posted.c:40 > #22 0x000000000043843a in ngx_process_events_and_timers (cycle=0x1e86db0) > at src/event/ngx_event.c:275 > #23 0x0000000000445dad in ngx_worker_process_cycle (cycle=0x1e86db0, > data=0x1) at src/os/unix/ngx_process_cycle.c:879 > #24 0x00000000004423cb in ngx_spawn_process (cycle=0x1e86db0, proc=0x445bca > , data=0x1, name=0x4ff02f "worker process", > respawn=1) > at src/os/unix/ngx_process.c:198 > #25 0x000000000044579d in ngx_reap_children (cycle=0x1e86db0) at > src/os/unix/ngx_process_cycle.c:688 > #26 0x0000000000444443 in ngx_master_process_cycle (cycle=0x1e86db0) at > src/os/unix/ngx_process_cycle.c:241 > #27 0x00000000004075fb in main (argc=3, argv=0x7ffc53c4a278) at > src/core/nginx.c:407 This feels like some sort concurrency/reentrancy issue, and the certificate processed is probably one that nginx got off the wire from a remote server. Find out what nginx is connecting to and why, and whether there are any potential concurrency issues. -- Viktor. From quanah at zimbra.com Wed Aug 24 23:47:12 2016 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Wed, 24 Aug 2016 16:47:12 -0700 Subject: [openssl-dev] [openssl.org #4658] bug: Abort() in 1.0.2h parsing server cert in ASN.1 routine In-Reply-To: <20160824233637.GN4670@mournblade.imrryr.org> References: <89871704495BA8B3771170F2@[192.168.1.19]> <20160824233637.GN4670@mournblade.imrryr.org> Message-ID: <621497F2AD76E17D24EB9CFC@[192.168.1.19]> --On Thursday, August 25, 2016 12:36 AM +0000 Viktor Dukhovni wrote: > On Wed, Aug 24, 2016 at 11:17:21PM +0000, Quanah Gibson-Mount via RT > wrote: > >> When a process (nginx in this case) has this as the server cert, it core >> dumps with an abort() when clients request the cert: > > You say the server dumps core, and yet: > >> # 1 0x00007f22ba125ce8 in __GI_abort () at abort.c:90 >> [...] >> # 14 0x00007f22bac435ec in d2i_X509 (a=a at entry=0x0, >> in=in at entry=0x7ffc53c49a60, len=len at entry=1517) at x_x509.c:143 >> # 15 0x00007f22baf71da2 in ssl3_get_server_certificate >> # (s=s at entry=0x2167a50) >> at s3_clnt.c:1228 >> # 16 0x00007f22baf76cee in ssl3_connect (s=0x2167a50) at s3_clnt.c:345 >> # 17 0x00007f22baf8166e in ssl23_get_server_hello (s=0x2167a50) at >> s23_clnt.c:799 >> # 18 ssl23_connect (s=0x2167a50) at s23_clnt.c:228 > > this is clearly a TLS client-side stack trace. Why is nginx acting > as an SSL/TLS client? It's a proxy server... so it's proxying between the client connecting to nginx on the IMAPS port and the jetty server on the other side. so: end user <-> nginx:143 <-> jetty:7143 The issue only happens when proxying IMAP on port 143 with startTLS or 993 (IMAPS). It does not occur on POP w/ starttls or web traffic (443). It also is only happening with this one particular client, as we have numerous customers (and our own setup) not experiencing this issue. I'll have them supply what's in their keystore that Jetty's using as well. --Quanah -- Quanah Gibson-Mount From tshort at akamai.com Thu Aug 25 12:21:15 2016 From: tshort at akamai.com (Short, Todd) Date: Thu, 25 Aug 2016 12:21:15 +0000 Subject: [openssl-dev] [openssl-users] Building OpenSSL 1.0.1t without tls1.1 support? In-Reply-To: References: Message-ID: <786204F1-1C75-40ED-91AC-B317EE987676@akamai.com> 1.0.1 is old, and not really supported, except some security fixes. 1.0.x does not provide the ability to compile out TLSv1.0 from 1.1 from 1.2. The upcoming 1.1.x does. If you disable tls1, then you?ve also disabled all later versions, so enable tlsv1 at config time and use the SSL options to enable/disable the protocols at run time. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Aug 22, 2016, at 3:08 PM, Scott Neugroschl > wrote: I?ve done a custom build of OpenSSL where I ran Configure with ?no-ssl2? and ?no-ssl3?. I?d like to disable TLS1 and 1.1 if possible. Will the no-tls1 option disable just TLS1 or all TLS1.x protocols? Thanks, ScottN -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu Aug 25 12:46:36 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 25 Aug 2016 12:46:36 +0000 Subject: [openssl-dev] [openssl.org #2712] Be more liberal when trying to recognize the XMPP starttls headers In-Reply-To: <1310978044.760.17.camel@vespa.frost.loc> References: <1310978044.760.17.camel@vespa.frost.loc> Message-ID: Now being discussed at https://github.com/openssl/openssl/issues/1494 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2712 Please log in as guest with password guest if prompted From openssl at openssl.org Thu Aug 25 16:46:45 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 25 Aug 2016 16:46:45 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0 published Message-ID: <20160825164645.GA30454@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.1.0 released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.0 of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.0-notes.html OpenSSL 1.1.0 is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0.tar.gz Size: 5146831 SHA1 checksum: 15e651c40424abdaeba5d5c1a8658e8668e798c8 SHA256 checksum: f5c69ff9ac1472c80b868efc1c1c0d8dcfc746d29ebe563de2365dd56dbd8c82 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0.tar.gz openssl sha256 openssl-1.1.0.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXvw7WAAoJENnE0m0OYESRmhkH/1UTJ3I1v52w3NDWKK5XGyxH HKr/EMgjo05IdmtmY3lLB0aPwN50am5Y9w8SmFnXA8+bsKwH61+G5Sr9L+ABuhI2 95QQzxAyQBHf0IxH1hYBLZxI0Hr46O9qefphr7lcBIh/XrFu6Hg96s8lo/87UEEC LUzOAGAEpM6kicBA4bxrLdXSV+IR+j/2mRrkGvw4Ecb9aQYxWJ6daWxJcvXKKy8N S8Gw4DNJH2636UyKsbY/6bMGlBWbjmL9GLzbD1YT+NxvSsWPPRkrdDhMKxkxDrP4 gIBBSE4C7mZgqvSxVIo2GQszQgTUdroyd9UStUDsBF/xYK2a8bvoL0PtihZF+0E= =Zq4E -----END PGP SIGNATURE----- From rt at openssl.org Thu Aug 25 17:47:56 2016 From: rt at openssl.org (Ian Spence via RT) Date: Thu, 25 Aug 2016 17:47:56 +0000 Subject: [openssl-dev] [openssl.org #4659] Enhancement: PEM_write_PrivateKey should return an error response if an invalid cipher is specified In-Reply-To: References: Message-ID: Hello I just overcame an annoying problem where PEM_write_PrivateKey would return a success response code, but the file would be blank. I ensured that I closed the FILE pointer, so any cached data should've been flushed. Eventually I found that I was specifying an incorrect cipher. Here's what I was doing before: FILE * f = fopen("PathToMyPrivateKey.pem", "wb"); const char * password = "Password"; int rv = PEM_write_PrivateKey(f, pkey, EVP_aes_256_cbc_hmac_sha1(), (unsigned char *)password, (int)strlen(password), NULL, NULL); fclose(f); return rv; RV will be 1, indicating success, but the file will be 0 bytes. I changed the cipher to use EVP_aes_256_cbc() instead, and then everything worked as intended. I propose an enhancement that if the cipher is not valid, an error response is returned. Thank you! -- Ian Spence / Systems Administrator and Software Developer +1 (778) 872-9254/ ian at ecnepsnai.com PGP Key: keybase.io/ecnepsnai -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4659 Please log in as guest with password guest if prompted From steffen at sdaoden.eu Thu Aug 25 21:14:06 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 25 Aug 2016 23:14:06 +0200 Subject: [openssl-dev] OpenSSL version 1.1.0 published In-Reply-To: <20160825164645.GA30454@openssl.org> References: <20160825164645.GA30454@openssl.org> Message-ID: <20160825211406.h14-41XWm%steffen@sdaoden.eu> Good evening. OpenSSL wrote: | OpenSSL version 1.1.0 released A bit distressing that it is me again, as if i would have something to do with that..., but: the tag is missing. | https://www.openssl.org/news/openssl-1.1.0-notes.html Looks good in Lynx! Anyway, it must be a huge relief to finally be rid of all those lines of development, with a [master] that is several thousand commits ahead, so: Congratulations! Ciao. --steffen From tom at ritter.vg Thu Aug 25 21:33:31 2016 From: tom at ritter.vg (Tom Ritter) Date: Thu, 25 Aug 2016 16:33:31 -0500 Subject: [openssl-dev] Fuzzer Patch(es) Message-ID: NCC Group has prepared (or begun preparing) a patch that integrates fuzzing of OpenSSL. This work was done primarily by Tim Newsham, although the code is based on selftls by Hanno B?ck, and it was modified by me to fit into the OpenSSL tree. The general messiness is caused by me, not Tim. Rather than attach a giant patch, I put it up here: https://github.com/nccgroup/openssl/tree/ncc-fuzzer It consists of three parts: - Expansive changes to the ossltest engine to support (broken) RSA and many more (broken) symmetric ciphers - Two function additions to OpenSSL that, when compiled with FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION, insert deterministic timestamps into the TLS protocol - The ftls fuzz harness that speaks TLS to itself and allows for fuzzing any individual client or server message in the handshake This has only been tested on Linux x64 so far. I have had some trouble getting some parts working, but the fuzzing does commence. wget http://lcamtuf.coredump.cx/afl/releases/afl-latest.tgz tar xfv afl- ln -s afl-2 afl cd afl ; make ; cd .. git clone git at github.com:nccgroup/openssl.git ncc-fuzzer cd ncc-fuzzer git checkout ncc-fuzzer CC=../afl/afl-clang ./Configure linux-x86_64 -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION enable-ssl3 enable-ssl3-method enable-weak-ssl-ciphers enable-crypto-mdebug enable-asan enable-afl-fuzz (Optional: Edit Makefile and change '-O3' to '-O0' and '-g' to '-ggdb'. I couldn't figure out how to make this part of the Configure command.) make (Ignore errors at the end for code in test/fuzz) cd test/ftls ln -s ../../../afl-2 afl make all ./genCerts ./makeInputs LD_LIBRARY_PATH=../../ ./afl/afl-fuzz -i inputs -o outputs -m 99999999999999 -- ./ftls-afl There are few pieces that I was unable to get working correctly: 1) The ossltest engine needs to have libcrypto statically linked into it. ftls has openssl libraries statically linked into them for ASAN+AFL fuzzing, but ossltest wants them loaded dynamically. The correct thing to do is compile ossltest with libcrypto linked statically, but I could not figure out the correct way to represent that with the build.info configurations. http://stackoverflow.com/a/2649792 seems to be the correct instructions for the compiler/linker. Until this is fixed, the above LD_LIBRARY_PATH=../../ is needed. 2) I had trouble compiling with 'enable-asan' unless I used clang. gcc gave me problems. 3) I got compilation errors for code in test/ when compiling with enable-afl-fuzz; however the important stuff compiled. 4) ERR_load_OSSLTEST_strings() in the original e_ossltest.c was causing a Segfault (under ASAN) on exit, so I commented it out. 5) The original version of ftls by Tim included support for compiling and fuzzing on 32-bit and also getting gcov-based profiling information. While references and stubs to this are still in the Makefile, I wasn't able to fully investigate and get those aspects of it working 6) There are some memory leaks that are exposed when you run ./makeInputs - I tracked most of them down, but a few remained. I believe these are from ftls and not OpenSSL. This fuzzer hits lots of things, but there are lots more things in OpenSSL. It has the following limitations: - It doesn't support all the possible features of TLS. But it does support a lot of them. (makeInputs lists many things not completed at the end of the file) - The ossltest engine does not include support for removed ciphers like DES, RC2, or GOST. However, there are some mentions/stubs of that, as the fuzzer was written before all of these things were removed from 1.1 - Because ossltest cooks MD5 to output a constant value, OpenSSL's RNG becomes constant. This causes an error in ssl/ssl_sess.c:generate_session_id() because it always generates a colliding Session ID. This breaks renegotiation in the test harness. I haven't thought of an elegant way to resolve this. My ability to continue this effort is going to be extremely limited in the upcoming weeks, so I'm hopeful a community member will help us bring this across the finish line if OpenSSL is (still) interested in having this work merged into master. -tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Aug 25 22:29:38 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 25 Aug 2016 23:29:38 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 published In-Reply-To: <20160825211406.h14-41XWm%steffen@sdaoden.eu> References: <20160825164645.GA30454@openssl.org> <20160825211406.h14-41XWm%steffen@sdaoden.eu> Message-ID: On 25/08/16 22:14, Steffen Nurpmeso wrote: > Good evening. > > OpenSSL wrote: > | OpenSSL version 1.1.0 released > > A bit distressing that it is me again, as if i would have > something to do with that..., but: the tag is missing. Really? I seem to be able to see it in both the primary openssl repo and the github repo. Matt > > | https://www.openssl.org/news/openssl-1.1.0-notes.html > > Looks good in Lynx! > Anyway, it must be a huge relief to finally be rid of all those > lines of development, with a [master] that is several thousand > commits ahead, so: Congratulations! > Ciao. > > --steffen > From matt at openssl.org Thu Aug 25 22:34:23 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 25 Aug 2016 23:34:23 +0100 Subject: [openssl-dev] Fuzzer Patch(es) In-Reply-To: References: Message-ID: <5d0cee73-2dd1-1eb8-9248-8984ab1a0ab7@openssl.org> On 25/08/16 22:33, Tom Ritter wrote: > NCC Group has prepared (or begun preparing) a patch that integrates > fuzzing of OpenSSL. This work was done primarily by Tim Newsham, > although the code is based on selftls by Hanno B?ck, and it was modified > by me to fit into the OpenSSL tree. The general messiness is caused by > me, not Tim. > > Rather than attach a giant patch, I put it up here: > https://github.com/nccgroup/openssl/tree/ncc-fuzzer > > It consists of three parts: > > - Expansive changes to the ossltest engine to support (broken) RSA and > many more (broken) symmetric ciphers > - Two function additions to OpenSSL that, when compiled with > FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION, insert deterministic > timestamps into the TLS protocol > - The ftls fuzz harness that speaks TLS to itself and allows for fuzzing > any individual client or server message in the handshake > > > This has only been tested on Linux x64 so far. I have had some trouble > getting some parts working, but the fuzzing does commence. > > wget http://lcamtuf.coredump.cx/afl/releases/afl-latest.tgz > tar xfv afl- > ln -s afl-2 afl > cd afl ; make ; cd .. > git clone git at github.com:nccgroup/openssl.git ncc-fuzzer > cd ncc-fuzzer > git checkout ncc-fuzzer > CC=../afl/afl-clang ./Configure linux-x86_64 > -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION enable-ssl3 > enable-ssl3-method enable-weak-ssl-ciphers enable-crypto-mdebug > enable-asan enable-afl-fuzz > (Optional: Edit Makefile and change '-O3' to '-O0' and '-g' to '-ggdb'. > I couldn't figure out how to make this part of the Configure command.) > make > (Ignore errors at the end for code in test/fuzz) > cd test/ftls > ln -s ../../../afl-2 afl > make all > ./genCerts > ./makeInputs > LD_LIBRARY_PATH=../../ ./afl/afl-fuzz -i inputs -o outputs -m > 99999999999999 -- ./ftls-afl > > > There are few pieces that I was unable to get working correctly: > > 1) The ossltest engine needs to have libcrypto statically linked into > it. ftls has openssl libraries statically linked into them for ASAN+AFL > fuzzing, but ossltest wants them loaded dynamically. The correct thing > to do is compile ossltest with libcrypto linked statically, but I could > not figure out the correct way to represent that with the build.info > configurations. http://stackoverflow.com/a/2649792 > seems to be the correct instructions for the compiler/linker. > > Until this is fixed, the above LD_LIBRARY_PATH=../../ is needed. > > 2) I had trouble compiling with 'enable-asan' unless I used clang. gcc > gave me problems. > > 3) I got compilation errors for code in test/ when compiling with > enable-afl-fuzz; however the important stuff compiled. > > 4) ERR_load_OSSLTEST_strings() in the original e_ossltest.c was causing > a Segfault (under ASAN) on exit, so I commented it out. > > 5) The original version of ftls by Tim included support for compiling > and fuzzing on 32-bit and also getting gcov-based profiling information. > While references and stubs to this are still in the Makefile, I wasn't > able to fully investigate and get those aspects of it working > > 6) There are some memory leaks that are exposed when you run > ./makeInputs - I tracked most of them down, but a few remained. I > believe these are from ftls and not OpenSSL. > > > This fuzzer hits lots of things, but there are lots more things in > OpenSSL. It has the following limitations: > - It doesn't support all the possible features of TLS. But it does > support a lot of them. (makeInputs lists many things not completed at > the end of the file) > - The ossltest engine does not include support for removed ciphers like > DES, RC2, or GOST. However, there are some mentions/stubs of that, as > the fuzzer was written before all of these things were removed from 1.1 > - Because ossltest cooks MD5 to output a constant value, OpenSSL's RNG > becomes constant. This causes an error in > ssl/ssl_sess.c:generate_session_id() because it always generates a > colliding Session ID. This breaks renegotiation in the test harness. I > haven't thought of an elegant way to resolve this. > > > My ability to continue this effort is going to be extremely limited in > the upcoming weeks, so I'm hopeful a community member will help us bring > this across the finish line if OpenSSL is (still) interested in having > this work merged into master. Wow! Thanks Tom and Tim. This is fantastic. I really hope someone picks this up - this would be great to get integrated. Matt From raysatiro at yahoo.com Fri Aug 26 05:14:22 2016 From: raysatiro at yahoo.com (Ray Satiro) Date: Fri, 26 Aug 2016 01:14:22 -0400 Subject: [openssl-dev] Lib names on Windows changed in OpenSSL 1.1.0 Message-ID: <7ff7678e-3c4c-6343-3a5b-b2aa0caf7ba5@yahoo.com> I am part of a project that has several build systems, and two in particular are not dynamically generated, a makefile and a number of Visual Studio project files, all of which link to ssleay32.lib and libeay32.lib for OpenSSL. I've noticed in 1.1.0 the names were changed to libssl.lib and libcrypto.lib. We would like for our project files to be compatible with OpenSSL 1.1.0 and earlier versions, so that someone can just open a project file and it will link to whatever version of OpenSSL they're using. I am wondering if anyone else has brought this up (searching I couldn't find anything), whether you have considered for compatibility copying the libs to the old names, or if you have any ideas for me. The project is cURL, https://github.com/curl/curl. Thanks From levitte at openssl.org Fri Aug 26 07:19:27 2016 From: levitte at openssl.org (Richard Levitte) Date: Fri, 26 Aug 2016 09:19:27 +0200 (CEST) Subject: [openssl-dev] Lib names on Windows changed in OpenSSL 1.1.0 In-Reply-To: <7ff7678e-3c4c-6343-3a5b-b2aa0caf7ba5@yahoo.com> References: <7ff7678e-3c4c-6343-3a5b-b2aa0caf7ba5@yahoo.com> Message-ID: <20160826.091927.1041211560195411018.levitte@openssl.org> In message <7ff7678e-3c4c-6343-3a5b-b2aa0caf7ba5 at yahoo.com> on Fri, 26 Aug 2016 01:14:22 -0400, Ray Satiro said: raysatiro> I am part of a project that has several build systems, and two in raysatiro> particular are not dynamically generated, a makefile and a number of raysatiro> Visual Studio project files, all of which link to ssleay32.lib and raysatiro> libeay32.lib for OpenSSL. I've noticed in 1.1.0 the names were changed raysatiro> to libssl.lib and libcrypto.lib. We would like for our project files raysatiro> to be compatible with OpenSSL 1.1.0 and earlier versions, so that raysatiro> someone can just open a project file and it will link to whatever raysatiro> version of OpenSSL they're using. I am wondering if anyone else has raysatiro> brought this up (searching I couldn't find anything), whether you have raysatiro> considered for compatibility copying the libs to the old names, or if raysatiro> you have any ideas for me. The project is cURL, raysatiro> https://github.com/curl/curl. Thanks I do recall discussing this quite a bit, back when the unified build system was introduced, which was at the beginning of this year. I cannot currently recall exactly where the discussions were taking place. Some were on github, some were internal within the team. As for your project file, you're talking about the stuff in winbuild/, right? I had a look here: https://github.com/curl/curl/tree/master/winbuild So I'm wondering, couldn't you have something among the action lines in https://github.com/curl/curl/blob/master/winbuild/Makefile.vc, something like this? SET LIBCRYPTO_NAME=libcrypto SET LIBSSL_NAME=libssl IF EXIST libeay32.lib SET LIBCRYPTO_NAME=libeay32 IF EXIST ssleay32.lib SET LIBSSL_NAME=ssleay32 And then make sure to use $(LIBCRYPTO_NAME) and $(LIBSSL_NAME) in MakefileBuild.vc? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From steffen at sdaoden.eu Fri Aug 26 10:42:03 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 26 Aug 2016 12:42:03 +0200 Subject: [openssl-dev] OpenSSL version 1.1.0 published In-Reply-To: References: <20160825164645.GA30454@openssl.org> <20160825211406.h14-41XWm%steffen@sdaoden.eu> Message-ID: <20160826104203.XZMEd1pQh%steffen@sdaoden.eu> N'morning UK. (^.^) Matt Caswell wrote: |On 25/08/16 22:14, Steffen Nurpmeso wrote: |> OpenSSL wrote: |>| OpenSSL version 1.1.0 released |> |> A bit distressing that it is me again, as if i would have |> something to do with that..., but: the tag is missing. | |Really? I seem to be able to see it in both the primary openssl repo and |the github repo. Hmmm. ?130[steffen at wales code.arena]$ ./.arena-manager.sh autoup openssl.git/ /home/steffen/usr/bin/arena-manager: script startup, mode autoup Checking how likely it is an update would succeed openssl.git: looks good ================================================================ openssl.git: performing autoup: update Looking up git.openssl.org ... done. Connecting to git.openssl.org (port 9418) ... 194.97.150.234 done. remote: warning: unable to access '/root/.config/git/attributes': Permission denied From git://git.openssl.org/openssl 156e34f..bbf73f8 master -> origin/master 1027ad4..3953bf5 OpenSSL_1_0_2-stable -> origin/OpenSSL_1_0_2-stable = [up to date] OpenSSL_1_0_1-stable -> origin/OpenSSL_1_0_1-stable ... {at least "master" and "remotes/origin/master" differ, marking for autogc} ... ok: openssl.git ================================================================ ================================================================ openssl.git: performing autoup: automerge ... Performing automerge from origin/master to master Updating 156e34f..bbf73f8 Fast-forward CHANGES | 4 ---- 1 file changed, 4 deletions(-) ... ok: openssl.git ================================================================ Turned over to mode gc ================================================================ openssl.git: performing gc real 0m10.079s user 0m6.830s sys 0m1.703s ... ok: openssl.git ================================================================ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ All seems fine around here, ciao ?0[steffen at wales code.arena]$ cd openssl.git/ ?0[steffen at wales openssl.git]$ git describe master OpenSSL_1_1_0-pre6-297-gbbf73f8 No, no, not that i know. Ciao. --steffen From matt at openssl.org Fri Aug 26 10:54:28 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 26 Aug 2016 11:54:28 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 published In-Reply-To: <20160826104203.XZMEd1pQh%steffen@sdaoden.eu> References: <20160825164645.GA30454@openssl.org> <20160825211406.h14-41XWm%steffen@sdaoden.eu> <20160826104203.XZMEd1pQh%steffen@sdaoden.eu> Message-ID: <288116ba-f768-83d7-d398-14d264451fdb@openssl.org> On 26/08/16 11:42, Steffen Nurpmeso wrote: > N'morning UK. (^.^) > > Matt Caswell wrote: > |On 25/08/16 22:14, Steffen Nurpmeso wrote: > |> OpenSSL wrote: > |>| OpenSSL version 1.1.0 released > |> > |> A bit distressing that it is me again, as if i would have > |> something to do with that..., but: the tag is missing. > | > |Really? I seem to be able to see it in both the primary openssl repo and > |the github repo. > > Hmmm. > > ?130[steffen at wales code.arena]$ ./.arena-manager.sh autoup openssl.git/ > /home/steffen/usr/bin/arena-manager: script startup, mode autoup > Checking how likely it is an update would succeed > openssl.git: looks good > > ================================================================ > openssl.git: performing autoup: update > Looking up git.openssl.org ... done. > Connecting to git.openssl.org (port 9418) ... 194.97.150.234 done. > remote: warning: unable to access '/root/.config/git/attributes': Permission denied > From git://git.openssl.org/openssl > 156e34f..bbf73f8 master -> origin/master > 1027ad4..3953bf5 OpenSSL_1_0_2-stable -> origin/OpenSSL_1_0_2-stable > = [up to date] OpenSSL_1_0_1-stable -> origin/OpenSSL_1_0_1-stable > ... {at least "master" and "remotes/origin/master" differ, marking for autogc} > ... ok: openssl.git > ================================================================ > > ================================================================ > openssl.git: performing autoup: automerge > > ... Performing automerge from origin/master to master > Updating 156e34f..bbf73f8 > Fast-forward > CHANGES | 4 ---- > 1 file changed, 4 deletions(-) > ... ok: openssl.git > ================================================================ > Turned over to mode gc > > ================================================================ > openssl.git: performing gc > > real 0m10.079s > user 0m6.830s > sys 0m1.703s > ... ok: openssl.git > ================================================================ > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > All seems fine around here, ciao > ?0[steffen at wales code.arena]$ cd openssl.git/ > ?0[steffen at wales openssl.git]$ git describe master > OpenSSL_1_1_0-pre6-297-gbbf73f8 > > No, no, not that i know. > Ciao. I'm not sure what you're trying to show me there. What does this give you: git ls-remote --tags origin | grep OpenSSL_1_1_0 Matt From steffen at sdaoden.eu Fri Aug 26 10:58:34 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 26 Aug 2016 12:58:34 +0200 Subject: [openssl-dev] OpenSSL version 1.1.0 published In-Reply-To: <20160826104203.XZMEd1pQh%steffen@sdaoden.eu> References: <20160825164645.GA30454@openssl.org> <20160825211406.h14-41XWm%steffen@sdaoden.eu> <20160826104203.XZMEd1pQh%steffen@sdaoden.eu> Message-ID: <20160826105834.h-VME0hzM%steffen@sdaoden.eu> |N'morning UK. (^.^) Ok i'm awake, you've created a new branch for that. Thanks. --steffen From steffen at sdaoden.eu Fri Aug 26 11:04:25 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 26 Aug 2016 13:04:25 +0200 Subject: [openssl-dev] OpenSSL version 1.1.0 published In-Reply-To: <288116ba-f768-83d7-d398-14d264451fdb@openssl.org> References: <20160825164645.GA30454@openssl.org> <20160825211406.h14-41XWm%steffen@sdaoden.eu> <20160826104203.XZMEd1pQh%steffen@sdaoden.eu> <288116ba-f768-83d7-d398-14d264451fdb@openssl.org> Message-ID: <20160826110425.uoWHc7X5r%steffen@sdaoden.eu> Matt Caswell wrote: |> Matt Caswell wrote: |>|On 25/08/16 22:14, Steffen Nurpmeso wrote: |>|> OpenSSL wrote: |>|>| OpenSSL version 1.1.0 released |>|> |>|> A bit distressing that it is me again, as if i would have |>|> something to do with that..., but: the tag is missing. |>| |>|Really? I seem to be able to see it in both the primary openssl repo and |>|the github repo. |> ?0[steffen at wales code.arena]$ cd openssl.git/ |> ?0[steffen at wales openssl.git]$ git describe master |> OpenSSL_1_1_0-pre6-297-gbbf73f8 |> |> No, no, not that i know. |I'm not sure what you're trying to show me there. What does this give you: | |git ls-remote --tags origin | grep OpenSSL_1_1_0 Yes, thank you. You have created a new branch for this tag, i didn't think about that first, because all the pre- were on plain [master]. Now have it. Ciao. --steffen From asmarner at yahoo.com Fri Aug 26 15:14:58 2016 From: asmarner at yahoo.com (asmarner at yahoo.com) Date: Fri, 26 Aug 2016 15:14:58 +0000 (UTC) Subject: [openssl-dev] SSL_CTX_use_certificate_chain_file() References: <1214035507.263225.1472224498381.ref@mail.yahoo.com> Message-ID: <1214035507.263225.1472224498381@mail.yahoo.com> Hi, ? Is there any negative impact ofusing?SSL_CTX_use_certificate_file() and SSL_CTX_use_certificate_chain_file() together? ? My application loads thecertificate using SSL_CTX_use_certificate_file()and loads the complete chain using SSL_CTX_use_certificate_chain_file(). ? Theapplication works as expected. ? Justwanted to know if there will be any negative impact. Wanted this information fromOpenssl developer forum. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Aug 26 15:21:24 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 26 Aug 2016 15:21:24 +0000 Subject: [openssl-dev] SSL_CTX_use_certificate_chain_file() In-Reply-To: <1214035507.263225.1472224498381@mail.yahoo.com> References: <1214035507.263225.1472224498381.ref@mail.yahoo.com> <1214035507.263225.1472224498381@mail.yahoo.com> Message-ID: <20160826152123.GS4670@mournblade.imrryr.org> On Fri, Aug 26, 2016 at 03:14:58PM +0000, asmarner at yahoo.com wrote: > Is there any negative impact ofusing?SSL_CTX_use_certificate_file() and > SSL_CTX_use_certificate_chain_file() together? The first is redundant and should avoided. > My application loads thecertificate using SSL_CTX_use_certificate_file() and > loads the complete chain using SSL_CTX_use_certificate_chain_file(). The latter also loads the leaf certificate, so the former is not needed. -- Viktor. From asmarner at yahoo.com Fri Aug 26 15:28:10 2016 From: asmarner at yahoo.com (asmarner at yahoo.com) Date: Fri, 26 Aug 2016 15:28:10 +0000 (UTC) Subject: [openssl-dev] SSL_CTX_use_certificate_chain_file() In-Reply-To: <20160826152123.GS4670@mournblade.imrryr.org> References: <1214035507.263225.1472224498381.ref@mail.yahoo.com> <1214035507.263225.1472224498381@mail.yahoo.com> <20160826152123.GS4670@mournblade.imrryr.org> Message-ID: <2004095032.273758.1472225290701@mail.yahoo.com> Thanks for the reply. I know about the redundancy part. Wanted to know if there could be any negative impact. On Friday, August 26, 2016 8:51 PM, Viktor Dukhovni wrote: On Fri, Aug 26, 2016 at 03:14:58PM +0000, asmarner at yahoo.com wrote: > Is there any negative impact ofusing?SSL_CTX_use_certificate_file() and > SSL_CTX_use_certificate_chain_file() together? The first is redundant and should avoided. > My application loads thecertificate using SSL_CTX_use_certificate_file() and > loads the complete chain using SSL_CTX_use_certificate_chain_file(). The latter also loads the leaf certificate, so the former is not needed. -- ??? Viktor. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From wsware at gmail.com Fri Aug 26 16:01:16 2016 From: wsware at gmail.com (Scott Ware) Date: Fri, 26 Aug 2016 12:01:16 -0400 Subject: [openssl-dev] Building VC-WIN32 with VS2012 and above breaks older CPU compatability Message-ID: When building with Visual Studio 2008 SSE is disabled by default. When building with Visual Studio 2012 and above you must supply a new flag /arch:IA32 to not build with SSE. Would it be acceptable to update the Configure process to add the /arch:IA32 if Visual Studio 2012 or greater is detected? This applies to the normal C code. We ran into issues when running on an AMD Geode processor. I tested changing the VC-32.pl on OpenSSL 1.0.2g and it worked well, but I see the whole build process has changed in Current. I wanted to find out if this is an acceptable change before I figure out the new Configure process and submit a patch. else # Win32 { ...... if (`nmake /? 2>&1` =~ /Version ([0-9]+\.[0-9]+)/ && $1 >= 11.0) { $app_cflag.=" /arch:IA32"; $lib_cflag.=" /arch:IA32"; } } Thanks, Scott Ware From bkaduk at akamai.com Fri Aug 26 16:33:52 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 26 Aug 2016 11:33:52 -0500 Subject: [openssl-dev] Fuzzer Patch(es) In-Reply-To: References: Message-ID: <50b33bd2-e534-70be-684c-0eea5bfe4cb4@akamai.com> On 08/25/2016 04:33 PM, Tom Ritter wrote: > NCC Group has prepared (or begun preparing) a patch that integrates > fuzzing of OpenSSL. Exciting stuff, most of which I will ignore for now and ask a targeted question. > - Because ossltest cooks MD5 to output a constant value, OpenSSL's RNG > becomes constant. Is it specifically MD5 and not SHA1? That would be worrisome, as I thought rand_lcl.h would be setting up for USE_SHA1_RAND by default, not md5. -Ben > This causes an error in ssl/ssl_sess.c:generate_session_id() because > it always generates a colliding Session ID. This breaks renegotiation > in the test harness. I haven't thought of an elegant way to resolve this. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at efca.com Fri Aug 26 16:56:52 2016 From: erik at efca.com (Erik Forsberg) Date: Fri, 26 Aug 2016 09:56:52 -0700 Subject: [openssl-dev] Lib names on Windows changed in OpenSSL 1.1.0 In-Reply-To: <20160826.091927.1041211560195411018.levitte@openssl.org> References: <7ff7678e-3c4c-6343-3a5b-b2aa0caf7ba5@yahoo.com> <20160826.091927.1041211560195411018.levitte@openssl.org> Message-ID: Considering all of the API changes in 1.1, I think changing to the new library names are actually very useful, no chance of accidentally using old DLLs >-- Original Message -- > >In message <7ff7678e-3c4c-6343-3a5b-b2aa0caf7ba5 at yahoo.com> on Fri, 26 Aug 2016 01:14:22 -0400, Ray Satiro said: > >raysatiro> I am part of a project that has several build systems, and two in >raysatiro> particular are not dynamically generated, a makefile and a number of >raysatiro> Visual Studio project files, all of which link to ssleay32.lib and >raysatiro> libeay32.lib for OpenSSL. I've noticed in 1.1.0 the names were changed >raysatiro> to libssl.lib and libcrypto.lib. We would like for our project files >raysatiro> to be compatible with OpenSSL 1.1.0 and earlier versions, so that >raysatiro> someone can just open a project file and it will link to whatever >raysatiro> version of OpenSSL they're using. I am wondering if anyone else has >raysatiro> brought this up (searching I couldn't find anything), whether you have >raysatiro> considered for compatibility copying the libs to the old names, or if >raysatiro> you have any ideas for me. The project is cURL, >raysatiro> https://github.com/curl/curl. Thanks > >I do recall discussing this quite a bit, back when the unified build >system was introduced, which was at the beginning of this year. I >cannot currently recall exactly where the discussions were taking >place. Some were on github, some were internal within the team. > >As for your project file, you're talking about the stuff in winbuild/, >right? I had a look here: https://github.com/curl/curl/tree/master/winbuild >So I'm wondering, couldn't you have something among the action lines >in https://github.com/curl/curl/blob/master/winbuild/Makefile.vc, >something like this? > > SET LIBCRYPTO_NAME=libcrypto > SET LIBSSL_NAME=libssl > IF EXIST libeay32.lib SET LIBCRYPTO_NAME=libeay32 > IF EXIST ssleay32.lib SET LIBSSL_NAME=ssleay32 > >And then make sure to use $(LIBCRYPTO_NAME) and $(LIBSSL_NAME) in >MakefileBuild.vc? > >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 wsware at gmail.com Fri Aug 26 18:31:57 2016 From: wsware at gmail.com (Scott Ware) Date: Fri, 26 Aug 2016 14:31:57 -0400 Subject: [openssl-dev] Building VC-WIN32 with VS2012 and above breaks older CPU compatability In-Reply-To: References: Message-ID: On Fri, Aug 26, 2016 at 12:01 PM, Scott Ware wrote: > When building with Visual Studio 2008 SSE is disabled by default. When > building with Visual Studio 2012 and above you must supply a new flag > /arch:IA32 to not build with SSE. Would it be acceptable to update the > Configure process to add the /arch:IA32 if Visual Studio 2012 or > greater is detected? This applies to the normal C code. We ran into > issues when running on an AMD Geode processor. > > I tested changing the VC-32.pl on OpenSSL 1.0.2g and it worked well, > but I see the whole build process has changed in Current. I wanted to > find out if this is an acceptable change before I figure out the new > Configure process and submit a patch. > Something like this will work diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf index 2838c3d..4b33156 100644 --- a/Configurations/10-main.conf +++ b/Configurations/10-main.conf @@ -23,18 +23,24 @@ sub vc_win64a_info { my $vc_win32_info = {}; sub vc_win32_info { unless (%$vc_win32_info) { + my $arch=""; + if (`nmake /? 2>&1` =~ /Version ([0-9]+\.[0-9]+)/ && $1 >= 11.0) { + $arch="/arch:IA32"; + } my $ver=`nasm -v 2>NUL`; my $vew=`nasmw -v 2>NUL`; if ($ver ne "" || $vew ne "") { $vc_win32_info = { as => $ver ge $vew ? "nasm" : "nasmw", asflags => "-f win32", asoutflag => "-o", - perlasm_scheme => "win32n" }; + perlasm_scheme => "win32n", + cflags => $arch }; } elsif ($disabled{asm}) { $vc_win32_info = { as => "ml", asflags => "/nologo /Cp /coff /c /Cx /Zi", asoutflag => "/Fo", - perlasm_scheme => "win32" }; + perlasm_scheme => "win32", + cflags => $arch }; } else { die "NASM not found - please read INSTALL and NOTES.WIN for further details\n"; } @@ -1335,6 +1341,9 @@ sub vms_info { as => sub { vc_win32_info()->{as} }, asflags => sub { vc_win32_info()->{asflags} }, asoutflag => sub { vc_win32_info()->{asoutflag} }, + lib_cflags => add( sub { vc_win32_info()->{cflags} } ), + dso_cflags => add( sub { vc_win32_info()->{cflags} } ), + bin_cflags => add( sub { vc_win32_info()->{cflags} } ), ex_libs => add(sub { my @ex_libs = (); # WIN32 UNICODE build gets linked with unicows.lib for From levitte at openssl.org Fri Aug 26 19:18:08 2016 From: levitte at openssl.org (Richard Levitte) Date: Fri, 26 Aug 2016 21:18:08 +0200 (CEST) Subject: [openssl-dev] Building VC-WIN32 with VS2012 and above breaks older CPU compatability In-Reply-To: References: Message-ID: <20160826.211808.621675499673002443.levitte@openssl.org> In message on Fri, 26 Aug 2016 14:31:57 -0400, Scott Ware said: wsware> On Fri, Aug 26, 2016 at 12:01 PM, Scott Ware wrote: wsware> > When building with Visual Studio 2008 SSE is disabled by default. When wsware> > building with Visual Studio 2012 and above you must supply a new flag wsware> > /arch:IA32 to not build with SSE. Would it be acceptable to update the wsware> > Configure process to add the /arch:IA32 if Visual Studio 2012 or wsware> > greater is detected? This applies to the normal C code. We ran into wsware> > issues when running on an AMD Geode processor. wsware> > wsware> > I tested changing the VC-32.pl on OpenSSL 1.0.2g and it worked well, wsware> > but I see the whole build process has changed in Current. I wanted to wsware> > find out if this is an acceptable change before I figure out the new wsware> > Configure process and submit a patch. wsware> > wsware> wsware> Something like this will work Having eyed it, it looks functional. A small comment, though: wsware> @@ -1335,6 +1341,9 @@ sub vms_info { wsware> as => sub { vc_win32_info()->{as} }, wsware> asflags => sub { vc_win32_info()->{asflags} }, wsware> asoutflag => sub { vc_win32_info()->{asoutflag} }, wsware> + lib_cflags => add( sub { vc_win32_info()->{cflags} } ), wsware> + dso_cflags => add( sub { vc_win32_info()->{cflags} } ), wsware> + bin_cflags => add( sub { vc_win32_info()->{cflags} } ), wsware> ex_libs => add(sub { wsware> my @ex_libs = (); wsware> # WIN32 UNICODE build gets linked with unicows.lib for lib_cflags, dso_cflags and bin_cflags are fields meant for each specific typ och final product and are combined with the cflags field. If you're gonna add the exact same value to all three, you might as well only having this: cflags => add(sub { vc_win32_info()->{cflags} } ), Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From appro at openssl.org Fri Aug 26 21:04:51 2016 From: appro at openssl.org (Andy Polyakov) Date: Fri, 26 Aug 2016 23:04:51 +0200 Subject: [openssl-dev] Building VC-WIN32 with VS2012 and above breaks older CPU compatability In-Reply-To: References: Message-ID: >> When building with Visual Studio 2008 SSE is disabled by default. When >> building with Visual Studio 2012 and above you must supply a new flag >> /arch:IA32 to not build with SSE. Would it be acceptable to update the >> Configure process to add the /arch:IA32 if Visual Studio 2012 or >> greater is detected? This applies to the normal C code. We ran into >> issues when running on an AMD Geode processor. >> >> I tested changing the VC-32.pl on OpenSSL 1.0.2g and it worked well, >> but I see the whole build process has changed in Current. I wanted to >> find out if this is an acceptable change before I figure out the new >> Configure process and submit a patch. >> > > Something like this will work > > diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf > index 2838c3d..4b33156 100644 > --- a/Configurations/10-main.conf > +++ b/Configurations/10-main.conf > @@ -23,18 +23,24 @@ sub vc_win64a_info { > my $vc_win32_info = {}; > sub vc_win32_info { > unless (%$vc_win32_info) { > + my $arch=""; > + if (`nmake /? 2>&1` =~ /Version ([0-9]+\.[0-9]+)/ && $1 >= 11.0) { If anything one should check for cl version, not nmake. > + $arch="/arch:IA32"; > + } So suggestion is to impose /arch:ia32 on all users. Well, I personally have lesser problem with that (as most most performance-critical assembly code paths will be compiled anyway, processor capabilities detected at run-time, and inappropriate paths will be avoided), but I'm not sure if all users would appreciate it. Note that it's possible to set CL environment variable to add options of your preference without modifying anything. Maybe that would be more adequate option to customize builds for specific needs. In worst case it would be appropriate to tie this option to no-sse2 configuration option, but not unconditionally... From uri at ll.mit.edu Fri Aug 26 21:11:26 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 26 Aug 2016 21:11:26 +0000 Subject: [openssl-dev] Building VC-WIN32 with VS2012 and above breaks older CPU compatability In-Reply-To: References: Message-ID: On 8/26/16, 17:04, "openssl-dev on behalf of Andy Polyakov" wrote: >So suggestion is to impose /arch:ia32 on all users. Well, I personally >have lesser problem with that (as most most performance-critical >assembly code paths will be compiled anyway, processor capabilities >detected at run-time, and inappropriate paths will be avoided), but I'm >not sure if all users would appreciate it. Normally I don?t use Windows, so shouldn?t care. However, as occasionally I do stumble across a Windows system - I?d *much* dislike being stuck with /arch:ia32. 20 years ago I might have had a different opinion. ;) > Note that it's possible to >set CL environment variable to add options of your preference without >modifying anything. And that?s probably what the requester should do, IMHO. >Maybe that would be more adequate option to >customize builds for specific needs. In worst case it would be >appropriate to tie this option to no-sse2 configuration option, but not >unconditionally... Maybe? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From wsware at gmail.com Fri Aug 26 21:27:41 2016 From: wsware at gmail.com (Scott Ware) Date: Fri, 26 Aug 2016 17:27:41 -0400 Subject: [openssl-dev] Building VC-WIN32 with VS2012 and above breaks older CPU compatability In-Reply-To: References: Message-ID: On Fri, Aug 26, 2016 at 5:11 PM, Blumenthal, Uri - 0553 - MITLL wrote: > On 8/26/16, 17:04, "openssl-dev on behalf of Andy Polyakov" > wrote: > >>So suggestion is to impose /arch:ia32 on all users. Well, I personally >>have lesser problem with that (as most most performance-critical >>assembly code paths will be compiled anyway, processor capabilities >>detected at run-time, and inappropriate paths will be avoided), but I'm >>not sure if all users would appreciate it. > > Normally I don?t use Windows, so shouldn?t care. However, as occasionally > I do stumble across a Windows system - I?d *much* dislike being stuck with > /arch:ia32. > > 20 years ago I might have had a different opinion. ;) > > >> Note that it's possible to >>set CL environment variable to add options of your preference without >>modifying anything. > > And that?s probably what the requester should do, IMHO. > >>Maybe that would be more adequate option to >>customize builds for specific needs. In worst case it would be >>appropriate to tie this option to no-sse2 configuration option, but not >>unconditionally... > > Maybe? > I certainly agree for most modern users it is not needed and may slow down the code since it is not using the latest and greatest. How about something like this.. A VC-WIN32-XP target that has everything needed to make a max compatibility target When building under VS2012 and above.. (I also tested in VS2015) adds CFLAGS /arch:IA32 -D_USING_V110_SDK71_ adds BIN_LDFLAGS=/subsystem:console,5.01 /opt:ref And before you scream OMG XP.. https://support.microsoft.com/en-us/gp/lifewinembed - Windows Embedded Standard 2009. This product is an updated release of the toolkit and componentized version of Windows XP. It was originally released in 2008; and Extended Support will end on January 8, 2019. - Windows Embedded POSReady 2009. This product for Point of Sale devices reflects the updates available in Windows Embedded Standard 2009. It was originally released on 2009, and extended support will end on April 9, 2019. People just don't want to upgrade these embedded machines, but we want to keep the communications between them as secure as possible with the latest and greatest OpenSSL. :P From uri at ll.mit.edu Fri Aug 26 21:34:45 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 26 Aug 2016 21:34:45 +0000 Subject: [openssl-dev] Building VC-WIN32 with VS2012 and above breaks older CPU compatability In-Reply-To: References: Message-ID: If you want to dedicate a target to /arch:ia32, I can?t object or complain. VC-WIN32-XP sounds like a good choice for that. -- Regards, Uri Blumenthal On 8/26/16, 17:27, "openssl-dev on behalf of Scott Ware" wrote: >On Fri, Aug 26, 2016 at 5:11 PM, Blumenthal, Uri - 0553 - MITLL > wrote: >> On 8/26/16, 17:04, "openssl-dev on behalf of Andy Polyakov" >> wrote: >> >>>So suggestion is to impose /arch:ia32 on all users. Well, I personally >>>have lesser problem with that (as most most performance-critical >>>assembly code paths will be compiled anyway, processor capabilities >>>detected at run-time, and inappropriate paths will be avoided), but I'm >>>not sure if all users would appreciate it. >> >> Normally I don?t use Windows, so shouldn?t care. However, as >>occasionally >> I do stumble across a Windows system - I?d *much* dislike being stuck >>with >> /arch:ia32. >> >> 20 years ago I might have had a different opinion. ;) >> >> >>> Note that it's possible to >>>set CL environment variable to add options of your preference without >>>modifying anything. >> >> And that?s probably what the requester should do, IMHO. >> >>>Maybe that would be more adequate option to >>>customize builds for specific needs. In worst case it would be >>>appropriate to tie this option to no-sse2 configuration option, but not >>>unconditionally... >> >> Maybe? >> > >I certainly agree for most modern users it is not needed and may slow >down the code since it is not using the latest and greatest. > >How about something like this.. A VC-WIN32-XP target that has >everything needed to make a max compatibility target >When building under VS2012 and above.. (I also tested in VS2015) >adds CFLAGS /arch:IA32 -D_USING_V110_SDK71_ >adds BIN_LDFLAGS=/subsystem:console,5.01 /opt:ref > >And before you scream OMG XP.. >https://support.microsoft.com/en-us/gp/lifewinembed >- Windows Embedded Standard 2009. This product is an updated release >of the toolkit and componentized version of Windows XP. It was >originally released in 2008; and Extended Support will end on January >8, 2019. >- Windows Embedded POSReady 2009. This product for Point of Sale >devices reflects the updates available in Windows Embedded Standard >2009. It was originally released on 2009, and extended support will >end on April 9, 2019. > >People just don't want to upgrade these embedded machines, but we want >to keep the communications between them as secure as possible with the >latest and greatest OpenSSL. :P >-- >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: 5211 bytes Desc: not available URL: From appro at openssl.org Fri Aug 26 21:43:15 2016 From: appro at openssl.org (Andy Polyakov) Date: Fri, 26 Aug 2016 23:43:15 +0200 Subject: [openssl-dev] Building VC-WIN32 with VS2012 and above breaks older CPU compatability In-Reply-To: References: Message-ID: <70bd6aa0-6997-a884-b5d5-3d4fa5599943@openssl.org> > How about something like this.. A VC-WIN32-XP target that has > everything needed to make a max compatibility target > When building under VS2012 and above.. (I also tested in VS2015) > adds CFLAGS /arch:IA32 -D_USING_V110_SDK71_ > adds BIN_LDFLAGS=/subsystem:console,5.01 /opt:ref How about set CL=/arch:ia32 set LINK=/subsysten:console,5.00 Why this is inappropriate? Have another compiler version? Just adjust appropriately. Microsoft changes something? Just adjust appropriately. You *are* in control. From wsware at gmail.com Fri Aug 26 22:24:43 2016 From: wsware at gmail.com (Scott Ware) Date: Fri, 26 Aug 2016 18:24:43 -0400 Subject: [openssl-dev] Building VC-WIN32 with VS2012 and above breaks older CPU compatability In-Reply-To: <70bd6aa0-6997-a884-b5d5-3d4fa5599943@openssl.org> References: <70bd6aa0-6997-a884-b5d5-3d4fa5599943@openssl.org> Message-ID: On Fri, Aug 26, 2016 at 5:43 PM, Andy Polyakov wrote: >> How about something like this.. A VC-WIN32-XP target that has >> everything needed to make a max compatibility target >> When building under VS2012 and above.. (I also tested in VS2015) >> adds CFLAGS /arch:IA32 -D_USING_V110_SDK71_ >> adds BIN_LDFLAGS=/subsystem:console,5.01 /opt:ref > > How about > > set CL=/arch:ia32 > set LINK=/subsysten:console,5.00 > > Why this is inappropriate? Have another compiler version? Just adjust > appropriately. Microsoft changes something? Just adjust appropriately. > You *are* in control. It's not inappropriate at all. I just wanted to help people that may want that compatibility and don't know what flags to use. It would not be an uncommon configuration right now, but it is becoming more uncommon every day. I'll submit a patch and if it is rejected so be it. I spent way more time then I wanted to figuring out why it would not run on the AMD Geode processor and then how to get it working in XP and wanted to make it easier for others. Thank you all for the feedback! -Scott Ware From rt at openssl.org Sat Aug 27 14:01:12 2016 From: rt at openssl.org (shuai.chang via RT) Date: Sat, 27 Aug 2016 14:01:12 +0000 Subject: [openssl-dev] [openssl.org #4660] error:89070063:lib(137):CAPI_RSA_SIGN:cant create hash object In-Reply-To: References: Message-ID: hello: i want to use libcurl with openssl, and i build openssl use this cmd: "perl configure VC-WIN32 no-asm -DOPENSSL_SSL_CLIENT_ENGINE_AUTO=capi -DOPENSSL_CAPIENG_DIALO" when i use curl get url,eg "curl -k https://*.com",return the error: error:89070063:lib(137):CAPI_RSA_SIGN:cant create hash object tks. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4660 Please log in as guest with password guest if prompted From rt at openssl.org Sat Aug 27 14:01:13 2016 From: rt at openssl.org (Ray Satiro via RT) Date: Sat, 27 Aug 2016 14:01:13 +0000 Subject: [openssl-dev] [openssl.org #4661] OpenSSL 1.1.0 ssltest_old assertion failure in Windows requires interaction In-Reply-To: References: Message-ID: I recently built OpenSSL 1.1.0 x64 debug using Visual Studio 2010, like this: perl Configure debug-VC-WIN64A no-asm nmake Then I ran the tests nmake test At test\recipes\80-test_ssl_old.t a message box popped up with an assertion failure, I debugged it and saved the information. However when the tests completed it said 'All tests successful', so I'm not sure what's happened here. Maybe you expect that test to fail with an assertion? If that is the case I don't think you want interaction with a message box pop up, perhaps you want something like SetErrorMode(SEM_FAILCRITICALERRORS|SEM_NOGPFAULTERRORBOX|SEM_NOOPENFILEERRORBOX); Here is the information from the test. I got this information by recording the process command line, and running the process a second time and debugging it. > libssl-1_1-x64.dll!ssl_free_wbio_buffer(ssl_st * s) Line 3327 + 0x26 bytes C libssl-1_1-x64.dll!SSL_free(ssl_st * s) Line 981 C ssltest_old.exe!main(int argc, char * * argv) Line 1920 C ssltest_old.exe!__tmainCRTStartup() Line 555 + 0x19 bytes C ssltest_old.exe!mainCRTStartup() Line 371 C kernel32.dll!BaseThreadInitThunk() + 0xd bytes ntdll.dll!RtlUserThreadStart() + 0x21 bytes ssltest_old.exe -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert certU.ss -s_cipher EDH -c_cipher EDH:@SECLEVEL=1 -dhe512 8132:error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too small:ssl\s3_lib.c:3265: 8132:error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too small:ssl\s3_lib.c:3265: 8132:error:02001003:system library:fopen:No such process:crypto\bio\bss_file.c:74:fopen('C:\Program Files\Common Files\SSL/ct_log_list.cnf','rb') 8132:error:2006D080:BIO routines:BIO_new_file:no such file:crypto\bio\bss_file.c:77: 8132:error:0E078072:configuration file routines:def_load:no such file:crypto\conf\conf_def.c:144: 8132:error:3207B06D:CT routines:CTLOG_STORE_load_file:log conf invalid:crypto\ct\ct_log.c:207: Doing handshakes=1 bytes=256 ERROR in SERVER 8132:error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:ssl\statem\statem_srvr.c:1422: TLSv1.2, cipher (NONE) (NONE) Assertion failed: s->wbio != NULL, file ssl\ssl_lib.c, line 3327 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4661 Please log in as guest with password guest if prompted From rt at openssl.org Sat Aug 27 14:02:19 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Sat, 27 Aug 2016 14:02:19 +0000 Subject: [openssl-dev] [openssl.org #4662] overflow check missing on BIO_new_file In-Reply-To: <8cfab1178bbf4f279964c88fec764c05@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8cfab1178bbf4f279964c88fec764c05@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: From: Sunil Singh [mailto:ekodeveloper0 at gmail.com] Sent: Saturday, August 27, 2016 2:42 AM To: Salz, Rich; openssl-security at openssl.org Subject: Re: [openssl-security] Multiple issue with BIO_new_file Internal function (potential stack overflow/Crash) I don't think its right to say that its not a security bug, if somebody pass a huge filename string which results is _alloca failure obviously its leads to stack overflow on the same grounds i can lightly compare it to malloc and not checking its return value? Input to function can come from any place why do you think its should not be validated? Also if i agrees with you i can say simply strlen(...) is also valid then but its depreciated by MSFT and other strlen_l(...) is provided which accept size For you convenience check this http://linux.die.net/man/3/alloca http://stackoverflow.com/questions/1018853/why-is-the-use-of-alloca-not-considered-good-practice Also previously i provided already MSFT link which clearly mentions about its usage Thanks On Fri, Aug 26, 2016 at 10:44 PM, Salz, Rich > wrote: This is not a security bug; an application program could mis-use the API. Thanks for looking at the code! -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From: Sunil Singh [mailto:ekodeveloper0 at gmail.com] Sent: Friday, August 26, 2016 1:09 PM To: openssl-security at openssl.org Subject: [openssl-security] Multiple issue with BIO_new_file Internal function (potential stack overflow/Crash) Hello, While working on the program of https://hackerone.com/ibb-openssl this was found Report Below:- Function Design issue 1. in BIO_new_file no check of filename param 2. in internal function call static FILE *file_fopen(const char *filename, const char *mode) again no check of filename param 3. At WCHAR *wfilename = _alloca(sz * sizeof(WCHAR)) Refer to https://msdn.microsoft.com/en-us/library/wb1s57t5.aspx for proper use of _alloca it must be guarded can cause stack overflow in case stack memory not fulfilled and again no return value(wfilename ) is checked Thanks, Sunil Singh -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4662 Please log in as guest with password guest if prompted From appro at openssl.org Sat Aug 27 19:31:02 2016 From: appro at openssl.org (Andy Polyakov) Date: Sat, 27 Aug 2016 21:31:02 +0200 Subject: [openssl-dev] Building VC-WIN32 with VS2012 and above breaks older CPU compatability In-Reply-To: References: <70bd6aa0-6997-a884-b5d5-3d4fa5599943@openssl.org> Message-ID: <8b8918da-cf64-2123-8dc8-54a6ffea724e@openssl.org> >>> How about something like this.. A VC-WIN32-XP target that has >>> everything needed to make a max compatibility target >>> When building under VS2012 and above.. (I also tested in VS2015) >>> adds CFLAGS /arch:IA32 -D_USING_V110_SDK71_ >>> adds BIN_LDFLAGS=/subsystem:console,5.01 /opt:ref >> >> How about >> >> set CL=/arch:ia32 >> set LINK=/subsysten:console,5.00 >> >> Why this is inappropriate? Have another compiler version? Just adjust >> appropriately. Microsoft changes something? Just adjust appropriately. >> You *are* in control. > > It's not inappropriate at all. I just wanted to help people that may > want that compatibility and don't know what flags to use. Here is dilemma. To help people you have to convey the information. In *either* case, right? But which words to choose? Ones telling how to take control over situation in arbitrary case, or suggest version-specifc config they might have to adjust anyway? At any occasion I also want to point out/remind that contributes configs are meant to go separate files in Configurations catalog. From tom at ritter.vg Sat Aug 27 21:59:48 2016 From: tom at ritter.vg (Tom Ritter) Date: Sat, 27 Aug 2016 16:59:48 -0500 Subject: [openssl-dev] Fuzzer Patch(es) In-Reply-To: <50b33bd2-e534-70be-684c-0eea5bfe4cb4@akamai.com> References: <50b33bd2-e534-70be-684c-0eea5bfe4cb4@akamai.com> Message-ID: On 26 August 2016 at 11:33, Benjamin Kaduk wrote: > - Because ossltest cooks MD5 to output a constant value, OpenSSL's RNG > becomes constant. > > > Is it specifically MD5 and not SHA1? That would be worrisome, as I > thought rand_lcl.h would be setting up for USE_SHA1_RAND by default, not > md5. > No, that was an offhand comment - it produces a constant output for most hash functions: MD5, SHA-1, SHA256, 384, and 512. -tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From asmarner at yahoo.com Sun Aug 28 14:54:09 2016 From: asmarner at yahoo.com (asmarner at yahoo.com) Date: Sun, 28 Aug 2016 14:54:09 +0000 (UTC) Subject: [openssl-dev] Certificate chain issue. References: <1795475824.1129747.1472396049615.ref@mail.yahoo.com> Message-ID: <1795475824.1129747.1472396049615@mail.yahoo.com> I am using SSL_CTX_use_certificate_chain_file() to load the certificate chain. Due to some issue, my certificate chain file has the following (please look at the stray character "?") -----BEGIN CERTIFICATE----- Base-64 data of server -----END CERTIFICATE----- ?-----BEGIN CERTIFICATE----- Base-64 data of Int CA -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- Base-64 data of Root CA -----END CERTIFICATE----- ? I see that the certificate immediately following the "?" is getting not delivered during handshake; in this case certificate of Intermediate CA. Was going through?https://www.irt.org/rfc/rfc7468.htm ############################################################### Textual encoding begins with a line comprising "-----BEGIN ", a label, and "-----", and ends with a line comprising "-----END ", a label, and "-----". Between these lines, or "encapsulation boundaries", are base64-encoded data according to Section 4 of [RFC4648]. (PEM [RFC1421] referred to this data as the "encapsulated Josefsson & Leonard Standards Track [Page 3] RFC 7468 PKIX Textual Encodings April 2015 text portion".) Data before the encapsulation boundaries are permitted, and parsers MUST NOT malfunction when processing such data.########################################################################Could someone please comment on this one? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sun Aug 28 15:07:55 2016 From: rt at openssl.org (ndof@gmx.li via RT) Date: Sun, 28 Aug 2016 15:07:55 +0000 Subject: [openssl-dev] [openssl.org #4663] #4536 Android arm-v8/arm64/aarch64 Support In-Reply-To: <47247633-dcf4-286e-c4d5-f7daa7f36fcd@gmx.li> References: <47247633-dcf4-286e-c4d5-f7daa7f36fcd@gmx.li> Message-ID: After some test, I found out, that with 1.1.0 it will be able to build. But the way on the wiki don't work. The only way I found was this: NDK=/PathToNDK TargetDir=/opt/openssl-android API=24 ARCH=arch-arm64 TARGET=aarch64-linux-android BUILD_OS=linux-x86_64 TOOLCHAIN_BIN=${NDK}/toolchains/${TARGET}-4.9/prebuilt/${BUILD_OS}/bin export SYSROOT=${NDK}/platforms/android-${API}/${ARCH} export CROSS_SYSROOT=${SYSROOT} export CC=${TOOLCHAIN_BIN}/${TARGET}-gcc export AR=${TOOLCHAIN_BIN}/${TARGET}-ar export RANLIB=${TOOLCHAIN_BIN}/${TARGET}-ranlib ./Configure shared android64-aarch64 --prefix=$TargetDir make depend make -j4 make install_sw rm -rf $TargetDir/bin rm -rf $TargetDir/ssl find $TargetDir/ -type f -executable -print0 | xargs -0 chmod +w find $TargetDir/ -type f -executable -print0 | xargs -0 ${TOOLCHAIN_BIN}/${TARGET}-strip --strip-all using OpenSSL 1.1.0 and NDK r12b -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4663 Please log in as guest with password guest if prompted From rsalz at akamai.com Sun Aug 28 15:10:55 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 28 Aug 2016 15:10:55 +0000 Subject: [openssl-dev] Certificate chain issue. In-Reply-To: <1795475824.1129747.1472396049615@mail.yahoo.com> References: <1795475824.1129747.1472396049615.ref@mail.yahoo.com> <1795475824.1129747.1472396049615@mail.yahoo.com> Message-ID: <80a66a9d36884fea91575a18f15840b0@usma1ex-dag1mb1.msg.corp.akamai.com> When the RFC says ?a line comprising? it means ONLY having that text. Otherwise it would have said ?a line including.? The file is mis-formatted. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sun Aug 28 16:33:33 2016 From: rt at openssl.org (Mike Gilbert via RT) Date: Sun, 28 Aug 2016 16:33:33 +0000 Subject: [openssl-dev] [openssl.org #4664] Enhancement: better handling of CFLAGS and LDFLAGS In-Reply-To: References: Message-ID: With the current build system, user-defined CFLAGS are accepted as any unrecognized command line argument passed to Configure. This seems a little dangerous to me since it means a simple typo could end up getting passed to the C compiler. As well, the current build system forcibly enables optimization (-O3) or debug symbols (-g) depending on the build type (--release or --debug). There does not appear to be any method for the user to pass additional LDFLAGS to the build system. I would like to propose the following changes: 1. Read CFLAGS and LDFLAGS from the environment within the Configure script. 2. Allow the user to opt-out of the default release or debug cflags, perhaps by adding a third build type (neither release nor debug). These changes would my job as a distro maintainer on Gentoo Linux just a little bit easier. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4664 Please log in as guest with password guest if prompted From asmarner at yahoo.com Sun Aug 28 18:01:11 2016 From: asmarner at yahoo.com (asmarner at yahoo.com) Date: Sun, 28 Aug 2016 18:01:11 +0000 (UTC) Subject: [openssl-dev] Certificate chain issue. In-Reply-To: <80a66a9d36884fea91575a18f15840b0@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1795475824.1129747.1472396049615.ref@mail.yahoo.com> <1795475824.1129747.1472396049615@mail.yahoo.com> <80a66a9d36884fea91575a18f15840b0@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <967175540.1194446.1472407271491@mail.yahoo.com> I was referring to "Data before the encapsulation boundaries are permitted, and parsers MUST NOT malfunction when processing such data." Wondering whether we could consider "?" as the data. On Sunday, August 28, 2016 8:40 PM, "Salz, Rich" wrote: #yiv4319403386 #yiv4319403386 -- _filtered #yiv4319403386 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv4319403386 {font-family:Consolas;panose-1:2 11 6 9 2 2 4 3 2 4;}#yiv4319403386 #yiv4319403386 p.yiv4319403386MsoNormal, #yiv4319403386 li.yiv4319403386MsoNormal, #yiv4319403386 div.yiv4319403386MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv4319403386 a:link, #yiv4319403386 span.yiv4319403386MsoHyperlink {color:blue;text-decoration:underline;}#yiv4319403386 a:visited, #yiv4319403386 span.yiv4319403386MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv4319403386 pre {margin:0in;margin-bottom:.0001pt;font-size:10.0pt;}#yiv4319403386 span.yiv4319403386HTMLPreformattedChar {font-family:Consolas;}#yiv4319403386 span.yiv4319403386EmailStyle19 {color:#1F497D;}#yiv4319403386 .yiv4319403386MsoChpDefault {font-size:10.0pt;} _filtered #yiv4319403386 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv4319403386 div.yiv4319403386WordSection1 {}#yiv4319403386 When the RFC says ?a line comprising? it means ONLY having that text.? Otherwise it would have said ?a line including.? ? The file is mis-formatted. ? --? Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sun Aug 28 18:58:02 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 28 Aug 2016 18:58:02 +0000 Subject: [openssl-dev] Certificate chain issue. In-Reply-To: <967175540.1194446.1472407271491@mail.yahoo.com> References: <1795475824.1129747.1472396049615.ref@mail.yahoo.com> <1795475824.1129747.1472396049615@mail.yahoo.com> <80a66a9d36884fea91575a18f15840b0@usma1ex-dag1mb1.msg.corp.akamai.com> <967175540.1194446.1472407271491@mail.yahoo.com> Message-ID: > Wondering whether we could consider "?" as the data. No, it is part of the prolog line, and since such a line must be made of the parts defined (and only those parts), the file is malformed. The RFC does not allow arbitrary data after the newline and before the prolog, nor after the epilog and before the next newline. ? --? Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From dwmw2 at infradead.org Sun Aug 28 21:18:53 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 28 Aug 2016 22:18:53 +0100 Subject: [openssl-dev] [PATCH] Support broken PKCS#12 key generation. Message-ID: <1472419133.3390.23.camel@infradead.org> On Wed, 2016-08-24 at 18:55 +0100, Dr. Stephen Henson wrote: > commit?647ac8d3d7143e3721d55e1f57730b6f26e72fc9 > > OpenSSL versions before 1.1.0 didn't convert non-ASCII > UTF8 PKCS#12 passwords to Unicode correctly. > > To correctly decrypt older files, if MAC verification fails > with the supplied password attempt to use the broken format > which is compatible with earlier versions of OpenSSL. > > Reviewed-by: Richard Levitte Hm, this sounds like something that other crypto libraries also ought to try to work around.? Please could you elaborate on the specific problem, and/or show a test case? I'm not quite sure how to interpret the patch itself. You pass the password through OPENSSL_asc2uni() and then OPENSSL_uni2utf8() ? which is essentially converting ISO8859-1 to UTF-8. So, if my password is "na?ve". In UTF-8 that's?6e 61 c3 af 76 65, which is the correct sequence of bytes to use for the password? And you now convert that sequence of bytes to 6e 61 c3 83 c2 af 76 65 by assuming it's ISO8859-1 (which would be 'na??ve') and converting to UTF-8? So... what was the bug that was actually being worked around? That older versions were converting from the local charset to UTF-8 twice in a row? So you've implemented a "convert ISO8859-1 to UTF-8" fallback which will cope with that in *some* locales but not all...? I don't really understand. Thanks for any light you can shed on it! /me goes off to add non-ASCII passwords to the growing torture test suite at http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From rt at openssl.org Mon Aug 29 07:36:49 2016 From: rt at openssl.org (Tomas Mraz via RT) Date: Mon, 29 Aug 2016 07:36:49 +0000 Subject: [openssl-dev] [openssl.org #4664] Enhancement: better handling of CFLAGS and LDFLAGS In-Reply-To: <1472456192.15146.2.camel@redhat.com> References: <1472456192.15146.2.camel@redhat.com> Message-ID: I would like to join this request as maintainer of OpenSSL for Fedora and Red Hat Enterprise Linux. It would clean up things for us as well. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4664 Please log in as guest with password guest if prompted From rt at openssl.org Mon Aug 29 12:27:59 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 29 Aug 2016 12:27:59 +0000 Subject: [openssl-dev] [openssl.org #4664] Enhancement: better handling of CFLAGS and LDFLAGS In-Reply-To: References: Message-ID: > With the current build system, user-defined CFLAGS are accepted as any > unrecognized command line argument passed to Configure. This seems a > little dangerous to me since it means a simple typo could end up > getting passed to the C compiler. Is it more dangerous than interactive access? But on serious note I don't quite grasp the problem. How do you pass CFLAGS? Or rather how is it specific to OpenSSL? I mean you either set CFLAGS environment variable and call 'make -e' or call 'make CFLAGS=something', right? But this is the way *make* is. Or is suggestion that we should implement own internal .ext1.ext2 rules independent on CFLAGS? > As well, the current build system forcibly enables optimization (-O3) > or debug symbols (-g) depending on the build type (--release or > --debug). Could you elaborate on the problem? If you need release build with debug symbols you can simply add -g when configuring... > There does not appear to be any method for the user to pass additional > LDFLAGS to the build system. You can pass them as arguments to ./Configure script. It recognizes -L, -l and -Wl,. > I would like to propose the following changes: > > 1. Read CFLAGS and LDFLAGS from the environment within the Configure script. > 2. Allow the user to opt-out of the default release or debug cflags, > perhaps by adding a third build type (neither release nor debug). > > These changes would my job as a distro maintainer on Gentoo Linux just > a little bit easier. Or maybe ("maybe" is reference to "I don't quite grasp" above) what we are talking about is Configure reading CFLAGS and LDFLAGS and *adding* them to generated Makefile. I mean we are not talking about passing them to 'make', but "freezing" them to their values at configure time. Could you clarify? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4664 Please log in as guest with password guest if prompted From appro at openssl.org Mon Aug 29 13:25:23 2016 From: appro at openssl.org (Andy Polyakov) Date: Mon, 29 Aug 2016 15:25:23 +0200 Subject: [openssl-dev] [PATCH] Support broken PKCS#12 key generation. In-Reply-To: <1472419133.3390.23.camel@infradead.org> References: <1472419133.3390.23.camel@infradead.org> Message-ID: First of all. *Everything* that is said below (and what modifications in question are about) applies to non-ASCII passwords. ASCII-only passwords are not affected by this and keep working as they were. >> commit 647ac8d3d7143e3721d55e1f57730b6f26e72fc9 >> >> OpenSSL versions before 1.1.0 didn't convert non-ASCII >> UTF8 PKCS#12 passwords to Unicode correctly. >> >> To correctly decrypt older files, if MAC verification fails >> with the supplied password attempt to use the broken format >> which is compatible with earlier versions of OpenSSL. >> >> Reviewed-by: Richard Levitte > > Hm, this sounds like something that other crypto libraries also ought > to try to work around. > > Please could you elaborate on the specific problem, and/or show a test > case? Note that there is 80-test_pkcs12.t that refers to shibboleth.pfx. > I'm not quite sure how to interpret the patch itself. You pass the > password through OPENSSL_asc2uni() and then OPENSSL_uni2utf8() ? which > is essentially converting ISO8859-1 to UTF-8. You make it sound like these two are called one after another. But that's not what happens. It *tries* to access data with passwords converted with OPENSSL_asc2uni *or* OPENSSL_utf82uni, effectively independently of each other, in order to see which one is right. So that you can *transparently* access old broken data, as well as specification-compliant one. > So, if my password is "na?ve". In UTF-8 that's 6e 61 c3 af 76 65, which > is the correct sequence of bytes to use for the password? 00 6e 00 61 00 ef 00 76 00 65, big-endian UTF-16. > And you now convert that sequence of bytes to 6e 61 c3 83 c2 af 76 65 > by assuming it's ISO8859-1 (which would be 'na??ve') and converting to UTF-8? I don't follow. Why would it have to be converted to this sequence? > So... what was the bug that was actually being worked around? 6e 61 c3 af 76 65 was expanded to 00 6e 00 61 00 c3 00 af 00 76 00 65, in violation of specification. > That > older versions were converting from the local charset to UTF-8 twice in > a row? So you've implemented a "convert ISO8859-1 to UTF-8" fallback > which will cope with that in *some* locales but not all...? Yeah, something like that. Note that if you have created PKCS#12 file with a non-UTF8 locale, it's not given that you can read it with another locale, UTF-8 or not. This was *always* the case. And that's *not* what we try to address here. We assume that you don't change locale when you upgrade OpenSSL version. Ultimate goal is to make it compliant with specification and therefore interoperable with other compliant implementations. But we can't just switch, because then it stops interoperate with older OpenSSL versions. This is the reason for why it looks messy. It's about having it both ways... Though there is one ambiguity in this. Said interoperability assumes UTF-8 locale (on *ix, or OPENSSL_WIN32_UTF8 opt-in environment variable on Windows). I.e. it's not given that users that use non-UTF8 locale can actually interoperate with other implementations. It's assumed that such users are not actually interested to, and if they express interest, they will be advised to switch to UTF-8 locale and convert their data to interoperable format. Is this helpful? From rt at openssl.org Mon Aug 29 14:27:18 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 29 Aug 2016 14:27:18 +0000 Subject: [openssl-dev] [openssl.org #4664] Enhancement: better handling of CFLAGS and LDFLAGS In-Reply-To: References: Message-ID: On Mon Aug 29 12:27:59 2016, appro wrote: > > With the current build system, user-defined CFLAGS are accepted as > > any > > unrecognized command line argument passed to Configure. This seems a > > little dangerous to me since it means a simple typo could end up > > getting passed to the C compiler. > > Is it more dangerous than interactive access? But on serious note I > don't quite grasp the problem. How do you pass CFLAGS? Or rather how > is > it specific to OpenSSL? I mean you either set CFLAGS environment > variable and call 'make -e' or call 'make CFLAGS=something', right? > But > this is the way *make* is. Or is suggestion that we should implement > own > internal .ext1.ext2 rules independent on CFLAGS? > > > As well, the current build system forcibly enables optimization (-O3) > > or debug symbols (-g) depending on the build type (--release or > > --debug). > > Could you elaborate on the problem? If you need release build with > debug > symbols you can simply add -g when configuring... > > > There does not appear to be any method for the user to pass > > additional > > LDFLAGS to the build system. > > You can pass them as arguments to ./Configure script. It recognizes > -L, > -l and -Wl,. > > > I would like to propose the following changes: > > > > 1. Read CFLAGS and LDFLAGS from the environment within the Configure > > script. > > 2. Allow the user to opt-out of the default release or debug cflags, > > perhaps by adding a third build type (neither release nor debug). > > > > These changes would my job as a distro maintainer on Gentoo Linux > > just > > a little bit easier. > > Or maybe ("maybe" is reference to "I don't quite grasp" above) what we > are talking about is Configure reading CFLAGS and LDFLAGS and *adding* > them to generated Makefile. I mean we are not talking about passing > them > to 'make', but "freezing" them to their values at configure time. > Could > you clarify? I assume, and please correct me if I'm wrong, that the request is to treat the environment variables CFLAGS and LDFLAGS the same way we treat CC, i.e. as an initial value to be used instead of what we get from the configuration target information. This should be quite easy to implement, and we can also continue to use whatever additional Configure arguments as compiler or linker flags to be used *in addition* to the initial value (that comes from the config target information, or if we decide to implement it, CFLAGS) Cheers, Richard -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4664 Please log in as guest with password guest if prompted From rt at openssl.org Mon Aug 29 16:00:21 2016 From: rt at openssl.org (Tomas Mraz via RT) Date: Mon, 29 Aug 2016 16:00:21 +0000 Subject: [openssl-dev] [openssl.org #4664] Enhancement: better handling of CFLAGS and LDFLAGS In-Reply-To: <1472486410.15146.12.camel@redhat.com> References: <1472486410.15146.12.camel@redhat.com> Message-ID: On Po, 2016-08-29 at 14:27 +0000, Richard Levitte via RT wrote: > On Mon Aug 29 12:27:59 2016, appro wrote: > >? > > Or maybe ("maybe" is reference to "I don't quite grasp" above) what > > we > > are talking about is Configure reading CFLAGS and LDFLAGS and > > *adding* > > them to generated Makefile. I mean we are not talking about passing > > them > > to 'make', but "freezing" them to their values at configure time. > > Could > > you clarify? > I assume, and please correct me if I'm wrong, that the request is to > treat the > environment variables CFLAGS and LDFLAGS the same way we treat CC, > i.e. as an > initial value to be used instead of what we get from the > configuration target > information. > > This should be quite easy to implement, and we can also continue to > use > whatever additional Configure arguments as compiler or linker flags > to be used > *in addition* to the initial value (that comes from the config target > information, or if we decide to implement it, CFLAGS) Ideally the optimization/debugging flags not affecting directly the code that is being compiled would be replaced with what is placed into CFLAGS/LDFLAGS. But things like -D would be kept from the config target information. --? 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.) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4664 Please log in as guest with password guest if prompted From dwmw2 at infradead.org Mon Aug 29 17:40:59 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 29 Aug 2016 18:40:59 +0100 Subject: [openssl-dev] [PATCH] Support broken PKCS#12 key generation. In-Reply-To: References: <1472419133.3390.23.camel@infradead.org> Message-ID: <1472492459.61594.685.camel@infradead.org> On Mon, 2016-08-29 at 15:25 +0200, Andy Polyakov wrote: > First of all. *Everything* that is said below (and what modifications in > question are about) applies to non-ASCII passwords. ASCII-only passwords > are not affected by this and keep working as they were. > > > > > > > > > commit 647ac8d3d7143e3721d55e1f57730b6f26e72fc9 > > > > > > OpenSSL versions before 1.1.0 didn't convert non-ASCII > > > UTF8 PKCS#12 passwords to Unicode correctly. > > > > > > To correctly decrypt older files, if MAC verification fails > > > with the supplied password attempt to use the broken format > > > which is compatible with earlier versions of OpenSSL. > > > > > > Reviewed-by: Richard Levitte > > > > Hm, this sounds like something that other crypto libraries also ought > > to try to work around. > > > > Please could you elaborate on the specific problem, and/or show a test > > case? > > Note that there is 80-test_pkcs12.t that refers to shibboleth.pfx. Thanks. > > I'm not quite sure how to interpret the patch itself. You pass the > > password through OPENSSL_asc2uni() and then OPENSSL_uni2utf8() ? which > > is essentially converting ISO8859-1 to UTF-8. > > You make it sound like these two are called one after another. But > that's not what happens. It *tries* to access data with passwords > converted with OPENSSL_asc2uni *or* OPENSSL_utf82uni, effectively > independently of each other, in order to see which one is right. So that > you can *transparently* access old broken data, as well as > specification-compliant one. Hm... at line 541 of pkcs12.c we call PKCS12_verify_mac(?mpass?) with the original provided password. Which is in the locale-native character set, is it not? No attempt to convert to anything known. Then if that *fails* we do indeed convert it via OPENSSL_asc2uni() and OPENSSL_uni2utf8() to make 'badpass' and try again: } else if (!PKCS12_verify_mac(p12, mpass, -1)) { /* * May be UTF8 from previous version of OpenSSL: * convert to a UTF8 form which will translate * to the same Unicode password. */ unsigned char *utmp; int utmplen; utmp = OPENSSL_asc2uni(mpass, -1, NULL, &utmplen); if (utmp == NULL) goto end; badpass = OPENSSL_uni2utf8(utmp, utmplen); OPENSSL_free(utmp); if (!PKCS12_verify_mac(p12, badpass, -1)) { BIO_printf(bio_err, "Mac verify error: invalid password?\n"); ERR_print_errors(bio_err); goto end; } else { BIO_printf(bio_err, "Warning: using broken algorithm\n"); if (!twopass) cpass = badpass; } The shibboleth.pfx test seems to pass on the *first* call to PKCS12_verify_mac() ? it *isn't* testing this fallback. If I add a space to the end of the correct password and stick a breakpoint on PKCS12_verify_mac(), I see the following calls: #0??PKCS12_verify_mac (p12=0x956e40,? ????pass=0x956a30 "??????? ???????? ", passlen=-1) ????at crypto/pkcs12/p12_mutl.c:152 #1??0x0000000000425567 in pkcs12_main (argc=0, argv=0x7fffffffdd90) ????at apps/pkcs12.c:541 And then it converts that string from ISO8859-1 (which it wasn't) to UTF-8, and calls PKCS12_verify_mac() again: #0??PKCS12_verify_mac (p12=0x956e40,? ????pass=0x9597e0 "?\302\203?\302\215?????????? ?????\302\216?\302\201???\302\203???? ", passlen=-1) at crypto/pkcs12/p12_mutl.c:152 #1??0x00000000004255fc in pkcs12_main (argc=0, argv=0x7fffffffdd90) ????at apps/pkcs12.c:554 > > > > So, if my password is "na?ve". In UTF-8 that's 6e 61 c3 af 76 65, which > > is the correct sequence of bytes to use for the password? > > 00 6e 00 61 00 ef 00 76 00 65, big-endian UTF-16. Is that conversion done inside PKCS12_verify_mac()? Because we definitely aren't passing UTF-16-BE into PKCS12_verify_mac(). > > > > And you now convert that sequence of bytes to 6e 61 c3 83 c2 af 76 65 > > by assuming it's ISO8859-1 (which would be 'na??ve') and converting to UTF-8? > > I don't follow. Why would it have to be converted to this sequence? That's what it's doing. Changing the example above and showing the same breakpoints as they get hit again... Starting program: /home/dwmw2/git/openssl/apps/openssl pkcs12 -noout -password pass:na?ve -in test/shibboleth.pfx [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, PKCS12_verify_mac (p12=0x956e30, pass=0x956a30 "na?ve", passlen=-1) at crypto/pkcs12/p12_mutl.c:152 152 if (p12->mac == NULL) { (gdb) x/7bx pass 0x956a30: 0x6e 0x61 0xc3 0xaf 0x76 0x65 0x00 (gdb) c Continuing. Breakpoint 1, PKCS12_verify_mac (p12=0x956e30, pass=0x959960 "na??ve", passlen=-1) at crypto/pkcs12/p12_mutl.c:152 152 if (p12->mac == NULL) { (gdb) x/8bx pass 0x959960: 0x6e 0x61 0xc3 0x83 0xc2 0xaf 0x76 0x65 > > > > So... what was the bug that was actually being worked around? > > 6e 61 c3 af 76 65 was expanded to 00 6e 00 61 00 c3 00 af 00 76 00 65, > in violation of specification. OK, that makes sense, because PKCS12_verify_mac() is going to convert that last byte sequence I showed above into?UTF16-BE making it: ? 006e 0061 00c3 00af 0076 0065 > > > > That > > older versions were converting from the local charset to UTF-8 twice in > > a row? So you've implemented a "convert ISO8859-1 to UTF-8" fallback > > which will cope with that in *some* locales but not all...? > > Yeah, something like that. Note that if you have created PKCS#12 file > with a non-UTF8 locale, it's not given that you can read it with another > locale, UTF-8 or not. This was *always* the case. And that's *not* what > we try to address here. We assume that you don't change locale when you > upgrade OpenSSL version. Ultimate goal is to make it compliant with > specification and therefore interoperable with other compliant > implementations. But we can't just switch, because then it stops > interoperate with older OpenSSL versions. Hm, words fail me. Well, that's not entirely true. But *polite* words fail me... Let me try to understand this... you have always ignored, and still ignore, the actual LC_CTYPE which tells you the character set in which the password was provided from the user. You *used* to convert it through your horribly misnamed OPENSSL_asc2uni() function, which actually converts ISO8859-1 to UTF16BE by simply expanding it and inserting 0x00 between each byte of the original. So effectively you were "assuming" the input was ISO8859-1. Now you assume it's UTF-8, and convert it with OPENSSL_utf8touni(). (And now what happens when the locale input *isn't* valid UTF-8, because it's a legacy 8-bit charset? That conversion should fail, right?) Your latest workaround (from which I started this thread) is addressing the first problem *purely* for the case of the UTF-8 locale. It checks for the "we treated UTF-8 as if it were ISO8859-1" case, which is what leads to the 006e 0061 00c3 00af 0076 0065 example you gave above. But you *haven't* actually implemented any workaround for the other whole set of "we treated locale XXXXX as if it were ISO8859-1" bugs that your original code had. Or the whole set of "we treated local XXXXX as if it were UTF-8" bugs that the new code has. So for other applications to try to read OpenSSL's PKCs#12 files, what we need to do is first convert the sane Unicode rendition of the password into the native locale charset (e.g. Windows-1252), then take that bytestream and *pretend* it's ISO8859-1, and convert to UTF-16BE to check the MAC. Then if that fails, take the same Windows-1252 bytestream and *pretend* it's UTF-8, and convert *that* to UTF-16BE to see if it works. So... let's have a password 'na?ve', in a ISO8859-2 environment where that is represented by the bytes 6e 61 b3 76 65. First I should try the correct version according to the spec: ?006e 0061 0142 0076 0065 Then we try the "OpenSSL assumed it was ISO8859-1" version: ?006e 0061 00b3 0076 0065 And finally we try the "OpenSSL assumed it was UTF-8" version: ?006e 0061 ... actually you *can't* convert that byte sequence "from" UTF-8 since it isn't valid UTF-8. So what will new OpenSSL do here, again? > Is this helpful? On the whole, I wish I hadn't asked.... but I think we need to sort it out. For a start, *please* can you kill those horribly misnamed OPENSSL_asc2uni() and OPENSSL_utf82uni() functions. Especially the former. Having a function which is misnamed in what it takes as input *and* what it gives out output is particularly impressive. It was a stupid thing for Windows to do, to misuse the term 'Unicode' to mean UCS-2LE (and later UTF-16LE when it retroactively changed its mind. For you to then abuse 'uni' to mean UTF-16BE, something *different* to what Windows abuses the term for, is really not very helpful at all! :) -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From dwmw2 at infradead.org Mon Aug 29 18:25:27 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 29 Aug 2016 19:25:27 +0100 Subject: [openssl-dev] [PATCH] Support broken PKCS#12 key generation. In-Reply-To: <1472492459.61594.685.camel@infradead.org> References: <1472419133.3390.23.camel@infradead.org> <1472492459.61594.685.camel@infradead.org> Message-ID: <1472495127.3390.35.camel@infradead.org> On Mon, 2016-08-29 at 18:40 +0100, David Woodhouse wrote: > > So... let's have a password 'na?ve', in a ISO8859-2 environment where > that is represented by the bytes 6e 61 b3 76 65. > > First I should try the correct version according to the spec: > ?006e 0061 0142 0076 0065 > > Then we try the "OpenSSL assumed it was ISO8859-1" version: > ?006e 0061 00b3 0076 0065 > > And finally we try the "OpenSSL assumed it was UTF-8" version: > ?006e 0061 ... actually you *can't* convert that byte sequence "from" > UTF-8 since it isn't valid UTF-8. So what will new OpenSSL do here, > again? In this specific example (the byte stream is not valid UTF-8 it looks like OPENSSL_utf8touni() will assume it's actually ISO8859-1 and thus the final case will be identical to the previous one. So let's try a better example. The password is "??" (U+0102 U+017b), and the locale (not that it *should* matter) is ISO8859-2. The correct rendition is 01 02 01 7b. The "old buggy OpenSSL" rendition, in the ISO8859-2 locale, would be to *convert* to ISO8859-2 (giving c3 af). Then to interpret those bytes as ISO8859-1 (in which they would mean "??") and convert *that* to UTF16LE to give 00 c3 00 af The "new buggy OpenSSL" rendition, again in the ISO8859-2 locale, would again be to convert to ISO8859-2 (c3 af). Then to interpret those bytes as UTF-8 (in which they would mean "?") and convert *that* to UTF16LE to give 00 ef. Right? --? dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From appro at openssl.org Mon Aug 29 21:01:43 2016 From: appro at openssl.org (Andy Polyakov) Date: Mon, 29 Aug 2016 23:01:43 +0200 Subject: [openssl-dev] [PATCH] Support broken PKCS#12 key generation. In-Reply-To: <1472495127.3390.35.camel@infradead.org> References: <1472419133.3390.23.camel@infradead.org> <1472492459.61594.685.camel@infradead.org> <1472495127.3390.35.camel@infradead.org> Message-ID: <5523721f-36b7-7e5a-2f4d-ae4446b50d3f@openssl.org> > So let's try a better example. The password is "??" (U+0102 U+017b), > and the locale (not that it *should* matter) is ISO8859-2. When it comes to locale in *this* case you should rather wonder what does your terminal emulator program do and how does it interact with your shell. Because these two are responsible for composing the string that OPENSSL_[asc|utf8]2uni gets. > The correct rendition is 01 02 01 7b. Yes. And now note that it's passed as 'c4 82 c5 bb' to openssl pkcs12 as argument or console input under an UTF-8 locale. Otherwise it would have been passed as 'c3 af'. > The "old buggy OpenSSL" rendition, in the ISO8859-2 locale, would be > to *convert* to ISO8859-2 (giving c3 af). No, no conversion from UTF-8 to ISO8859-x or any other conversion was *ever* performed. Nor is it performed now. It was and still is all about how string is composed by *somebody else*. That's why I said that "we assume that you don't change locale when you upgrade OpenSSL". > Then to interpret those bytes > as ISO8859-1 (in which they would mean "??") and convert *that* to > UTF16LE to give 00 c3 00 af Previously OpenSSL would convert 'c4 82 c5 bb' to '00 c4 00 82 00 c5 00 bb'. Now it converts it to '01 02 01 7b', but attempts even '00 c4 00 82 00 c5 00 bb' for "old times sake". And for 'c3 af' question is if it's valid UTF-8 encoding. If it is (it is in this example), then it would attempt '00 ef' (in this example) and then '00 c3 00 af', and if not, then it would go straight to '00 c3 00 af'. From rt at openssl.org Mon Aug 29 22:06:51 2016 From: rt at openssl.org (John L Veazey via RT) Date: Mon, 29 Aug 2016 22:06:51 +0000 Subject: [openssl-dev] [openssl.org #4665] Bug with OpenSSL 1.1.0 when path to Perl contains spaces In-Reply-To: <064801d20238$2b679b00$8236d100$@gmail.com> References: <064801d20238$2b679b00$8236d100$@gmail.com> Message-ID: I have a Windows machine where Perl is installed in "C:\Program Files\Perl64\bin\perl.exe". When executing "perl Configure VC-WIN32", I get the following error 'C:\Program' is not recognized as an internal or external command, operable program or batch file. I've fixed the problem, by modifying line #2394 in Configure and adding double quotes around $config{perl}. my $cmd = "\"$config{perl}\" \"-I.\" \"-Mconfigdata\" \"$dofile\" -o\"Configure\" \"".join("\" \"", at templates)."\" > \"$out.new\""; -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4665 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4861 bytes Desc: not available URL: From wangxiuyan552 at hotmail.com Mon Aug 29 22:24:25 2016 From: wangxiuyan552 at hotmail.com (wang xiuyan) Date: Mon, 29 Aug 2016 22:24:25 +0000 Subject: [openssl-dev] Is Intel ADX instruction extension supported by the latest OpenSSL? Message-ID: Dear OpenSSL developers, I'm looking at how to adopt Intel ADX instruction extension in OpenSSL. Below man page mentions ADCX/ADOX instructions: https://www.openssl.org/docs/manmaster/crypto/OPENSSL_ia32cap.html but I can not find ADCX/ADOX related words/expressions from OpenSSL-1.0.2h source code. I wonder whether OpenSSL already supports ADX. If so, what's the related code? Thanks, Xiuyan From dwmw2 at infradead.org Tue Aug 30 07:30:49 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 30 Aug 2016 08:30:49 +0100 Subject: [openssl-dev] [PATCH] Support broken PKCS#12 key generation. In-Reply-To: <5523721f-36b7-7e5a-2f4d-ae4446b50d3f@openssl.org> References: <1472419133.3390.23.camel@infradead.org> <1472492459.61594.685.camel@infradead.org> <1472495127.3390.35.camel@infradead.org> <5523721f-36b7-7e5a-2f4d-ae4446b50d3f@openssl.org> Message-ID: <1472542249.3390.50.camel@infradead.org> On Mon, 2016-08-29 at 23:01 +0200, Andy Polyakov wrote: > > > > So let's try a better example. The password is "??" (U+0102 U+017b), > > and the locale (not that it *should* matter) is ISO8859-2. > When it comes to locale in *this* case you should rather wonder what > does your terminal emulator program do and how does it interact with > your shell. Because these two are responsible for composing the string > that OPENSSL_[asc|utf8]2uni gets. Right. And for the purpose of my example I have moved to eastern Europe and fallen through a time-warp into the 20th century, so I'm using an ISO8859-2 locale. > > The correct rendition is 01 02 01 7b. > Yes. And now note that it's passed as 'c4 82 c5 bb' to openssl pkcs12 as > argument or console input under an UTF-8 locale. Otherwise it would have > been passed as 'c3 af'. No. My locale is ISO8859-2 so the password?"??" *is* passed as 'c3 af'. Old OpenSSL will ignore the fact that the locale is ISO8859-2, and perform an ISO8859-1 to UCS16BE conversion using the doubly-misnamed OPENSSL_asc2uni() function. So it'll use '00 c3 00 af'. New OpenSSL will ignore the fact that the locale is ISO8859-2, and perform a UTF-8 to UCS16BE conversion using the only singly renamed OPENSSL_utf82uni() function. So it'll use '00 ef'. You had a bug because you made assumptions about the input data and didn't properly convert from the locale charset to UTF16BE as you should have done. Instead of fixing the bug, you just changed the assumption you made to one that's slightly more likely to be valid in today's world. Leaving the rest of us with *two* buggy behaviours to try to work around. > > > > The "old buggy OpenSSL" rendition, in the ISO8859-2 locale, would be > > to *convert* to ISO8859-2 (giving c3 af). > No, no conversion from UTF-8 to ISO8859-x or any other conversion was > *ever* performed. Nor is it performed now. It was and still is all about > how string is composed by *somebody else*. That's why I said that "we > assume that you don't change locale when you upgrade OpenSSL". I'm talking about how other libraries should attempt to read the PKCS#12 files created by OpenSSL. In my code I have the string "??" which the user has provided as the password. It doesn't matter what charset it's in, as long as I *know* what charset it's in, and haven't wantonly thrown that information away and started making *assumptions* about how to interpret the stream of bytes. So in order to try to emulate the old OpenSSL bug and read the file, I need to convert to ISO8859-2, then "forget" that it's ISO8859-2 and treat it as ISO8859-1 for the purpose of converting to UTF16BE and trying to decrypt. Which gives me the '00 c3 00 af' as above. And in order to emulate the new OpenSSL bug and read the file, I need to convert to ISO8859-2, then "forget" that it's ISO8859-2 and treat it as UTF-8 for the purpose of converting to UTF16BE and trying to decrypt. Which gives me the '00 ef' that current OpenSSL will use. This latter buggy behaviour hasn't actually been released yet, has it? Is it too late to fix it properly? -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From rt at openssl.org Tue Aug 30 09:35:43 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Tue, 30 Aug 2016 09:35:43 +0000 Subject: [openssl-dev] [openssl.org #4665] Bug with OpenSSL 1.1.0 when path to Perl contains spaces In-Reply-To: <064801d20238$2b679b00$8236d100$@gmail.com> References: <064801d20238$2b679b00$8236d100$@gmail.com> Message-ID: Good find. I'll fix. Cheers, Richard On Mon Aug 29 22:06:51 2016, jveazey at gmail.com wrote: > I have a Windows machine where Perl is installed in "C:\Program > Files\Perl64\bin\perl.exe". > > > > When executing "perl Configure VC-WIN32", I get the following error > > > > 'C:\Program' is not recognized as an internal or external command, > > operable program or batch file. > > > > I've fixed the problem, by modifying line #2394 in Configure and adding > double quotes around $config{perl}. > > > > my $cmd = "\"$config{perl}\" \"-I.\" \"-Mconfigdata\" \"$dofile\" > -o\"Configure\" \"".join("\" \"", at templates)."\" > \"$out.new\""; > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4665 Please log in as guest with password guest if prompted From appro at openssl.org Tue Aug 30 10:38:52 2016 From: appro at openssl.org (Andy Polyakov) Date: Tue, 30 Aug 2016 12:38:52 +0200 Subject: [openssl-dev] [PATCH] Support broken PKCS#12 key generation. In-Reply-To: <1472492459.61594.685.camel@infradead.org> References: <1472419133.3390.23.camel@infradead.org> <1472492459.61594.685.camel@infradead.org> Message-ID: <049755b8-80ac-eb14-2bed-c82864508fce@openssl.org> > Hm, words fail me. > > Well, that's not entirely true. But *polite* words fail me... :-) > Let me try to understand this... you have always ignored, and still > ignore, the actual LC_CTYPE which tells you the character set in which > the password was provided from the user. > > You *used* to convert it through your horribly misnamed > OPENSSL_asc2uni() function, which actually converts ISO8859-1 to > UTF16BE by simply expanding it and inserting 0x00 between each byte of > the original. So effectively you were "assuming" the input was > ISO8859-1. Unfortunately yes. > Now you assume it's UTF-8, and convert it with OPENSSL_utf8touni(). > (And now what happens when the locale input *isn't* valid UTF-8, > because it's a legacy 8-bit charset? That conversion should fail, > right?) Right. Though more correct formulation probably "is likely to fail" instead of "should fail". > Your latest workaround (from which I started this thread) is addressing > the first problem *purely* for the case of the UTF-8 locale. It checks > for the "we treated UTF-8 as if it were ISO8859-1" case, which is what > leads to the 006e 0061 00c3 00af 0076 0065 example you gave above. Yes. > But you *haven't* actually implemented any workaround for the other > whole set of "we treated locale XXXXX as if it were ISO8859-1" bugs > that your original code had. Or the whole set of "we treated local > XXXXX as if it were UTF-8" bugs that the new code has. Yes. > So for other applications to try to read OpenSSL's PKCs#12 files, what > we need to do is first convert the sane Unicode rendition of the > password into the native locale charset (e.g. Windows-1252), then take > that bytestream and *pretend* it's ISO8859-1, and convert to UTF-16BE > to check the MAC. Then if that fails, take the same Windows-1252 > bytestream and *pretend* it's UTF-8, and convert *that* to UTF-16BE to > see if it works. Are you sure you want to know? I mean you already said "I wish I hadn't ask", and now you are bringing Windows into conversation :-) :-) :-) Yes, it's as bad as you can possibly imagine, and trouble is that there is no "right thing" to do *if* you formulate "keep old data accessible" as goal. I mean the right thing to do is to perform all due conversions to obtain locale-neutral big-endian UTF-16 (though it's not obvious if it's actually desired to bring in dependency on something like iconv into libcrypto), but trouble is that it will more than likely render old data inaccessible. That's why somewhat opportunistic approach is taken in this version, unfortunate as it is. Main goal is that given otherwise unchanged circumstances new version *has to* be able to read old data generated by previous version on the *same* system, irregardless how broken it is. At the same time a way to access and generate specification-compliant data is provided (on *ix it takes *an* UTF8 locale, which is default in absolute majority of cases bu now, and on Windows it's an *opt-in* environment variable for the time being). From appro at openssl.org Tue Aug 30 10:45:10 2016 From: appro at openssl.org (Andy Polyakov) Date: Tue, 30 Aug 2016 12:45:10 +0200 Subject: [openssl-dev] Is Intel ADX instruction extension supported by the latest OpenSSL? In-Reply-To: References: Message-ID: > I'm looking at how to adopt Intel ADX instruction extension in OpenSSL. Below man page mentions ADCX/ADOX instructions: > > https://www.openssl.org/docs/manmaster/crypto/OPENSSL_ia32cap.html > > but I can not find ADCX/ADOX related words/expressions from OpenSSL-1.0.2h source code. I wonder whether OpenSSL already supports ADX. If so, what's the related code? grep adox crypto/bn/asm/*. As for referred page, do note that there are minimum assembler version requirements. Even though AD[OC]X are not explicitly mentioned, there is minimum requirement even for that, and it's 2.23 for GNU assembler, 2.10 for nasm and 3.3 for clang. From dwmw2 at infradead.org Tue Aug 30 13:23:26 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 30 Aug 2016 14:23:26 +0100 Subject: [openssl-dev] [PATCH] Support broken PKCS#12 key generation. In-Reply-To: <049755b8-80ac-eb14-2bed-c82864508fce@openssl.org> References: <1472419133.3390.23.camel@infradead.org> <1472492459.61594.685.camel@infradead.org> <049755b8-80ac-eb14-2bed-c82864508fce@openssl.org> Message-ID: <1472563406.61594.728.camel@infradead.org> On Tue, 2016-08-30 at 12:38 +0200, Andy Polyakov wrote: > > So for other applications to try to read OpenSSL's PKCs#12 files, what > > we need to do is first convert the sane Unicode rendition of the > > password into the native locale charset (e.g. Windows-1252), then take > > that bytestream and *pretend* it's ISO8859-1, and convert to UTF-16BE > > to check the MAC. Then if that fails, take the same Windows-1252 > > bytestream and *pretend* it's UTF-8, and convert *that* to UTF-16BE to > > see if it works. > > Are you sure you want to know? I mean you already said "I wish I hadn't > ask", and now you are bringing Windows into conversation :-) :-) :-) I concede, I am a masochist. :) > Yes, it's as bad as you can possibly imagine, and trouble is that there > is no "right thing" to do *if* you formulate "keep old data accessible" > as goal. Yeah, if you want to be able to create PKCS#12 files that'll work (in the same locale) with older versions of OpenSSL, you're kind of stuck. I can live with that historical accident, and the workaround of "convert to the locale charset, then pretend that's ISO8859-1 and try again". I can even live with the fact that, for the reasons you've stated, OpenSSL *still* produces files which need that workaround. But I *really* wish you hadn't added *another* bug, and required another workaround.... > At the same time a way to access and generate > specification-compliant data is provided (on *ix it takes *an* UTF8 > locale, which is default in absolute majority of cases bu now, and on > Windows it's an *opt-in* environment variable for the time being). ... so instead of doing the UTF-8 thing whenever the incoming bytestream happens to be interpretable as valid UTF-8, why not do it only if LC_CTYPE actually *is* UTF-8? So my (admittedly contrived and unlikely) example of?"??" in an ISO8859-2 locale would only continue to do the *old* wrong thing, and not a *new* wrong thing that needs an additional workaround :) -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From rt at openssl.org Tue Aug 30 16:44:08 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Tue, 30 Aug 2016 16:44:08 +0000 Subject: [openssl-dev] [openssl.org #4665] Bug with OpenSSL 1.1.0 when path to Perl contains spaces In-Reply-To: References: <064801d20238$2b679b00$8236d100$@gmail.com> Message-ID: https://github.com/openssl/openssl/pull/1519 Cheers, Richard On Tue Aug 30 09:35:42 2016, levitte wrote: > Good find. I'll fix. > > Cheers, > Richard > > On Mon Aug 29 22:06:51 2016, jveazey at gmail.com wrote: > > I have a Windows machine where Perl is installed in "C:\Program > > Files\Perl64\bin\perl.exe". > > > > > > > > When executing "perl Configure VC-WIN32", I get the following error > > > > > > > > 'C:\Program' is not recognized as an internal or external command, > > > > operable program or batch file. > > > > > > > > I've fixed the problem, by modifying line #2394 in Configure and adding > > double quotes around $config{perl}. > > > > > > > > my $cmd = "\"$config{perl}\" \"-I.\" \"-Mconfigdata\" \"$dofile\" > > -o\"Configure\" \"".join("\" \"", at templates)."\" > \"$out.new\""; > > > > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4665 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 31 13:48:18 2016 From: rt at openssl.org (Claus Fischer via RT) Date: Wed, 31 Aug 2016 13:48:18 +0000 Subject: [openssl-dev] [openssl.org #4666] Fix for setenv-android.sh In-Reply-To: <20160831090750.GA3007@clausfischer.com> References: <20160831090750.GA3007@clausfischer.com> Message-ID: OpenSSL Version 1.1.x For this openssl version, the setenv-android.sh script on the Website https://wiki.openssl.org/images/7/70/Setenv-android.sh should export CROSS_SYSROOT instead of SYSROOT. -- Claus Fischer http://www.clausfischer.com/ -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4666 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 173 bytes Desc: not available URL: From rt at openssl.org Wed Aug 31 14:46:02 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 31 Aug 2016 14:46:02 +0000 Subject: [openssl-dev] [openssl.org #4665] Bug with OpenSSL 1.1.0 when path to Perl contains spaces In-Reply-To: References: <064801d20238$2b679b00$8236d100$@gmail.com> Message-ID: Haven't heard if this worked for you, John... the change has been reviewed and is now merged into master and the 1.1.0 release branch, so I'll close this ticket. If you have further problems, please report anew. Cheers, Richard On Tue Aug 30 16:44:08 2016, levitte wrote: > https://github.com/openssl/openssl/pull/1519 > > Cheers, > Richard > > On Tue Aug 30 09:35:42 2016, levitte wrote: > > Good find. I'll fix. > > > > Cheers, > > Richard > > > > On Mon Aug 29 22:06:51 2016, jveazey at gmail.com wrote: > > > I have a Windows machine where Perl is installed in "C:\Program > > > Files\Perl64\bin\perl.exe". > > > > > > > > > > > > When executing "perl Configure VC-WIN32", I get the following error > > > > > > > > > > > > 'C:\Program' is not recognized as an internal or external command, > > > > > > operable program or batch file. > > > > > > > > > > > > I've fixed the problem, by modifying line #2394 in Configure and adding > > > double quotes around $config{perl}. > > > > > > > > > > > > my $cmd = "\"$config{perl}\" \"-I.\" \"-Mconfigdata\" \"$dofile\" > > > -o\"Configure\" \"".join("\" \"", at templates)."\" > \"$out.new\""; > > > > > > > > > -- > > Richard Levitte > > levitte at openssl.org > > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4665 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 31 16:06:30 2016 From: rt at openssl.org (REIX, Tony via RT) Date: Wed, 31 Aug 2016 16:06:30 +0000 Subject: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O In-Reply-To: <57C6FCB5.1010100@atos.net> References: <57C6FCB5.1010100@atos.net> Message-ID: Hi, I do ports of OpenSSL on AIX 6.1 for one year. I had no issue with 1.0.1* and 1.0.2* versions, compiled with XLC. With version 1.1.0, I am encountering an issue with -O, both with XLC and GCC . 30-test_evp.t fails because using -O when compiling crypto/ppccap.c generates something wrong. Compiling only crypto/ppccap.c with -O0 does fix the issue. It is the same with XLC. I have put in place a simple work-around: use -O0 for crypto/ppccap.c . However, do you have an idea about: why crypto/ppccap.c seems sensitive to optimization ? Thanks/Regards, Tony Reix http://www.bullfreeware.com -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4667 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 31 16:34:06 2016 From: rt at openssl.org (sandeep umesh via RT) Date: Wed, 31 Aug 2016 16:34:06 +0000 Subject: [openssl-dev] [openssl.org #4647] bug report: OpenSSL 1.0.2h: Segment fault on AIX Power8 using optimization code In-Reply-To: References: <072e0c9e-338c-f823-3543-24edf4cf06e4@openssl.org> Message-ID: Hi Andy Our configure option is: ./Configure enable-ssl2 -DSSL_ALLOW_ADH --prefix=/usr --openssldir=/var/ssl no-idea no-rc5 no-symlinks shared threads aix64-xlc_r And in 1.0.2h Configure file, we have: "aix64-xlc_r", "cc:-q64 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst::-qthreaded -D_THREAD_SAFE:AIX::SIXTY_FOUR_BIT_LONG RC4_CHAR:${ppc64_asm}:aix64:dlfcn:aix-shared::-q64 -qmkshrobj:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)::-X 64", Thanks Regards Sandeep On Mon, Aug 22, 2016 at 2:36 AM, Andy Polyakov via RT wrote: > Hi, > > > We are using libcurl for REST programming, which internally uses openssl > > and libcrypto. > > curl suggested to implement few callbacks related to locking, which would > > be needed for openssl below 1.1 version(which is still in beta). > > > > The following callbacks were implemented: > > > > https://curl.haxx.se/libcurl/c/threaded-ssl.html > > > > lock_callback, thread_id, init_locks, kill_locks > > > > With these modifications we are facing a crash in openssl library when > used > > on a Power8 Hardware (with optimizations). > > The fact that it's affected by optimizations is likely to be > circumstantial. I'm not convinced that it's not MT problem with your > application, and whether or not crash is triggered is question of > delicate yet unfortunate timing. And that's what is affected by > optimizations, timing. Questions are. You say you implement the > callbacks, but are they actually engaged? Is your openssl actually > compiled with threads support? Which configuration target/config line > was used to compile it? > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4647 > Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4647 Please log in as guest with password guest if prompted From rt at openssl.org Wed Aug 31 16:46:53 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 31 Aug 2016 16:46:53 +0000 Subject: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O In-Reply-To: <57C6FCB5.1010100@atos.net> References: <57C6FCB5.1010100@atos.net> Message-ID: Curious. The diverse flags for the aix config targets' information in 1.1.0 are exact copies from the 1.0.x series... The best way you can help out here is to show us the build command lines you got for building crypto/ppccap.o in both 1.1.0 and 1.0.2, so we can see what actually differs. Cheers, Richard On Wed Aug 31 16:06:30 2016, tony.reix at atos.net wrote: > Hi, > > I do ports of OpenSSL on AIX 6.1 for one year. > I had no issue with 1.0.1* and 1.0.2* versions, compiled with XLC. > With version 1.1.0, I am encountering an issue with -O, both with XLC > and GCC . > > 30-test_evp.t fails because using -O when compiling crypto/ppccap.c > generates something wrong. > Compiling only crypto/ppccap.c with -O0 does fix the issue. > It is the same with XLC. > > I have put in place a simple work-around: use -O0 for crypto/ppccap.c > . > > However, do you have an idea about: why crypto/ppccap.c seems > sensitive to optimization ? > > Thanks/Regards, > > Tony Reix > http://www.bullfreeware.com > > > > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4667 Please log in as guest with password guest if prompted