From nico at cryptonector.com Tue Dec 1 00:14:42 2015 From: nico at cryptonector.com (Nico Williams) Date: Mon, 30 Nov 2015 18:14:42 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <2393198.BXy04kfg64@acid> References: <20151123015347.GJ18315@mournblade.imrryr.org> <38138022.XYSrmVJakE@acid> <1505607.eacbI7ABhB@pintsize.usersys.redhat.com> <2393198.BXy04kfg64@acid> Message-ID: <20151201001441.GA23318@localhost> On Tue, Dec 01, 2015 at 09:21:34AM +1000, Paul Dale wrote: > However, the obstacle preventing 100% CPU utilisation for both stacks > is lock contention. The NSS folks apparently spent a lot of effort > addressing this and they have a far more scalable locking model than > OpenSSL: one lock per context for all the different kinds of context > versus a small number of global locks. I prefer APIs which state that they are "thread-safe provided the application accesses each XYZ context from only one thread at a time". Leave it to the application to do locking, as much as possible. Many threaded applications won't need locking here because they may naturally have only one thread using a given context. Also, for something like a TLS context, ideally it should be naturally possible to have two threads active, as long as one thread only reads and the other thread only writes. There can be some dragons here with respect to fatal events and deletion of a context, but the simplest thing to do is to use atomics for manipulating state like "had a fatal alert", and use reference counts to defer deletion (then if the application developer wants it this way, each of the reader and writer threads can have a reference and the last one to stop using the context deletes it). > There is definitely scope for improvement here. My atomic operation > suggestion is one approach which was quick and easy to validate, > better might be more locks since it doesn't introduce a new paradigm > and is more widely supported (C11 notwithstanding). A platform compatibility atomics library would be simple enough (plenty exist, I believe). For platforms where no suitable implementation exists you can use a single global lock, and if there's not even that, then you can use non-atomic implementations and pretend it's all OK or fail to build (users of such platforms will quickly provide real implementations). (Most compilers have pre-C11 atomics intrinsics and many OSes have atomics libraries.) Nico -- From pwalten at au1.ibm.com Tue Dec 1 03:41:11 2015 From: pwalten at au1.ibm.com (Peter Waltenberg) Date: Tue, 1 Dec 2015 03:41:11 +0000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151201001441.GA23318@localhost> References: <20151201001441.GA23318@localhost>, <20151123015347.GJ18315@mournblade.imrryr.org> <38138022.XYSrmVJakE@acid> <1505607.eacbI7ABhB@pintsize.usersys.redhat.com> <2393198.BXy04kfg64@acid> Message-ID: <201512010341.tB13fh23012365@d23av03.au.ibm.com> An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Dec 1 09:03:56 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Tue, 01 Dec 2015 09:03:56 +0000 Subject: [openssl-dev] [openssl.org #4162] [PATCH] Removing vrsave load and store In-Reply-To: <565D6277.7070100@openssl.org> References: <20151130181406.GA14203@bluepex.com> <565D6277.7070100@openssl.org> Message-ID: Hi, > Access to VRSAVE have a high cost in performance. > Since ABI was update we don't need to save what > vector register we are using. Removing VRSAVE access > can improve a bit more our performance. Well, OpenSSL doesn't target exclusively post-ABI-update systems and the rationale for unconditional removal is questionable. I mean you say yourself "since update" and "our performance", but what about "prior update" and other OSes? Do *all*, i.e. even big-endian, Linux systems implement new ABI? AIX? MacOS X/PPC? Well, one can say the last one is dead, and even if it's not, modules in question [POWER8-specific] won't ever execute under it, but one before is not... IBM also pushes for POWER8 to be more open, so wouldn't it be more appropriate to keep options open? And why just POWER8-specific modules? I finally managed to find a copy of new specification and it classifies vrsave as reserved for system use. So that correct course of action is to make instructions reading/writing vrsave conditional, formulate the condition, and express it in code. I'd suggest to implement this in ppc-xlate. I.e. recognize 'mtspr 256,rA' and conditionally replace it with some kind of nop, e.g. or rA,rA,rA. 'mfspr rD,256' can be replaced with li rD,-1. This way one can affect all modules at once without having to examine each one of them. I can make suggestion a little bit later... From cpservicespb at gmail.com Tue Dec 1 09:42:23 2015 From: cpservicespb at gmail.com (CpServiceSPb .) Date: Tue, 1 Dec 2015 12:42:23 +0300 Subject: [openssl-dev] Fwd: OpenSSL as OCSP server (responder) as multithreading daemon ! Message-ID: I saw your roadmap. Yes, much work waits for you as dev. team. >> Moreover, I think, many people need it and will be glad to get it within OSSL released versions that will make OSSL more popular. >Sure. >But they do not have to be part of OpenSSL. Let' t allow to not agree with you. Quite more comfortable is to use Ocsp and/or other certification functionality 'parts' with certificates tools/core which is used to issue certiicates. Anyway, if your dev. team include Ocsp code modified by me and extend OSSL, it will be better to all.:) If you have some questions regarding modification, you will be wellcome. With many good wishes... Art Sun -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkario at redhat.com Tue Dec 1 10:38:29 2015 From: hkario at redhat.com (Hubert Kario) Date: Tue, 01 Dec 2015 11:38:29 +0100 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <2393198.BXy04kfg64@acid> References: <20151123015347.GJ18315@mournblade.imrryr.org> <1505607.eacbI7ABhB@pintsize.usersys.redhat.com> <2393198.BXy04kfg64@acid> Message-ID: <1569110.csLjTBX6Rr@pintsize.usersys.redhat.com> On Tuesday 01 December 2015 09:21:34 Paul Dale wrote: > > are you sure that the negotiated cipher suite is the same and that > > the NSS is not configured to reuse the server key share if you're > > using DHE or ECDHE? > > There is definitely scope for improvement here. My atomic operation > suggestion is one approach which was quick and easy to validate, > better might be more locks since it doesn't introduce a new paradigm > and is more widely supported (C11 notwithstanding). I'm not saying there is no room for improvement or that the improvements are useless. But as long as we're not comparing apples-to-apples the statistic is useless. Other things to look for: ServerKeyExchange curve or group and signature algorithm used as well as the key size of server. Each of those things can have impact completely overshadowing the lock contention differences (picking big RSA key size can easily slash performance by an order of magnitude). -- 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 hkario at redhat.com Tue Dec 1 12:24:17 2015 From: hkario at redhat.com (Hubert Kario) Date: Tue, 01 Dec 2015 13:24:17 +0100 Subject: [openssl-dev] [openssl.org #4157] Download Documentation In-Reply-To: References: <4278203.EzjrOVC3Ah@pintsize.usersys.redhat.com> Message-ID: <2435514.IszOCxNRsc@pintsize.usersys.redhat.com> On Monday 30 November 2015 16:23:48 Blumenthal, Uri - 0553 - MITLL wrote: > On 11/30/15, 11:10 , "openssl-dev on behalf of Hubert Kario" > > wrote: > >On Friday 27 November 2015 13:39:36 Tom Jay via RT wrote: > >> 3. Some kind of useful examples of common usages > >> of OpenSSL would be appreciated. > > > >https://wiki.openssl.org/index.php/Main_Page > > > >If you have specific use cases missing from there, please tell, but > >be precise > > It talks only about *programming*, using OpenSSL toolkit as a > *library* to link against (and about ways to extend that library). > > I think it omits a *huge* area of use cases where ?openssl? executable > itself is used to (a) test and/or debug other SSL/TLS applications > and packages, (b) perform cryptographic processing on files and data > - either standalone, or as a part of a script (shell or such). True, there are https://wiki.openssl.org/index.php/Command_Line_Utilities https://wiki.openssl.org/index.php/Enc https://wiki.openssl.org/index.php/Command_Line_Elliptic_Curve_Operations but they're not exactly brimming with examples... That being said, I think Tom was interested in library use, not application use, given that static compilation of the `openssl` binary is the default behaviour of configure scripts and it doesn't require installation to use. -- 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 hkario at redhat.com Tue Dec 1 12:26:11 2015 From: hkario at redhat.com (Hubert Kario) Date: Tue, 01 Dec 2015 13:26:11 +0100 Subject: [openssl-dev] Download Documentation In-Reply-To: <54c2ad4815b94cfb97fc9a530ab1bd8b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <54c2ad4815b94cfb97fc9a530ab1bd8b@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <1603659.NRxjEnNQeZ@pintsize.usersys.redhat.com> On Monday 30 November 2015 16:28:06 Salz, Rich wrote: > > I think it omits a *huge* area of use cases where ?openssl? > > executable itself is used to (a) test and/or debug other SSL/TLS > > applications and packages, (b) perform cryptographic processing on > > files and data - either standalone, or as a part of a script (shell > > or such). > > It would be great if people doing those kinds of things could post > information about it. > The community is in a better position to help here, not the > development team. I'll try to help, but I'm also biased towards testing _all_ supported features, not stuff that is used... -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rsalz at akamai.com Tue Dec 1 13:28:27 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 1 Dec 2015 13:28:27 +0000 Subject: [openssl-dev] Fwd: OpenSSL as OCSP server (responder) as multithreading daemon ! In-Reply-To: References: Message-ID: ? Let' t allow to not agree with you. Yes, as the English saying has it: we'll agree to disagree. ? Thanks very much for your interest, involvement, and use of OpenSSL! -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Tue Dec 1 21:21:12 2015 From: paul.dale at oracle.com (Paul Dale) Date: Wed, 02 Dec 2015 07:21:12 +1000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <1569110.csLjTBX6Rr@pintsize.usersys.redhat.com> References: <20151123015347.GJ18315@mournblade.imrryr.org> <2393198.BXy04kfg64@acid> <1569110.csLjTBX6Rr@pintsize.usersys.redhat.com> Message-ID: <2804457.9VHQcysgqt@acid> The figures were for connection reestablishment, RSA computations etc simply don't feature. For initial connection establishment, on the other hand, they are the single largest factor. The crypto is definitely not the bottleneck for this case. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Dec 2 08:54:31 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 02 Dec 2015 08:54:31 +0000 Subject: [openssl-dev] [openssl.org #4162] [PATCH] Removing vrsave load and store In-Reply-To: <565EB1BD.2040600@openssl.org> References: <20151130181406.GA14203@bluepex.com> <565D6277.7070100@openssl.org> <565EB1BD.2040600@openssl.org> Message-ID: Hi, >> Access to VRSAVE have a high cost in performance. >> Since ABI was update we don't need to save what >> vector register we are using. Removing VRSAVE access >> can improve a bit more our performance. > > ... I'd suggest to implement this in ppc-xlate. I.e. recognize > 'mtspr 256,rA' and conditionally replace it with some kind of nop, e.g. > or rA,rA,rA. 'mfspr rD,256' can be replaced with li rD,-1. This way one > can affect all modules at once without having to examine each one of > them. I can make suggestion a little bit later... Question is if the condition for $no_vrsave assignment is proper. Or rather if it should be /aix|linux64/. As I couldn't see that big-endian Linux I have access to uses ELF ABI V2, I've settled for /aix|linux64le/. -------------- next part -------------- A non-text attachment was scrubbed... Name: ppc-xlate.diff Type: text/x-patch Size: 757 bytes Desc: not available URL: From rt at openssl.org Wed Dec 2 14:24:07 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 02 Dec 2015 14:24:07 +0000 Subject: [openssl-dev] EXT :Re: [openssl.org #3931] OpenSSL 1.0.2(c, d) hangs on Sun T3 in OPENSSL_cpuid_setup() In-Reply-To: <565EFF04.9050907@openssl.org> References: <565C8916.7000805@oracle.com> <565EFF04.9050907@openssl.org> Message-ID: > >> I applied the patch you sent and configured/compiled using > >> "solaris-sparcv9-gcc" and the program completes normally. > >> As I am unable to use patched/unofficial code for our operational ... > > > >What is criteria for being "official"? Explicitly released as tar-ball > >or just commit to repository? > > Unless I'm missing it, this patch doesn't appear to have been committed > to the repository yet. Any chance you could get this into 1.0.2e? Committed. From rt at openssl.org Wed Dec 2 14:36:19 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 02 Dec 2015 14:36:19 +0000 Subject: [openssl-dev] [openssl.org #4138] Detection of assembler version In-Reply-To: <565F01E3.7040704@openssl.org> References: <20151111175820.GA14677@roeckx.be> <564502B8.7080901@openssl.org> <5645F941.7000806@kippdata.de> <565F01E3.7040704@openssl.org> Message-ID: >>> I just found out that building with at least with the French >>> locale the AVX code is missing. The problem is this code in >>> crypto/sha/asm/sha1-x86_64.pl: >>> if (`$ENV{CC} -Wa,-v -c -o /dev/null -x assembler /dev/null 2>&1` >>> =~ /GNU assembler version ([2-9]\.[0-9]+)/) { >>> $avx = ($1>=2.19) + ($1>=2.22); >>> } >>> >>> In English it returns: >>> GNU assembler version 2.25.1 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.25.1 >>> >>> But in French it returns: >>> Version de l'assembleur GNU 2.25.1 (x86_64-linux-gnu) utilisant la version BFD (GNU Binutils for Debian) 2.25.1 >>> >>> A quick grep at least shows 17 affected files. >>> >>> The fix should be easy setting the locale to C when doing that >>> check. >> >> Oh! Though I'd like to suggest taking it even further. Namely setting >> LANG to C in top-most Makefile. This way we would also ensure that even >> compiler error messages are readable when reported. What do you think? >> >> (I wish one could do something like that even with Microsouple >> l'compilateur ;-) > > Just a small addition: LANG gets overwritten by LC_* and LC_* gets > overwritten by LC_ALL. So it would be strongest to set LC_ALL, not LANG. LC_ALL it is. Closing. From rt at openssl.org Wed Dec 2 14:57:15 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 02 Dec 2015 14:57:15 +0000 Subject: [openssl-dev] [openssl.org #4142] Fail to detect Xcode 7 for Intel AVX code In-Reply-To: <565F06CB.2060300@openssl.org> References: <565F06CB.2060300@openssl.org> Message-ID: Hi, > I just found the perl script for x86_64 assembly failed to detect Xcode 7 environment (Apple LLVM 7.x), and skipped generating AVX code for MAC OS ($avx variable is always false). The reason is Apple since Xcode 7.0 removed string "based on LLVM x.y.z" from version information. Now the clang -v command returns: This was addressed in http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=76eba0d94bb418325be6409b272eac5e2bd4a0a9. Closing. From rt at openssl.org Wed Dec 2 14:59:38 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 02 Dec 2015 14:59:38 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <565F0759.404@openssl.org> References: <564B39A2.9040807@netbsd.org> <20151122112553.GA20758@roeckx.be> <5651ECCA.4050101@openssl.org> <5653159F.5000403@openssl.org> <565F0759.404@openssl.org> Message-ID: >> ... Either way, we seem to >> agree that *replacing* sun with __sun is not right thing to do in SunOS >> 4 context. One can argue for sun || __sun, or one can argue in favour of >> reverting. My vote goes for latter, because original conditions [in >> e_os.h] do work adequately. > > After closer look I have to withdraw my preference for just reverting. > Because there is one case that is not appropriate for *Solaris*. > Initially I noted that Solaris sys/ioctl.h includes sys/filio.h, but I > failed to notice and latter's inclusion is conditional and condition is > not met when OpenSSL compiles with defaults flags. As compiler targeting > Solaris doesn't *have to* define 'sun' for system headers to work, one > has to reserve for possibility that it's absent. Fixed. Closing. From rt at openssl.org Wed Dec 2 17:01:53 2015 From: rt at openssl.org (Leonidas Da Silva Barbosa via RT) Date: Wed, 02 Dec 2015 17:01:53 +0000 Subject: [openssl-dev] [openssl.org #4162] [PATCH] Removing vrsave load and store In-Reply-To: <20151202170133.GA1544@bluepex.com> References: <20151130181406.GA14203@bluepex.com> <565D6277.7070100@openssl.org> <20151202170133.GA1544@bluepex.com> Message-ID: On Tue, Dec 01, 2015 at 09:03:56AM +0000, Andy Polyakov via RT wrote: > Hi, > > Well, OpenSSL doesn't target exclusively post-ABI-update systems and the > rationale for unconditional removal is questionable. I mean you say > yourself "since update" and "our performance", but what about "prior > update" and other OSes? Do *all*, i.e. even big-endian, Linux systems > implement new ABI? AIX? MacOS X/PPC? Yes, I agree. We can only speak to Linux ABI V1/V2. > Well, one can say the last one is > dead, and even if it's not, modules in question [POWER8-specific] won't > ever execute under it, but one before is not... IBM also pushes for > POWER8 to be more open, so wouldn't it be more appropriate to keep > options open? And why just POWER8-specific modules? I finally managed to > find a copy of new specification and it classifies vrsave as reserved > for system use. So that correct course of action is to make instructions > reading/writing vrsave conditional, formulate the condition, and express > it in code. I'd suggest to implement this in ppc-xlate. I.e. recognize > 'mtspr 256,rA' and conditionally replace it with some kind of nop, e.g. > or rA,rA,rA. 'mfspr rD,256' can be replaced with li rD,-1. This way one > can affect all modules at once without having to examine each one of > them. I can make suggestion a little bit later... > I totally agree with your suggestions. I'll redo my patch according to them. Thanks a lot! From jeremy.farrell at oracle.com Wed Dec 2 18:40:18 2015 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Wed, 2 Dec 2015 18:40:18 +0000 Subject: [openssl-dev] EXT :Re: [openssl.org #3931] OpenSSL 1.0.2(c, d) hangs on Sun T3 in OPENSSL_cpuid_setup() In-Reply-To: References: <565C8916.7000805@oracle.com> <565EFF04.9050907@openssl.org> Message-ID: <565F3B12.80509@oracle.com> On 02/12/2015 14:24, Andy Polyakov via RT wrote: >>>> I applied the patch you sent and configured/compiled using >>>> "solaris-sparcv9-gcc" and the program completes normally. As I >>>> am unable to use patched/unofficial code for our operational >>>> ... >>> >>> What is criteria for being "official"? Explicitly released as >>> tar-ball or just commit to repository? >> >> Unless I'm missing it, this patch doesn't appear to have been >> committed to the repository yet. Any chance you could get this into >> 1.0.2e? > > Committed. Thanks Andy, much appreciated (as is all your and the team's work). Regards, jjf -- J. J. Farrell From antonio.ascrizzi at magnetimarelli.com Thu Dec 3 09:50:12 2015 From: antonio.ascrizzi at magnetimarelli.com (Ascrizzi Antonio (MM)) Date: Thu, 3 Dec 2015 10:50:12 +0100 Subject: [openssl-dev] URGENT QUESTION - about bn_mul.c Message-ID: Hi, I have a simple question: - Is the "BN_MUL" algorithm based on Karatsuba? - If YES please confirm, otherwise could you please explain me what algorithm is using? Thank you aa [cid:image003.png at 01D12DB8.62D5DBB0] Antonio Ascrizzi, PhD MM CTO System and SW Engineering Center - Senior SW Engineer/Architect Magneti Marelli S.p.A. Via del Timavo 33 - 40134 Bologna, Italy Phone: +39 051 6157945 Mobile: +39 3665703393 antonio.ascrizzi at magnetimarelli.com ________________________________ VISITA IL NOSTRO NUOVO SITO WEB! - VISIT OUR NEW WEB SITE! www.magnetimarelli.com Confidential Notice: This message - including its attachments - may contain proprietary, confidential and/or legally protected information and is intended solely for the use of the designated addressee(s) above. If you are not the intended recipient be aware that any downloading, copying, disclosure, distribution or use of the contents of the above information is strictly prohibited. If you have received this communication by mistake, please forward the message back to the sender at the email address above, delete the message from all mailboxes and any other electronic storage medium and destroy all copies. Disclaimer Notice: Internet communications cannot be guaranteed to be safe or error-free. Therefore we do not assure that this message is complete or accurate and we do not accept liability for any errors or omissions in the contents of this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 13538 bytes Desc: image003.png URL: From rt at openssl.org Thu Dec 3 12:54:59 2015 From: rt at openssl.org (Srinivas Koripella via RT) Date: Thu, 03 Dec 2015 12:54:59 +0000 Subject: [openssl-dev] [openssl.org #4163] Possible Issues with Null Dereferences in s3_enc.c In-Reply-To: References: Message-ID: Hello all, We found out two issues in s3_enc.c causing null dereferences. Kindly note that in both the cases malloc returned NULL causing these crashes. Issue 1) In function ssl3_init_finished_mac, we try to allocate s->s3->handshake_buffer but there is no check on whether we succeeded or not. If we fail here, we later dereference null in the below codepath causing crashes. Note that although we panic by dereferencing s->s3->handshake_dgst the actual cause is that this is being caused by s->s3->handshake_buffer being null as at this point during handshake only s->s3->handshake_buffer is allocated. s->s3->handshake_dgst is allocated later and is expected to be NULL here. The fix is to propogate the alloc failure upwards so we return error in the initial handshake path. backtrace: #0 0x00000000013a86c9 in ssl3_finish_mac (s=0x825100a0, buf=0xf3fc8535 "\001", len=98) at ../../../../../../src/crypto/openssl/ssl/s3_enc.c:599 #1 0x000000000139ff56 in ssl23_client_hello (s=) at ../../../../../../src/crypto/openssl/ssl/s23_clnt.c:585 #2 ssl23_connect (s=0x825100a0) at ../../../../../../src/crypto/openssl/ssl/s23_clnt.c:218 Issue 2) In ssl3_digest_cached_records we are calling EVP_MD_CTX_create to allocate individual MD_CTX. However, there is no check to see if the allocation succeeds or not. If the allocation fails, we dereference null subsequently in the call to EVP_DigestInit_ex. Srinivas -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Dec 3 13:36:38 2015 From: rt at openssl.org (Leonidas Da Silva Barbosa via RT) Date: Thu, 03 Dec 2015 13:36:38 +0000 Subject: [openssl-dev] [openssl.org #4162] [PATCH] Removing vrsave load and store In-Reply-To: <20151203133617.GA7347@bluepex.com> References: <20151130181406.GA14203@bluepex.com> <565D6277.7070100@openssl.org> <565EB1BD.2040600@openssl.org> <20151203133617.GA7347@bluepex.com> Message-ID: > Question is if the condition for $no_vrsave assignment is proper. Or > rather if it should be /aix|linux64/. As I couldn't see that big-endian > Linux I have access to uses ELF ABI V2, I've settled for /aix|linux64le/. I saw you already applied your patch. I'll test it againts a BE machine too, and if is the case update ppc-xlate with linux64/ only. BTW: We have a minicloud [1] with P8 systems that is open for external users, unfortunatly it is offline backing tomorrow, Do you already know about it? [1] http://openpower.ic.unicamp.br/minicloud/index.html Thanks!! From rt at openssl.org Thu Dec 3 14:04:25 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 03 Dec 2015 14:04:25 +0000 Subject: [openssl-dev] [openssl.org #4162] [PATCH] Removing vrsave load and store In-Reply-To: <56604C2E.1010106@openssl.org> References: <20151130181406.GA14203@bluepex.com> <565D6277.7070100@openssl.org> <565EB1BD.2040600@openssl.org> <20151203133617.GA7347@bluepex.com> <56604C2E.1010106@openssl.org> Message-ID: Hi, >> Question is if the condition for $no_vrsave assignment is proper. Or >> rather if it should be /aix|linux64/. As I couldn't see that big-endian >> Linux I have access to uses ELF ABI V2, I've settled for /aix|linux64le/. > I saw you already applied your patch. I apologize for not waiting for feedback. It's kind of a timing issue. I mean release is upcoming and ABI compliance is arguably important enough to set aside dialogue a little bit. > I'll test it againts a BE machine > too, and if is the case update ppc-xlate with linux64/ only. I've tested it on big-endian Linux, AIX and MacOS X. I know for sure that vrsave is required on MacOS X. I didn't find any evidence that big-endian Linux system I have access to (recent Fedora) uses ABI V2 and had no choice but to draw conclusion that it is version 1.9 that still applies, which requires vrsave. Then I found reference that AIX ABI specifies vrsave as reserved. Hence /aix|linux64le/. If it turns out that there are big-endian systems that use V2, then it might be appropriate to introduce additional $flavour to denote such systems, as opposite to assuming that all of them are V2 that is. > BTW: We have a minicloud [1] with P8 systems that is open for external users, unfortunatly it is > offline backing tomorrow, Do you already know about it? No. Thanks for the tip. From openssl at openssl.org Thu Dec 3 15:51:37 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 3 Dec 2015 15:51:37 +0000 Subject: [openssl-dev] OpenSSL version 0.9.8zh released Message-ID: <20151203155137.GA29017@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 0.9.8zh released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8zh of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-0.9.8-notes.html OpenSSL 0.9.8zh is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-0.9.8zh.tar.gz Size: 3817665 MD5 checksum: c00f014c64dfac1ec40dc7459d9673e6 SHA1 checksum: 77cc99e7c83794a212bc7b047480d8288addf9df SHA256 checksum: ea1a43a47900b90e014360572d752f85617fb119fa048800872c1b37db04fad3 The checksums were calculated using the following commands: openssl md5 openssl-0.9.8zh.tar.gz openssl sha1 openssl-0.9.8zh.tar.gz openssl sha256 openssl-0.9.8zh.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWYFkEAAoJENnE0m0OYESRs8MIAJNsinLBj9zDUwXMMO7f289r oOfwzhCsnjdNb40N5/j6EEiqYC3TwuFBEm6BD59Jr8R7GaUthpFoc8isIAMu+xYS rNFCneu8cM4vX23Wefg7e9MC0RAOG2GTlYmmbxDUXQUv3z+LX/DNc1rxCcOPbnf1 1TQdAiXBpU14kXNuauFbxj9y2mHslkmaiE/4riaQZKgMOU9oJKbMH/aDGHZjmzaf AEeLV0i51JxjUQ3aLvOYZnn+fSxPTJDkv3U3n2+sUYfPwqxTp365VKJ240YbjIx+ llYgloiU1chJo09hBBp+HavaBNcB1uorvsRCKo1PDYxQt4qeFirfM3VNJ1fESug= =Q6ea -----END PGP SIGNATURE----- From openssl at openssl.org Thu Dec 3 15:52:17 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 3 Dec 2015 15:52:17 +0000 Subject: [openssl-dev] OpenSSL version 1.0.0t released Message-ID: <20151203155217.GA29510@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.0t released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.0t of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.0-notes.html OpenSSL 1.0.0t is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.0t.tar.gz Size: 4091806 MD5 checksum: 62f5f2127c9bdd3d2768c78c8306039e SHA1 checksum: 949ecd8aa821b0cc5fde12862e4dde33c0320682 SHA256 checksum: 7ce1c3cab7a33bf494330074f70039a10856a972f6b8c430ef4b73db844bde50 The checksums were calculated using the following commands: openssl md5 openssl-1.0.0t.tar.gz openssl sha1 openssl-1.0.0t.tar.gz openssl sha256 openssl-1.0.0t.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWYFgZAAoJENnE0m0OYESRXuEH/iRgWMcdta23AqUGiPEhBZs0 GWj9VY85g0477EsWqS2wz+kYlnIcbXLGnt1IlPvuXv++VboAyhAyGVpqGMyvka8q pxLxUM7wDdUpdSCV/+wKrbF1nmZCYIhQFdbLHwGKw195+vWM/PlDUGpKTBfrZECf HaBF4FsrRnGew4ZIORyvJSD49/Qc8GCygR5ZB3+cGguCjo/+pCRgAA75DeTxbkjb hf7xZ/8umZZdBgE+ZsPu5+aM8pMKsTc42bv4cPqqwGvygEJPWyMEL16rkomOVshe m6vXPLFYcNNkd4JEUWpZRMQEelpw8/kKSu8ZGNZ3G3RW4EJipMuN7nxUSEmVvfE= =6tot -----END PGP SIGNATURE----- From openssl at openssl.org Thu Dec 3 15:53:30 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 3 Dec 2015 15:53:30 +0000 Subject: [openssl-dev] OpenSSL version 1.0.1q released Message-ID: <20151203155330.GA30297@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.1q released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.1q of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.1-notes.html OpenSSL 1.0.1q is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.1q.tar.gz Size: 4548189 MD5 checksum: d1221e2f88085b0953670779656b452f SHA1 checksum: 8f390cd667f87d9c393464ff91d42df89a6df3ac SHA256 checksum: 68f3b2f0f1e8da770f89c38eadf7e6c4dbf690fd4bb648f651addd3b92a9ddf1 The checksums were calculated using the following commands: openssl md5 openssl-1.0.1q.tar.gz openssl sha1 openssl-1.0.1q.tar.gz openssl sha256 openssl-1.0.1q.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWYFa1AAoJENnE0m0OYESRUnQIAKtEW4xb1nGTdJmGCevAQIS7 GjmIIJsIpKhNGx7j2Cm02F0HFKG6IQOy4gLcl84eNkxkgAnc6D4/H4MroFQQe7/x P9jrWjNqXNtoHKm8OdMUKVFDpzv0AGbVz/3r0XRCPS/zxj5ig8bq7IirrcWx137N /mLgm0OIuNnL99GBSSjUdji4aW50GwCYFZBtr85CdhKU5EMg6hQld6q72VbBBoBi cTRgRnTvl/s1dxqi7DTMTyUXglcYNvm+/QYBKNK10IMXuhhu20MIwUNIy9WVgkCo +bRkdNhHE7A1RklSEQyOCoJXkElTdXDwTElSlYhCdhcgRSX2eM63rOvwm9Zp45s= =9n6L -----END PGP SIGNATURE----- From openssl at openssl.org Thu Dec 3 15:53:46 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 3 Dec 2015 15:53:46 +0000 Subject: [openssl-dev] OpenSSL version 1.0.2e released Message-ID: <20151203155346.GA30466@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.2e released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2e of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2e is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2e.tar.gz Size: 5255719 MD5 checksum: 2218c1a6f807f7206c11eb3ee3a5ec80 SHA1 checksum: fa4d6e94084e80478d4a7749b97d955e89f04ec2 SHA256 checksum: eee11def03647aa2267434a779608af6fca645023c9a194ddb82f14426835537 The checksums were calculated using the following commands: openssl md5 openssl-1.0.2e.tar.gz openssl sha1 openssl-1.0.2e.tar.gz openssl sha256 openssl-1.0.2e.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWYFVTAAoJENnE0m0OYESR+VYIAJjA5F9echoXC39pYUw1SmdT DIy2ExFbfXsWJXhoRA2H/OImo9rWxo715BGvkHSNWHZQxXaisFUkB3OLuU0BwGRR U5yUbQDSFIBXH0p2OXKburS7LhzI61SFSirQb4jiRnkohidC9crxl2VDGbeP7yhe M6d1AHwkZp7pnAC8RG3RpzP5sU2oMHPnWTMajAQNZpnrcY0sN4QcW5Ko7kPCHRNv mCUdc1fu2R99HWpky6pySVu5efheGxGDk+W+rjNYDzb1RuFdWStBZTbfEFGI7+ER O63SPMm7bqAkIpfopRsLNpjlHcLpx5C15tj9QQUlTTlTOORq7ZDTFFipY1aYpok= =cM6W -----END PGP SIGNATURE----- From openssl at openssl.org Thu Dec 3 15:57:34 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 3 Dec 2015 15:57:34 +0000 Subject: [openssl-dev] OpenSSL Security Advisory Message-ID: <20151203155734.GA493@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL Security Advisory [3 Dec 2015] ======================================= NOTE: WE ANTICIPATE THAT 1.0.0t AND 0.9.8zh WILL BE THE LAST RELEASES FOR THE 0.9.8 AND 1.0.0 VERSIONS AND THAT NO MORE SECURITY FIXES WILL BE PROVIDED (AS PER PREVIOUS ANNOUNCEMENTS). USERS ARE ADVISED TO UPGRADE TO LATER VERSIONS. BN_mod_exp may produce incorrect results on x86_64 (CVE-2015-3193) ================================================================== Severity: Moderate There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. For example this can occur by default in OpenSSL DHE based SSL/TLS ciphersuites. This issue affects OpenSSL version 1.0.2. OpenSSL 1.0.2 users should upgrade to 1.0.2e This issue was reported to OpenSSL on August 13 2015 by Hanno B??ck. The fix was developed by Andy Polyakov of the OpenSSL development team. Certificate verify crash with missing PSS parameter (CVE-2015-3194) =================================================================== Severity: Moderate The signature verification routines will crash with a NULL pointer dereference if presented with an ASN.1 signature using the RSA PSS algorithm and absent mask generation function parameter. Since these routines are used to verify certificate signature algorithms this can be used to crash any certificate verification operation and exploited in a DoS attack. Any application which performs certificate verification is vulnerable including OpenSSL clients and servers which enable client authentication. This issue affects OpenSSL versions 1.0.2 and 1.0.1. OpenSSL 1.0.2 users should upgrade to 1.0.2e OpenSSL 1.0.1 users should upgrade to 1.0.1q This issue was reported to OpenSSL on August 27 2015 by Lo??c Jonas Etienne (Qnective AG). The fix was developed by Dr. Stephen Henson of the OpenSSL development team. X509_ATTRIBUTE memory leak (CVE-2015-3195) ========================================== Severity: Moderate When presented with a malformed X509_ATTRIBUTE structure OpenSSL will leak memory. This structure is used by the PKCS#7 and CMS routines so any application which reads PKCS#7 or CMS data from untrusted sources is affected. SSL/TLS is not affected. This issue affects OpenSSL versions 1.0.2 and 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2e OpenSSL 1.0.1 users should upgrade to 1.0.1q OpenSSL 1.0.0 users should upgrade to 1.0.0t OpenSSL 0.9.8 users should upgrade to 0.9.8zh This issue was reported to OpenSSL on November 9 2015 by Adam Langley (Google/BoringSSL) using libFuzzer. The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Race condition handling PSK identify hint (CVE-2015-3196) ========================================================= Severity: Low If PSK identity hints are received by a multi-threaded client then the values are wrongly updated in the parent SSL_CTX structure. This can result in a race condition potentially leading to a double free of the identify hint data. This issue was fixed in OpenSSL 1.0.2d and 1.0.1p but has not been previously listed in an OpenSSL security advisory. This issue also affects OpenSSL 1.0.0 and has not been previously fixed in an OpenSSL 1.0.0 release. OpenSSL 1.0.2 users should upgrade to 1.0.2d OpenSSL 1.0.1 users should upgrade to 1.0.1p OpenSSL 1.0.0 users should upgrade to 1.0.0t The fix for this issue can be identified in the OpenSSL git repository by commit ids 3c66a669dfc7 (1.0.2), d6be3124f228 (1.0.1) and 1392c238657e (1.0.0). The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Note ==== As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these versions will be provided after that date. In the absence of significant security issues being identified prior to that date, the 1.0.0t and 0.9.8zh releases will be the last for those versions. Users of these versions are advised to upgrade. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20151203.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWYFodAAoJENnE0m0OYESRWZwIALI/Vd1a4QJVCbwkmkx76fUw DguuYXXk6+w59Ie39xA5PN/YJ3PygbIeS/WbFSeZTTlMFyiNMn/B5WSD6Uyfmsm0 pqiyRZZonSXcK7m89D3SaCRw86rAN9K5aVuCM6YQly1A+cuvwhnRJwNVIfzzFYRH 7eWKv8eBBZ+013FQxeiDgNZRPPR69HnHVS3029LXuTuvqqb54TB83ekB6R97eFY5 MoYNzbPrnyRrkDVrcRuAZyblbTUT1jkfrhl+V5f6jtvuAvpbawIk1riwMplIp4Dj mymP7epl5JUfUkdAjXSdOULBL4ps3I7r64JznI5njs+96i4SpcWuDi1mFfzpoLE= =6qxq -----END PGP SIGNATURE----- From rt at openssl.org Thu Dec 3 16:28:06 2015 From: rt at openssl.org (Ake, Earle F via RT) Date: Thu, 03 Dec 2015 16:28:06 +0000 Subject: [openssl-dev] [openssl.org #4164] bctest and pod2mantest missing in openssl-1.0.2e In-Reply-To: References: Message-ID: I compiled and was trying to test the new OpenSSL and found the file test/bctest was missing. I copied from openssl-1.0.2d and it worked fine. May want to add that to the distribution. I also found when trying to install, the file util/pod2mantest was also missing. I also copied that from the previous release to make this install work. Earle Ake, Technology Engineer 11450 Grooms Road | Cincinnati, Ohio 45242 | Office 513.387.7057 ------------------------------------------------------------------------------------------- KROGER TECHNOLOGY CUSTOMER | QUALITY | INNOVATION ________________________________ This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From matt at openssl.org Thu Dec 3 18:53:21 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 3 Dec 2015 18:53:21 +0000 Subject: [openssl-dev] OpenSSL version 1.0.2e released (corrected download) Message-ID: <56608FA1.2080403@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Due to an error in the release process the original distribution downloads were failing to build. New downloads have now been made available on the website. Corrected checksums are given below. OpenSSL version 1.0.2e released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2e of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2e is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2e.tar.gz Size: 5256555 MD5 checksum: 5262bfa25b60ed9de9f28d5d52d77fc5 SHA1 checksum: 2c5691496761cb18f98476eefa4d35c835448fb6 SHA256 checksum: e23ccafdb75cfcde782da0151731aa2185195ac745eea3846133f2e05c0e0bff The checksums were calculated using the following commands: openssl md5 openssl-1.0.2e.tar.gz openssl sha1 openssl-1.0.2e.tar.gz openssl sha256 openssl-1.0.2e.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWYI+hAAoJENnE0m0OYESRdz8IALIWuYoQnsCnwISeaIDuKMqj VDYdPtJRHz3dLXIal6tHtuqPP/NAq+EY+7WMCufUiCLJaVLOm5baw/G69ksF7RMd yeaLsBw7Lq4B/glSFXfPopi2rY6zmhQV6/DdGQ/BvCH9Z38nH8ZR/GTYR546XN7o GLWyHwe18HEUoRQok7UbGopC2iZPMDah0V7KB3q1fHIOIfeVstw33khNMBBZ7O8R m4SsUyJ1tVgpSv2UB1L2rkxuKPfCYBrS+7sw8ZH2kyNMVeAuHPxcG9LKoDCMSii5 00b0XcIC7MoOXeTmXK93N7NDRRYhKfeJYCSwBBBAshJrGtj27avAZR4jB5PpdsU= =JPLJ -----END PGP SIGNATURE----- From matt at openssl.org Thu Dec 3 18:57:34 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 3 Dec 2015 18:57:34 +0000 Subject: [openssl-dev] OpenSSL version 1.0.1q released (corrected download) Message-ID: <5660909E.8090403@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Due to an error in the release process the original distribution downloads were failing to build. New downloads have now been made available on the website. Corrected checksums are given below. OpenSSL version 1.0.1q released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.1q of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.1-notes.html OpenSSL 1.0.1q is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.1q.tar.gz Size: 4549898 MD5 checksum: 54538d0cdcb912f9bc2b36268388205e SHA1 checksum: c65a7bec49b72092d7ebb97a263c496cc1e1d6af SHA256 checksum: b3658b84e9ea606a5ded3c972a5517cd785282e7ea86b20c78aa4b773a047fb7 The checksums were calculated using the following commands: openssl md5 openssl-1.0.1q.tar.gz openssl sha1 openssl-1.0.1q.tar.gz openssl sha256 openssl-1.0.1q.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWYJCeAAoJENnE0m0OYESRQqsIAL/W3CN6X1Lm5cySm0ludaxX 7GZTIIjQjoPLu5UFhgHb0MlYFxvU2CgeahpR8wCFI/s10/enGs7bD54chlBJMqZC C+7+QWq6oY45f2Jnb5toGWK7jkWSW6ASkwTfvK086D+XlIGwgokI1cy3nL+UhdVl YHPb5hoR51l6rMQBB3uR1k2SXp3CEanMnJ1vL81gY05gPkc8qGfFaDj7JrteyOcB o+vwqaGg/J6VIPQIlxC46xeANAg6H3uDXHHjbOYyGHdNRhkQHaFx7c85dIHv8WJ5 J1XXcEmAae4Th+LCQkSu7IKr4Qezr0sw2xMnRgne7oytgYQpyY4xbkTdBFoFtTA= =2dkv -----END PGP SIGNATURE----- From matt at openssl.org Thu Dec 3 19:00:51 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 3 Dec 2015 19:00:51 +0000 Subject: [openssl-dev] OpenSSL version 1.0.0t released (corrected download) Message-ID: <56609163.2070501@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Due to an error in the release process the original distribution downloads were failing to build. New downloads have now been made available on the website. Corrected checksums are given below. OpenSSL version 1.0.0t released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.0t of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.0-notes.html OpenSSL 1.0.0t is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.0t.tar.gz Size: 4092302 MD5 checksum: 7b7e9f6039a97e4a453b596055912435 SHA1 checksum: ab41cb253405a974063392063a034951a30076e9 SHA256 checksum: 5ab6e348c6c2a95d457e7a00e0aa653bfc7eb4df7b24e7c9ab63163ac0299097 The checksums were calculated using the following commands: openssl md5 openssl-1.0.0t.tar.gz openssl sha1 openssl-1.0.0t.tar.gz openssl sha256 openssl-1.0.0t.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWYJFjAAoJENnE0m0OYESR1d8H/3j6OADtQxQY6bLoQ6Nv65OM oztdsyGQz9hU7ttWwaFi/n2h0sC71fRsEVPR2UkewwnCnX4+VyduVZMg+fhMBP5d TyxN7fbNKfRZD7kus3odVIjUrJX/Rp0LdG5+5hc3fPlnvLJ/QSb+jAVZJy6HWLEO 4M5yJOvcPFaiWEuoVnIEhUuJ5K9xfKNk8nwURkA/aiFi88NgI1d/NZ10SX8IjyGV 1Znfe6ck2c09zA09iKLngmbXWDBwXMzFnvtBdk9Xni/Usn1m/fEkf0LehRVy8cKp woVKGUcWKEGt85l6RitjFXkNmMrPuimRiBYoajFQ7JNTPYbUaqh+xtnowSemTbc= =ygoc -----END PGP SIGNATURE----- From matt at openssl.org Thu Dec 3 19:03:57 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 3 Dec 2015 19:03:57 +0000 Subject: [openssl-dev] OpenSSL version 0.9.8zh released (corrected download) Message-ID: <5660921D.2000303@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Due to an error in the release process the original distribution downloads were failing to build. New downloads have now been made available on the website. Corrected checksums are given below. OpenSSL version 0.9.8zh released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8zh of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-0.9.8-notes.html OpenSSL 0.9.8zh is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-0.9.8zh.tar.gz Size: 3818524 MD5 checksum: c813c065dd53d7bd0a560a870ddd0af5 SHA1 checksum: 3ff71636bea85a99f4d76a10d119c09bda0421e3 SHA256 checksum: f1d9f3ed1b85a82ecf80d0e2d389e1fda3fca9a4dba0bf07adbf231e1a5e2fd6 The checksums were calculated using the following commands: openssl md5 openssl-0.9.8zh.tar.gz openssl sha1 openssl-0.9.8zh.tar.gz openssl sha256 openssl-0.9.8zh.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWYJIdAAoJENnE0m0OYESR2LoH/j+PPvqiLnh1AgcXMFXlJ+2L 1GxJXVhUVW/d6ws6P1u0ogvX8/W6VCtiWHEcP08zhzQKoQNrga6EvxYlSNQgE80s z+GTC1fI2F8gnz9my1s4IowKQOCumSUKU39YhhZ+JpicbThj3tTE3eC07mnJtHYK bCl3Ec6Q4K5HRq7KxHRFLPwD7Mt3gJ4SCMLgRLT/Q/kbHdV20luMFqS6YsI0tdpB mPBZYeNrU0n8OtRS4aXu8O0+iYHN6xsnaLhGNGVtqkbb9cy3GFcU7clP990D67Td R6XHEae4hA0gxsI91/ARfkRsbwr3HToOmjqasmYWdzS9YfULtyXCvHGwPYJv8O8= =ps/C -----END PGP SIGNATURE----- From quanah at zimbra.com Thu Dec 3 19:10:50 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Thu, 03 Dec 2015 11:10:50 -0800 Subject: [openssl-dev] OpenSSL version 1.0.1q released (corrected download) In-Reply-To: <5660909E.8090403@openssl.org> References: <5660909E.8090403@openssl.org> Message-ID: <6F239AC30CB0CC9CF9D0F7F4@[192.168.1.9]> This build is still busted: build at u1290:~/p4/zimbra/main/ThirdParty/openssl/src$ md5sum openssl-1.0.1q.tar.gz 54538d0cdcb912f9bc2b36268388205e openssl-1.0.1q.tar.gz make[5]: Entering directory `/home/build/p4/zimbra/main/ThirdParty/openssl/tmp/UBUNTU12_64/zimbra-openssl/crypto/evp' gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -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 -D_FORTIFY_SOURCE=2 -c -o encode.o encode.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -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 -D_FORTIFY_SOURCE=2 -c -o digest.o digest.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -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 -D_FORTIFY_SOURCE=2 -c -o evp_enc.o evp_enc.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -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 -D_FORTIFY_SOURCE=2 -c -o evp_key.o evp_key.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -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 -D_FORTIFY_SOURCE=2 -c -o evp_acnf.o evp_acnf.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -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 -D_FORTIFY_SOURCE=2 -c -o evp_cnf.o evp_cnf.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -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 -D_FORTIFY_SOURCE=2 -c -o e_des.o e_des.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -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 -D_FORTIFY_SOURCE=2 -c -o e_bf.o e_bf.c make[5]: *** No rule to make target `../../include/openssl/idea.h', needed by `e_idea.o'. Stop. --Quanah --On Thursday, December 03, 2015 6:57 PM +0000 Matt Caswell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Due to an error in the release process the original distribution > downloads were failing to build. New downloads have now been made > available on the website. Corrected checksums are given below. > > OpenSSL version 1.0.1q released > =============================== > > OpenSSL - The Open Source toolkit for SSL/TLS > http://www.openssl.org/ > > The OpenSSL project team is pleased to announce the release of > version 1.0.1q of our open source toolkit for SSL/TLS. For details > of changes and known issues see the release notes at: > > http://www.openssl.org/news/openssl-1.0.1-notes.html > > OpenSSL 1.0.1q is available for download via HTTP and FTP from the > following master locations (you can find the various FTP mirrors > under > http://www.openssl.org/source/mirror.html): > > * http://www.openssl.org/source/ > * ftp://ftp.openssl.org/source/ > > The distribution file name is: > > o openssl-1.0.1q.tar.gz > Size: 4549898 > MD5 checksum: 54538d0cdcb912f9bc2b36268388205e > SHA1 checksum: c65a7bec49b72092d7ebb97a263c496cc1e1d6af > SHA256 checksum: > b3658b84e9ea606a5ded3c972a5517cd785282e7ea86b20c78aa4b773a047fb7 > > The checksums were calculated using the following commands: > > openssl md5 openssl-1.0.1q.tar.gz > openssl sha1 openssl-1.0.1q.tar.gz > openssl sha256 openssl-1.0.1q.tar.gz > > Yours, > > The OpenSSL Project Team. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJWYJCeAAoJENnE0m0OYESRQqsIAL/W3CN6X1Lm5cySm0ludaxX > 7GZTIIjQjoPLu5UFhgHb0MlYFxvU2CgeahpR8wCFI/s10/enGs7bD54chlBJMqZC > C+7+QWq6oY45f2Jnb5toGWK7jkWSW6ASkwTfvK086D+XlIGwgokI1cy3nL+UhdVl > YHPb5hoR51l6rMQBB3uR1k2SXp3CEanMnJ1vL81gY05gPkc8qGfFaDj7JrteyOcB > o+vwqaGg/J6VIPQIlxC46xeANAg6H3uDXHHjbOYyGHdNRhkQHaFx7c85dIHv8WJ5 > J1XXcEmAae4Th+LCQkSu7IKr4Qezr0sw2xMnRgne7oytgYQpyY4xbkTdBFoFtTA= > =2dkv > -----END PGP SIGNATURE----- > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From matt at openssl.org Thu Dec 3 19:18:43 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 3 Dec 2015 19:18:43 +0000 Subject: [openssl-dev] OpenSSL version 1.0.1q released (corrected download) In-Reply-To: <6F239AC30CB0CC9CF9D0F7F4@[192.168.1.9]> References: <5660909E.8090403@openssl.org> <6F239AC30CB0CC9CF9D0F7F4@[192.168.1.9]> Message-ID: <56609593.2000400@openssl.org> On 03/12/15 19:10, Quanah Gibson-Mount wrote: > make[5]: *** No rule to make target `../../include/openssl/idea.h', > needed by `e_idea.o'. Stop. Hmmm. I don't get that. Can you post your build steps? Matt From quanah at zimbra.com Thu Dec 3 19:28:06 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Thu, 03 Dec 2015 11:28:06 -0800 Subject: [openssl-dev] OpenSSL version 1.0.1q released (corrected download) In-Reply-To: <56609593.2000400@openssl.org> References: <5660909E.8090403@openssl.org> <6F239AC30CB0CC9CF9D0F7F4@[192.168.1.9]> <56609593.2000400@openssl.org> Message-ID: <20F1FE9F9E9E4CE2A80B1AA1@[192.168.1.9]> --On Thursday, December 03, 2015 7:18 PM +0000 Matt Caswell wrote: > > > On 03/12/15 19:10, Quanah Gibson-Mount wrote: >> make[5]: *** No rule to make target `../../include/openssl/idea.h', >> needed by `e_idea.o'. Stop. > > Hmmm. I don't get that. Can you post your build steps? Configure is: ./Configure no-idea enable-ec_nistp_64_gcc_128 no-mdc2 no-rc5 no-ssl2 \ no-hw --prefix=/opt/zimbra/common --libdir=lib --openssldir=/opt/zimbra/common/etc/ssl \ shared linux-x86_64 -g -O2 -DOPENSSL_NO_HEARTBEATS then: LD_RUN_PATH=/opt/zimbra/common/lib make I only see it on Ubuntu12 & Ubuntu14. It works fine on RHEL6/RHEL7 with the same Configure parameters. I see one difference, in that on RHEL, we're running make depend before running make all. After adding "make depend" to occur before "make all", it now succeeds. However, this worked on prior releases, so it seems that requiring "make depend" is new to 1.0.1q. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From quanah at zimbra.com Thu Dec 3 19:59:55 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Thu, 03 Dec 2015 11:59:55 -0800 Subject: [openssl-dev] OpenSSL version 1.0.1q released (corrected download) In-Reply-To: <20F1FE9F9E9E4CE2A80B1AA1@[192.168.1.9]> References: <5660909E.8090403@openssl.org> <6F239AC30CB0CC9CF9D0F7F4@[192.168.1.9]> <56609593.2000400@openssl.org> <20F1FE9F9E9E4CE2A80B1AA1@[192.168.1.9]> Message-ID: --On Thursday, December 03, 2015 11:28 AM -0800 Quanah Gibson-Mount wrote: > After adding "make depend" to occur before "make all", it now succeeds. > However, this worked on prior releases, so it seems that requiring "make > depend" is new to 1.0.1q. Filed this via RT this AM, but it hasn't shown up since it's waiting on moderation. Also filed as --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From rt at openssl.org Thu Dec 3 20:08:59 2015 From: rt at openssl.org (Quanah Gibson-Mount via RT) Date: Thu, 03 Dec 2015 20:08:59 +0000 Subject: [openssl-dev] [openssl.org #4165] 1.0.1q release busted, does not compile In-Reply-To: <4563EA1819BE84DB34CB1EEB@[192.168.1.9]> References: <4563EA1819BE84DB34CB1EEB@[192.168.1.9]> Message-ID: make[5]: Leaving directory `/home/build/p4/zimbra/main/ThirdParty/openssl/tmp/UBUNTU14_64/zimbra-openssl/crypto/err' making all in crypto/evp... make[5]: Entering directory `/home/build/p4/zimbra/main/ThirdParty/openssl/tmp/UBUNTU14_64/zimbra-openssl/crypto/evp' gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -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 -D_FORTIFY_SOURCE=2 -c -o encode.o encode.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -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 -D_FORTIFY_SOURCE=2 -c -o digest.o digest.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -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 -D_FORTIFY_SOURCE=2 -c -o evp_enc.o evp_enc.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -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 -D_FORTIFY_SOURCE=2 -c -o evp_key.o evp_key.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -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 -D_FORTIFY_SOURCE=2 -c -o evp_acnf.o evp_acnf.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -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 -D_FORTIFY_SOURCE=2 -c -o evp_cnf.o evp_cnf.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -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 -D_FORTIFY_SOURCE=2 -c -o e_des.o e_des.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -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 -D_FORTIFY_SOURCE=2 -c -o e_bf.o e_bf.c make[5]: *** No rule to make target `../../include/openssl/idea.h', needed by `e_idea.o'. Stop. -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Dec 3 20:09:59 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 03 Dec 2015 20:09:59 +0000 Subject: [openssl-dev] [openssl.org #4165] 1.0.1q release busted, does not compile In-Reply-To: <2d811d80bca54e5f89876b6b70658f4c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <4563EA1819BE84DB34CB1EEB@[192.168.1.9]> <2d811d80bca54e5f89876b6b70658f4c@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Also see as https://github.com/openssl/openssl/issues/492 From quanah at zimbra.com Thu Dec 3 20:30:20 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Thu, 03 Dec 2015 12:30:20 -0800 Subject: [openssl-dev] deadlock issue with OpenSSL 1.0.1j In-Reply-To: <22BAFCF8B929B9A55F527DCF@[192.168.1.9]> References: <22BAFCF8B929B9A55F527DCF@[192.168.1.9]> Message-ID: --On Monday, May 18, 2015 3:32 PM -0700 Quanah Gibson-Mount wrote: > We've been seeing a problem with openssl deadlocking in the 1.0.1j > release that didn't occur in previous releases. I've looked over the > change log fixes for the k, l, and m releases, but I haven't seen > anything that appears to resolve a deadlock problem. Does anyone know of > such an issue that was released since 1.0.1j? Looks like this actually had to do with using a new module in OpenLDAP that had incorrect symbol names that caused classes with various TLS modules. This was fixed in OpenLDAP 2.4.43 () --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From quanah at zimbra.com Thu Dec 3 20:31:49 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Thu, 03 Dec 2015 12:31:49 -0800 Subject: [openssl-dev] deadlock issue with OpenSSL 1.0.1j In-Reply-To: References: <22BAFCF8B929B9A55F527DCF@[192.168.1.9]> Message-ID: <3E7D93A555043F0BFDE341E1@[192.168.1.9]> --On Thursday, December 03, 2015 12:30 PM -0800 Quanah Gibson-Mount wrote: > --On Monday, May 18, 2015 3:32 PM -0700 Quanah Gibson-Mount > wrote: > >> We've been seeing a problem with openssl deadlocking in the 1.0.1j >> release that didn't occur in previous releases. I've looked over the >> change log fixes for the k, l, and m releases, but I haven't seen >> anything that appears to resolve a deadlock problem. Does anyone know of >> such an issue that was released since 1.0.1j? > > Looks like this actually had to do with using a new module in OpenLDAP > that had incorrect symbol names that caused classes with various TLS > modules. This was fixed in OpenLDAP 2.4.43 > () s/classes/clashes/ ;) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From matt at openssl.org Thu Dec 3 20:51:57 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 3 Dec 2015 20:51:57 +0000 Subject: [openssl-dev] OpenSSL version 1.0.1q released (corrected download) In-Reply-To: <20F1FE9F9E9E4CE2A80B1AA1@[192.168.1.9]> References: <5660909E.8090403@openssl.org> <6F239AC30CB0CC9CF9D0F7F4@[192.168.1.9]> <56609593.2000400@openssl.org> <20F1FE9F9E9E4CE2A80B1AA1@[192.168.1.9]> Message-ID: <5660AB6D.2040705@openssl.org> On 03/12/15 19:28, Quanah Gibson-Mount wrote: > --On Thursday, December 03, 2015 7:18 PM +0000 Matt Caswell > wrote: > >> >> >> On 03/12/15 19:10, Quanah Gibson-Mount wrote: >>> make[5]: *** No rule to make target `../../include/openssl/idea.h', >>> needed by `e_idea.o'. Stop. >> >> Hmmm. I don't get that. Can you post your build steps? > > Configure is: > > ./Configure no-idea enable-ec_nistp_64_gcc_128 no-mdc2 no-rc5 > no-ssl2 \ > no-hw --prefix=/opt/zimbra/common --libdir=lib > --openssldir=/opt/zimbra/common/etc/ssl \ > shared linux-x86_64 -g -O2 -DOPENSSL_NO_HEARTBEATS > > then: > > LD_RUN_PATH=/opt/zimbra/common/lib make > > I only see it on Ubuntu12 & Ubuntu14. It works fine on RHEL6/RHEL7 with > the same Configure parameters. I see one difference, in that on RHEL, > we're running make depend before running make all. > > After adding "make depend" to occur before "make all", it now succeeds. > However, this worked on prior releases, so it seems that requiring "make > depend" is new to 1.0.1q. Well the end of your output from Configure should look like this (even on 1.0.1p): Since you've disabled or enabled at least one algorithm, you need to do the following before building: make depend Configured for linux-x86_64. So it does explicitly tell you to run "make depend". I'm not sure I'd call it a regression that you got away with it before!! Matt From quanah at zimbra.com Thu Dec 3 20:55:27 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Thu, 03 Dec 2015 12:55:27 -0800 Subject: [openssl-dev] OpenSSL version 1.0.1q released (corrected download) In-Reply-To: <5660AB6D.2040705@openssl.org> References: <5660909E.8090403@openssl.org> <6F239AC30CB0CC9CF9D0F7F4@[192.168.1.9]> <56609593.2000400@openssl.org> <20F1FE9F9E9E4CE2A80B1AA1@[192.168.1.9]> <5660AB6D.2040705@openssl.org> Message-ID: <562E20E2DFFF2FB44983815A@[192.168.1.9]> --On Thursday, December 03, 2015 8:51 PM +0000 Matt Caswell wrote: > So it does explicitly tell you to run "make depend". I'm not sure I'd > call it a regression that you got away with it before!! I would say it is a regression because it worked for all prior 1.0.1[a-p], and all the releases of 1.0.0 and 0.9.8 that I used prior to moving to the 1.0.1 series. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From nico at cryptonector.com Thu Dec 3 21:05:25 2015 From: nico at cryptonector.com (Nico Williams) Date: Thu, 3 Dec 2015 15:05:25 -0600 Subject: [openssl-dev] Review of PR #451 (thread-safety / builtin locks) Message-ID: <20151203210524.GD23318@localhost> Hi. Below are my high-level comments about this PR. Of course, first, thanks for doing this work; I hope you see it through! Comments: - If support for systems older than Vista is needed, then you'll need an implementation of InitOnceExecuteOnce(). I can point at suitable implementations if need be. E.g., https://github.com/heimdal/heimdal/blob/master/lib/base/heimbase.c#L406 (Should be easy to massage into exactly InitOnceExecuteOnce().) - The thread-local API is problematic. The implementation uses locks only because it allows the caller of the setter to also pass in a destructor. Instead the API should be much more like the POSIX pthread_key_create(), pthread_getspecific(), pthread_setspecific(), and pthread_key_destroy(). On Windows you should use DllMain() to process DLL_THREAD_DETACH to call destructors for the thread's keys. Then you'll be able to say "look ma', no locks here". For me this is critical and must be fixed as described. - What is the status of the old lock callback getters/setters after this? I don't see any changes to that code. Dead code should be removed, thought you should leave the old functions just for backwards compatibility. But then again, if the app provides these callbacks in a non-threaded configuration of OpenSSL, then they ought to be used! - I don't feel confident that using rw locks is a good idea for the first iteration. When I wrote the commits in the thread_safety branch of my clone (https://github.com/nicowilliams/openssl) I didn't feel at all confident that OpenSSL's use of read/write locks was correct. The reason is that the underlying locks are generally exclusive locks (when callbacks are provided), so the use of read vs write locks may be incorrect. Use of rw vs exclusive locks should be configurable for a while, and thourough testing should be done to ensure that rw locks will work. Also, exclusive locks are easier to use on Windows (as we can see in this PR, that's what's used on Windows). You might want to copy my once-initializer for the pthread case from the thread_safety branch of my clone. This will prove useful for other things even if you don't retain support for using lock callbacks provided by the app (which is why I needed a once- initializer: so I could set callbacks once and only once). (It was probably silly for me to try to use lock callbacks if provided, in retrospect I see little value for that, except in the non-threaded configurations of OpenSSL.) - I don't understand why use different function names for the locking functions. Can you explain? - I don't think critical sections are the right thing to do on Windows. A mutex on Windows would be better (but one needs a once-initializer to set those up correctly since there's no static initializer for mutexes on Windows). - I wonder if OpenSSL in non-threaded configuration could detect and adjust to transitions to threaded mode. This would be heroic on the part of OpenSSL, so I won't insist on it :) It would be nice, but it can wait too. For the dynamically-linked case you can detect threaded-ness by using weak symbols for pthreads, where weak symbols are supported anyways, and there's no need to use dlopen(). Although the switch from not-threaded to threaded will require care (a once initializer), and in particular locks that were "owned" in the not-threaded case should become real locks and acquired so that they stay owned if the caller is the main thread, otherwise if the caller is not the main thread and the main thread owns OpenSSL locks, then you must return an error. I'm not sure how one would do this in the statically linked case. Cheers, Nico -- From tjmao at tjmao.net Thu Dec 3 21:14:43 2015 From: tjmao at tjmao.net (Tianjie Mao) Date: Fri, 4 Dec 2015 05:14:43 +0800 Subject: [openssl-dev] OpenSSL version 1.0.1q released (corrected download) In-Reply-To: <20F1FE9F9E9E4CE2A80B1AA1@192.168.1.9> References: <5660909E.8090403@openssl.org> <6F239AC30CB0CC9CF9D0F7F4@192.168.1.9> <56609593.2000400@openssl.org> <20F1FE9F9E9E4CE2A80B1AA1@192.168.1.9> Message-ID: Hi, I agree with Matt. Looks like you disabled some ciphers but did not run make depend to reflect dependency changes, notably IDEA, which was exactly where make had complained. This is not new as in 0.9.x there was already `make depend' in place. I can confirm that: 1) Previous releases (1.0.1o for example) have been pre-configured for target "cc" (in fact, it missed no-asm on x86_64) 2) 1.0.1q won't build at all without running ./Configure But generally one would configure and customise for their own unique environment before building a software package from source code, so I don't think having to ./Configure introduces a big problem, either. Tianjie Mao On 12/4/15, Quanah Gibson-Mount wrote: > --On Thursday, December 03, 2015 7:18 PM +0000 Matt Caswell > wrote: > >> >> >> On 03/12/15 19:10, Quanah Gibson-Mount wrote: >>> make[5]: *** No rule to make target `../../include/openssl/idea.h', >>> needed by `e_idea.o'. Stop. >> >> Hmmm. I don't get that. Can you post your build steps? > > Configure is: > > ./Configure no-idea enable-ec_nistp_64_gcc_128 no-mdc2 no-rc5 > no-ssl2 \ > no-hw --prefix=/opt/zimbra/common --libdir=lib > --openssldir=/opt/zimbra/common/etc/ssl \ > shared linux-x86_64 -g -O2 -DOPENSSL_NO_HEARTBEATS > > then: > > LD_RUN_PATH=/opt/zimbra/common/lib make > > I only see it on Ubuntu12 & Ubuntu14. It works fine on RHEL6/RHEL7 with > the same Configure parameters. I see one difference, in that on RHEL, > we're running make depend before running make all. > > After adding "make depend" to occur before "make all", it now succeeds. > However, this worked on prior releases, so it seems that requiring "make > depend" is new to 1.0.1q. > > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From vinschen at redhat.com Thu Dec 3 21:08:53 2015 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 3 Dec 2015 22:08:53 +0100 Subject: [openssl-dev] OpenSSL version 1.0.2e released (corrected download) In-Reply-To: <56608FA1.2080403@openssl.org> References: <56608FA1.2080403@openssl.org> Message-ID: <20151203210853.GN18447@calimero.vinschen.de> Hi, the corrected archive is still broken: On Dec 3 18:53, Matt Caswell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Due to an error in the release process the original distribution > downloads were failing to build. New downloads have now been made > available on the website. Corrected checksums are given below. > > OpenSSL version 1.0.2e released > =============================== > > OpenSSL - The Open Source toolkit for SSL/TLS > http://www.openssl.org/ > > The OpenSSL project team is pleased to announce the release of > version 1.0.2e of our open source toolkit for SSL/TLS. For details > of changes and known issues see the release notes at: > > http://www.openssl.org/news/openssl-1.0.2-notes.html > > OpenSSL 1.0.2e is available for download via HTTP and FTP from the > following master locations (you can find the various FTP mirrors > under > http://www.openssl.org/source/mirror.html): > > * http://www.openssl.org/source/ > * ftp://ftp.openssl.org/source/ > > The distribution file name is: > > o openssl-1.0.2e.tar.gz > Size: 5256555 > MD5 checksum: 5262bfa25b60ed9de9f28d5d52d77fc5 > SHA1 checksum: 2c5691496761cb18f98476eefa4d35c835448fb6 > SHA256 checksum: > e23ccafdb75cfcde782da0151731aa2185195ac745eea3846133f2e05c0e0bff This archive has invalid symlinks: $ sha256sum openssl-1.0.2e.tar.gz e23ccafdb75cfcde782da0151731aa2185195ac745eea3846133f2e05c0e0bff openssl-1.0.2e.tar.gz $ tar tvzf openssl-1.0.2e.tar.gz | grep '^l' | head -3 lrwxrwxrwx openssl/openssl 0 2015-12-03 15:44 openssl-1.0.2e/apps/md4.c -> openssl-1.0.2e/../crypto/md4/md4.c lrwxrwxrwx openssl/openssl 0 2015-12-03 15:44 openssl-1.0.2e/test/bftest.c -> openssl-1.0.2e/../crypto/bf/bftest.c lrwxrwxrwx openssl/openssl 0 2015-12-03 15:44 openssl-1.0.2e/test/bntest.c -> openssl-1.0.2e/../crypto/bn/bntest.c Compare with openssl-1.0.2d: $ tar tvzf openssl-1.0.2d.tar.gz openssl-1.0.2d | grep '^l' | head -3 lrwxrwxrwx openssl/openssl 0 2015-07-09 14:03 openssl-1.0.2d/apps/md4.c -> ../crypto/md4/md4.c lrwxrwxrwx openssl/openssl 0 2015-07-09 14:03 openssl-1.0.2d/include/openssl/aes.h -> ../../crypto/aes/aes.h lrwxrwxrwx openssl/openssl 0 2015-07-09 14:03 openssl-1.0.2d/include/openssl/asn1.h -> ../../crypto/asn1/asn1.h Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From matt at openssl.org Thu Dec 3 21:42:27 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 3 Dec 2015 21:42:27 +0000 Subject: [openssl-dev] OpenSSL version 1.0.2e released (corrected download) In-Reply-To: <20151203210853.GN18447@calimero.vinschen.de> References: <56608FA1.2080403@openssl.org> <20151203210853.GN18447@calimero.vinschen.de> Message-ID: <5660B743.6020505@openssl.org> On 03/12/15 21:08, Corinna Vinschen wrote: > This archive has invalid symlinks: > > $ sha256sum openssl-1.0.2e.tar.gz > e23ccafdb75cfcde782da0151731aa2185195ac745eea3846133f2e05c0e0bff openssl-1.0.2e.tar.gz > $ tar tvzf openssl-1.0.2e.tar.gz | grep '^l' | head -3 > lrwxrwxrwx openssl/openssl 0 2015-12-03 15:44 openssl-1.0.2e/apps/md4.c -> openssl-1.0.2e/../crypto/md4/md4.c > lrwxrwxrwx openssl/openssl 0 2015-12-03 15:44 openssl-1.0.2e/test/bftest.c -> openssl-1.0.2e/../crypto/bf/bftest.c > lrwxrwxrwx openssl/openssl 0 2015-12-03 15:44 openssl-1.0.2e/test/bntest.c -> openssl-1.0.2e/../crypto/bn/bntest.c > > Compare with openssl-1.0.2d: > > $ tar tvzf openssl-1.0.2d.tar.gz openssl-1.0.2d | grep '^l' | head -3 > lrwxrwxrwx openssl/openssl 0 2015-07-09 14:03 openssl-1.0.2d/apps/md4.c -> ../crypto/md4/md4.c > lrwxrwxrwx openssl/openssl 0 2015-07-09 14:03 openssl-1.0.2d/include/openssl/aes.h -> ../../crypto/aes/aes.h > lrwxrwxrwx openssl/openssl 0 2015-07-09 14:03 openssl-1.0.2d/include/openssl/asn1.h -> ../../crypto/asn1/asn1.h The symlinks get recreated at Configure time so this should not cause any issues. It will get cleaned up properly in the next release. Matt From vinschen at redhat.com Thu Dec 3 22:04:07 2015 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 3 Dec 2015 23:04:07 +0100 Subject: [openssl-dev] OpenSSL version 1.0.2e released (corrected download) In-Reply-To: <5660B743.6020505@openssl.org> References: <56608FA1.2080403@openssl.org> <20151203210853.GN18447@calimero.vinschen.de> <5660B743.6020505@openssl.org> Message-ID: <20151203220407.GO18447@calimero.vinschen.de> On Dec 3 21:42, Matt Caswell wrote: > > > On 03/12/15 21:08, Corinna Vinschen wrote: > > > This archive has invalid symlinks: > > > > $ sha256sum openssl-1.0.2e.tar.gz > > e23ccafdb75cfcde782da0151731aa2185195ac745eea3846133f2e05c0e0bff openssl-1.0.2e.tar.gz > > $ tar tvzf openssl-1.0.2e.tar.gz | grep '^l' | head -3 > > lrwxrwxrwx openssl/openssl 0 2015-12-03 15:44 openssl-1.0.2e/apps/md4.c -> openssl-1.0.2e/../crypto/md4/md4.c > > lrwxrwxrwx openssl/openssl 0 2015-12-03 15:44 openssl-1.0.2e/test/bftest.c -> openssl-1.0.2e/../crypto/bf/bftest.c > > lrwxrwxrwx openssl/openssl 0 2015-12-03 15:44 openssl-1.0.2e/test/bntest.c -> openssl-1.0.2e/../crypto/bn/bntest.c > > > > Compare with openssl-1.0.2d: > > > > $ tar tvzf openssl-1.0.2d.tar.gz openssl-1.0.2d | grep '^l' | head -3 > > lrwxrwxrwx openssl/openssl 0 2015-07-09 14:03 openssl-1.0.2d/apps/md4.c -> ../crypto/md4/md4.c > > lrwxrwxrwx openssl/openssl 0 2015-07-09 14:03 openssl-1.0.2d/include/openssl/aes.h -> ../../crypto/aes/aes.h > > lrwxrwxrwx openssl/openssl 0 2015-07-09 14:03 openssl-1.0.2d/include/openssl/asn1.h -> ../../crypto/asn1/asn1.h > > The symlinks get recreated at Configure time so this should not cause > any issues. It will get cleaned up properly in the next release. It's an issue for out-of-tree builds when creating the source archive for distro packaging. It's not for me to decide but IMHO it would be cleaner to make sure to have a fixed archive for 1.0.2e as well. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From ca+ssl-dev at esmtp.org Thu Dec 3 22:50:32 2015 From: ca+ssl-dev at esmtp.org (Claus Assmann) Date: Thu, 3 Dec 2015 14:50:32 -0800 Subject: [openssl-dev] OpenSSL version 1.0.2e released (corrected download) In-Reply-To: <20151203220407.GO18447@calimero.vinschen.de> References: <56608FA1.2080403@openssl.org> <20151203210853.GN18447@calimero.vinschen.de> <5660B743.6020505@openssl.org> <20151203220407.GO18447@calimero.vinschen.de> Message-ID: <20151203225032.GA29810@x2.esmtp.org> On Thu, Dec 03, 2015, Corinna Vinschen wrote: > cleaner to make sure to have a fixed archive for 1.0.2e as well. If there will be another "re-release" then please bump the version number. Having different versions (files) with the same name/number (and valid PGP signatures) is rather confusing. From j at w1.fi Thu Dec 3 23:09:07 2015 From: j at w1.fi (Jouni Malinen) Date: Fri, 4 Dec 2015 01:09:07 +0200 Subject: [openssl-dev] EAP-FAST and OpenSSL 1.1.x with new client TLS state machine Message-ID: <20151203230907.GA9237@w1.fi> It looks like the new client TLS state machine breaks the EAP-FAST peer implementation in wpa_supplicant. Based on git bisect, the first commit where this happens was this one: commit 8723588e1b9a13511ffd7b806c73293120bc1f44 Implement Client TLS state machine This swaps the implementation of the client TLS state machine to use the new state machine code instead. Based on the commit message, I guess the real trigger for the issue is either in this commit or one of the earlier commits implementing the new state machine. I haven't yet looked at what exactly causes this. What I see on the TLS client side is that the first connection with EAP-FAST PAC (i.e., without that special form for TLS session ticket) goes through successfully, but the connection with PAC (i.e., TLS session ticket with external storage and set with SSL_set_session_ticket_ext()) is attempted, OpenSSL rejects the message following ServerHello as unexpected_message (i.e., does not seem to allow the abbreviated handshake to be used with this type of session ticket case): SSL: SSL_connect:before SSL initialization OpenSSL: TX ver=0x303 content_type=22 (handshake/client hello) SSL: SSL_connect:SSLv3/TLS write client hello OpenSSL: RX ver=0x303 content_type=22 (handshake/server hello) EAP-FAST: SessionTicket callback SSL: SSL_connect:SSLv3/TLS read server hello OpenSSL: TX ver=0x303 content_type=21 (alert/) SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unexpected_message Going back one commit in the master branch fixes EAP-FAST and the log looks like this: OpenSSL: RX ver=0x303 content_type=22 (handshake/server hello) EAP-FAST: SessionTicket callback SSL: SSL_connect:SSLv3 read server hello A OpenSSL: RX ver=0x303 content_type=20 (change cipher spec/) ... Any idea what happened with these OpenSSL client state machine changes and how to get this fixed to restore EAP-FAST functionality? -- Jouni Malinen PGP id EFC895FA From Carl.Tietjen at microfocus.com Fri Dec 4 01:33:00 2015 From: Carl.Tietjen at microfocus.com (Carl Tietjen) Date: Fri, 4 Dec 2015 01:33:00 +0000 Subject: [openssl-dev] Windows x86_64 build broken -- RE: [openssl-users] OpenSSL version 1.0.1q released (corrected download) Message-ID: <3AB7EF789FF16E4C81C5BA3833C2A195133D94B9@prvxmb01.microfocus.com> Folks, It looks like the Windows x86_64 build for OpenSSL version 1.0.1q is broken. I am building a FIPS capable version, and have verified that I have the corrected download build: SHA1 checksum: c65a7bec49b72092d7ebb97a263c496cc1e1d6af FYI - I have successfully built on 3 Linux platforms with this tar file. Build steps: 1) perl Configure VC-WIN64A fips --with-fipslibdir=c:\FIPS\openssl-fips-ecp-2.0.9 no-ec2m no-idea no-mdc2 no-rc5 2) ms\do_win64a 3) nmake -f ms\nt.mak ... NMAKE : fatal error U1073: don't know how to make 'tmp32\applink.obj' ____________ It looks like the nt.mak file ends up different than the one from 1.0.1p. The relevant changes are: 1.0.1p: ... $(PREMAIN_DSO_EXE): $(OBJ_D)\$(E_PREMAIN_DSO).obj $(CRYPTOOBJ) $(O_FIPSCANISTER) $(LINK) $(LFLAGS) /out:$(PREMAIN_DSO_EXE) @<< $(EX_LIBS) $(OBJ_D)\$(E_PREMAIN_DSO).obj $(CRYPTOOBJ) $(O_FIPSCANISTER) $(EX_LIBS) ... 1.0.1q $(PREMAIN_DSO_EXE): $(OBJ_D)\$(E_PREMAIN_DSO).obj $(CRYPTOOBJ) $(O_FIPSCANISTER) $(OBJ_D)\applink.obj $(LINK) $(LFLAGS) /out:$(PREMAIN_DSO_EXE) @<< $(EX_LIBS) $(OBJ_D)\applink.obj $(OBJ_D)\$(E_PREMAIN_DSO).obj $(CRYPTOOBJ) $(O_FIPSCANISTER) $(EX_LIBS) _______________ I have tried to find any changes in the perl scripts that would cause this change, but have been unsuccessful so far. Thanks in advance for any help Carl From eijdenberg at google.com Fri Dec 4 03:05:28 2015 From: eijdenberg at google.com (Adam Eijdenberg) Date: Fri, 04 Dec 2015 03:05:28 +0000 Subject: [openssl-dev] test_ordinals causes make update to fail after make clean Message-ID: Hi openssl-dev, When I'm preparing a patch I've gotten myself used to the following workflow to try to get my working environment into a sane state: ./config --strict-warnings make clean make update make -j32 make tests Today I noticed that "make update" is failing with the following error: /Applications/Xcode.app/Contents/Developer/usr/bin/make TESTS=test_ordinals test /Users/aeijdenberg/src/openssl/util/opensslwrap.sh: line 25: /Users/aeijdenberg/src/openssl/util/../apps/openssl: No such file or directory Probably not surprising because "make clean" removes apps/openssl. AFAIK until this commit ( https://github.com/openssl/openssl/commit/0aca86b313d286be979629a3193a12e17bf7171a) yesterday that calls test_ordinals as part of "make update", prior to that there were no dependencies on apps/openssl having been built already. Maybe my workflow is wrong (I derived it mostly from trial and error) - but I thought I'd bring it up for discussion. Cheers, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Fri Dec 4 03:56:57 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 4 Dec 2015 03:56:57 +0000 Subject: [openssl-dev] Windows x86_64 build broken -- RE: [openssl-users] OpenSSL version 1.0.1q released (corrected download) In-Reply-To: <3AB7EF789FF16E4C81C5BA3833C2A195133D94B9@prvxmb01.microfocus.com> References: <3AB7EF789FF16E4C81C5BA3833C2A195133D94B9@prvxmb01.microfocus.com> Message-ID: <20151204035657.GA22717@openssl.org> On Fri, Dec 04, 2015, Carl Tietjen wrote: > Folks, > > It looks like the Windows x86_64 build for OpenSSL version 1.0.1q is broken. > > I am building a FIPS capable version, and have verified that I have the corrected download build: SHA1 checksum: c65a7bec49b72092d7ebb97a263c496cc1e1d6af > FYI - I have successfully built on 3 Linux platforms with this tar file. > > Build steps: > 1) perl Configure VC-WIN64A fips --with-fipslibdir=c:\FIPS\openssl-fips-ecp-2.0.9 no-ec2m no-idea no-mdc2 no-rc5 > 2) ms\do_win64a > 3) nmake -f ms\nt.mak > ... > NMAKE : fatal error U1073: don't know how to make 'tmp32\applink.obj' > > ____________ > > It looks like the nt.mak file ends up different than the one from 1.0.1p. The relevant changes are: > > 1.0.1p: > ... > $(PREMAIN_DSO_EXE): $(OBJ_D)\$(E_PREMAIN_DSO).obj $(CRYPTOOBJ) $(O_FIPSCANISTER) > $(LINK) $(LFLAGS) /out:$(PREMAIN_DSO_EXE) @<< > $(EX_LIBS) $(OBJ_D)\$(E_PREMAIN_DSO).obj $(CRYPTOOBJ) $(O_FIPSCANISTER) $(EX_LIBS) > ... > > 1.0.1q > $(PREMAIN_DSO_EXE): $(OBJ_D)\$(E_PREMAIN_DSO).obj $(CRYPTOOBJ) $(O_FIPSCANISTER) $(OBJ_D)\applink.obj > $(LINK) $(LFLAGS) /out:$(PREMAIN_DSO_EXE) @<< > $(EX_LIBS) $(OBJ_D)\applink.obj $(OBJ_D)\$(E_PREMAIN_DSO).obj $(CRYPTOOBJ) $(O_FIPSCANISTER) $(EX_LIBS) > > _______________ > > I have tried to find any changes in the perl scripts that would cause this change, but have been unsuccessful so far. > > Thanks in advance for any help > That update was to fix a linker error in some versions of VC++. I just tried that on the latest 1.0.1 branch and can't reproduce your problem. What version of VC++ are you using? However you need to use --with-fipsdir not --with-fipslibdir and it need to point to wherever the FIPS module was installed, not the source directory. Alternatively you can set the FIPSDIR environment variable before building the FIPS module and it will be installed to that location and the FIPS capable OpenSSL will use that without the need to use --with-fipsdir. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From openssl-users at dukhovni.org Fri Dec 4 05:47:10 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 4 Dec 2015 05:47:10 +0000 Subject: [openssl-dev] test_ordinals causes make update to fail after make clean In-Reply-To: References: Message-ID: <20151204054709.GN18315@mournblade.imrryr.org> On Fri, Dec 04, 2015 at 03:05:28AM +0000, Adam Eijdenberg wrote: > When I'm preparing a patch I've gotten myself used to the following > workflow to try to get my working environment into a sane state: > > ./config --strict-warnings > make clean > make update > make -j32 > make tests > > Today I noticed that "make update" is failing with the following error: > > /Applications/Xcode.app/Contents/Developer/usr/bin/make TESTS=test_ordinals > test > /Users/aeijdenberg/src/openssl/util/opensslwrap.sh: line 25: > /Users/aeijdenberg/src/openssl/util/../apps/openssl: No such file or > directory Since you're on Darwin, presumably using a 64-bit Intel CPU, have you considered instead: ./Configure shared darwin64-x86_64-cc make clean make depend make -j32 make tests (note --strict-warnings is a developer option, no guarantee that it will work at all times on all platforms). -- Viktor. From bhat.jayalakshmi at gmail.com Fri Dec 4 06:53:00 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Fri, 4 Dec 2015 12:23:00 +0530 Subject: [openssl-dev] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d Message-ID: Hi All, Recently we have ported OpenSSL 1.0.2d. Everything works perfect except the below explained issue. When we enable only TLS 1.0 protocol and select CBC ciphers, TLS handshake fails with the error "bad record mac". Error is in function static int ssl3_get_record(SSL *s). Error happens at if (i < 0 || mac == NULL || CRYPTO_memcmp(md, mac, (size_t)mac_size) != 0). CRYPTO_memcmp is failing. I debugged further. I replaced constant_time_eq_8 usage in s3_cbc.c with the implementation available in OpenSSL 1.0.1e. Things worked fine. OpenSSL 1.0.2d has this implementation in constant_time_locl.h. OpenSSL 1.0.1e has this implementation local to s3_cbc.c Now my question is whatever I did is it correct? Or Do need to replace complete s3_cbc.c with OpenSSL 1.0.1e? Regards Jaya -------------- next part -------------- An HTML attachment was scrubbed... URL: From Carl.Tietjen at microfocus.com Fri Dec 4 09:55:53 2015 From: Carl.Tietjen at microfocus.com (Carl Tietjen) Date: Fri, 4 Dec 2015 09:55:53 +0000 Subject: [openssl-dev] Windows x86_64 build broken -- RE: [openssl-users] OpenSSL version 1.0.1q released (corrected download) In-Reply-To: <20151204035657.GA22717@openssl.org> References: <3AB7EF789FF16E4C81C5BA3833C2A195133D94B9@prvxmb01.microfocus.com> <20151204035657.GA22717@openssl.org> Message-ID: <3AB7EF789FF16E4C81C5BA3833C2A195133D9530@prvxmb01.microfocus.com> >>What version of VC++ are you using? We are using Visual Studio 2010 Professional SP1 + security Hotfixes Version 10.0.40219.1 SP1Rel FYI -- We are using the older compiler because VS 2010 is what was used for the FIPS evaluations. I tired setting the FIPSDIR environment variable, building the FIPS object module, and then trying to build the FIPS capable OpenSSL, however it failed exactly the same. __________________________________ On a minor note, now, as previously, when I tried using the --with-fipsdir option, the build fails quite early because it cannot find the fipscanister.lib. I followed the instructions in The User Guide for OpenSSL FIPS Object Module v2.0: 4.3.2 Installing and Protecting the FIPS Object Module The system administrator should install the generated fipscanister.lib, fipscanister.lib.sha1, and fips_premain.c files in a location protected by the host operating system security features. ... 4.3.3 Building a FIPS Capable OpenSSL ... do: perl Configure VC-WIN32 fips --with-fipsdir=c:\fips\path where "c:\fips\path" is wherever the FIPS module from the first stage was installed. ... However, the build is expecting fipscanister.lib to be in a "lib" subdirectory, off of the specified fipsdir path, which is contrary to the instructions above. When I first ran into this issue, I figured out (from the make files) that if I used the fipslibdir instead of fipsdir, then the build would work. Thanks, Carl -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Dr. Stephen Henson Sent: Thursday, December 03, 2015 7:57 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Windows x86_64 build broken -- RE: [openssl-users] OpenSSL version 1.0.1q released (corrected download) On Fri, Dec 04, 2015, Carl Tietjen wrote: > Folks, > > It looks like the Windows x86_64 build for OpenSSL version 1.0.1q is broken. > > I am building a FIPS capable version, and have verified that I have the corrected download build: SHA1 checksum: c65a7bec49b72092d7ebb97a263c496cc1e1d6af > FYI - I have successfully built on 3 Linux platforms with this tar file. > > Build steps: > 1) perl Configure VC-WIN64A fips --with-fipslibdir=c:\FIPS\openssl-fips-ecp-2.0.9 no-ec2m no-idea no-mdc2 no-rc5 > 2) ms\do_win64a > 3) nmake -f ms\nt.mak > ... > NMAKE : fatal error U1073: don't know how to make 'tmp32\applink.obj' > > ____________ > > It looks like the nt.mak file ends up different than the one from 1.0.1p. The relevant changes are: > > 1.0.1p: > ... > $(PREMAIN_DSO_EXE): $(OBJ_D)\$(E_PREMAIN_DSO).obj $(CRYPTOOBJ) $(O_FIPSCANISTER) > $(LINK) $(LFLAGS) /out:$(PREMAIN_DSO_EXE) @<< > $(EX_LIBS) $(OBJ_D)\$(E_PREMAIN_DSO).obj $(CRYPTOOBJ) $(O_FIPSCANISTER) $(EX_LIBS) > ... > > 1.0.1q > $(PREMAIN_DSO_EXE): $(OBJ_D)\$(E_PREMAIN_DSO).obj $(CRYPTOOBJ) $(O_FIPSCANISTER) $(OBJ_D)\applink.obj > $(LINK) $(LFLAGS) /out:$(PREMAIN_DSO_EXE) @<< > $(EX_LIBS) $(OBJ_D)\applink.obj $(OBJ_D)\$(E_PREMAIN_DSO).obj $(CRYPTOOBJ) $(O_FIPSCANISTER) $(EX_LIBS) > > _______________ > > I have tried to find any changes in the perl scripts that would cause this change, but have been unsuccessful so far. > > Thanks in advance for any help > That update was to fix a linker error in some versions of VC++. I just tried that on the latest 1.0.1 branch and can't reproduce your problem. What version of VC++ are you using? However you need to use --with-fipsdir not --with-fipslibdir and it need to point to wherever the FIPS module was installed, not the source directory. Alternatively you can set the FIPSDIR environment variable before building the FIPS module and it will be installed to that location and the FIPS capable OpenSSL will use that without the need to use --with-fipsdir. 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 From matt at openssl.org Fri Dec 4 10:27:48 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 4 Dec 2015 10:27:48 +0000 Subject: [openssl-dev] EAP-FAST and OpenSSL 1.1.x with new client TLS state machine In-Reply-To: <20151203230907.GA9237@w1.fi> References: <20151203230907.GA9237@w1.fi> Message-ID: <56616AA4.9060506@openssl.org> On 03/12/15 23:09, Jouni Malinen wrote: > Any idea what happened with these OpenSSL client state machine changes > and how to get this fixed to restore EAP-FAST functionality? EAP-FAST is very strange. Normally you know whether you are resuming a session or not based on the session id returned from the server. However that's not the case with EAP-FAST - you have to wait to see what message the server sends you next to determine what's happening (which is really horrible). The new state machine code waits until a message is received from the peer and then checks it against its allowed list of transitions based on its current state. If its not allowed then you get an unexpected message alert. It looks like the check for the EAP-FAST session resumption case is missing from the new code. Please can you try the attached patch and see if that resolves the issue? Let me know how you get on. Thanks Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-eap-fast.patch Type: text/x-patch Size: 1687 bytes Desc: not available URL: From j at w1.fi Fri Dec 4 13:08:34 2015 From: j at w1.fi (Jouni Malinen) Date: Fri, 4 Dec 2015 15:08:34 +0200 Subject: [openssl-dev] EAP-FAST and OpenSSL 1.1.x with new client TLS state machine In-Reply-To: <56616AA4.9060506@openssl.org> References: <20151203230907.GA9237@w1.fi> <56616AA4.9060506@openssl.org> Message-ID: <20151204130834.GA16102@w1.fi> On Fri, Dec 04, 2015 at 10:27:48AM +0000, Matt Caswell wrote: > EAP-FAST is very strange. Normally you know whether you are resuming a > session or not based on the session id returned from the server. However > that's not the case with EAP-FAST - you have to wait to see what message > the server sends you next to determine what's happening (which is really > horrible). Indeed. EAP-FAST is a good example of what can happen if a company designs a new EAP method and pushes that to the market without going through proper IETF review.. This part here is not the only difficult item in supporting EAP-FAST. :( > The new state machine code waits until a message is received from the > peer and then checks it against its allowed list of transitions based on > its current state. If its not allowed then you get an unexpected message > alert. It looks like the check for the EAP-FAST session resumption case > is missing from the new code. > > Please can you try the attached patch and see if that resolves the > issue? Let me know how you get on. Thanks! That fixes the issue. With this applied on top of the current master branch snapshot, I was able to pass all my EAP regression tests. -- Jouni Malinen PGP id EFC895FA From openssl at openssl.org Fri Dec 4 14:41:32 2015 From: openssl at openssl.org (OpenSSL) Date: Fri, 4 Dec 2015 14:41:32 +0000 Subject: [openssl-dev] Updated OpenSSL Security Advisory Message-ID: <20151204144132.GA16102@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL Security Advisory [3 Dec 2015] - Updated [4 Dec 2015] ============================================================= [Updated 4 Dec 2015]: This advisory has been updated to include the details of CVE-2015-1794, a Low severity issue affecting OpenSSL 1.0.2 which had a fix included in the released packages but was missed from the advisory text. NOTE: WE ANTICIPATE THAT 1.0.0t AND 0.9.8zh WILL BE THE LAST RELEASES FOR THE 0.9.8 AND 1.0.0 VERSIONS AND THAT NO MORE SECURITY FIXES WILL BE PROVIDED (AS PER PREVIOUS ANNOUNCEMENTS). USERS ARE ADVISED TO UPGRADE TO LATER VERSIONS. BN_mod_exp may produce incorrect results on x86_64 (CVE-2015-3193) ================================================================== Severity: Moderate There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. For example this can occur by default in OpenSSL DHE based SSL/TLS ciphersuites. This issue affects OpenSSL version 1.0.2. OpenSSL 1.0.2 users should upgrade to 1.0.2e This issue was reported to OpenSSL on August 13 2015 by Hanno B??ck. The fix was developed by Andy Polyakov of the OpenSSL development team. Certificate verify crash with missing PSS parameter (CVE-2015-3194) =================================================================== Severity: Moderate The signature verification routines will crash with a NULL pointer dereference if presented with an ASN.1 signature using the RSA PSS algorithm and absent mask generation function parameter. Since these routines are used to verify certificate signature algorithms this can be used to crash any certificate verification operation and exploited in a DoS attack. Any application which performs certificate verification is vulnerable including OpenSSL clients and servers which enable client authentication. This issue affects OpenSSL versions 1.0.2 and 1.0.1. OpenSSL 1.0.2 users should upgrade to 1.0.2e OpenSSL 1.0.1 users should upgrade to 1.0.1q This issue was reported to OpenSSL on August 27 2015 by Lo??c Jonas Etienne (Qnective AG). The fix was developed by Dr. Stephen Henson of the OpenSSL development team. X509_ATTRIBUTE memory leak (CVE-2015-3195) ========================================== Severity: Moderate When presented with a malformed X509_ATTRIBUTE structure OpenSSL will leak memory. This structure is used by the PKCS#7 and CMS routines so any application which reads PKCS#7 or CMS data from untrusted sources is affected. SSL/TLS is not affected. This issue affects OpenSSL versions 1.0.2 and 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2e OpenSSL 1.0.1 users should upgrade to 1.0.1q OpenSSL 1.0.0 users should upgrade to 1.0.0t OpenSSL 0.9.8 users should upgrade to 0.9.8zh This issue was reported to OpenSSL on November 9 2015 by Adam Langley (Google/BoringSSL) using libFuzzer. The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Race condition handling PSK identify hint (CVE-2015-3196) ========================================================= Severity: Low If PSK identity hints are received by a multi-threaded client then the values are wrongly updated in the parent SSL_CTX structure. This can result in a race condition potentially leading to a double free of the identify hint data. This issue was fixed in OpenSSL 1.0.2d and 1.0.1p but has not been previously listed in an OpenSSL security advisory. This issue also affects OpenSSL 1.0.0 and has not been previously fixed in an OpenSSL 1.0.0 release. OpenSSL 1.0.2 users should upgrade to 1.0.2d OpenSSL 1.0.1 users should upgrade to 1.0.1p OpenSSL 1.0.0 users should upgrade to 1.0.0t The fix for this issue can be identified in the OpenSSL git repository by commit ids 3c66a669dfc7 (1.0.2), d6be3124f228 (1.0.1) and 1392c238657e (1.0.0). The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Anon DH ServerKeyExchange with 0 p parameter (CVE-2015-1794) ============================================================ Severity: Low If a client receives a ServerKeyExchange for an anonymous DH ciphersuite with the value of p set to 0 then a seg fault can occur leading to a possible denial of service attack. This issue affects OpenSSL version 1.0.2. OpenSSL 1.0.2 users should upgrade to 1.0.2e This issue was reported to OpenSSL on August 3 2015 by Guy Leaver (Cisco). The fix was developed by Matt Caswell of the OpenSSL development team. Note ==== As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these versions will be provided after that date. In the absence of significant security issues being identified prior to that date, the 1.0.0t and 0.9.8zh releases will be the last for those versions. Users of these versions are advised to upgrade. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20151203.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWYaMQAAoJENnE0m0OYESRvMAIAKkGjtOTKeqpUuWvzCVs8VV/ lHWZ7ZKZMI3LQHLX0lOTu8Ypipth83eHPDQxEzhkjzjGPsVrEZ+2Labm/awTKr7H UhrvFEl0R1hag/ssvyXWOaQ+ZyHITzeSHVcOu35tf9cSrHf6JMYOwV1H2JDyAoX/ 7Spwxj/scmH2VS9Xz9sIzV5FTxZV1V0QrerU67gjp7ZYiUMW+4nvCGsEk6fOW52G R06XjV4HyDP9TbAVYexu8uqpBLPavWT+zGxDlMZzyY41OptDHcHwPRfI/pgPdA2g m9oVmxGRAi6MMz/uOAXaUC5dPFSqt9iJATIrFALpXsY4OjebpqFucN/qyT0KDco= =VWCg -----END PGP SIGNATURE----- From rt at openssl.org Fri Dec 4 15:25:35 2015 From: rt at openssl.org (Oliver Schonrock via RT) Date: Fri, 04 Dec 2015 15:25:35 +0000 Subject: [openssl-dev] [openssl.org #4166] Bug: OpenSSL 1.0.1l fails to verify SOME root CAs: error:num=20:unable to get local issuer certificate In-Reply-To: <56615C48.7010003@schonrocks.com> References: <56615C48.7010003@schonrocks.com> Message-ID: The openssl in FreeBSD 10.1-RELEASE (amd64) (OpenSSL 1.0.1l) fails to verify some server certificates using /usr/local/share/certs/ca-root-nss.crt. FreeBSD 10.2 works fine. I suspect this is an issue with openssl rather than FreeBSD. To Reproduce: $ openssl s_client -connect api.textmarketer.co.uk:443 depth=2 C = US, O = "thawte, Inc.", OU = Certification Services Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA verify error:num=20:unable to get local issuer certificate ... The same command on FreeBSD 10.2 (OpenSSL 1.0.1p) results in: $ openssl s_client -connect api.textmarketer.co.uk:443 depth=2 C = US, O = "thawte, Inc.", OU = Certification Services Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA verify return:1 ... This error message is widely reported as being due to path issues to the CA bundle. In fact on FreeBSD 10.1 a similar command even fails to verify other server certs with a different root CA: $ openssl s_client -connect google.com:443 depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify error:num=20:unable to get local issuer certificate However the google.com Equifax secure root CA can be made to work with 10.1 if you specify the -CAfile $ openssl s_client -CAfile /usr/local/share/certs/ca-root-nss.crt -connect google.com:443 depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 This is NOT the case for the original Thawte example: $ openssl s_client -CAfile /usr/local/share/certs/ca-root-nss.crt -connect api.textmarketer.co.uk:443 depth=2 C = US, O = "thawte, Inc.", OU = Certification Services Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA verify error:num=20:unable to get local issuer certificate On FreeBSD 10.2 all CA root certs tested verify fine, with the default install without the need for CAfile. Having to pass -CAfile might be acceptable, as this is just a "packaging and OS integration issue on paths", however the fact that even with the correct -CAfile SOME root certs do NOT verify, leads me to believe that something more fundamental is broken with the openssl version in FreeBSD 10.1, which is: OpenSSL 1.0.1l-freebsd 15 Jan 2015 This was tested and verified on a clean install of 10.1-RELEASE. -- Oliver Sch?nrock -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Dec 4 15:25:36 2015 From: rt at openssl.org (Franz Glasner via RT) Date: Fri, 04 Dec 2015 15:25:36 +0000 Subject: [openssl-dev] [openssl.org #4167] Missing "include/openssl" in the latest tarballs In-Reply-To: References: Message-ID: Hello, the latest tarballs openssl-0.9.8zh.tar.gz, openssl-1.0.0t.tar.gz, openssl-1.0.1q.tar.gz, openssl-1.0.2e.tar.gz (re-released versions) are missing all the public header files in "include/openssl". The older releases (0.9.9zg, 1.0.0s, 1.0.1p, 1.0.2d) where ok. This seems due to commit 27f98436b9a84b94fbdd8e32960504634ae44cc0, where some stuff in "Makefile.org" got rearranged. All entities named "openssl" are excluded from the tarballs which unfortunately hits the foldername of the public header files. Another but minor consequence of this change is that many ".cvsignore" files are now included in the tarballs. They where excluded previously. Please fix and re-release again. Thank you. Best regards, Franz Glasner _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Dec 4 15:28:07 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 04 Dec 2015 15:28:07 +0000 Subject: [openssl-dev] [openssl.org #4167] Missing "include/openssl" in the latest tarballs In-Reply-To: References: Message-ID: The files in "include/openssl" get populated at configure time and are not necessary to successfully build and install openssl. Closing this ticket. Matt From eijdenberg at google.com Fri Dec 4 15:41:45 2015 From: eijdenberg at google.com (Adam Eijdenberg) Date: Fri, 04 Dec 2015 15:41:45 +0000 Subject: [openssl-dev] test_ordinals causes make update to fail after make clean In-Reply-To: <20151204054709.GN18315@mournblade.imrryr.org> References: <20151204054709.GN18315@mournblade.imrryr.org> Message-ID: On Thu, Dec 3, 2015 at 9:47 PM Viktor Dukhovni wrote: > On Fri, Dec 04, 2015 at 03:05:28AM +0000, Adam Eijdenberg wrote: > > > When I'm preparing a patch I've gotten myself used to the following > > workflow to try to get my working environment into a sane state: > > > > ./config --strict-warnings > > make clean > > make update > > make -j32 > > make tests > > > > Today I noticed that "make update" is failing with the following error: > > > > /Applications/Xcode.app/Contents/Developer/usr/bin/make > TESTS=test_ordinals > > test > > /Users/aeijdenberg/src/openssl/util/opensslwrap.sh: line 25: > > /Users/aeijdenberg/src/openssl/util/../apps/openssl: No such file or > > directory > > Since you're on Darwin, presumably using a 64-bit Intel CPU, have > you considered instead: > > ./Configure shared darwin64-x86_64-cc > make clean > make depend > make -j32 > make tests > > (note --strict-warnings is a developer option, no guarantee that > it will work at all times on all platforms). > Hi Viktor, Yes, I understand it's a developer option, and that there are likely more appropriate build targets on Darwin, but I don't believe either are related to the issue that I'm trying to report (which I also get on my Linux workstation), which is that "make update" now won't work on a cleanly checked out source tree, whereas it did 2 days ago (before https://github.com/openssl/openssl/commit/0aca86b313d286be979629a3193a12e17bf7171a ). Is that expected behavior or not? (my understanding of "make update" is that it will call all the things I might need after making changes to the source, such as re-generating error files, safestack stuff, make depend etc, so it's kind of nice that it works before the source itself is built) Cheers, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Dec 4 15:43:41 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 4 Dec 2015 15:43:41 +0000 Subject: [openssl-dev] test_ordinals causes make update to fail after make clean In-Reply-To: References: <20151204054709.GN18315@mournblade.imrryr.org> Message-ID: <5661B4AD.9060500@openssl.org> On 04/12/15 15:41, Adam Eijdenberg wrote: > On Thu, Dec 3, 2015 at 9:47 PM Viktor Dukhovni > > wrote: > > On Fri, Dec 04, 2015 at 03:05:28AM +0000, Adam Eijdenberg wrote: > > > When I'm preparing a patch I've gotten myself used to the following > > workflow to try to get my working environment into a sane state: > > > > ./config --strict-warnings > > make clean > > make update > > make -j32 > > make tests > > > > Today I noticed that "make update" is failing with the following > error: > > > > /Applications/Xcode.app/Contents/Developer/usr/bin/make > TESTS=test_ordinals > > test > > /Users/aeijdenberg/src/openssl/util/opensslwrap.sh: line 25: > > /Users/aeijdenberg/src/openssl/util/../apps/openssl: No such file or > > directory > > Since you're on Darwin, presumably using a 64-bit Intel CPU, have > you considered instead: > > ./Configure shared darwin64-x86_64-cc > make clean > make depend > make -j32 > make tests > > (note --strict-warnings is a developer option, no guarantee that > it will work at all times on all platforms). > > > Hi Viktor, > > Yes, I understand it's a developer option, and that there are likely > more appropriate build targets on Darwin, but I don't believe either are > related to the issue that I'm trying to report (which I also get on my > Linux workstation), which is that "make update" now won't work on a > cleanly checked out source tree, whereas it did 2 days ago > (before https://github.com/openssl/openssl/commit/0aca86b313d286be979629a3193a12e17bf7171a). > > Is that expected behavior or not? > > (my understanding of "make update" is that it will call all the things I > might need after making changes to the source, such as re-generating > error files, safestack stuff, make depend etc, so it's kind of nice that > it works before the source itself is built) > This is definitely a problem. I am hitting the same thing. Matt From eijdenberg at google.com Fri Dec 4 15:55:55 2015 From: eijdenberg at google.com (Adam Eijdenberg) Date: Fri, 04 Dec 2015 15:55:55 +0000 Subject: [openssl-dev] test_ordinals causes make update to fail after make clean In-Reply-To: <5661B4AD.9060500@openssl.org> References: <20151204054709.GN18315@mournblade.imrryr.org> <5661B4AD.9060500@openssl.org> Message-ID: On Fri, Dec 4, 2015 at 7:43 AM Matt Caswell wrote: > This is definitely a problem. I am hitting the same thing. > Created PR to revert: https://github.com/openssl/openssl/pull/497 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Dec 4 16:03:59 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 4 Dec 2015 16:03:59 +0000 Subject: [openssl-dev] test_ordinals causes make update to fail after make clean In-Reply-To: <5661B4AD.9060500@openssl.org> References: <20151204054709.GN18315@mournblade.imrryr.org> <5661B4AD.9060500@openssl.org> Message-ID: > > (my understanding of "make update" is that it will call all the things > > I might need after making changes to the source, such as re-generating > > error files, safestack stuff, make depend etc, so it's kind of nice > > that it works before the source itself is built) > > > > This is definitely a problem. I am hitting the same thing. Yeah, remove "test_ordinals" from the update line and we'll fix it in master shortly. From levitte at openssl.org Fri Dec 4 16:13:09 2015 From: levitte at openssl.org (Richard Levitte) Date: Fri, 04 Dec 2015 17:13:09 +0100 (CET) Subject: [openssl-dev] test_ordinals causes make update to fail after make clean In-Reply-To: <5661B4AD.9060500@openssl.org> References: <20151204054709.GN18315@mournblade.imrryr.org> <5661B4AD.9060500@openssl.org> Message-ID: <20151204.171309.2158168122690223997.levitte@openssl.org> In message <5661B4AD.9060500 at openssl.org> on Fri, 4 Dec 2015 15:43:41 +0000, Matt Caswell said: matt> matt> matt> On 04/12/15 15:41, Adam Eijdenberg wrote: matt> > Hi Viktor, matt> > matt> > Yes, I understand it's a developer option, and that there are likely matt> > more appropriate build targets on Darwin, but I don't believe either are matt> > related to the issue that I'm trying to report (which I also get on my matt> > Linux workstation), which is that "make update" now won't work on a matt> > cleanly checked out source tree, whereas it did 2 days ago matt> > (before https://github.com/openssl/openssl/commit/0aca86b313d286be979629a3193a12e17bf7171a). matt> > matt> > Is that expected behavior or not? matt> > matt> This is definitely a problem. I am hitting the same thing. I'm having an idea how to solve this... a small function OpenSSL::Test::Utils::prepare_demo_certs, to be called by any test recipe that needs to use that cert directory, then remove the dependency on the rehash target in the top Makefile. Obviously, test_ordinals doesn't need those certs, so that should clear this problem. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Fri Dec 4 16:20:15 2015 From: levitte at openssl.org (Richard Levitte) Date: Fri, 04 Dec 2015 17:20:15 +0100 (CET) Subject: [openssl-dev] test_ordinals causes make update to fail after make clean In-Reply-To: <20151204.171309.2158168122690223997.levitte@openssl.org> References: <5661B4AD.9060500@openssl.org> <20151204.171309.2158168122690223997.levitte@openssl.org> Message-ID: <20151204.172015.2097424889404904588.levitte@openssl.org> In message <20151204.171309.2158168122690223997.levitte at openssl.org> on Fri, 04 Dec 2015 17:13:09 +0100 (CET), Richard Levitte said: levitte> In message <5661B4AD.9060500 at openssl.org> on Fri, 4 Dec 2015 15:43:41 +0000, Matt Caswell said: levitte> levitte> matt> levitte> matt> levitte> matt> On 04/12/15 15:41, Adam Eijdenberg wrote: levitte> matt> > Hi Viktor, levitte> matt> > levitte> matt> > Yes, I understand it's a developer option, and that there are likely levitte> matt> > more appropriate build targets on Darwin, but I don't believe either are levitte> matt> > related to the issue that I'm trying to report (which I also get on my levitte> matt> > Linux workstation), which is that "make update" now won't work on a levitte> matt> > cleanly checked out source tree, whereas it did 2 days ago levitte> matt> > (before https://github.com/openssl/openssl/commit/0aca86b313d286be979629a3193a12e17bf7171a). levitte> matt> > levitte> matt> > Is that expected behavior or not? levitte> matt> > levitte> matt> This is definitely a problem. I am hitting the same thing. levitte> levitte> I'm having an idea how to solve this... a small function levitte> OpenSSL::Test::Utils::prepare_demo_certs, to be called by any test levitte> recipe that needs to use that cert directory, then remove the levitte> dependency on the rehash target in the top Makefile. Obviously, levitte> test_ordinals doesn't need those certs, so that should clear this levitte> problem. Never mind that, I keep forgetting that rehash requires a complete build... There are other ideas floating around. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From eijdenberg at google.com Fri Dec 4 16:47:44 2015 From: eijdenberg at google.com (Adam Eijdenberg) Date: Fri, 04 Dec 2015 16:47:44 +0000 Subject: [openssl-dev] test_ordinals causes make update to fail after make clean In-Reply-To: <20151204.172015.2097424889404904588.levitte@openssl.org> References: <5661B4AD.9060500@openssl.org> <20151204.171309.2158168122690223997.levitte@openssl.org> <20151204.172015.2097424889404904588.levitte@openssl.org> Message-ID: Fixed by Richard Levitte in: https://github.com/openssl/openssl/commit/f6e9c5533101066b2c759986ae8694c0f1926735 Thanks! (and confirmed that "make update" now runs cleanly on my system) Cheers, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Dec 4 17:16:23 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 4 Dec 2015 17:16:23 +0000 Subject: [openssl-dev] [openssl.org #4166] Bug: OpenSSL 1.0.1l fails to verify SOME root CAs: error:num=20:unable to get local issuer certificate In-Reply-To: References: <56615C48.7010003@schonrocks.com> Message-ID: <20151204171623.GW18315@mournblade.imrryr.org> [ Redirecting to openssl-users ] On Fri, Dec 04, 2015 at 03:25:35PM +0000, Oliver Schonrock via RT wrote: > To Reproduce: > $ openssl s_client -connect api.textmarketer.co.uk:443 > depth=2 C = US, O = "thawte, Inc.", OU = Certification Services > Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = > thawte Primary Root CA > verify error:num=20:unable to get local issuer certificate > ... Despite the CN string, the certificate presented by that server on the wire is not a root certificate. See the attached chain. Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=premium-server at thawte.com Validity Not Before: Nov 17 00:00:00 2006 GMT Not After : Dec 30 23:59:59 2020 GMT Subject: C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA > The same command on FreeBSD 10.2 (OpenSSL 1.0.1p) results in: > $ openssl s_client -connect api.textmarketer.co.uk:443 > depth=2 C = US, O = "thawte, Inc.", OU = Certification Services > Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = > thawte Primary Root CA > verify return:1 In 1.0.1p OpenSSL looks in the trust store before consulting the provided chain. You likely have a better Thawte certificate there than the one sent by the server. -- Viktor. -------------- next part -------------- Certificate: Data: Version: 3 (0x2) Serial Number: 21:b8:6b:cc:47:2f:b7:b0:d1:0e:15:eb:af:30:61:8f Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=thawte, Inc., OU=Domain Validated SSL, CN=thawte DV SSL CA - G2 Validity Not Before: May 25 00:00:00 2015 GMT Not After : Jul 23 23:59:59 2017 GMT Subject: CN=api.textmarketer.co.uk Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:a6:ca:50:c1:29:ad:4d:da:26:ca:de:ac:8e:05: ba:ff:00:ae:18:3f:02:ad:39:66:ec:f6:16:23:f0: 80:94:cc:8c:d5:96:9c:63:bc:50:63:07:8b:ad:d5: 86:09:cf:2a:ff:9a:ca:ae:0e:88:07:9b:32:7b:4e: b0:12:a1:df:a9:02:b5:96:9c:61:55:17:30:79:14: 2c:38:ea:18:07:b4:a1:2d:40:a2:5d:62:0b:bd:67: 41:0e:c9:4e:a3:bd:bf:ce:03:ac:0f:ac:fc:a2:7c: 23:6b:05:ea:88:78:7e:c6:2c:ac:6f:8c:67:2b:6f: 15:c7:cb:a7:ad:2e:8c:27:2f:4f:02:92:1d:6d:72: 15:f7:5d:bf:55:be:53:57:c5:0c:38:29:33:a7:f0: 97:02:c9:00:88:0e:bc:7e:2e:23:37:3b:54:ce:98: 24:fd:6c:cd:5b:d4:5e:fe:c4:8b:60:0e:c6:54:63: 7c:d6:ad:91:eb:53:ce:d6:b6:77:9d:9e:fa:20:a7: 20:7f:2f:00:59:4b:af:50:09:f4:8a:61:58:3d:b3: b8:ba:ce:79:a7:66:00:c3:a3:a5:a2:71:ab:b3:6e: 40:66:32:c4:b4:2b:b1:37:f5:0c:93:66:68:54:5c: ba:35:ef:75:62:70:9a:2b:d3:8f:b4:de:3c:79:a4: ea:c3 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Alternative Name: DNS:api.textmarketer.co.uk X509v3 Basic Constraints: CA:FALSE X509v3 CRL Distribution Points: Full Name: URI:http://tn.symcb.com/tn.crl X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 CPS: https://www.thawte.com/cps User Notice: Explicit Text: https://www.thawte.com/repository X509v3 Authority Key Identifier: keyid:9F:B8:C1:A9:6C:F2:F5:C0:22:2A:94:ED:5C:99:AC:D4:EC:D7:C6:07 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication Authority Information Access: OCSP - URI:http://tn.symcd.com CA Issuers - URI:http://tn.symcb.com/tn.crt Signature Algorithm: sha256WithRSAEncryption 84:85:37:ae:9c:6f:e8:3f:3b:3d:da:a4:a9:ff:ba:56:3d:ad: f9:bf:ea:8f:d8:9d:4b:35:ac:73:76:c4:f6:67:1b:c0:1f:fe: 7e:3d:56:3b:70:e0:74:71:bd:0d:e0:cd:a7:03:61:8c:25:72: 4c:6a:c2:db:d7:fd:14:7b:92:0a:8d:2b:0f:f7:c0:c2:0e:46: 65:29:21:cf:b1:aa:ed:92:b0:db:e7:fe:54:de:fb:1a:a7:b0: 61:14:fa:a6:14:ab:99:a3:26:8e:75:97:cf:de:fb:33:25:10: ef:23:da:91:14:d8:2a:d4:cf:0d:dc:e7:14:4b:9a:ed:31:34: e0:a1:7c:1e:2d:0f:e1:52:0d:83:3c:c8:eb:df:43:85:4b:96: 03:e8:75:a6:46:9b:99:6e:02:e4:38:0b:9c:93:c2:8e:97:db: 27:77:75:a6:e6:46:c1:02:bd:d4:14:a0:af:3e:f8:56:4f:94: 0c:e6:d3:49:5e:67:c8:4c:be:75:a3:a5:8f:b6:6a:4c:3d:52: ab:24:ac:e5:69:5f:d7:fe:01:08:ce:24:7a:ad:0f:3c:6f:46: fe:b9:5a:2d:c5:37:00:5e:6b:40:ab:1b:61:7e:8c:13:df:8f: 5c:e1:76:7e:73:e3:28:33:07:3b:31:81:03:fe:91:a2:ec:f5: 99:95:56:ed -----BEGIN CERTIFICATE----- MIIEiDCCA3CgAwIBAgIQIbhrzEcvt7DRDhXrrzBhjzANBgkqhkiG9w0BAQsFADBj MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMdGhhd3RlLCBJbmMuMR0wGwYDVQQLExRE b21haW4gVmFsaWRhdGVkIFNTTDEeMBwGA1UEAxMVdGhhd3RlIERWIFNTTCBDQSAt IEcyMB4XDTE1MDUyNTAwMDAwMFoXDTE3MDcyMzIzNTk1OVowITEfMB0GA1UEAxQW YXBpLnRleHRtYXJrZXRlci5jby51azCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAKbKUMEprU3aJsrerI4Fuv8Arhg/Aq05Zuz2FiPwgJTMjNWWnGO8UGMH i63VhgnPKv+ayq4OiAebMntOsBKh36kCtZacYVUXMHkULDjqGAe0oS1Aol1iC71n QQ7JTqO9v84DrA+s/KJ8I2sF6oh4fsYsrG+MZytvFcfLp60ujCcvTwKSHW1yFfdd v1W+U1fFDDgpM6fwlwLJAIgOvH4uIzc7VM6YJP1szVvUXv7Ei2AOxlRjfNatketT zta2d52e+iCnIH8vAFlLr1AJ9IphWD2zuLrOeadmAMOjpaJxq7NuQGYyxLQrsTf1 DJNmaFRcujXvdWJwmivTj7TePHmk6sMCAwEAAaOCAXgwggF0MCEGA1UdEQQaMBiC FmFwaS50ZXh0bWFya2V0ZXIuY28udWswCQYDVR0TBAIwADArBgNVHR8EJDAiMCCg HqAchhpodHRwOi8vdG4uc3ltY2IuY29tL3RuLmNybDBuBgNVHSAEZzBlMGMGBmeB DAECATBZMCYGCCsGAQUFBwIBFhpodHRwczovL3d3dy50aGF3dGUuY29tL2NwczAv BggrBgEFBQcCAjAjDCFodHRwczovL3d3dy50aGF3dGUuY29tL3JlcG9zaXRvcnkw HwYDVR0jBBgwFoAUn7jBqWzy9cAiKpTtXJms1OzXxgcwDgYDVR0PAQH/BAQDAgWg MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBXBggrBgEFBQcBAQRLMEkw HwYIKwYBBQUHMAGGE2h0dHA6Ly90bi5zeW1jZC5jb20wJgYIKwYBBQUHMAKGGmh0 dHA6Ly90bi5zeW1jYi5jb20vdG4uY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCEhTeu nG/oPzs92qSp/7pWPa35v+qP2J1LNaxzdsT2ZxvAH/5+PVY7cOB0cb0N4M2nA2GM JXJMasLb1/0Ue5IKjSsP98DCDkZlKSHPsartkrDb5/5U3vsap7BhFPqmFKuZoyaO dZfP3vszJRDvI9qRFNgq1M8N3OcUS5rtMTTgoXweLQ/hUg2DPMjr30OFS5YD6HWm RpuZbgLkOAuck8KOl9snd3Wm5kbBAr3UFKCvPvhWT5QM5tNJXmfITL51o6WPtmpM PVKrJKzlaV/X/gEIziR6rQ88b0b+uVotxTcAXmtAqxthfowT349c4XZ+c+MoMwc7 MYED/pGi7PWZlVbt -----END CERTIFICATE----- Certificate: Data: Version: 3 (0x2) Serial Number: 2c:69:e1:2f:6a:67:0b:d9:9d:d2:0f:91:9e:f0:9e:51 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA Validity Not Before: Jun 10 00:00:00 2014 GMT Not After : Jun 9 23:59:59 2024 GMT Subject: C=US, O=thawte, Inc., OU=Domain Validated SSL, CN=thawte DV SSL CA - G2 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ea:94:07:85:c8:41:2c:f6:83:12:6c:92:5f:ab: 1f:00:d4:96:6f:74:cd:2e:11:e9:6c:0f:39:01:b9: 48:90:40:39:4d:c4:a2:c8:79:6a:a5:9a:bd:91:44: 65:77:54:ad:ff:25:5f:ee:42:fb:b3:02:0f:ea:5d: 7a:dd:1a:54:9e:d7:73:42:9b:cc:79:5f:c5:4d:f4: b7:0b:18:39:20:7a:dd:50:01:5d:34:45:5f:4c:11: 0e:f5:87:26:26:b4:b0:f3:7e:71:a0:31:71:50:89: 68:5a:63:8a:14:62:e5:8c:3a:16:55:0d:3e:eb:aa: 80:1d:71:7a:e3:87:07:ab:bd:a2:74:cd:da:08:01: 9d:1b:cc:27:88:8c:47:d4:69:25:42:d6:bb:50:6d: 85:50:d0:48:82:0d:08:9f:e9:23:e3:42:c6:3c:98: b8:bb:6e:c5:70:13:df:19:1d:01:fd:d2:b5:4e:e6: 62:f4:07:fa:6b:7d:11:77:c4:62:4f:40:4e:a5:78: 97:ab:2c:4d:0c:a7:7c:c3:c4:50:32:9f:d0:70:9b: 0f:ff:ff:75:59:34:85:ad:49:d5:35:ee:4f:5b:d4: d4:36:95:a0:7e:e8:c5:a1:1c:bd:13:4e:7d:ee:63: 6a:96:19:99:c8:a7:2a:00:e6:51:8d:46:eb:30:58: e8:2d Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Certificate Policies: Policy: 2.16.840.1.113733.1.7.54 CPS: https://www.thawte.com/cps X509v3 Key Usage: critical Certificate Sign, CRL Sign Authority Information Access: OCSP - URI:http://t.symcd.com X509v3 CRL Distribution Points: Full Name: URI:http://t.symcb.com/ThawtePCA.crl X509v3 Subject Alternative Name: DirName:/CN=SymantecPKI-1-698 X509v3 Subject Key Identifier: 9F:B8:C1:A9:6C:F2:F5:C0:22:2A:94:ED:5C:99:AC:D4:EC:D7:C6:07 X509v3 Authority Key Identifier: keyid:7B:5B:45:CF:AF:CE:CB:7A:FD:31:92:1A:6A:B6:F3:46:EB:57:48:50 Signature Algorithm: sha256WithRSAEncryption 53:54:f2:47:a8:02:d7:ef:aa:35:78:be:4a:08:0d:90:18:4b: 6d:9e:2a:53:2b:e9:54:17:77:74:29:7e:d0:37:07:05:b8:e4: fa:b8:b4:63:98:44:dc:c6:4f:81:06:8c:3a:be:c7:30:57:c6: 70:fc:d6:93:19:9f:c3:55:d7:3e:1f:72:8a:9d:30:5a:35:97: 32:cb:63:e4:c6:72:df:fb:68:ca:69:2f:db:cd:50:38:3e:2b: bb:ab:3b:82:c7:fd:4b:9b:bd:7c:41:98:ef:01:53:d8:35:8f: 25:c9:03:06:e6:9c:57:c1:51:0f:9e:f6:7d:93:4d:f8:76:c8: 3a:6b:f4:c4:8f:33:32:7f:9d:21:84:34:d9:a7:f9:92:fa:41: 91:61:84:05:9d:a3:79:46:ce:67:e7:81:f2:5e:ac:4c:bc:a8: ab:6a:6d:15:e2:9c:4e:5a:d9:63:80:bc:f7:42:eb:9a:44:c6: 8c:6b:06:36:b4:8b:32:89:de:c2:f1:a8:26:aa:a9:ac:ff:ea: 71:a6:e7:8c:41:fa:17:35:bb:b3:87:31:a9:93:c2:c8:58:e1: 0a:4e:95:83:9c:b9:ed:3b:a5:ef:08:e0:74:f9:c3:1b:e6:07: a3:ee:07:d7:42:22:79:21:a0:a1:d4:1d:26:d3:d0:d6:a6:5d: 2b:41:c0:79 -----BEGIN CERTIFICATE----- MIIE0jCCA7qgAwIBAgIQLGnhL2pnC9md0g+RnvCeUTANBgkqhkiG9w0BAQsFADCB qTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDHRoYXd0ZSwgSW5jLjEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjE4MDYGA1UECxMvKGMpIDIw MDYgdGhhd3RlLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNV BAMTFnRoYXd0ZSBQcmltYXJ5IFJvb3QgQ0EwHhcNMTQwNjEwMDAwMDAwWhcNMjQw NjA5MjM1OTU5WjBjMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMdGhhd3RlLCBJbmMu MR0wGwYDVQQLExREb21haW4gVmFsaWRhdGVkIFNTTDEeMBwGA1UEAxMVdGhhd3Rl IERWIFNTTCBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 6pQHhchBLPaDEmySX6sfANSWb3TNLhHpbA85AblIkEA5TcSiyHlqpZq9kURld1St /yVf7kL7swIP6l163RpUntdzQpvMeV/FTfS3Cxg5IHrdUAFdNEVfTBEO9YcmJrSw 835xoDFxUIloWmOKFGLljDoWVQ0+66qAHXF644cHq72idM3aCAGdG8wniIxH1Gkl Qta7UG2FUNBIgg0In+kj40LGPJi4u27FcBPfGR0B/dK1TuZi9Af6a30Rd8RiT0BO pXiXqyxNDKd8w8RQMp/QcJsP//91WTSFrUnVNe5PW9TUNpWgfujFoRy9E0597mNq lhmZyKcqAOZRjUbrMFjoLQIDAQABo4IBOTCCATUwEgYDVR0TAQH/BAgwBgEB/wIB ADBBBgNVHSAEOjA4MDYGCmCGSAGG+EUBBzYwKDAmBggrBgEFBQcCARYaaHR0cHM6 Ly93d3cudGhhd3RlLmNvbS9jcHMwDgYDVR0PAQH/BAQDAgEGMC4GCCsGAQUFBwEB BCIwIDAeBggrBgEFBQcwAYYSaHR0cDovL3Quc3ltY2QuY29tMDEGA1UdHwQqMCgw JqAkoCKGIGh0dHA6Ly90LnN5bWNiLmNvbS9UaGF3dGVQQ0EuY3JsMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFTeW1hbnRlY1BLSS0xLTY5ODAdBgNVHQ4EFgQUn7jB qWzy9cAiKpTtXJms1OzXxgcwHwYDVR0jBBgwFoAUe1tFz6/Oy3r9MZIaarbzRutX SFAwDQYJKoZIhvcNAQELBQADggEBAFNU8keoAtfvqjV4vkoIDZAYS22eKlMr6VQX d3QpftA3BwW45Pq4tGOYRNzGT4EGjDq+xzBXxnD81pMZn8NV1z4fcoqdMFo1lzLL Y+TGct/7aMppL9vNUDg+K7urO4LH/UubvXxBmO8BU9g1jyXJAwbmnFfBUQ+e9n2T Tfh2yDpr9MSPMzJ/nSGENNmn+ZL6QZFhhAWdo3lGzmfngfJerEy8qKtqbRXinE5a 2WOAvPdC65pExoxrBja0izKJ3sLxqCaqqaz/6nGm54xB+hc1u7OHMamTwshY4QpO lYOcue07pe8I4HT5wxvmB6PuB9dCInkhoKHUHSbT0NamXStBwHk= -----END CERTIFICATE----- Certificate: Data: Version: 3 (0x2) Serial Number: 5f:a6:be:80:b6:86:c6:2f:01:ed:0c:ab:b1:96:a1:05 Signature Algorithm: sha1WithRSAEncryption Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=premium-server at thawte.com Validity Not Before: Nov 17 00:00:00 2006 GMT Not After : Dec 30 23:59:59 2020 GMT Subject: C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ac:a0:f0:fb:80:59:d4:9c:c7:a4:cf:9d:a1:59: 73:09:10:45:0c:0d:2c:6e:68:f1:6c:5b:48:68:49: 59:37:fc:0b:33:19:c2:77:7f:cc:10:2d:95:34:1c: e6:eb:4d:09:a7:1c:d2:b8:c9:97:36:02:b7:89:d4: 24:5f:06:c0:cc:44:94:94:8d:02:62:6f:eb:5a:dd: 11:8d:28:9a:5c:84:90:10:7a:0d:bd:74:66:2f:6a: 38:a0:e2:d5:54:44:eb:1d:07:9f:07:ba:6f:ee:e9: fd:4e:0b:29:f5:3e:84:a0:01:f1:9c:ab:f8:1c:7e: 89:a4:e8:a1:d8:71:65:0d:a3:51:7b:ee:bc:d2:22: 60:0d:b9:5b:9d:df:ba:fc:51:5b:0b:af:98:b2:e9: 2e:e9:04:e8:62:87:de:2b:c8:d7:4e:c1:4c:64:1e: dd:cf:87:58:ba:4a:4f:ca:68:07:1d:1c:9d:4a:c6: d5:2f:91:cc:7c:71:72:1c:c5:c0:67:eb:32:fd:c9: 92:5c:94:da:85:c0:9b:bf:53:7d:2b:09:f4:8c:9d: 91:1f:97:6a:52:cb:de:09:36:a4:77:d8:7b:87:50: 44:d5:3e:6e:29:69:fb:39:49:26:1e:09:a5:80:7b: 40:2d:eb:e8:27:85:c9:fe:61:fd:7e:e6:7c:97:1d: d5:9d Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Certificate Policies: Policy: X509v3 Any Policy CPS: https://www.thawte.com/cps X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Subject Key Identifier: 7B:5B:45:CF:AF:CE:CB:7A:FD:31:92:1A:6A:B6:F3:46:EB:57:48:50 X509v3 CRL Distribution Points: Full Name: URI:http://crl.thawte.com/ThawtePremiumServerCA.crl X509v3 Extended Key Usage: Netscape Server Gated Crypto, 2.16.840.1.113733.1.8.1 X509v3 Authority Key Identifier: DirName:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server at thawte.com serial:01 Signature Algorithm: sha1WithRSAEncryption 2b:ca:12:c9:dd:d7:cc:63:1c:9b:31:35:4a:dd:e4:b7:f6:9d: d1:a4:fb:1e:f8:47:f9:ae:07:8e:0d:58:12:fb:da:ed:b5:cc: 33:e5:97:68:47:61:42:d5:66:a9:6e:1e:47:bf:85:db:7d:58: d1:77:5a:cc:90:61:98:9a:29:f5:9d:b1:cf:b8:dc:f3:7b:80: 47:48:d1:7d:f4:68:8c:c4:41:cb:b4:e9:fd:f0:23:e0:b1:9b: 76:2a:6d:28:56:a3:8c:cd:e9:ec:21:00:71:f0:5f:dd:50:a5: 69:42:1b:83:11:5d:84:28:d3:27:ae:ec:2a:ab:2f:60:42:c5: c4:78 -----BEGIN CERTIFICATE----- MIIFUTCCBLqgAwIBAgIQX6a+gLaGxi8B7QyrsZahBTANBgkqhkiG9w0BAQUFADCB zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl cnZlckB0aGF3dGUuY29tMB4XDTA2MTExNzAwMDAwMFoXDTIwMTIzMDIzNTk1OVow gakxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwx0aGF3dGUsIEluYy4xKDAmBgNVBAsT H0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xODA2BgNVBAsTLyhjKSAy MDA2IHRoYXd0ZSwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYD VQQDExZ0aGF3dGUgUHJpbWFyeSBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEArKDw+4BZ1JzHpM+doVlzCRBFDA0sbmjxbFtIaElZN/wLMxnC d3/MEC2VNBzm600JpxzSuMmXNgK3idQkXwbAzESUlI0CYm/rWt0RjSiaXISQEHoN vXRmL2o4oOLVVETrHQefB7pv7un9Tgsp9T6EoAHxnKv4HH6JpOih2HFlDaNRe+68 0iJgDblbnd+6/FFbC6+Ysuku6QToYofeK8jXTsFMZB7dz4dYukpPymgHHRydSsbV L5HMfHFyHMXAZ+sy/cmSXJTahcCbv1N9Kwn0jJ2RH5dqUsveCTakd9h7h1BE1T5u KWn7OUkmHgmlgHtALevoJ4XJ/mH9fuZ8lx3VnQIDAQABo4IBzTCCAckwDwYDVR0T AQH/BAUwAwEB/zA7BgNVHSAENDAyMDAGBFUdIAAwKDAmBggrBgEFBQcCARYaaHR0 cHM6Ly93d3cudGhhd3RlLmNvbS9jcHMwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQW BBR7W0XPr87Lev0xkhpqtvNG61dIUDBABgNVHR8EOTA3MDWgM6Axhi9odHRwOi8v Y3JsLnRoYXd0ZS5jb20vVGhhd3RlUHJlbWl1bVNlcnZlckNBLmNybDAgBgNVHSUE GTAXBglghkgBhvhCBAEGCmCGSAGG+EUBCAEwgeUGA1UdIwSB3TCB2qGB1KSB0TCB zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl cnZlckB0aGF3dGUuY29tggEBMA0GCSqGSIb3DQEBBQUAA4GBACvKEsnd18xjHJsx NUrd5Lf2ndGk+x74R/muB44NWBL72u21zDPll2hHYULVZqluHke/hdt9WNF3WsyQ YZiaKfWdsc+43PN7gEdI0X30aIzEQcu06f3wI+Cxm3YqbShWo4zN6ewhAHHwX91Q pWlCG4MRXYQo0yeu7CqrL2BCxcR4 -----END CERTIFICATE----- From rt at openssl.org Fri Dec 4 17:37:46 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Fri, 04 Dec 2015 17:37:46 +0000 Subject: [openssl-dev] [openssl.org #4165] 1.0.1q release busted, does not compile In-Reply-To: <20151204173730.GA22449@roeckx.be> References: <4563EA1819BE84DB34CB1EEB@[192.168.1.9]> <20151204173730.GA22449@roeckx.be> Message-ID: On Thu, Dec 03, 2015 at 08:08:59PM +0000, Quanah Gibson-Mount via RT wrote: > make[5]: *** No rule to make target `../../include/openssl/idea.h', needed > by `e_idea.o'. Stop. You need to run make depend after configure. From levitte at openssl.org Fri Dec 4 16:53:40 2015 From: levitte at openssl.org (Richard Levitte) Date: Fri, 04 Dec 2015 17:53:40 +0100 (CET) Subject: [openssl-dev] test_ordinals causes make update to fail after make clean In-Reply-To: <5661B4AD.9060500@openssl.org> References: <20151204054709.GN18315@mournblade.imrryr.org> <5661B4AD.9060500@openssl.org> Message-ID: <20151204.175340.1819285926011811965.levitte@openssl.org> In message <5661B4AD.9060500 at openssl.org> on Fri, 4 Dec 2015 15:43:41 +0000, Matt Caswell said: matt> matt> matt> On 04/12/15 15:41, Adam Eijdenberg wrote: matt> > Hi Viktor, matt> > matt> > Yes, I understand it's a developer option, and that there are likely matt> > more appropriate build targets on Darwin, but I don't believe either are matt> > related to the issue that I'm trying to report (which I also get on my matt> > Linux workstation), which is that "make update" now won't work on a matt> > cleanly checked out source tree, whereas it did 2 days ago matt> > (before https://github.com/openssl/openssl/commit/0aca86b313d286be979629a3193a12e17bf7171a). matt> > matt> > Is that expected behavior or not? matt> > matt> > (my understanding of "make update" is that it will call all the things I matt> > might need after making changes to the source, such as re-generating matt> > error files, safestack stuff, make depend etc, so it's kind of nice that matt> > it works before the source itself is built) matt> > matt> matt> This is definitely a problem. I am hitting the same thing. Fixed in f6e9c5533101066b2c759986ae8694c0f1926735 Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From phpdev at ehrhardt.nl Fri Dec 4 17:46:56 2015 From: phpdev at ehrhardt.nl (Jan Ehrhardt) Date: Fri, 04 Dec 2015 18:46:56 +0100 Subject: [openssl-dev] Windows x86_64 build broken -- RE: [openssl-users] OpenSSL version 1.0.1q released (corrected download) References: <3AB7EF789FF16E4C81C5BA3833C2A195133D94B9@prvxmb01.microfocus.com> Message-ID: Carl Tietjen in gmane.comp.encryption.openssl.devel (Fri, 4 Dec 2015 01:33:00 +0000): >Folks, > >It looks like the Windows x86_64 build for OpenSSL version 1.0.1q is broken. > >I am building a FIPS capable version, and have verified that I have the >corrected download build: SHA1 checksum: >c65a7bec49b72092d7ebb97a263c496cc1e1d6af >FYI - I have successfully built on 3 Linux platforms with this tar file. > >Build steps: >1) perl Configure VC-WIN64A fips --with-fipslibdir=c:\FIPS\openssl-fips-ecp-2.0.9 no-ec2m no-idea no-mdc2 no-rc5 >2) ms\do_win64a >3) nmake -f ms\nt.mak >... >NMAKE : fatal error U1073: don't know how to make 'tmp32\applink.obj' Start with nmake -f ms\ntdll.mak and copy tmp32dll\applink.obj to tmp32\applink.obj to continue building. -- Jan From matt at openssl.org Fri Dec 4 20:30:58 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 4 Dec 2015 20:30:58 +0000 Subject: [openssl-dev] EAP-FAST and OpenSSL 1.1.x with new client TLS state machine In-Reply-To: <20151204130834.GA16102@w1.fi> References: <20151203230907.GA9237@w1.fi> <56616AA4.9060506@openssl.org> <20151204130834.GA16102@w1.fi> Message-ID: <5661F802.8050109@openssl.org> On 04/12/15 13:08, Jouni Malinen wrote: > On Fri, Dec 04, 2015 at 10:27:48AM +0000, Matt Caswell wrote: >> EAP-FAST is very strange. Normally you know whether you are resuming a >> session or not based on the session id returned from the server. However >> that's not the case with EAP-FAST - you have to wait to see what message >> the server sends you next to determine what's happening (which is really >> horrible). > > Indeed. EAP-FAST is a good example of what can happen if a company > designs a new EAP method and pushes that to the market without going > through proper IETF review.. This part here is not the only difficult > item in supporting EAP-FAST. :( > >> The new state machine code waits until a message is received from the >> peer and then checks it against its allowed list of transitions based on >> its current state. If its not allowed then you get an unexpected message >> alert. It looks like the check for the EAP-FAST session resumption case >> is missing from the new code. >> >> Please can you try the attached patch and see if that resolves the >> issue? Let me know how you get on. > > Thanks! That fixes the issue. With this applied on top of the current > master branch snapshot, I was able to pass all my EAP regression tests. > This has now been committed to master. Matt From appro at openssl.org Fri Dec 4 22:12:53 2015 From: appro at openssl.org (Andy Polyakov) Date: Fri, 4 Dec 2015 23:12:53 +0100 Subject: [openssl-dev] URGENT QUESTION - about bn_mul.c In-Reply-To: References: Message-ID: <56620FE5.2080705@openssl.org> > I have a simple question: > > - Is the ?*BN_MUL*? algorithm based on *Karatsuba*? > > - If YES please confirm, otherwise could you please explain me what > algorithm is using? And 'grep Karatsuba crypto/bn/*.c' in not an option? But answer to question might be irrelevant. Because on most popular platforms most resource-hungry procedure of modular exponentiation does not use Karatsuba method, because alternative methods (more notably fusing multiplication with Montgomery reduction) were found to deliver better performance. > Confidential Notice: This message - including its attachments - may > contain proprietary, confidential and/or legally protected information > and is intended solely for the use of the designated addressee(s) above. OP is prohibited to read above message, because it's in formal conflict with self-imposed restrictions :-) From wilson.judson at gmail.com Sat Dec 5 09:11:16 2015 From: wilson.judson at gmail.com (Judson Wilson) Date: Sat, 5 Dec 2015 01:11:16 -0800 Subject: [openssl-dev] s_client uses SSL_write(..., 0) for renegotiation? Message-ID: Should s_client really be using a zero-byte-length SSL_write(...) as a followup to SSL_renegotiate(...)? All versions of the man pages on the OpenSSL web site state this will yield undefined behavior (which I find odd, but whatever). Is SSL_do_handshake(...) more appropriate? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilson.judson at gmail.com Sat Dec 5 09:42:18 2015 From: wilson.judson at gmail.com (Judson Wilson) Date: Sat, 5 Dec 2015 01:42:18 -0800 Subject: [openssl-dev] renegotiation failure causes SSL_shutdown to return 1? Message-ID: I am noticing the following sequence of events: 1) SSL_renegotiate(...), followed by SSL_write(..., 0) fails when a web server rejects it by sending a TCP FIN 2) SSL_get_error returns SSL_ERROR_SSL 3) SSL_in_init(...) is true 4) SSL_shutdown returns 1 <-- this seems strange. I'm not sure that this is the right behavior. Shutting down in a handshake without sending/receiving close_notify shouldn't give the "everything shutdown gracefully" signal. Perhaps it would be better to return -1 and signal SSL_ERROR_SSL? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sat Dec 5 10:13:22 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Sat, 05 Dec 2015 10:13:22 +0000 Subject: [openssl-dev] [openssl.org #4156] Wrong expectation of value of _IOB_ENTRIES with Visual Studio 2015 In-Reply-To: <5662B8BE.5020601@openssl.org> References: <5656089E.8010909@ascolab.com> <5662B8BE.5020601@openssl.org> Message-ID: Hi, > when using OpenSSL (1.0.1p) in our applications, we get the error 'No > OPENSSL_Applink' when calling PEM_read_X509_CRL. We build both OpenSSL > and the application using the same C runtime configuration (/MDd), using > Visual Studio 2015 on Windows 10. Original intention with OPENSSL_Applink was to facilitate certain things for old code. This kind of implies that new code should be written in such manner that would *avoid* Applink. For this reason I would recommend to modify application and switch to PEM_read_bio_X509_CRL. But the keyword is that you should let OpenSSL open the file for you by calling BIO_new_file. As opposite to opening yourself and calling BIO_new_fp that is. > After some hours of debugging and comparing with the same scenario using > Visual Studio 2010, I discovered that _IOB_ENTRIES is defined > differently in the two versions of Visual Studio: > > VS2015: c:\Program Files (x86)\Windows > Kits\10\Include\10.0.10150.0\ucrt\stdio.h: #define _IOB_ENTRIES 3 > VS2010: c:\Program Files (x86)\Microsoft Visual Studio > 10.0\VC\include\stdio.h: #define _IOB_ENTRIES 20 > > Now there's code in openssl-1.0.1p\crypto\bio\bss_file.c that seems to > expect _IOB_ENTRIES to have the value 20: > > # if defined(__MINGW32__) && defined(__MSVCRT__) && !defined(_IOB_ENTRIES) > # define _IOB_ENTRIES 20 > # endif > # if defined(_IOB_ENTRIES) > /* Safety net to catch purely internal BIO_set_fp calls */ > if ((size_t)ptr >= (size_t)stdin && > (size_t)ptr < (size_t)(stdin + _IOB_ENTRIES)) > BIO_clear_flags(b, BIO_FLAGS_UPLINK); > # endif > # endif > # ifdef UP_fsetmod > if (b->flags & BIO_FLAGS_UPLINK) > UP_fsetmod(b->ptr, (char)((num & BIO_FP_TEXT) ? 't' : 'b')); > else > # endif > > The 'safety net' does not work here, as _IOB_ENTRIES is too small in > VS2015 and the flags don't get cleared (as for VS2010), so UP_fsetmod is > being called which leads to the 'No OPENSSL_Applink' error. Well, commentary is probably misleading in the context, because "purely internal BIO_set_fp" refers to BIO_set_fp called with FILE * created internally, rather than just any BIO_set_fp called internally. So that if application passes FILE * it created itself, it should expect UPLINK calls. The fact that it worked for you without applink.c in VS2010 is circumstantial. > We kindly ask you to provide a solution for our problem, as we currently > are not able to use OpenSSL in combination with VS2015. Linking the > applink.c into our applications is no option for us, as we would have to > deploy multiple C runtimes (one for OpenSSL and one for the application). Last sentence is false in sense that linking applink.c into application does *not* force you into using multiple C runtimes. It allows to use multiple runtimes, but does not prohibit/prevent using single one. In other words if this is the only reason for not linking the applink.c, then it should be disregarded. But, once again, the right thing to do is to adhere to PEM_read_bio_X509_CRL. This applies to all interfaces that accept FILE *. From rt at openssl.org Sat Dec 5 18:01:53 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Sat, 05 Dec 2015 18:01:53 +0000 Subject: [openssl-dev] [openssl.org #4166] Bug: OpenSSL 1.0.1l fails to verify SOME root CAs: error:num=20:unable to get local issuer certificate In-Reply-To: <5663268C.3090502@openssl.org> References: <56615C48.7010003@schonrocks.com> <20151204171623.GW18315@mournblade.imrryr.org> <5663268C.3090502@openssl.org> Message-ID: > [ Redirecting to openssl-users ] Problem is that if reported is not subscribed to either list, then he won't ever get the message. Whatever comes through is better passed though . > On Fri, Dec 04, 2015 at 03:25:35PM +0000, Oliver Schonrock via RT wrote: > >> To Reproduce: >> $ openssl s_client -connect api.textmarketer.co.uk:443 >> depth=2 C = US, O = "thawte, Inc.", OU = Certification Services >> Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = >> thawte Primary Root CA >> verify error:num=20:unable to get local issuer certificate >> ... > > Despite the CN string, the certificate presented by that server on > the wire is not a root certificate. Well, server is not actually required to send complete chain, it's free to make assumption about root certificate being in client's local store. It's natural assumption and is common place. What happens in this case is that this last root certificate is not present in OS-provided chain, which naturally causes failure to build the chain. This is not OpenSSL problem, but OS configuration. Case is being dismissed. > See the attached chain. > > Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=premium-server at thawte.com > Validity > Not Before: Nov 17 00:00:00 2006 GMT > Not After : Dec 30 23:59:59 2020 GMT > Subject: C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA > >> The same command on FreeBSD 10.2 (OpenSSL 1.0.1p) results in: >> $ openssl s_client -connect api.textmarketer.co.uk:443 >> depth=2 C = US, O = "thawte, Inc.", OU = Certification Services >> Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = >> thawte Primary Root CA >> verify return:1 > > In 1.0.1p OpenSSL looks in the trust store before consulting the > provided chain. You likely have a better Thawte certificate there > than the one sent by the server. From rt at openssl.org Sun Dec 6 22:48:58 2015 From: rt at openssl.org (PGNet Dev via RT) Date: Sun, 06 Dec 2015 22:48:58 +0000 Subject: [openssl-dev] [openssl.org #4168] openssl-1.0.2e local build incorrectly links libssl.so against *system*, not local, libcrypto.so In-Reply-To: <56647C8C.3020509@gmail.com> References: <56647C8C.3020509@gmail.com> Message-ID: Building openssl-1.0.2e from src wget http://www.openssl.org/source/openssl-1.0.2e.tar.gz tar zxvf openssl-1.0.2e.tar.gz cd openssl-1.0.2e on lsb_release -rd Description: openSUSE Leap 42.1 (x86_64) Release: 42.1 gcc --version gcc (SUSE Linux) 5.2.1 20151130 [gcc-5-branch revision 231058] Copyright (C) 2015 Free Software Foundation, Inc. ./config ... make -j4 make install completes without build-time error ls -al \ /usr/local/ssl/bin/openssl \ /usr/local/ssl/lib64/libssl* -rwxr-xr-x+ 1 root root 617K Dec 6 10:10 /usr/local/ssl/bin/openssl* -rw-r--r--+ 1 root root 719K Dec 6 10:10 /usr/local/ssl/lib64/libssl.a lrwxrwxrwx 1 root root 15 Dec 6 10:10 /usr/local/ssl/lib64/libssl.so -> libssl.so.1.0.0* -r-xr-xr-x+ 1 root root 486K Dec 6 10:10 /usr/local/ssl/lib64/libssl.so.1.0.0* Checking linking for the bin ldd /usr/local/ssl/bin/openssl | egrep "ssl|crypto" libssl.so.1.0.0 => /usr/local/ssl/lib64/libssl.so.1.0.0 (0x00007fd161a34000) libcrypto.so.1.0.0 => /usr/local/ssl/lib64/libcrypto.so.1.0.0 (0x00007fd1615ed000) , it's correctly linked to the just-built libs. But the libssl is INCORRECTLY linked to the *system* librypto, NOT the just-built instance, ldd /usr/local/ssl/lib64/lib{ssl,crypto}.so.1.0.0 | egrep "ssl|crypto" libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007ff3ebeb5000) Can be remedied AFTER the incorrect build ldd /usr/local/ssl/lib64/libssl.so.1.0.0 | egrep "ssl|crypto" libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007f55e46c0000) readelf --dynamic /usr/local/ssl/lib64/libssl.so.1.0.0 | egrep -i "rpath|runpath" (empty) patchelf --set-rpath "/usr/local/ssl/lib64" --force-rpath /usr/local/ssl/lib64/libssl.so.1.0.0 readelf --dynamic /usr/local/ssl/lib64/libssl.so.1.0.0 | egrep -i "rpath|runpath" 0x000000000000000f (RPATH) Library rpath: [/usr/local/ssl/lib64] ldd /usr/local/ssl/lib64/libssl.so | egrep "ssl|crypto" libcrypto.so.1.0.0 => /usr/local/ssl/lib64/libcrypto.so.1.0.0 (0x00007f476b4fc000) _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Dec 6 22:48:58 2015 From: rt at openssl.org (PGNet Dev via RT) Date: Sun, 06 Dec 2015 22:48:58 +0000 Subject: [openssl-dev] [openssl.org #4169] openssl-1.0.2e build still recommends deprecated (unnecessary?) `make depend`, returns numerous warnings abt not finding stddef.h In-Reply-To: <566478DD.4030105@gmail.com> References: <566478DD.4030105@gmail.com> Message-ID: Building openssl-1.0.2e from src wget http://www.openssl.org/source/openssl-1.0.2e.tar.gz tar zxvf openssl-1.0.2e.tar.gz cd openssl-1.0.2e on lsb_release -rd Description: openSUSE Leap 42.1 (x86_64) Release: 42.1 gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/5/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada,go --enable-checking=release --with-gxx-include-dir=/usr/include/c++/5 --enable-ssp --disable-libssp --disable-libvtv --enable-libmpx --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --with-default-libstdcxx-abi=gcc4-compatible --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-5 --without-system-libunwind --enable-multilib --with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux Thread model: posix gcc version 5.2.1 20151130 [gcc-5-branch revision 231058] (SUSE Linux) gcc -print-search-dirs install: /usr/lib64/gcc/x86_64-suse-linux/5/ programs: =/usr/lib64/gcc/x86_64-suse-linux/5/:/usr/lib64/gcc/x86_64-suse-linux/5/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/5/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/x86_64-suse-linux/5/:/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ libraries: =/usr/lib64/gcc/x86_64-suse-linux/5/:/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/lib/x86_64-suse-linux/5/:/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/lib/../lib64/:/usr/lib64/gcc/x86_64-suse-linux/5/../../../x86_64-suse-linux/5/:/usr/lib64/gcc/x86_64-suse-linux/5/../../../../lib64/:/lib/x86_64-suse-linux/5/:/lib/../lib64/:/usr/lib/x86_64-suse-linux/5/:/usr/lib/../lib64/:/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/lib/:/usr/lib64/gcc/x86_64-suse-linux/5/../../../:/lib/:/usr/lib/ with following config ./config ... \ enable-ec_nistp_64_gcc_128 \ enable-rfc3779 \ enable-ecdsa \ no-idea \ no-ssl2 \ no-rc5 \ no-rc2 \ no-mdc2 invokes need for subsequent `make depend` ... Since you've disabled or enabled at least one algorithm, you need to do the following before building: make depend Configured for linux-x86_64. which completes, but reports many instances of 'stddef.h' not found, make depend making depend in crypto... make[1]: Entering directory '/usr/local/src/openssl-TEST/openssl-1.0.2e/crypto' makedepend: warning: cryptlib.c (reading /usr/include/stdlib.h, line 32): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: /usr/include/time.h includes /usr/include/bits/types.h more than once! Already have /usr/include/bits/types.h makedepend: warning: /usr/include/time.h includes /usr/include/bits/types.h more than once! Already have /usr/include/bits/types.h makedepend: warning: /usr/include/time.h includes /usr/include/bits/types.h more than once! Already have /usr/include/bits/types.h makedepend: warning: cryptlib.c (reading /usr/include/sys/types.h, line 146): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h ... On this machine locate stddef.h /usr/include/linux/stddef.h /usr/lib64/gcc/x86_64-suse-linux/4.8/include/stddef.h /usr/lib64/gcc/x86_64-suse-linux/5/include/stddef.h /usr/src/linux-4.3.0-21.g0e6e680/include/linux/stddef.h /usr/src/linux-4.3.0-21.g0e6e680/include/uapi/linux/stddef.h This same issue is raised, and unanswered at [openssl-dev] `make depend`, advised by ./config, fails to find stddef.h in system/compiler path. old bug (#3566) says don't bother with `make depend`? true, or another bug? https://mta.openssl.org/pipermail/openssl-dev/2015-April/001263.html Also references this BUG http://openssl-dev.openssl.narkive.com/93uFX5UC/openssl-org-3566-openssl-1-0-1j-make-depend-failes with comment Stephen Henson via RT 2014-10-16 12:50:20 UTC Obviously this needs fixing but as a workaround: if you're building from scratch (or after "make clean") it should compile fine with without doing "make depend". Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org with no subsequent fix or reference If I skip `make depend` make clean ./config ... make -j4 build completes with no obvious errors At this upstream bug, 2007-2011, Bug 10021 - [makedepend] complains of being unable to find stddef.h, stdarg.h and others (edit) https://bugs.freedesktop.org/show_bug.cgi?id=10021 " Jeremy Huddleston Sequoia 2011-10-09 03:11:01 UTC If you want to submit a patch to add this support, we'll certainly consider it, but nobody really cares about makedepend any more since we migrated away from that build system..." It's reasonable to expect to get a consistent/uptodate 'story' about the use of 'make depend' ... makedepend's been deprecated. it seems it's NOT necessary (?) to a successful build of openssl from src. the advice from the build system to use it is questionable, if not unnecessary. _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From leif.thuresson at foxt.com Mon Dec 7 09:53:15 2015 From: leif.thuresson at foxt.com (Leif Thuresson) Date: Mon, 7 Dec 2015 10:53:15 +0100 Subject: [openssl-dev] Need CVE-2015-3193 impact explained Message-ID: <5665570B.3040306@foxt.com> The description of CVE-2015-3193 in 2015-12-04 security advisory states that EC algorithms are not affected, but attacks against DH are considered feasible. Not being a cryptographer that leaves me a bit confused. Are applications supporting cipher suites with ECDHE- variants vulnerable? Thanks, /Leif From openssl-users at dukhovni.org Mon Dec 7 09:59:43 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 7 Dec 2015 09:59:43 +0000 Subject: [openssl-dev] Need CVE-2015-3193 impact explained In-Reply-To: <5665570B.3040306@foxt.com> References: <5665570B.3040306@foxt.com> Message-ID: <20151207095942.GY18315@mournblade.imrryr.org> On Mon, Dec 07, 2015 at 10:53:15AM +0100, Leif Thuresson wrote: > The description of CVE-2015-3193 in 2015-12-04 security advisory > states that EC algorithms are not affected, but attacks against DH are > considered feasible. DH as distinct from ECDH. The issue affects modular exponentiation which is used in RSA and (finite-field) DH, but not ECDSA or ECDH. > Not being a cryptographer that leaves me a bit confused. > Are applications supporting cipher suites with ECDHE- variants vulnerable? Only to the extent that they are already vulnerable as a result of using RSA certificates to sign the key exchange parameters. The key exchange itself is not. -- Viktor. From appro at openssl.org Mon Dec 7 10:00:23 2015 From: appro at openssl.org (Andy Polyakov) Date: Mon, 7 Dec 2015 11:00:23 +0100 Subject: [openssl-dev] Need CVE-2015-3193 impact explained In-Reply-To: <5665570B.3040306@foxt.com> References: <5665570B.3040306@foxt.com> Message-ID: <566558B7.8030705@openssl.org> > The description of CVE-2015-3193 in 2015-12-04 security advisory > states that EC algorithms are not affected, but attacks against DH are > considered feasible. > Not being a cryptographer that leaves me a bit confused. > Are applications supporting cipher suites with ECDHE- variants vulnerable? *No* EC algorithms are affected. Advisory refers to non-EC DH key exchange. So that answer to specific question is no. From leif.thuresson at foxt.com Mon Dec 7 10:12:56 2015 From: leif.thuresson at foxt.com (Leif Thuresson) Date: Mon, 7 Dec 2015 11:12:56 +0100 Subject: [openssl-dev] Need CVE-2015-3193 impact explained In-Reply-To: <20151207095942.GY18315@mournblade.imrryr.org> References: <5665570B.3040306@foxt.com> <20151207095942.GY18315@mournblade.imrryr.org> Message-ID: <56655BA8.5020603@foxt.com> On 2015-12-07 10:59, Viktor Dukhovni wrote: > On Mon, Dec 07, 2015 at 10:53:15AM +0100, Leif Thuresson wrote: > >> The description of CVE-2015-3193 in 2015-12-04 security advisory >> states that EC algorithms are not affected, but attacks against DH are >> considered feasible. > DH as distinct from ECDH. The issue affects modular exponentiation > which is used in RSA and (finite-field) DH, but not ECDSA or ECDH. > >> Not being a cryptographer that leaves me a bit confused. >> Are applications supporting cipher suites with ECDHE- variants vulnerable? > Only to the extent that they are already vulnerable as a result of > using RSA certificates to sign the key exchange parameters. The > key exchange itself is not. > Thanks for the quick response. That is what I needed to know. regards, /Leif From rt at openssl.org Mon Dec 7 12:42:49 2015 From: rt at openssl.org (Stig Ekstrom via RT) Date: Mon, 07 Dec 2015 12:42:49 +0000 Subject: [openssl-dev] [openssl.org #4170] Illegal instruction in sha1-586.asm when building for win32 using Visual Studio 2015 In-Reply-To: References: Message-ID: When building openss-1.0.2e for win32 using Visual Studio 2015 I get error in the assembler code: ml /nologo /Cp /coff /c /Cx /Zi /Fotmp32dll\sha1-586.obj tmp32dll\sha1-586.asm Assembling: tmp32dll\sha1-586.asm tmp32dll\sha1-586.asm(1432) : error A2070:invalid instruction operands tmp32dll\sha1-586.asm(1576) : error A2070:invalid instruction operands NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\ml.EXE"' : return code '0x1' Stop. When building for win64 it builds without any errors. Regards Stig Ekstr?m -------------- next part -------------- A non-text attachment was scrubbed... Name: sha1-586-asm.zip Type: application/zip Size: 8681 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Dec 7 12:59:24 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 07 Dec 2015 12:59:24 +0000 Subject: [openssl-dev] [openssl.org #4170] Illegal instruction in sha1-586.asm when building for win32 using Visual Studio 2015 In-Reply-To: <566582AB.2010004@openssl.org> References: <566582AB.2010004@openssl.org> Message-ID: > When building openss-1.0.2e for win32 using Visual Studio 2015 I get error > in the assembler code: > > ml /nologo /Cp /coff /c /Cx /Zi /Fotmp32dll\sha1-586.obj > tmp32dll\sha1-586.asm > Assembling: tmp32dll\sha1-586.asm > tmp32dll\sha1-586.asm(1432) : error A2070:invalid instruction operands > tmp32dll\sha1-586.asm(1576) : error A2070:invalid instruction operands > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual > Studio 14.0\VC\BIN\ml.EXE"' : return code > '0x1' > Stop. > > When building for win64 it builds without any errors. Quoting INSTALL.W32: - you need ... - Netwide Assembler, a.k.a. NASM, available from http://nasm.sourceforge.net/ is required if you intend to utilize assembler modules. Note that NASM is now the only supported assembler. From fweimer at redhat.com Mon Dec 7 13:41:35 2015 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 7 Dec 2015 14:41:35 +0100 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151125174834.GA7307@roeckx.be> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <20151123204824.GC9363@localhost> <20151123220832.GA17864@roeckx.be> <5655A355.4060501@redhat.com> <20151125174834.GA7307@roeckx.be> Message-ID: <56658C8F.1010305@redhat.com> On 11/25/2015 06:48 PM, Kurt Roeckx wrote: > On Wed, Nov 25, 2015 at 01:02:29PM +0100, Florian Weimer wrote: >> On 11/23/2015 11:08 PM, Kurt Roeckx wrote: >> >>> I think that we currently don't do any compile / link test to >>> detect features but that we instead explicitly say so for each >>> platform. >>> >>> Anyway, the gcc the documentation is here: >>> https://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html >>> >>> TLS support clearly isn't supported everywhere. >> >> The most portable approach is to switch C++11, which provides you >> thread-local variables with destructors (and you also get portable >> atomics). There are simply no standards-based C solutions as long as >> you have to support the Microsoft compiler under Windows. > > Please note that we use C, not C++. But C11 has the same atomics > extentions as C++11. C++11 support is much more widespread than C11 support. You will have trouble finding reliable support for C11 atomics with the Microsoft toolchain. > We're also currently still targetting C89/C90 (with some minor > extentions), but I think we should try to use them if the platform > supports it. It is a lot of working getting the atomics right on all supported platforms. Florian From rt at openssl.org Mon Dec 7 15:07:34 2015 From: rt at openssl.org (Paul Kehrer via RT) Date: Mon, 07 Dec 2015 15:07:34 +0000 Subject: [openssl-dev] [openssl.org #4171] Compile failure on OS X 10.7 clang with OpenSSL 1.0.2e In-Reply-To: References: Message-ID: https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=301a6dcd4590fb2f69d08259577e215b4cc3caa3#patch5 added a check to see if it should use the ADDX instructions based on the clang version. Unfortunately, on older versions of clang on OS X this check incorrectly returns true and compilation then fails due to not knowing the instructions: x86_64-mont.s:966:2 error: invalid instruction mnemonic 'adcxq' adcxq %rax,%r12 ^~~~~ The version of the compiler in question is: `Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)` (On an ancient OS X 10.7 VM) This issue was also filed in Github (https://github.com/openssl/openssl/issues/494) -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Dec 7 15:47:56 2015 From: rt at openssl.org (Michel via RT) Date: Mon, 07 Dec 2015 15:47:56 +0000 Subject: [openssl-dev] [openssl.org #4173] help to check whether handshake negociates SRP or PSK ciphersuite In-Reply-To: <003401d13104$78233ae0$6869b0a0$@sales@free.fr> References: <003401d13104$78233ae0$6869b0a0$@sales@free.fr> Message-ID: Hi, I believe it would be nice to have an efficient way to check if handshake results in a SRP or PSK ciphersuite. As I do not like to trick with OpenSSL internal structures, I suggest to add the following to ssl_ciph.c : int SSL_CIPHER_is_PSK(const SSL_CIPHER *c) { if (c != NULL && c->algorithm_auth == SSL_aPSK) return 1; return 0; } int SSL_CIPHER_is_SRP(const SSL_CIPHER *c) { if (c != NULL && c->algorithm_auth == SSL_aSRP) return 1; return 0; } Might be a better alternative ? By the way, I do not see a reason why SSL_CIPHER_get_id() is not protected against NULL pointer dereference of SSL_CIPHER *c as in SSL_CIPHER_get_bits() or SSL_CIPHER_get_name(). A patch against 1.0.2e is attached, but need update of .def ordinals. Thanks for your work, Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: ssl_ciph-1.0.2e.patch Type: application/octet-stream Size: 1302 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Dec 7 15:47:57 2015 From: rt at openssl.org (Rob Stradling via RT) Date: Mon, 07 Dec 2015 15:47:57 +0000 Subject: [openssl-dev] [openssl.org #4174] Support the TLS Feature (aka Must Staple) X.509v3 extension (RFC7633) In-Reply-To: <5665A835.1020206@comodo.com> References: <5665A835.1020206@comodo.com> Message-ID: https://github.com/openssl/openssl/pull/495 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Dec 7 15:47:56 2015 From: rt at openssl.org (Michel via RT) Date: Mon, 07 Dec 2015 15:47:56 +0000 Subject: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory In-Reply-To: <003a01d13105$d6b66450$84232cf0$@sales@free.fr> References: <003a01d13105$d6b66450$84232cf0$@sales@free.fr> Message-ID: Hi, Following my previous mail, here attached is an updated patch against 1.02e to fix the SRP VBASE memory leaks. I understand the VBASE stuff is not a TLS critical component, but it is part of the SRP command line tool. NB : it's a pity that the base64 encoding is not the same than the one use elsewhere by OpenSSL. Regards, Michel. De : openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Michel Envoy? : lundi 23 mars 2015 12:10 ? : openssl-dev at openssl.org Objet : [openssl-dev] SRP memory leaks and more leaks Hi, Trying to use the 'SRP' code, I found two kinds of memory leaks in srp_vfy.c . 1) The first kind was due to bad use of OpenSSL 'stack' code and cumbersome / confusing names of structure / functions. In this case, leaks occurs when loading a verifier file containing 'index' lines. Two structures are used : SRP_gN and SRP_gN_cache. And unfortunatly, the SRP_gN_free function free a SRP_gN_cache structure. The SRP_VBASE_free() function, line 276, should call : sk_SRP_gN_cache_pop_free(vb->gN_cache, SRP_gN_cache_free); instead of : sk_SRP_gN_cache_free(vb->gN_cache); And consequently the SRP_gN_cache_free() function, lines 305-312, has to move before SRP_VBASE_free() The attached patch solve this kind of leaks. 2) When simulating a 'fake user' as per RFC 5054, ? '2.5.1.3. Unknown SRP User Name', the SRP_VBASE_get_by_user() function returns a newly allocated SRP_user_pwd structure whose adress is not kept anywhere else. So, the caller should free it later, but from outside the function, there is no way to distinguish between 'fake users' and real ones which are managed and freed throught the use of the SRP_VBASE structure / functions. I am afraid there is no other solution than changing the SRP_VBASE_get_by_user() function prototype. It is better I do not share here my opinion about the comments below : /* need to check whether there are memory leaks */, s_server.c line 433 or : /* there may be still some leaks to fix, */ srp_vfy.c line 449 >:( Hope this will save time to other users, Michel. -------------- next part -------------- A non-text attachment was scrubbed... Name: srp_vfy-1.0.2e.patch Type: application/octet-stream Size: 3035 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From nico at cryptonector.com Mon Dec 7 20:50:56 2015 From: nico at cryptonector.com (Nico Williams) Date: Mon, 7 Dec 2015 14:50:56 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <56658C8F.1010305@redhat.com> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <20151123204824.GC9363@localhost> <20151123220832.GA17864@roeckx.be> <5655A355.4060501@redhat.com> <20151125174834.GA7307@roeckx.be> <56658C8F.1010305@redhat.com> Message-ID: <20151207205055.GN23318@localhost> On Mon, Dec 07, 2015 at 02:41:35PM +0100, Florian Weimer wrote: > On 11/25/2015 06:48 PM, Kurt Roeckx wrote: > > Please note that we use C, not C++. But C11 has the same atomics > > extentions as C++11. > > C++11 support is much more widespread than C11 support. You will have > trouble finding reliable support for C11 atomics with the Microsoft > toolchain. > > [...] > > It is a lot of working getting the atomics right on all supported platforms. The MSFT toolchain has its own intrisics, as do GCC/clang. A variety of OSes have their own atomics libraries (e.g., Solaris/Illumos, FreeBSD, and others). Linux has several as well, but I am not sure that the licensing on those will be compatible to link against (much less to incorporate as source in OpenSSL). Some of the BSD or CDDL licensed libraries might be possible to incorporate as source into OpenSSL. It's a solvable problem, but yes, a lot of work :( Still, it seems worth doing. Nico -- From nico at cryptonector.com Mon Dec 7 21:02:30 2015 From: nico at cryptonector.com (Nico Williams) Date: Mon, 7 Dec 2015 15:02:30 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151207205055.GN23318@localhost> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <20151123204824.GC9363@localhost> <20151123220832.GA17864@roeckx.be> <5655A355.4060501@redhat.com> <20151125174834.GA7307@roeckx.be> <56658C8F.1010305@redhat.com> <20151207205055.GN23318@localhost> Message-ID: <20151207210229.GO23318@localhost> Maybe http://trac.mpich.org/projects/openpa/ would fit the bill? From fw at deneb.enyo.de Tue Dec 8 10:19:32 2015 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 08 Dec 2015 11:19:32 +0100 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151207210229.GO23318@localhost> (Nico Williams's message of "Mon, 7 Dec 2015 15:02:30 -0600") References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <20151123204824.GC9363@localhost> <20151123220832.GA17864@roeckx.be> <5655A355.4060501@redhat.com> <20151125174834.GA7307@roeckx.be> <56658C8F.1010305@redhat.com> <20151207205055.GN23318@localhost> <20151207210229.GO23318@localhost> Message-ID: <87fuzdgs3v.fsf@mid.deneb.enyo.de> * Nico Williams: > Maybe http://trac.mpich.org/projects/openpa/ would fit the bill? It seems to have trouble to keep up with new architectures. From rt at openssl.org Tue Dec 8 12:51:11 2015 From: rt at openssl.org (Long, Qin via RT) Date: Tue, 08 Dec 2015 12:51:11 +0000 Subject: [openssl-dev] [openssl.org #4175] Add new macro or PKCS7 flag to disable the check for both data and content In-Reply-To: References: Message-ID: The OpenSSL new release / HEAD updates removed the following comment-out statement in PKCS7_verify() routine, which will return error for one call if both embedded-content and detached data were provided. #if 0 --> Removed /* * NB: this test commented out because some versions of Netscape * illegally include zero length content when signing data. */ /* Check for data and content: two sets of data */ if (!PKCS7_get_detached(p7) && indata) { PKCS7err(PKCS7_F_PKCS7_VERIFY, PKCS7_R_CONTENT_AND_DATA_PRESENT); return 0; } #endif This update will break some existing Authenticode verification solutions which leveraged the Pkcs7_verify() interface, such as UEFI secure boot, and other open-source utilities (e.g. osslsigncode). The root cause is the Authenticode is one extended PKCS7 format, and its verification process is different (the embedded data is one extended structure (SpcIndirectDataContent), and will not be used directly for signature verification) . The old comment-out in PKCS7_verify just helped to support the Authenticode verification with embedded p7data and user-supplied inData (some extra checking will be handled outside). It's better to introduce one new macro or new PKCS7 flag to re-enable this capability. E.g. #if !defined(OPENSSL_ALLOW_PKCS7_CONTENT_AND_DATA_PRESENT) .... Or If (!(flags & PKCS7_NO_CHECK_BOTH_DATASET)) ... If two data sets (embedded and detached data) were present, the input data will be the default Input for validation (just as the current logic.), so there should be no risk. Best Regards & Thanks, LONG, Qin -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Dec 8 12:56:02 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 08 Dec 2015 12:56:02 +0000 Subject: [openssl-dev] [openssl.org #4175] Add new macro or PKCS7 flag to disable the check for both data and content In-Reply-To: References: Message-ID: I think that instead of the #ifdef being removed, the if() test should be removed. This was my mistake. From rt at openssl.org Tue Dec 8 14:31:27 2015 From: rt at openssl.org (Hannes Mezger via RT) Date: Tue, 08 Dec 2015 14:31:27 +0000 Subject: [openssl-dev] [openssl.org #4156] Wrong expectation of value of _IOB_ENTRIES with Visual Studio 2015 In-Reply-To: <5666E9B0.3070804@ascolab.com> References: <5656089E.8010909@ascolab.com> <5662B8BE.5020601@openssl.org> <5666E9B0.3070804@ascolab.com> Message-ID: Hi, thanks for the detailed explanation. We can change our code to use the BIO-functionality instead of using FILE pointers, so far this works fine and even simplifies our code. But two issues remain: 1. There is still no explanation on why it worked fine with Visual Studio 2005 - 2013 (yes, checked all of those). To me it seems that the code either doesn't handle the changed _IOB_ENTRIES correctly or is not prepared to work with the new Windows 10 SDK. 2. The more important issue: we use 'ERR_print_errors_fp(stderr)' to print OpenSSL errors directly to stderr. This doesn't work, too. But it can't be fixed by using the 'ERR_print_errors()' function instead, as creating the BIO using 'BIO_new_fp(stderr, BIO_NOCLOSE)' also fails with the same error (no Applink). Is there a recommentation what to use in that case? Best regards, Hannes *Hannes Mezger* ascolab GmbH Tel.: +49 9131 691 124 Fax: +49 9131 691 128 Web: http://www.ascolab.com GPG-KeyId: 46EC1280 GPG-Fingerprint: D28A DE55 05FA 2FF3 8628 323A 1D6E 9EC8 46EC 1280 -- ascolab GmbH - Am Weichselgarten 7 - 91058 Erlangen - Germany Handelsregister/Commercial Register: Amtsgericht F?rth HRB 9360 Gesch?ftsf?hrer/Managing Directors: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrau? This email contains confidential information and is for the exclusive use of the addressee. If you are not the addressee, then any distribution, copying or use of this email is prohibited. If received in error, please advise the sender and delete immediately. We accept no liability for any loss or damage suffered by any person arising from use of this email. Am 05.12.2015 um 11:13 schrieb Andy Polyakov via RT: > Hi, > >> when using OpenSSL (1.0.1p) in our applications, we get the error 'No >> OPENSSL_Applink' when calling PEM_read_X509_CRL. We build both OpenSSL >> and the application using the same C runtime configuration (/MDd), using >> Visual Studio 2015 on Windows 10. > Original intention with OPENSSL_Applink was to facilitate certain things > for old code. This kind of implies that new code should be written in > such manner that would *avoid* Applink. For this reason I would > recommend to modify application and switch to PEM_read_bio_X509_CRL. But > the keyword is that you should let OpenSSL open the file for you by > calling BIO_new_file. As opposite to opening yourself and calling > BIO_new_fp that is. > >> After some hours of debugging and comparing with the same scenario using >> Visual Studio 2010, I discovered that _IOB_ENTRIES is defined >> differently in the two versions of Visual Studio: >> >> VS2015: c:\Program Files (x86)\Windows >> Kits\10\Include\10.0.10150.0\ucrt\stdio.h: #define _IOB_ENTRIES 3 >> VS2010: c:\Program Files (x86)\Microsoft Visual Studio >> 10.0\VC\include\stdio.h: #define _IOB_ENTRIES 20 >> >> Now there's code in openssl-1.0.1p\crypto\bio\bss_file.c that seems to >> expect _IOB_ENTRIES to have the value 20: >> >> # if defined(__MINGW32__) && defined(__MSVCRT__) && !defined(_IOB_ENTRIES) >> # define _IOB_ENTRIES 20 >> # endif >> # if defined(_IOB_ENTRIES) >> /* Safety net to catch purely internal BIO_set_fp calls */ >> if ((size_t)ptr >= (size_t)stdin && >> (size_t)ptr < (size_t)(stdin + _IOB_ENTRIES)) >> BIO_clear_flags(b, BIO_FLAGS_UPLINK); >> # endif >> # endif >> # ifdef UP_fsetmod >> if (b->flags & BIO_FLAGS_UPLINK) >> UP_fsetmod(b->ptr, (char)((num & BIO_FP_TEXT) ? 't' : 'b')); >> else >> # endif >> >> The 'safety net' does not work here, as _IOB_ENTRIES is too small in >> VS2015 and the flags don't get cleared (as for VS2010), so UP_fsetmod is >> being called which leads to the 'No OPENSSL_Applink' error. > Well, commentary is probably misleading in the context, because "purely > internal BIO_set_fp" refers to BIO_set_fp called with FILE * created > internally, rather than just any BIO_set_fp called internally. So that > if application passes FILE * it created itself, it should expect UPLINK > calls. The fact that it worked for you without applink.c in VS2010 is > circumstantial. > >> We kindly ask you to provide a solution for our problem, as we currently >> are not able to use OpenSSL in combination with VS2015. Linking the >> applink.c into our applications is no option for us, as we would have to >> deploy multiple C runtimes (one for OpenSSL and one for the application). > Last sentence is false in sense that linking applink.c into application > does *not* force you into using multiple C runtimes. It allows to use > multiple runtimes, but does not prohibit/prevent using single one. In > other words if this is the only reason for not linking the applink.c, > then it should be disregarded. But, once again, the right thing to do is > to adhere to PEM_read_bio_X509_CRL. This applies to all interfaces that > accept FILE *. > > From rt at openssl.org Tue Dec 8 16:46:42 2015 From: rt at openssl.org (Long, Qin via RT) Date: Tue, 08 Dec 2015 16:46:42 +0000 Subject: [openssl-dev] [openssl.org #4175] Add new macro or PKCS7 flag to disable the check for both data and content In-Reply-To: References: Message-ID: Agree. It will be more straight to remove the if() test here, since the later logic will handle the inData directly if this parameter was provided. > -----Original Message----- > From: Salz, Rich via RT [mailto:rt at openssl.org] > Sent: Tuesday, December 8, 2015 8:56 PM > To: Long, Qin > Cc: openssl-dev at openssl.org > Subject: RE: [openssl-dev] [openssl.org #4175] Add new macro or PKCS7 flag to disable the check for both data and content > > I think that instead of the #ifdef being removed, the if() test should be removed. > This was my mistake. > From nico at cryptonector.com Tue Dec 8 17:22:01 2015 From: nico at cryptonector.com (Nico Williams) Date: Tue, 8 Dec 2015 11:22:01 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <87fuzdgs3v.fsf@mid.deneb.enyo.de> References: <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <20151123204824.GC9363@localhost> <20151123220832.GA17864@roeckx.be> <5655A355.4060501@redhat.com> <20151125174834.GA7307@roeckx.be> <56658C8F.1010305@redhat.com> <20151207205055.GN23318@localhost> <20151207210229.GO23318@localhost> <87fuzdgs3v.fsf@mid.deneb.enyo.de> Message-ID: <20151208172200.GC23318@localhost> On Tue, Dec 08, 2015 at 11:19:32AM +0100, Florian Weimer wrote: > > Maybe http://trac.mpich.org/projects/openpa/ would fit the bill? > > It seems to have trouble to keep up with new architectures. New architectures are not really a problem because between a) decent compilers with C11 and/or non-C11 atomic intrinsics, b) asm-coded atomics, and c) mutex-based dumb atomics, we can get full coverage. Anyone who's still not satisfied can then contribute missing asm-coded atomics to OpenPA. I suspect that OpenSSL using OpenPA is likely to lead to contributions to OpenPA that will make it better anyways. What's the alternative anyways? We're talking about API and performance enhancements to OpenSSL to go faster on platforms for which there are atomics, and maybe slower otherwise -- or maybe not; maybe we can implement context up-/down-ref functions that use fine-grained (or even global) locking as a fallback that yields performance comparable to today's. If OpenPA's (or some other such library's) license works for OpenSSL, someone might start using it. That someone might be me. So that seems like a good question to ask: is OpenPA's license compatible with OpenSSL's? For inclusion into OpenSSL's tree, or for use by OpenSSL? Nico -- From paul.dale at oracle.com Tue Dec 8 23:27:16 2015 From: paul.dale at oracle.com (Paul Dale) Date: Wed, 09 Dec 2015 09:27:16 +1000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151208172200.GC23318@localhost> References: <20151123174937.GA9363@localhost> <87fuzdgs3v.fsf@mid.deneb.enyo.de> <20151208172200.GC23318@localhost> Message-ID: <3076174.zi5TWTTx77@acid> It will be possible to support atomics in such a way that there is no performance penalty for machines without them or for single threaded operation. My sketcy design is along the lines of adding a new API CRYPTO_add_atomic that takes the same arguments as CRYPTO_add (i.e. reference to counter, value to add and lock to use): CRYPTO_add_atomic(int *addr, int amount, int lock) if have-atomics then atomic_add(addr, amount) else if (lock == have-lock-already) *addr += amount else CRYPTO_add(addr, amount, lock) The have-lock-already will need to be a new code that indicates that the caller has the relevant lock held and there is no need to lock before the add. Some conditional compilation like CRYPTO_add & CRYPTO_add_lock have can be done to get the overhead down to zero in the single threaded case and the case where it is known beforehand that there are no atomic operations. It is also possible for the atomic_add function to be passed in as a user call back as per the other locking callbacks which means OSSL doesn't actually need to know how any of this works underneath. Once this is done, most instances of CRYPTO_add can be changed to CRYPTO_add_atomic. Unfortunately, not all can be changed, so this would involve manual inspection of each lock for which CRYPTO_add is used to see if atomics are suitable. I've done a partial list of which could be changed over (attached) but it is pretty rough and needs rechecking. It would be prudent to have a CRYPTO_add_atomic_lock call underneath CRYPTO_add_atomic, like CRYPTO_add has CRYPTO_add_lock, to get the extra debug output. Finally, can someone explain what the callback passed to CRYPTO_set_add_lock_callback is supposed to do? Superficially, it seems like a way to use atomic operations instead of full locking -- but that breaks things due to the way the locking is done elsewhere. So this call back needs to lock, add and unlock like the alternate code path in the CRYPTO_add_lock function. There is no obvious benefit to providing it. Pauli On Tue, 8 Dec 2015 11:22:01 AM Nico Williams wrote: > On Tue, Dec 08, 2015 at 11:19:32AM +0100, Florian Weimer wrote: > > > Maybe http://trac.mpich.org/projects/openpa/ would fit the bill? > > > > It seems to have trouble to keep up with new architectures. > > New architectures are not really a problem because between a) decent > compilers with C11 and/or non-C11 atomic intrinsics, b) asm-coded > atomics, and c) mutex-based dumb atomics, we can get full coverage. > Anyone who's still not satisfied can then contribute missing asm-coded > atomics to OpenPA. I suspect that OpenSSL using OpenPA is likely to > lead to contributions to OpenPA that will make it better anyways. > > What's the alternative anyways? > > We're talking about API and performance enhancements to OpenSSL to go > faster on platforms for which there are atomics, and maybe slower > otherwise -- or maybe not; maybe we can implement context up-/down-ref > functions that use fine-grained (or even global) locking as a fallback > that yields performance comparable to today's. > > If OpenPA's (or some other such library's) license works for OpenSSL, > someone might start using it. That someone might be me. So that seems > like a good question to ask: is OpenPA's license compatible with > OpenSSL's? For inclusion into OpenSSL's tree, or for use by OpenSSL? > > Nico > -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- Lock # Note CRYPTO_LOCK_ERR 28 one problem with decrement using CRYPTO_add -- leave as is CRYPTO_LOCK_EX_DATA 7 safe, no CRYPTO_add CRYPTO_LOCK_X509 10 most likely safe, needs deeper recheck down call chains CRYPTO_LOCK_X509_INFO 2 safe, only uses CRYPTO_add CRYPTO_LOCK_X509_PKEY 2 safe, only uses CRYPTO_add CRYPTO_LOCK_X509_CRL 5 unsure CRYPTO_LOCK_X509_REQ 2 only ASN1_SEQUENCE_re CRYPTO_LOCK_DSA 5 safe with atomic add (double check)? CRYPTO_LOCK_RSA 19 most likely safe, needs deeper recheck down call chains CRYPTO_LOCK_EVP_PKEY 27 safe with atomic add CRYPTO_LOCK_X509_STORE 35 assume unsafe, one CRYPTO_add only CRYPTO_LOCK_SSL_CTX 26 one increment unsafe, rest seems okay -> make increment atomic CRYPTO_LOCK_SSL_CERT 3 safe, only uses CRYPTO_add CRYPTO_LOCK_SSL_SESSION 9 safe if atomic add is used inside locked block in ssl/ssl_sess.c CRYPTO_LOCK_SSL_SESS_CERT 1 unused CRYPTO_LOCK_SSL 11 safe without compression, probably safe with but would need a double check CRYPTO_LOCK_SSL_METHOD 1 unused CRYPTO_LOCK_RAND 16 safe, no CRYPTO_add CRYPTO_LOCK_RAND2 11 safe, no CRYPTO_add CRYPTO_LOCK_MALLOC 13 safe, no CRYPTO_add CRYPTO_LOCK_BIO 8 safe with atomic add CRYPTO_LOCK_GETHOSTBYNAME 3 safe, no CRYPTO_add CRYPTO_LOCK_GETSERVBYNAME 3 safe, no CRYPTO_add CRYPTO_LOCK_READDIR 3 safe, no CRYPTO_add CRYPTO_LOCK_RSA_BLINDING 4 safe, no CRYPTO_add CRYPTO_LOCK_DH 5 safe with atomic add CRYPTO_LOCK_MALLOC2 9 safe, no CRYPTO_add CRYPTO_LOCK_DSO 3 safe, only uses CRYPTO_add CRYPTO_LOCK_DYNLOCK 12 safe, no CRYPTO_add CRYPTO_LOCK_ENGINE 65 unsafe, two CRYPTO_add -- eave as is. CRYPTO_LOCK_UI 3 safe, no CRYPTO_add CRYPTO_LOCK_ECDSA 1 unused CRYPTO_LOCK_EC 7 safe to change to atomic add outside locked blocks CRYPTO_LOCK_ECDH 1 unused CRYPTO_LOCK_BN 2 unused CRYPTO_LOCK_EC_PRE_COMP 16 safe, only uses CRYPTO_add CRYPTO_LOCK_STORE 1 unused CRYPTO_LOCK_COMP 1 unused CRYPTO_LOCK_FIPS 1 unused CRYPTO_LOCK_FIPS2 1 unused From nico at cryptonector.com Wed Dec 9 04:01:20 2015 From: nico at cryptonector.com (Nico Williams) Date: Tue, 8 Dec 2015 22:01:20 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <3076174.zi5TWTTx77@acid> References: <20151123174937.GA9363@localhost> <87fuzdgs3v.fsf@mid.deneb.enyo.de> <20151208172200.GC23318@localhost> <3076174.zi5TWTTx77@acid> Message-ID: <20151209040119.GB3198@localhost> On Wed, Dec 09, 2015 at 09:27:16AM +1000, Paul Dale wrote: > It will be possible to support atomics in such a way that there is no > performance penalty for machines without them or for single threaded > operation. My sketcy design is along the lines of adding a new API > CRYPTO_add_atomic that takes the same arguments as CRYPTO_add (i.e. > reference to counter, value to add and lock to use): > > CRYPTO_add_atomic(int *addr, int amount, int lock) > if have-atomics then > atomic_add(addr, amount) > else if (lock == have-lock-already) > *addr += amount > else > CRYPTO_add(addr, amount, lock) "have-atomics" must be known at compile time. "lock" should not be needed because we should always have atomics, even when we don't have true atomics: just use a global lock in a stub implementation of atomic_add() and such. KISS. Besides, this will add pressure to add true atomics wherever they are truly needed. Nico -- From paul.dale at oracle.com Wed Dec 9 04:33:13 2015 From: paul.dale at oracle.com (Paul Dale) Date: Wed, 09 Dec 2015 14:33:13 +1000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151209040119.GB3198@localhost> References: <20151123174937.GA9363@localhost> <3076174.zi5TWTTx77@acid> <20151209040119.GB3198@localhost> Message-ID: <2625168.mWHZQFq4te@acid> The "have-atomics" is intended to test if the callback was installed by the user. If we're using an atomic library or compiler support, then it isn't required since we know we've got them. Likewise, the lock argument isn't required if atomics are used everywhere. However, some code will need fixing since there are places that adjust reference counters directly using arithmetic operators (while holding the appropriate lock). These will have to be changed to atomics and the locked sections of code checked to see that that doesn't introduce other problems. All possible of course. Pauli On Tue, 8 Dec 2015 10:01:20 PM Nico Williams wrote: > On Wed, Dec 09, 2015 at 09:27:16AM +1000, Paul Dale wrote: > > It will be possible to support atomics in such a way that there is no > > performance penalty for machines without them or for single threaded > > operation. My sketcy design is along the lines of adding a new API > > CRYPTO_add_atomic that takes the same arguments as CRYPTO_add (i.e. > > reference to counter, value to add and lock to use): > > > > CRYPTO_add_atomic(int *addr, int amount, int lock) > > if have-atomics then > > atomic_add(addr, amount) > > else if (lock == have-lock-already) > > *addr += amount > > else > > CRYPTO_add(addr, amount, lock) > > "have-atomics" must be known at compile time. > > "lock" should not be needed because we should always have atomics, even > when we don't have true atomics: just use a global lock in a stub > implementation of atomic_add() and such. KISS. Besides, this will add > pressure to add true atomics wherever they are truly needed. > > Nico > -- -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From ashwini.vpatil at siemens.com Wed Dec 9 05:07:14 2015 From: ashwini.vpatil at siemens.com (Patil, Ashwini IN BLR SHC) Date: Wed, 9 Dec 2015 10:37:14 +0530 Subject: [openssl-dev] Openssl 1.0.2e is compatible with FIPS module openssl-fips-2.0.10 Message-ID: <8878620CF8603E45BB794422B7899E9E1370600CE1@INBLRK77M1MSX.in002.siemens.net> Hello All, Please let me know if the Openssl 1.0.2e is compatible with FIPS module openssl-fips-2.0.10. Your help is appreciated. With best regards, Ashwini V Patil Siemens Healthcare Private Limited HC SI DC IN H1-FH STD IBP 6 84, Hosur Road Bengaluru 560100, Indien Mobil: +91 9008132565 mailto:ashwini.vpatil at siemens.com Registered Office: 130, Pandurang Budhkar Marg, Worli, Mumbai 400 018. Telephone +91 22 39677000. Fax +91 22 39677075. Other Offices: Bengaluru. Corporate Identity number: U74999MH2015PTC264859 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jyothi.v at freescale.com Wed Dec 9 06:10:13 2015 From: jyothi.v at freescale.com (Vemulapalli Jyothi) Date: Wed, 9 Dec 2015 06:10:13 +0000 Subject: [openssl-dev] procedure for adding new engine registration In-Reply-To: <5645CCED.2000804@openssl.org> References: <5645B361.7040908@openssl.org> <5645CCED.2000804@openssl.org> Message-ID: Hi Matt, We could successfully execute dynamic engine support. Thanks for help. One issue regarding cleanup. When I gone through openssl cleanup (ie apps_shutdown() or engine interface cleanup ) functionality, I see that there are two function pointers that can set to ENGINE interface: destroy and finish. But after completion of openssl command execution or when invoking quit from openssl utility, these function pointers are not getting invoked. In apps_shutdown(), I can see the call to ENGINE_cleanup(). But this cleanup is internal to openssl library. How can we set our engine de-init function pointer to openssl, where it should be invoked part of apps_shutdown() call. We are using openssl-1.0.1g version. Can you please give us some data on this. Thank you, Jyothi -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Friday, November 13, 2015 5:14 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] procedure for adding new engine registration On 13/11/15 11:16, Vemulapalli Jyothi wrote: > Hi Matt, > > Very useful information. > > I too agree with you that we need not have a new engine distribution. > > I see some options like dynamic engines and static engine support. > > If we have built a library with dynamic engine interface, how can we do speed test using openssl speed command. As follows (on Linux): OPENSSL_ENGINES=/path/to/my/engine/dir openssl speed -engine myengine Matt _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From nico at cryptonector.com Wed Dec 9 08:33:46 2015 From: nico at cryptonector.com (Nico Williams) Date: Wed, 9 Dec 2015 02:33:46 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <2625168.mWHZQFq4te@acid> References: <20151123174937.GA9363@localhost> <3076174.zi5TWTTx77@acid> <20151209040119.GB3198@localhost> <2625168.mWHZQFq4te@acid> Message-ID: No more installing callbacks to get locking and atomics. This has to all work out of the box (the user could be allowed tip supply their own implementations if these things at OpenSSL build time, but that's it, not at run-time). Nico -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico at cryptonector.com Wed Dec 9 09:27:51 2015 From: nico at cryptonector.com (Nico Williams) Date: Wed, 9 Dec 2015 03:27:51 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: References: <20151123174937.GA9363@localhost> <3076174.zi5TWTTx77@acid> <20151209040119.GB3198@localhost> <2625168.mWHZQFq4te@acid> Message-ID: <20151209092749.GC3198@localhost> On Wed, Dec 09, 2015 at 02:33:46AM -0600, Nico Williams wrote: > No more installing callbacks to get locking and atomics. I should explain why. First, lock callbacks are a serious detriment to usability. Second, they are an admission that OpenSSL is incomplete. Third, if we have lock callbacks to install, then we have the risk of racing (by multiple libraries using OpenSSL) to install them. Unless there's a single function to install *all* such callbacks, then there's no way to install callbacks atomically. But every once in a while we'll need to add an Nth callback, thus breaking the ABI or atomicity. So, no, no lock callbacks. OpenSSL should work thread-safely out of the box like other libraries. That means that the default configuration should be to use pthreads on *nix, for example. We'll need an atomics library (e.g., OpenPA, or something new) with safe and sane -if not very performant- defaults that use global locks for platform/compiler combinations where there's no built-in atomics intrinsics or system library. It should be possible to have a no-threads configuration where the locks and atomics are non-concurrent-safe implementations. Nico -- From levitte at openssl.org Wed Dec 9 09:43:15 2015 From: levitte at openssl.org (Richard Levitte) Date: Wed, 09 Dec 2015 10:43:15 +0100 (CET) Subject: [openssl-dev] procedure for adding new engine registration In-Reply-To: References: <5645CCED.2000804@openssl.org> Message-ID: <20151209.104315.614492458186916920.levitte@openssl.org> If your engine's 'destroy' isn't being invoked, you might want to have a look at what ENGINE_remove() does, and ultimately, engine_free_util() (found in crypto/engine/eng_lib.c). Those should be called as part of ENGINE_cleanup(). Cheers, Richard In message on Wed, 9 Dec 2015 06:10:13 +0000, Vemulapalli Jyothi said: jyothi.v> Hi Matt, jyothi.v> jyothi.v> We could successfully execute dynamic engine support. jyothi.v> Thanks for help. jyothi.v> jyothi.v> One issue regarding cleanup. jyothi.v> When I gone through openssl cleanup (ie apps_shutdown() or engine interface cleanup ) functionality, I see that there are two function pointers that can set to ENGINE interface: destroy and finish. jyothi.v> jyothi.v> But after completion of openssl command execution or when invoking quit from openssl utility, these function pointers are not getting invoked. jyothi.v> In apps_shutdown(), I can see the call to ENGINE_cleanup(). But this cleanup is internal to openssl library. How can we set our engine de-init function pointer to openssl, where it should be invoked part of apps_shutdown() call. jyothi.v> jyothi.v> We are using openssl-1.0.1g version. jyothi.v> jyothi.v> Can you please give us some data on this. jyothi.v> jyothi.v> Thank you, jyothi.v> Jyothi jyothi.v> jyothi.v> jyothi.v> jyothi.v> -----Original Message----- jyothi.v> From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell jyothi.v> Sent: Friday, November 13, 2015 5:14 PM jyothi.v> To: openssl-dev at openssl.org jyothi.v> Subject: Re: [openssl-dev] procedure for adding new engine registration jyothi.v> jyothi.v> jyothi.v> jyothi.v> On 13/11/15 11:16, Vemulapalli Jyothi wrote: jyothi.v> > Hi Matt, jyothi.v> > jyothi.v> > Very useful information. jyothi.v> > jyothi.v> > I too agree with you that we need not have a new engine distribution. jyothi.v> > jyothi.v> > I see some options like dynamic engines and static engine support. jyothi.v> > jyothi.v> > If we have built a library with dynamic engine interface, how can we do speed test using openssl speed command. jyothi.v> jyothi.v> As follows (on Linux): jyothi.v> jyothi.v> OPENSSL_ENGINES=/path/to/my/engine/dir openssl speed -engine myengine jyothi.v> jyothi.v> jyothi.v> Matt jyothi.v> jyothi.v> _______________________________________________ jyothi.v> openssl-dev mailing list jyothi.v> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev jyothi.v> _______________________________________________ jyothi.v> openssl-dev mailing list jyothi.v> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev jyothi.v> From emilia at openssl.org Wed Dec 9 11:15:45 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Wed, 9 Dec 2015 12:15:45 +0100 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <56582015.7010109@cryptsoft.com> References: <3CB9005A-76B1-4F42-BA72-DE46AB82C27D@akamai.com> <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <201511210210.tAL2AvJi030500@d23av02.au.ibm.com> <56535644.3010002@wisemo.com> <56582015.7010109@cryptsoft.com> Message-ID: To close off this thread: OpenSSL will not be making any changes. The team voted on moving a set of algorithms to maintenance mode, and removing the corresponding assembly implementations from libcrypto, but the vote did not pass. Emilia On Fri, Nov 27, 2015 at 10:19 AM, Tim Hudson wrote: > On 24/11/2015 4:09 AM, Jakob Bohm wrote: > > But they care very much if Cisco AnyConnect (or any other > > OpenSSL using program they may need) stops working or > > becomes insecure because the OpenSSL team is breaking > > stuff just because it is not needed in their own handful > > of example uses. > > The OpenSSL team (like most open source projects) is made up of > individuals that have widely varying backgrounds and experiences - and > those experiences lead to different view points on a lot of fairly > fundamental topics. This is a good thing - as frankly a project that > doesn't have a mix of view points tends to not last. > > Between the OpenSSL team members our experiences cover a very wide range > of uses and many of us have been working on the code base for 17+ years > and have worked in areas that are certainly well outside the average or > common uses. However despite that experience we certainly don't think > that we know what all the users of the code base are doing. > > Increasingly we are making sure any debate on project direction where > there are mixed view points within the team brings in the openssl-users > and/or openssl-dev lists so we get to have input from a wider set of > people - who may or may not represent uses that we don't already know > about. > > All the view points being expressed are valid and there are good reasons > why we could as a team head in either direction (dropping out code or > keeping everything or anything along that spectrum) and what is > important is to listen to the input and see the varying points of view > and add that into the decision making process. > > So if you have a use of OpenSSL that you think the team might not know > about then please express that clearly on the list. View points on what > has been proposed are also welcome - but I think you'll find increasing > the awareness of the team about what our users are doing is the more > important of the two objectives in seeking feedback. > > Tim. > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Wed Dec 9 13:06:28 2015 From: marquess at openssl.com (Steve Marquess) Date: Wed, 9 Dec 2015 08:06:28 -0500 Subject: [openssl-dev] Openssl 1.0.2e is compatible with FIPS module openssl-fips-2.0.10 In-Reply-To: <8878620CF8603E45BB794422B7899E9E1370600CE1@INBLRK77M1MSX.in002.siemens.net> References: <8878620CF8603E45BB794422B7899E9E1370600CE1@INBLRK77M1MSX.in002.siemens.net> Message-ID: <56682754.5060602@openssl.com> On 12/09/2015 12:07 AM, Patil, Ashwini IN BLR SHC wrote: > Hello All, > > Please let me know if the Openssl 1.0.2e is compatible with FIPS module > openssl-fips-2.0.10. > Your help is appreciated. The OpenSSL FIPS Object Module v2.0 (all openssl-fips-2.0.N.tar.gz tarballs for the #1747, #2398, #2473 validations) is compatible with all OpenSSL 1.0.1 and 1.0.2 releases. We have 2.0.11 and 2.0.12 revisions in process (and waiting and waiting...); those and any subsequent 2.0.N revisions will also be compatible with 1.0.1 and 1.0.2. It will not be compatible with the upcoming 1.1 releases. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From rsalz at akamai.com Wed Dec 9 13:32:18 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 9 Dec 2015 13:32:18 +0000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151209040119.GB3198@localhost> References: <20151123174937.GA9363@localhost> <87fuzdgs3v.fsf@mid.deneb.enyo.de> <20151208172200.GC23318@localhost> <3076174.zi5TWTTx77@acid> <20151209040119.GB3198@localhost> Message-ID: <6c52b0fc18ed4925a226c95302fd4309@usma1ex-dag1mb1.msg.corp.akamai.com> > "have-atomics" must be known at compile time. > > "lock" should not be needed because we should always have atomics, even > when we don't have true atomics: just use a global lock in a stub > implementation of atomic_add() and such. KISS. Besides, this will add > pressure to add true atomics wherever they are truly needed. Agree. From rsalz at akamai.com Wed Dec 9 13:34:46 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 9 Dec 2015 13:34:46 +0000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <2625168.mWHZQFq4te@acid> References: <20151123174937.GA9363@localhost> <3076174.zi5TWTTx77@acid> <20151209040119.GB3198@localhost> <2625168.mWHZQFq4te@acid> Message-ID: <1dd0d9b933794e19a367743cd778cd84@usma1ex-dag1mb1.msg.corp.akamai.com> > The "have-atomics" is intended to test if the callback was installed by the > user. I want to move away from runtime callback installations. It makes it too hard to know what the library is doing, if it is correct, and it complicates the code. There is almost never any reason for the flexibility that OpenSSL "used to" have. :) From uri at ll.mit.edu Wed Dec 9 14:02:28 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 9 Dec 2015 14:02:28 +0000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread Message-ID: <20151209140236.17788988.66944.39524@ll.mit.edu> +2 to Rich and Nico. Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Salz, Rich Sent: Wednesday, December 9, 2015 08:37 To: paul.dale at oracle.com; openssl-dev at openssl.org; Nico Williams Reply To: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread > The "have-atomics" is intended to test if the callback was installed by the > user. I want to move away from runtime callback installations. It makes it too hard to know what the library is doing, if it is correct, and it complicates the code. There is almost never any reason for the flexibility that OpenSSL "used to" have. :) _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From steve at openssl.org Wed Dec 9 14:41:44 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 9 Dec 2015 14:41:44 +0000 Subject: [openssl-dev] Windows x86_64 build broken -- RE: [openssl-users] OpenSSL version 1.0.1q released (corrected download) In-Reply-To: <3AB7EF789FF16E4C81C5BA3833C2A195133D94B9@prvxmb01.microfocus.com> References: <3AB7EF789FF16E4C81C5BA3833C2A195133D94B9@prvxmb01.microfocus.com> Message-ID: <20151209144144.GA2891@openssl.org> On Fri, Dec 04, 2015, Carl Tietjen wrote: > Folks, > > It looks like the Windows x86_64 build for OpenSSL version 1.0.1q is broken. > > I am building a FIPS capable version, and have verified that I have the corrected download build: SHA1 checksum: c65a7bec49b72092d7ebb97a263c496cc1e1d6af > FYI - I have successfully built on 3 Linux platforms with this tar file. > > Build steps: > 1) perl Configure VC-WIN64A fips --with-fipslibdir=c:\FIPS\openssl-fips-ecp-2.0.9 no-ec2m no-idea no-mdc2 no-rc5 > 2) ms\do_win64a > 3) nmake -f ms\nt.mak > ... > NMAKE : fatal error U1073: don't know how to make 'tmp32\applink.obj' > Fixed in commit 544058202be49a6 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Wed Dec 9 16:48:00 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Wed, 09 Dec 2015 16:48:00 +0000 Subject: [openssl-dev] [openssl.org #4131] Memory leak when parsing invalid X509_ATTRIBUTE In-Reply-To: References: Message-ID: Assigned CVE-2015-3195 and fixed now. Thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From paul.dale at oracle.com Wed Dec 9 21:06:15 2015 From: paul.dale at oracle.com (Paul Dale) Date: Thu, 10 Dec 2015 07:06:15 +1000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151209092749.GC3198@localhost> References: <20151123174937.GA9363@localhost> <20151209092749.GC3198@localhost> Message-ID: <1586844.JSXKrFSBPO@acid> Nico, Thanks for the clarification. I was making an assumption that following the existing locking model, which did seem over complicated, was desirable. Now that that is shot down, things can be much simpler. It would make more sense to have a structure containing the reference counter and (optionally?) a lock to use for that counter. With atomics, the lock isn't there or at least isn't used. Without them, it is. This is because, I somewhat suspect having a fall back global lock for all atomic operations would be worse than the current situation were at least a few different locks are used. There is also the possibility of only using the per reference counter lock and not using atomic operations at all -- this would reduce the contention a lot and might not hurt performance much. It would be easy to benchmark an uncontested lock/add/unlock versus atomic add on the target platforms to see the difference. Thanks against for the insights, Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia On Wed, 9 Dec 2015 03:27:51 AM Nico Williams wrote: > On Wed, Dec 09, 2015 at 02:33:46AM -0600, Nico Williams wrote: > > No more installing callbacks to get locking and atomics. > > I should explain why. > > First, lock callbacks are a serious detriment to usability. > > Second, they are an admission that OpenSSL is incomplete. > > Third, if we have lock callbacks to install, then we have the risk of > racing (by multiple libraries using OpenSSL) to install them. Unless > there's a single function to install *all* such callbacks, then there's > no way to install callbacks atomically. But every once in a while we'll > need to add an Nth callback, thus breaking the ABI or atomicity. > > So, no, no lock callbacks. OpenSSL should work thread-safely out of the > box like other libraries. That means that the default configuration > should be to use pthreads on *nix, for example. We'll need an atomics > library (e.g., OpenPA, or something new) with safe and sane -if not very > performant- defaults that use global locks for platform/compiler > combinations where there's no built-in atomics intrinsics or system > library. It should be possible to have a no-threads configuration where > the locks and atomics are non-concurrent-safe implementations. > > Nico > -- From uri at ll.mit.edu Wed Dec 9 21:24:41 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 9 Dec 2015 21:24:41 +0000 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? Message-ID: I?m having a problem, and am not sure whether it?s due to my ignorance/misuse of the tool (i.e. it should be done differently), or a bug in the tool, or it?s just not capable of doing what I want it to. What I?m trying to accomplish: use engine_pkcs11 with OpenSSL to sign and decrypt with private keys on a smart card, accessed as a PKCS#11 token. To support this engine, I?ve also installed libp11 , and of course OpenSC itself. This shows that OpenSC works and accesses the smart card successfully: $ p11tool --provider /Library/OpenSC/lib/opensc-pkcs11.dylib --list-privkeys --login Token 'PIV_II (PIV Card Holder pin)' with URL 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=PIV _II%20%28PIV%20Card%20Holder%20pin%29' requires user PIN Enter PIN: Object 0: URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=PIV_ II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object=PIV%20AUTH%20key;object-t ype=private Type: Private key Label: PIV AUTH key Flags: CKA_WRAP/UNWRAP; CKA_PRIVATE; CKA_SENSITIVE; ID: 01 Object 1: URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=PIV_ II%20%28PIV%20Card%20Holder%20pin%29;id=%02;object=SIGN%20key;object-type=pr ivate Type: Private key Label: SIGN key Flags: CKA_PRIVATE; CKA_SENSITIVE; ID: 02 Object 2: URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=PIV_ II%20%28PIV%20Card%20Holder%20pin%29;id=%03;object=KEY%20MAN%20key;object-ty pe=private Type: Private key Label: KEY MAN key Flags: CKA_WRAP/UNWRAP; CKA_PRIVATE; CKA_SENSITIVE; ID: 03 Object 3: URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=PIV_ II%20%28PIV%20Card%20Holder%20pin%29;id=%04;object=CARD%20AUTH%20key;object- type=private Type: Private key Label: CARD AUTH key Flags: CKA_SENSITIVE; ID: 04 This shows that OpenSSL does seem to load the engine, but fails to access the key on the smart card: $ openssl engine pkcs11 -t (pkcs11) pkcs11 engine [ available ] $ openssl req -engine pkcs11 -new -key "pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=PIV _II%20%28PIV%20Card%20Holder%20pin%29;id=%02;object=SIGN%20key;object-type=p rivate;pin-value=123456" -keyform engine -out req.pem -text -x509 -subj "/CN=Tester" engine "pkcs11" set. specified object not found PKCS11_get_private_key returned NULL cannot load Private Key from engine 140735296230224:error:26096080:engine routines:ENGINE_load_private_key:failed loading private key:eng_pkey.c:124: unable to load Private Key $ LOAD_CERT_CTRL=true VERBOSE=7 openssl pkeyutl -engine pkcs11 -sign -inkey "pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -keyform engine -out config.status.sig -in config.status.hash engine "pkcs11" set. Error opening Private Key pkcs11:object=SIGN%20key;object-type=private;pin-value=123456 140735296230224:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen('pkcs11:object=SIGN%20key;object-type=private ;pin-value=123456','r') 140735296230224:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400: unable to load Private Key Error initializing context Usage: pkeyutl [options] -in file input file -out file output file -sigfile file signature file (verify operation only) -inkey file input key -keyform arg private key format - default PEM -pubin input is a public key -certin input is a certificate carrying a public key -pkeyopt X:Y public key options -sign sign with private key -verify verify with public key -verifyrecover verify with public key, recover original data -encrypt encrypt with public key -decrypt decrypt with private key -derive derive shared secret -hexdump hex dump output -engine e use engine e, possibly a hardware device. -passin arg pass phrase source $ I would appreciate guidance regarding how to accomplish what I?m trying to do, and whether it is possible to do so staying within the OpenSSL CLI. Thanks! P.S. I followed the README from https://github.com/OpenSC/engine_pkcs11 as an example of how to use OpenSSL with engine_pkcs11 and the token. -- Regards, Uri Blumenthal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From nico at cryptonector.com Wed Dec 9 22:47:45 2015 From: nico at cryptonector.com (Nico Williams) Date: Wed, 9 Dec 2015 16:47:45 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <1586844.JSXKrFSBPO@acid> References: <20151123174937.GA9363@localhost> <20151209092749.GC3198@localhost> <1586844.JSXKrFSBPO@acid> Message-ID: <20151209224744.GH3198@localhost> On Thu, Dec 10, 2015 at 07:06:15AM +1000, Paul Dale wrote: > Thanks for the clarification. I was making an assumption that > following the existing locking model, which did seem over complicated, > was desirable. Now that that is shot down, things can be much > simpler. Exactly :) Sorry if I was a bit brusque. Since inertia is strong, I figured I needed to make a forceful argument. However, it seems it was easy to get consensus after all. > It would make more sense to have a structure containing the reference > counter and (optionally?) a lock to use for that counter. It'd work but it'd be a complication, since now every integer to be used with atomic increment/decrement, or CAS, or whatever, now needs to be a struct type with the integer as one field and the rest as opaque. It'd be much nicer to be able to use ints normally, though I would agree that having a special type for atomics has the benefit that it is self-describing. It's perfectly fine to have a worst-case atomics implementation that uses a global lock. Yes, that would be slow, but we need some incentive to add true atomics for each platform, and making it slow is the exact right incentive. So even if for documentation and type-safety reasons we wanted to wrap ints in structs for ints meant to be used with atomics, I'd still want the worst-case atomics implementation to be slow. > With atomics, the lock isn't there or at least isn't used. Without > them, it is. This is because, I somewhat suspect having a fall back > global lock for all atomic operations would be worse than the current > situation were at least a few different locks are used. That's a feature :) Nico -- From ron.jordan at oracle.com Thu Dec 10 00:54:47 2015 From: ron.jordan at oracle.com (Ron Jordan) Date: Wed, 9 Dec 2015 16:54:47 -0800 Subject: [openssl-dev] Where are include/openssl symbolic links created? Message-ID: <5668CD57.4070800@oracle.com> Hi Folks, I have test workspace on Solaris 10 where I was able to build openssl-1.0.1p. I'm attempting to update to openssl-1.0.1q and am running into issues. Some of the header file symbolic links in include/openssl (ec.h, ecdh.h, idea.h, mcd2.h, seed.h, whrlpool.h) are not being created and I'm seeing errors like the following: ar: creating ../libcrypto.a gmake[3]: *** No rule to make target `../../include/openssl/ec.h', needed by `hm_pmeth.o'. gmake[3]: *** No rule to make target `../../include/openssl/ecdh.h', needed by `hm_pmeth.o'. gmake[3]: *** No rule to make target `../../include/openssl/ecdsa.h', needed by `hm_pmeth.o'. gmake[3]: Target `all' not remade because of errors. gmake[2]: *** [subdirs] Error 1 gmake[2]: Target `all' not remade because of errors. gmake[1]: *** [build_crypto] Error 1 This is due to my workspace environment I'm sure, but I haven't been able to find where the symbolic links in include/openssl are created. I still have some digging to do, but if anyone can point me to the make/config/install file that creates them, I'd appreciate it. Thank you! Ron Jordan From levitte at openssl.org Thu Dec 10 00:57:46 2015 From: levitte at openssl.org (Richard Levitte) Date: Thu, 10 Dec 2015 01:57:46 +0100 Subject: [openssl-dev] Where are include/openssl symbolic links created? In-Reply-To: <5668CD57.4070800@oracle.com> References: <5668CD57.4070800@oracle.com> Message-ID: <3A4C70BC-C033-43A4-8350-247BD5332008@openssl.org> . /Configure probably said you need to run 'make depend'. I suggest you do just that. Cheers Richard On December 10, 2015 1:54:47 AM GMT+01:00, Ron Jordan wrote: >Hi Folks, > >I have test workspace on Solaris 10 where I was able to build >openssl-1.0.1p. I'm attempting to update to openssl-1.0.1q and am >running into issues. Some of the header file symbolic links in >include/openssl (ec.h, ecdh.h, idea.h, mcd2.h, seed.h, whrlpool.h) are > >not being created and I'm seeing errors like the following: > > ar: creating ../libcrypto.a > gmake[3]: *** No rule to make target `../../include/openssl/ec.h', >needed by `hm_pmeth.o'. > gmake[3]: *** No rule to make target `../../include/openssl/ecdh.h', >needed by `hm_pmeth.o'. > gmake[3]: *** No rule to make target `../../include/openssl/ecdsa.h', >needed by `hm_pmeth.o'. > gmake[3]: Target `all' not remade because of errors. > gmake[2]: *** [subdirs] Error 1 > gmake[2]: Target `all' not remade because of errors. > gmake[1]: *** [build_crypto] Error 1 > > >This is due to my workspace environment I'm sure, but I haven't been >able to find where the symbolic links in include/openssl are created. >I >still have some digging to do, but if anyone can point me to the >make/config/install file that creates them, I'd appreciate it. Thank >you! > > >Ron Jordan >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- levitte at openssl.org From pw178860 at gmail.com Thu Dec 10 07:54:20 2015 From: pw178860 at gmail.com (=?UTF-8?B?UGF3ZcWCIFdpdGFz?=) Date: Thu, 10 Dec 2015 08:54:20 +0100 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: References: Message-ID: C:\Libs\openssl\bin>pkcs11-tool.exe --module enigmap11.dll --login --login-type user --type privkey -O Using slot 0 with a present token (0x0) Logging in to "ENCARD Token kwalifikowany". Please enter User PIN: Private Key Object; RSA label: ID: d7f4b99792cc4dd708e408d3eb91b566e0a06c02 Usage: decrypt, sign C:\Libs\openssl\bin>openssl req -engine pkcs11 -new -key slot_0-id_d7f4b99792cc4dd708e408d3eb91b566e0a06c02 -keyform engine -x509 -out req.pem -text -days 365 -subj "/C=PL/ST=woj./L=miejscowosc/O=firma/OU=dzial/CN=nazwisko/emailAddress= ktos at domena.pl" engine "pkcs11" set. PKCS#11 token PIN: Loading 'screen' into random state - done C:\Libs\openssl\bin>openssl x509 -engine pkcs11 -signkey slot_0-id_ -keyform engine -in req.pem -out test.pem engine "pkcs11" set. Loading 'screen' into random state - done Getting Private key PKCS#11 token PIN: C:\Libs\openssl\bin>type test.pem -----BEGIN CERTIFICATE----- MIIC2DCCAkGgAwIBAgIJAL/pU6nbSHVMMA0GCSqGSIb3DQEBCwUAMIGEMQswCQYD VQQGEwJQTDENMAsGA1UECAwEd29qLjEUMBIGA1UEBwwLbWllanNjb3dvc2MxDjAM BgNVBAoMBWZpcm1hMQ4wDAYDVQQLDAVkemlhbDERMA8GA1UEAwwIbmF6d2lza28x HTAbBgkqhkiG9w0BCQEWDmt0b3NAZG9tZW5hLnBsMB4XDTE1MTIxMDA3NDkxMVoX DTE2MDEwOTA3NDkxMVowgYQxCzAJBgNVBAYTAlBMMQ0wCwYDVQQIDAR3b2ouMRQw EgYDVQQHDAttaWVqc2Nvd29zYzEOMAwGA1UECgwFZmlybWExDjAMBgNVBAsMBWR6 aWFsMREwDwYDVQQDDAhuYXp3aXNrbzEdMBsGCSqGSIb3DQEJARYOa3Rvc0Bkb21l bmEucGwwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKdYUM4S5DViugWYLu15 Ch3E/Z8DTbj6f+U78RTgmgTgaZuoezRkDubkT/0B++Xig+UEkijDEJov4vJxpJWs Dz0zs6Z1Re1wrzuUw4rd4eu6PvNHTEmqbTxhmm0xlHfzSVPzp1vFnwJaRNzHiZQl 8FmYWzqiYq6py1giYB/dpjYLAgMBAAGjUDBOMB0GA1UdDgQWBBTX9LmXksxN1wjk CNPrkbVm4KBsAjAfBgNVHSMEGDAWgBTX9LmXksxN1wjkCNPrkbVm4KBsAjAMBgNV HRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4GBAC48XmI9bYJcH8uyO4CB3+zIw+iq wRfJRO779Uqkn1MyiGBLawrCtnWtIqerYHqmwnglMY1rHqU67RlAAo7NojFZtyUQ 3O/0T3nQzsmLXozBw3XzLlSi+fHQ/9eQ6cxFkRXSJNK2nOFlxy6fcuGYxuWuthjF W0aq8L5+6DemsZDd -----END CERTIFICATE----- C:\Libs\openssl\bin>type req.pem Certificate: Data: Version: 3 (0x2) Serial Number: bf:e9:53:a9:db:48:75:4c Signature Algorithm: sha256WithRSAEncryption Issuer: C=PL, ST=woj., L=miejscowosc, O=firma, OU=dzial, CN=nazwisko/emailAddress=ktos at dome Validity Not Before: Dec 10 07:49:05 2015 GMT Not After : Dec 9 07:49:05 2016 GMT Subject: C=PL, ST=woj., L=miejscowosc, O=firma, OU=dzial, CN=nazwisko/emailAddress=ktos at dom Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:a7:58:50:ce:12:e4:35:62:ba:05:98:2e:ed:79: 0a:1d:c4:fd:9f:03:4d:b8:fa:7f:e5:3b:f1:14:e0: 9a:04:e0:69:9b:a8:7b:34:64:0e:e6:e4:4f:fd:01: fb:e5:e2:83:e5:04:92:28:c3:10:9a:2f:e2:f2:71: a4:95:ac:0f:3d:33:b3:a6:75:45:ed:70:af:3b:94: c3:8a:dd:e1:eb:ba:3e:f3:47:4c:49:aa:6d:3c:61: 9a:6d:31:94:77:f3:49:53:f3:a7:5b:c5:9f:02:5a: 44:dc:c7:89:94:25:f0:59:98:5b:3a:a2:62:ae:a9: cb:58:22:60:1f:dd:a6:36:0b Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: D7:F4:B9:97:92:CC:4D:D7:08:E4:08:D3:EB:91:B5:66:E0:A0:6C:02 X509v3 Authority Key Identifier: keyid:D7:F4:B9:97:92:CC:4D:D7:08:E4:08:D3:EB:91:B5:66:E0:A0:6C:02 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha256WithRSAEncryption 6c:98:76:ab:1e:f4:98:b7:25:06:e1:13:c5:d7:48:f0:b0:b1: 97:56:ee:d4:ef:5d:30:aa:e3:de:83:75:09:39:31:41:22:2f: 0a:f2:6e:48:10:c0:b9:bf:07:92:0f:02:ce:6a:67:fe:92:7d: 9f:61:de:84:57:80:c0:84:d4:56:23:d9:5c:ea:88:4c:50:65: 03:14:9b:8e:d4:3e:34:75:a9:53:b9:0d:f1:6c:47:65:fc:7e: 7c:e1:eb:55:4a:97:d0:f5:e2:ad:cd:a5:0d:6a:50:f1:41:85: bb:a0:31:5b:61:40:0c:14:b7:f8:98:f0:80:7e:1a:d6:b4:58: 22:cd -----BEGIN CERTIFICATE----- MIIC2DCCAkGgAwIBAgIJAL/pU6nbSHVMMA0GCSqGSIb3DQEBCwUAMIGEMQswCQYD VQQGEwJQTDENMAsGA1UECAwEd29qLjEUMBIGA1UEBwwLbWllanNjb3dvc2MxDjAM BgNVBAoMBWZpcm1hMQ4wDAYDVQQLDAVkemlhbDERMA8GA1UEAwwIbmF6d2lza28x HTAbBgkqhkiG9w0BCQEWDmt0b3NAZG9tZW5hLnBsMB4XDTE1MTIxMDA3NDkwNVoX DTE2MTIwOTA3NDkwNVowgYQxCzAJBgNVBAYTAlBMMQ0wCwYDVQQIDAR3b2ouMRQw EgYDVQQHDAttaWVqc2Nvd29zYzEOMAwGA1UECgwFZmlybWExDjAMBgNVBAsMBWR6 aWFsMREwDwYDVQQDDAhuYXp3aXNrbzEdMBsGCSqGSIb3DQEJARYOa3Rvc0Bkb21l bmEucGwwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKdYUM4S5DViugWYLu15 Ch3E/Z8DTbj6f+U78RTgmgTgaZuoezRkDubkT/0B++Xig+UEkijDEJov4vJxpJWs Dz0zs6Z1Re1wrzuUw4rd4eu6PvNHTEmqbTxhmm0xlHfzSVPzp1vFnwJaRNzHiZQl 8FmYWzqiYq6py1giYB/dpjYLAgMBAAGjUDBOMB0GA1UdDgQWBBTX9LmXksxN1wjk CNPrkbVm4KBsAjAfBgNVHSMEGDAWgBTX9LmXksxN1wjkCNPrkbVm4KBsAjAMBgNV HRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4GBAGyYdqse9Ji3JQbhE8XXSPCwsZdW 7tTvXTCq496DdQk5MUEiLwrybkgQwLm/B5IPAs5qZ/6SfZ9h3oRXgMCE1FYj2Vzq iExQZQMUm47UPjR1qVO5DfFsR2X8fnzh61VKl9D14q3NpQ1qUPFBhbugMVthQAwU t/iY8IB+Gta0WCLN -----END CERTIFICATE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From pw178860 at gmail.com Thu Dec 10 07:59:06 2015 From: pw178860 at gmail.com (=?UTF-8?B?UGF3ZcWCIFdpdGFz?=) Date: Thu, 10 Dec 2015 08:59:06 +0100 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: References: Message-ID: Correction: I forgot to paste my token ID. openssl x509 -engine pkcs11 -signkey slot_0-id_d7f4b99792cc4dd708e408d3eb91b566e0a06c02 -keyform engine -in req.pem -out test.pem On Thu, Dec 10, 2015 at 8:54 AM, Pawe? Witas wrote: > C:\Libs\openssl\bin>pkcs11-tool.exe --module enigmap11.dll --login > --login-type user --type privkey -O > Using slot 0 with a present token (0x0) > Logging in to "ENCARD Token kwalifikowany". > Please enter User PIN: Private Key Object; RSA > label: > ID: d7f4b99792cc4dd708e408d3eb91b566e0a06c02 > Usage: decrypt, sign > > C:\Libs\openssl\bin>openssl req -engine pkcs11 -new -key > slot_0-id_d7f4b99792cc4dd708e408d3eb91b566e0a06c02 -keyform engine -x509 > -out req.pem -text -days 365 -subj > "/C=PL/ST=woj./L=miejscowosc/O=firma/OU=dzial/CN=nazwisko/emailAddress= > ktos at domena.pl" > engine "pkcs11" set. > PKCS#11 token PIN: > Loading 'screen' into random state - done > > C:\Libs\openssl\bin>openssl x509 -engine pkcs11 -signkey slot_0-id_ > -keyform engine -in req.pem -out test.pem > engine "pkcs11" set. > Loading 'screen' into random state - done > Getting Private key > PKCS#11 token PIN: > > C:\Libs\openssl\bin>type test.pem > -----BEGIN CERTIFICATE----- > MIIC2DCCAkGgAwIBAgIJAL/pU6nbSHVMMA0GCSqGSIb3DQEBCwUAMIGEMQswCQYD > VQQGEwJQTDENMAsGA1UECAwEd29qLjEUMBIGA1UEBwwLbWllanNjb3dvc2MxDjAM > BgNVBAoMBWZpcm1hMQ4wDAYDVQQLDAVkemlhbDERMA8GA1UEAwwIbmF6d2lza28x > HTAbBgkqhkiG9w0BCQEWDmt0b3NAZG9tZW5hLnBsMB4XDTE1MTIxMDA3NDkxMVoX > DTE2MDEwOTA3NDkxMVowgYQxCzAJBgNVBAYTAlBMMQ0wCwYDVQQIDAR3b2ouMRQw > EgYDVQQHDAttaWVqc2Nvd29zYzEOMAwGA1UECgwFZmlybWExDjAMBgNVBAsMBWR6 > aWFsMREwDwYDVQQDDAhuYXp3aXNrbzEdMBsGCSqGSIb3DQEJARYOa3Rvc0Bkb21l > bmEucGwwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKdYUM4S5DViugWYLu15 > Ch3E/Z8DTbj6f+U78RTgmgTgaZuoezRkDubkT/0B++Xig+UEkijDEJov4vJxpJWs > Dz0zs6Z1Re1wrzuUw4rd4eu6PvNHTEmqbTxhmm0xlHfzSVPzp1vFnwJaRNzHiZQl > 8FmYWzqiYq6py1giYB/dpjYLAgMBAAGjUDBOMB0GA1UdDgQWBBTX9LmXksxN1wjk > CNPrkbVm4KBsAjAfBgNVHSMEGDAWgBTX9LmXksxN1wjkCNPrkbVm4KBsAjAMBgNV > HRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4GBAC48XmI9bYJcH8uyO4CB3+zIw+iq > wRfJRO779Uqkn1MyiGBLawrCtnWtIqerYHqmwnglMY1rHqU67RlAAo7NojFZtyUQ > 3O/0T3nQzsmLXozBw3XzLlSi+fHQ/9eQ6cxFkRXSJNK2nOFlxy6fcuGYxuWuthjF > W0aq8L5+6DemsZDd > -----END CERTIFICATE----- > > C:\Libs\openssl\bin>type req.pem > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > bf:e9:53:a9:db:48:75:4c > Signature Algorithm: sha256WithRSAEncryption > Issuer: C=PL, ST=woj., L=miejscowosc, O=firma, OU=dzial, > CN=nazwisko/emailAddress=ktos at dome > Validity > Not Before: Dec 10 07:49:05 2015 GMT > Not After : Dec 9 07:49:05 2016 GMT > Subject: C=PL, ST=woj., L=miejscowosc, O=firma, OU=dzial, > CN=nazwisko/emailAddress=ktos at dom > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (1024 bit) > Modulus: > 00:a7:58:50:ce:12:e4:35:62:ba:05:98:2e:ed:79: > 0a:1d:c4:fd:9f:03:4d:b8:fa:7f:e5:3b:f1:14:e0: > 9a:04:e0:69:9b:a8:7b:34:64:0e:e6:e4:4f:fd:01: > fb:e5:e2:83:e5:04:92:28:c3:10:9a:2f:e2:f2:71: > a4:95:ac:0f:3d:33:b3:a6:75:45:ed:70:af:3b:94: > c3:8a:dd:e1:eb:ba:3e:f3:47:4c:49:aa:6d:3c:61: > 9a:6d:31:94:77:f3:49:53:f3:a7:5b:c5:9f:02:5a: > 44:dc:c7:89:94:25:f0:59:98:5b:3a:a2:62:ae:a9: > cb:58:22:60:1f:dd:a6:36:0b > Exponent: 65537 (0x10001) > X509v3 extensions: > X509v3 Subject Key Identifier: > D7:F4:B9:97:92:CC:4D:D7:08:E4:08:D3:EB:91:B5:66:E0:A0:6C:02 > X509v3 Authority Key Identifier: > > keyid:D7:F4:B9:97:92:CC:4D:D7:08:E4:08:D3:EB:91:B5:66:E0:A0:6C:02 > > X509v3 Basic Constraints: > CA:TRUE > Signature Algorithm: sha256WithRSAEncryption > 6c:98:76:ab:1e:f4:98:b7:25:06:e1:13:c5:d7:48:f0:b0:b1: > 97:56:ee:d4:ef:5d:30:aa:e3:de:83:75:09:39:31:41:22:2f: > 0a:f2:6e:48:10:c0:b9:bf:07:92:0f:02:ce:6a:67:fe:92:7d: > 9f:61:de:84:57:80:c0:84:d4:56:23:d9:5c:ea:88:4c:50:65: > 03:14:9b:8e:d4:3e:34:75:a9:53:b9:0d:f1:6c:47:65:fc:7e: > 7c:e1:eb:55:4a:97:d0:f5:e2:ad:cd:a5:0d:6a:50:f1:41:85: > bb:a0:31:5b:61:40:0c:14:b7:f8:98:f0:80:7e:1a:d6:b4:58: > 22:cd > -----BEGIN CERTIFICATE----- > MIIC2DCCAkGgAwIBAgIJAL/pU6nbSHVMMA0GCSqGSIb3DQEBCwUAMIGEMQswCQYD > VQQGEwJQTDENMAsGA1UECAwEd29qLjEUMBIGA1UEBwwLbWllanNjb3dvc2MxDjAM > BgNVBAoMBWZpcm1hMQ4wDAYDVQQLDAVkemlhbDERMA8GA1UEAwwIbmF6d2lza28x > HTAbBgkqhkiG9w0BCQEWDmt0b3NAZG9tZW5hLnBsMB4XDTE1MTIxMDA3NDkwNVoX > DTE2MTIwOTA3NDkwNVowgYQxCzAJBgNVBAYTAlBMMQ0wCwYDVQQIDAR3b2ouMRQw > EgYDVQQHDAttaWVqc2Nvd29zYzEOMAwGA1UECgwFZmlybWExDjAMBgNVBAsMBWR6 > aWFsMREwDwYDVQQDDAhuYXp3aXNrbzEdMBsGCSqGSIb3DQEJARYOa3Rvc0Bkb21l > bmEucGwwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKdYUM4S5DViugWYLu15 > Ch3E/Z8DTbj6f+U78RTgmgTgaZuoezRkDubkT/0B++Xig+UEkijDEJov4vJxpJWs > Dz0zs6Z1Re1wrzuUw4rd4eu6PvNHTEmqbTxhmm0xlHfzSVPzp1vFnwJaRNzHiZQl > 8FmYWzqiYq6py1giYB/dpjYLAgMBAAGjUDBOMB0GA1UdDgQWBBTX9LmXksxN1wjk > CNPrkbVm4KBsAjAfBgNVHSMEGDAWgBTX9LmXksxN1wjkCNPrkbVm4KBsAjAMBgNV > HRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4GBAGyYdqse9Ji3JQbhE8XXSPCwsZdW > 7tTvXTCq496DdQk5MUEiLwrybkgQwLm/B5IPAs5qZ/6SfZ9h3oRXgMCE1FYj2Vzq > iExQZQMUm47UPjR1qVO5DfFsR2X8fnzh61VKl9D14q3NpQ1qUPFBhbugMVthQAwU > t/iY8IB+Gta0WCLN > -----END CERTIFICATE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu Dec 10 08:39:31 2015 From: levitte at openssl.org (Richard Levitte) Date: Thu, 10 Dec 2015 09:39:31 +0100 (CET) Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: References: Message-ID: <20151210.093931.1997199079828500981.levitte@openssl.org> This is an odity with 'openssl pkeyutl'. Try this option order: LOAD_CERT_CTRL=true VERBOSE=7 openssl pkeyutl -engine pkcs11 -sign -keyform engine -inkey "pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -out config.status.sig -in config.status.hash The reason for this is that pkeyutl (as opposed to most other openssl subcommands) tries to load the key while parsing the options, so if '-keyform engine' comes after '-inkey ...', it will try to load the key before having seen that it should be loaded from engine. I think a bugfix for this is in order... Cheers, Richard In message on Wed, 9 Dec 2015 21:24:41 +0000, "Blumenthal, Uri - 0553 - MITLL" said: uri> I?m having a problem, and am not sure whether it?s due to my uri> ignorance/misuse of the tool (i.e. it should be done differently), or uri> a bug in the tool, or it?s just not capable of doing what I want it uri> to. uri> uri> What I?m trying to accomplish: use engine_pkcs11 with OpenSSL to sign uri> and decrypt with private keys on a smart card, accessed as a PKCS#11 uri> token. To support this engine, I?ve also installed libp11, and of uri> course OpenSC itself. uri> uri> This shows that OpenSC works and accesses the smart card successfully: uri> uri> $ p11tool --provider /Library/OpenSC/lib/opensc-pkcs11.dylib - uri> -list-privkeys --login uri> uri> Token 'PIV_II (PIV Card Holder pin)' with URL uri> 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29' uri> requires user PIN uri> uri> Enter PIN: uri> uri> Object 0: uri> uri> URL: uri> pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object=PIV%20AUTH%20key;object-type=private uri> uri> Type: Private key uri> uri> Label: PIV AUTH key uri> uri> Flags: CKA_WRAP/UNWRAP; CKA_PRIVATE; CKA_SENSITIVE; uri> uri> ID: 01 uri> uri> Object 1: uri> uri> URL: uri> pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%02;object=SIGN%20key;object-type=private uri> uri> Type: Private key uri> uri> Label: SIGN key uri> uri> Flags: CKA_PRIVATE; CKA_SENSITIVE; uri> uri> ID: 02 uri> uri> Object 2: uri> uri> URL: uri> pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%03;object=KEY%20MAN%20key;object-type=private uri> uri> Type: Private key uri> uri> Label: KEY MAN key uri> uri> Flags: CKA_WRAP/UNWRAP; CKA_PRIVATE; CKA_SENSITIVE; uri> uri> ID: 03 uri> uri> Object 3: uri> uri> URL: uri> pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%04;object=CARD%20AUTH%20key;object-type=private uri> uri> Type: Private key uri> uri> Label: CARD AUTH key uri> uri> Flags: CKA_SENSITIVE; uri> uri> ID: 04 uri> uri> This shows that OpenSSL does seem to load the engine, but fails to uri> access the key on the smart card: uri> uri> $ openssl engine pkcs11 -t uri> uri> (pkcs11) pkcs11 engine uri> uri> [ available ] uri> uri> $ openssl req -engine pkcs11 -new -key uri> "pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%02;object=SIGN%20key;object-type=private;pin-value=123456" uri> -keyform engine -out req.pem -text -x509 -subj "/CN=Tester" uri> uri> engine "pkcs11" set. uri> uri> specified object not found uri> uri> PKCS11_get_private_key returned NULL uri> uri> cannot load Private Key from engine uri> uri> 140735296230224:error:26096080:engine uri> routines:ENGINE_load_private_key:failed loading private uri> key:eng_pkey.c:124: uri> uri> unable to load Private Key uri> uri> $ LOAD_CERT_CTRL=true VERBOSE=7 openssl pkeyutl -engine pkcs11 -sign - uri> inkey "pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" - uri> keyform engine -out config.status.sig -in config.status.hash uri> uri> engine "pkcs11" set. uri> uri> Error opening Private Key uri> pkcs11:object=SIGN%20key;object-type=private;pin-value=123456 uri> uri> 140735296230224:error:02001002:system library:fopen:No such file or uri> directory:bss_file.c:398:fopen uri> ('pkcs11:object=SIGN%20key;object-type=private;pin-value=123456','r') uri> uri> 140735296230224:error:20074002:BIO routines:FILE_CTRL:system uri> lib:bss_file.c:400: uri> uri> unable to load Private Key uri> uri> Error initializing context uri> uri> Usage: pkeyutl [options] uri> uri> -in file input file uri> uri> -out file output file uri> uri> -sigfile file signature file (verify operation only) uri> uri> -inkey file input key uri> uri> -keyform arg private key format - default PEM uri> uri> -pubin input is a public key uri> uri> -certin input is a certificate carrying a public key uri> uri> -pkeyopt X:Y public key options uri> uri> -sign sign with private key uri> uri> -verify verify with public key uri> uri> -verifyrecover verify with public key, recover original data uri> uri> -encrypt encrypt with public key uri> uri> -decrypt decrypt with private key uri> uri> -derive derive shared secret uri> uri> -hexdump hex dump output uri> uri> -engine e use engine e, possibly a hardware device. uri> uri> -passin arg pass phrase source uri> uri> $ uri> uri> I would appreciate guidance regarding how to accomplish what I?m uri> trying to do, and whether it is possible to do so staying within the uri> OpenSSL CLI. uri> uri> Thanks! uri> uri> P.S. I followed the README from uri> https://github.com/OpenSC/engine_pkcs11 as an example of how to use uri> OpenSSL with engine_pkcs11 and the token. uri> -- uri> Regards, uri> Uri Blumenthal From pw178860 at gmail.com Thu Dec 10 09:20:02 2015 From: pw178860 at gmail.com (=?UTF-8?B?UGF3ZcWCIFdpdGFz?=) Date: Thu, 10 Dec 2015 10:20:02 +0100 Subject: [openssl-dev] [BUG] Different heap implementations in engine_pkcs11.dll and OpenSSL cause crash at EVP_PKEY_free(cpk->privatekey) Message-ID: Hello I'm working on implementing PKCS#11 encrypted communication on Windows platform. This crash occurs on Windows Vista and above when engine_pkcs11.dll is compiled by mingw toolchain and OpenSSL is compiled by Visual Studio 2012. It does not occur on Windows XP or when both engine_pkcs11.dll and OpenSSL are compiled by mingw toolchain. The cause of this crash are different and incompatible implementations of memory allocators in engine_pkcs11.dll (from Windows kernel's msvcrt.dll) and OpenSSL (from VS212 msvcr110.dll). The private key is allocated by engine_pkcs11.dll on its private heap via callback from OpenSSL, but freed by the OpenSSL library itself. This is troublesome, because I can compile OpenSSL by mingw for my clients and put it at the beginning of the PATH,, but I can't replace OpenSSL statically linked with third party products, i.e. Symantec Antivirus LicenseMan.dll, which causes antivirus crash, because it loads my openssl.cnf with engine_pkcs11.dll configured and tries to use it (why?). I solved this problem by replacing references to environment variable "OPENSSL_CONF" by "OPENSSL_KONF" in my compilation of OpenSSL, but the real solution would be allowing the engine_pkcs11.dll library to deallocate its own keys by the deallocating callback from OpenSSL. It will require modifications to both OpenSSL and engine_pkcs11.dll library. Best regards Pawel -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu Dec 10 11:14:36 2015 From: levitte at openssl.org (Richard Levitte) Date: Thu, 10 Dec 2015 12:14:36 +0100 (CET) Subject: [openssl-dev] [BUG] Different heap implementations in engine_pkcs11.dll and OpenSSL cause crash at EVP_PKEY_free(cpk->privatekey) In-Reply-To: References: Message-ID: <20151210.121436.488429995585241065.levitte@openssl.org> Hey Pawe?, In message on Thu, 10 Dec 2015 10:20:02 +0100, Pawe? Witas said: pw178860> I'm working on implementing PKCS#11 encrypted communication on Windows pw178860> platform. pw178860> This crash occurs on Windows Vista and above when engine_pkcs11.dll is pw178860> compiled by mingw toolchain and OpenSSL is compiled by Visual Studio pw178860> 2012. pw178860> It does not occur on Windows XP or when both engine_pkcs11.dll and pw178860> OpenSSL are compiled by mingw toolchain. pw178860> pw178860> The cause of this crash are different and incompatible implementations pw178860> of memory allocators in engine_pkcs11.dll (from Windows kernel's pw178860> msvcrt.dll) and OpenSSL (from VS212 msvcr110.dll). pw178860> The private key is allocated by engine_pkcs11.dll on its private heap pw178860> via callback from OpenSSL, but freed by the OpenSSL library itself. Here's a detail, IMPLEMENT_DYNAMIC_BIND_FN, passes down the memory allocation callbacks to the OpenSSL that the engine uses (be it statically linked or not). This means that memory allocated with OPENSSL_malloc and friends in engine_pkcs11.dll *should* be allocated in OpenSSL library heap rather than engine_pkcs11.dll private heap. However, if anything returned through EVP_PKEY* returns (I suspect the issues come up around keys) is allocated using something other than OPENSSL allocation calls (such as malloc(), calloc()...), then yes, you do get in trouble. I just spent a bit of time eyeing through engine_pkcs11 and libp11 and couldn't immediately find a culprit of that sort, but ... pw178860> This is troublesome, because I can compile OpenSSL by mingw for my pw178860> clients and put it at the beginning of the PATH,, but I can't replace pw178860> OpenSSL statically linked with third party products, i.e. Symantec pw178860> Antivirus LicenseMan.dll, which causes antivirus crash, because it pw178860> loads my openssl.cnf with engine_pkcs11.dll configured and tries to pw178860> use it (why?). I have no idea what LicenseMan.dll is or why it uses OpenSSL. However, if it does, it may very well call OPENSSL_config or CONF_modules_load_file, which will load whatever configuration file that's given through the OPENSSL_CONF environment variable. It might be that they need to use a different default section (the default is "openssl_conf"); that might be something to report back to Symantec. pw178860> I solved this problem by replacing references to environment variable pw178860> "OPENSSL_CONF" by "OPENSSL_KONF" in my compilation of OpenSSL, but the pw178860> real solution would be allowing the engine_pkcs11.dll library to pw178860> deallocate its own keys by the deallocating callback from OpenSSL. pw178860> It will require modifications to both OpenSSL and engine_pkcs11.dll pw178860> library. I agree with those thoughts. That will be for a future major OpenSSL version, I cannot say which one for the moment. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From pw178860 at gmail.com Thu Dec 10 11:56:38 2015 From: pw178860 at gmail.com (=?UTF-8?B?UGF3ZcWCIFdpdGFz?=) Date: Thu, 10 Dec 2015 12:56:38 +0100 Subject: [openssl-dev] [BUG] Different heap implementations in engine_pkcs11.dll and OpenSSL cause crash at EVP_PKEY_free(cpk->privatekey) In-Reply-To: <20151210.121436.488429995585241065.levitte@openssl.org> References: <20151210.121436.488429995585241065.levitte@openssl.org> Message-ID: Thanks for fast response. Yes, engine_pkcs11.dll and libp11.dll are statically linked with OpenSSL (compiled by mingw gcc), but affected Libcurl.dll (or Curl.exe or Openssl.exe) compiled by MS Visual Studio, uses dynamically linked OpenSSL, that loads configuration file, that asks OpenSSL to load this engine. As a result, engine_pkcs11.dll allocates memory on its private heap by using its own statically linked OpenSSL, that uses different heap implementation than OpenSSL used by some other programs. On Thu, Dec 10, 2015 at 12:14 PM, Richard Levitte wrote: > Hey Pawe?, > > In message < > CAPv+SJGWXnbkJPd4ykYOTMEAEib-wcP5DETbeZM2XnSV9id4Vg at mail.gmail.com> on > Thu, 10 Dec 2015 10:20:02 +0100, Pawe? Witas said: > > pw178860> I'm working on implementing PKCS#11 encrypted communication on > Windows > pw178860> platform. > pw178860> This crash occurs on Windows Vista and above when > engine_pkcs11.dll is > pw178860> compiled by mingw toolchain and OpenSSL is compiled by Visual > Studio > pw178860> 2012. > pw178860> It does not occur on Windows XP or when both engine_pkcs11.dll > and > pw178860> OpenSSL are compiled by mingw toolchain. > pw178860> > pw178860> The cause of this crash are different and incompatible > implementations > pw178860> of memory allocators in engine_pkcs11.dll (from Windows kernel's > pw178860> msvcrt.dll) and OpenSSL (from VS212 msvcr110.dll). > pw178860> The private key is allocated by engine_pkcs11.dll on its private > heap > pw178860> via callback from OpenSSL, but freed by the OpenSSL library > itself. > > Here's a detail, IMPLEMENT_DYNAMIC_BIND_FN, passes down the memory > allocation callbacks to the OpenSSL that the engine uses (be it > statically linked or not). This means that memory allocated with > OPENSSL_malloc and friends in engine_pkcs11.dll *should* be allocated > in OpenSSL library heap rather than engine_pkcs11.dll private heap. > However, if anything returned through EVP_PKEY* returns (I suspect the > issues come up around keys) is allocated using something other than > OPENSSL allocation calls (such as malloc(), calloc()...), then yes, > you do get in trouble. I just spent a bit of time eyeing through > engine_pkcs11 and libp11 and couldn't immediately find a culprit of > that sort, but ... > > pw178860> This is troublesome, because I can compile OpenSSL by mingw for > my > pw178860> clients and put it at the beginning of the PATH,, but I can't > replace > pw178860> OpenSSL statically linked with third party products, i.e. > Symantec > pw178860> Antivirus LicenseMan.dll, which causes antivirus crash, because > it > pw178860> loads my openssl.cnf with engine_pkcs11.dll configured and tries > to > pw178860> use it (why?). > > I have no idea what LicenseMan.dll is or why it uses OpenSSL. > However, if it does, it may very well call OPENSSL_config or > CONF_modules_load_file, which will load whatever configuration file > that's given through the OPENSSL_CONF environment variable. It might > be that they need to use a different default section (the default is > "openssl_conf"); that might be something to report back to Symantec. > > pw178860> I solved this problem by replacing references to environment > variable > pw178860> "OPENSSL_CONF" by "OPENSSL_KONF" in my compilation of OpenSSL, > but the > pw178860> real solution would be allowing the engine_pkcs11.dll library to > pw178860> deallocate its own keys by the deallocating callback from > OpenSSL. > pw178860> It will require modifications to both OpenSSL and > engine_pkcs11.dll > pw178860> library. > > I agree with those thoughts. That will be for a future major OpenSSL > version, I cannot say which one for the moment. > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu Dec 10 12:17:04 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 10 Dec 2015 12:17:04 +0000 Subject: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory In-Reply-To: <20151210121648.GA13127@roeckx.be> References: <003a01d13105$d6b66450$84232cf0$@sales@free.fr> <20151210121648.GA13127@roeckx.be> Message-ID: On Mon, Dec 07, 2015 at 03:47:56PM +0000, Michel via RT wrote: > Hi, > > Following my previous mail, here attached is an updated patch against 1.02e > to fix the SRP VBASE memory leaks. Can you confirm that this would be the correct patch for master? I still need to look at it. Kurt -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_srp_memleak.patch Type: text/x-diff Size: 2338 bytes Desc: not available URL: From kurt at roeckx.be Thu Dec 10 12:21:14 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 10 Dec 2015 13:21:14 +0100 Subject: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory In-Reply-To: References: <003a01d13105$d6b66450$84232cf0$@sales@free.fr> <20151210121648.GA13127@roeckx.be> Message-ID: <20151210122114.GB13127@roeckx.be> On Thu, Dec 10, 2015 at 12:17:04PM +0000, Kurt Roeckx via RT wrote: > On Mon, Dec 07, 2015 at 03:47:56PM +0000, Michel via RT wrote: > > Hi, > > > > Following my previous mail, here attached is an updated patch against 1.02e > > to fix the SRP VBASE memory leaks. > > Can you confirm that this would be the correct patch for master? > > I still need to look at it. It doesn't even compile ... Kurt From rt at openssl.org Thu Dec 10 12:21:30 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 10 Dec 2015 12:21:30 +0000 Subject: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory In-Reply-To: <20151210122114.GB13127@roeckx.be> References: <003a01d13105$d6b66450$84232cf0$@sales@free.fr> <20151210121648.GA13127@roeckx.be> <20151210122114.GB13127@roeckx.be> Message-ID: On Thu, Dec 10, 2015 at 12:17:04PM +0000, Kurt Roeckx via RT wrote: > On Mon, Dec 07, 2015 at 03:47:56PM +0000, Michel via RT wrote: > > Hi, > > > > Following my previous mail, here attached is an updated patch against 1.02e > > to fix the SRP VBASE memory leaks. > > Can you confirm that this would be the correct patch for master? > > I still need to look at it. It doesn't even compile ... Kurt From rt at openssl.org Thu Dec 10 12:27:41 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 10 Dec 2015 12:27:41 +0000 Subject: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory In-Reply-To: <20151210122738.GA18048@roeckx.be> References: <003a01d13105$d6b66450$84232cf0$@sales@free.fr> <20151210121648.GA13127@roeckx.be> <20151210122738.GA18048@roeckx.be> Message-ID: On Thu, Dec 10, 2015 at 01:16:48PM +0100, Kurt Roeckx wrote: > On Mon, Dec 07, 2015 at 03:47:56PM +0000, Michel via RT wrote: > > Hi, > > > > Following my previous mail, here attached is an updated patch against 1.02e > > to fix the SRP VBASE memory leaks. > > Can you confirm that this would be the correct patch for master? The following patch should at least compile. Kurt -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-SRP-VBASE-memory-leak.patch Type: text/x-diff Size: 3061 bytes Desc: not available URL: From rt at openssl.org Thu Dec 10 13:06:03 2015 From: rt at openssl.org (Michel via RT) Date: Thu, 10 Dec 2015 13:06:03 +0000 Subject: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory In-Reply-To: <003201d1334b$789353e0$69b9fba0$@sales@free.fr> References: <003a01d13105$d6b66450$84232cf0$@sales@free.fr> <20151210121648.GA13127@roeckx.be> <20151210122738.GA18048@roeckx.be> <003201d1334b$789353e0$69b9fba0$@sales@free.fr> Message-ID: Hi Kurt, First, thanks to look at this. I just look at your mail. Quick answer : I applied this patch before sending to RT, and not only it compiles but I tested it concerning memory leaks, consequently I am very surprise. So I will review this and return to you soon. In the meantimehere some additional info : I am working with Visual Studio 2015 community Ed., under Windows 7, OpenSSL 1.0.2e. Thanks again, Regards, Michel -----Message d'origine----- De : Kurt Roeckx via RT [mailto:rt at openssl.org] Envoy? : jeudi 10 d?cembre 2015 13:28 ? : michel.sales at free.fr Cc : openssl-dev at openssl.org Objet : Re: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory On Thu, Dec 10, 2015 at 01:16:48PM +0100, Kurt Roeckx wrote: > On Mon, Dec 07, 2015 at 03:47:56PM +0000, Michel via RT wrote: > > Hi, > > > > Following my previous mail, here attached is an updated patch > > against 1.02e to fix the SRP VBASE memory leaks. > > Can you confirm that this would be the correct patch for master? The following patch should at least compile. Kurt From rt at openssl.org Thu Dec 10 13:15:39 2015 From: rt at openssl.org (Michel via RT) Date: Thu, 10 Dec 2015 13:15:39 +0000 Subject: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory In-Reply-To: <003301d1334c$d4df4c70$7e9de550$@sales@free.fr> References: <003a01d13105$d6b66450$84232cf0$@sales@free.fr> <20151210121648.GA13127@roeckx.be> <20151210122738.GA18048@roeckx.be> <003301d1334c$d4df4c70$7e9de550$@sales@free.fr> Message-ID: I did not try it on master, only with 1.0.2e. I will prepare a new one againt master to see what happened. -----Message d'origine----- De : Kurt Roeckx via RT [mailto:rt at openssl.org] Envoy? : jeudi 10 d?cembre 2015 13:28 ? : michel.sales at free.fr Cc : openssl-dev at openssl.org Objet : Re: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory On Thu, Dec 10, 2015 at 01:16:48PM +0100, Kurt Roeckx wrote: > On Mon, Dec 07, 2015 at 03:47:56PM +0000, Michel via RT wrote: > > Hi, > > > > Following my previous mail, here attached is an updated patch > > against 1.02e to fix the SRP VBASE memory leaks. > > Can you confirm that this would be the correct patch for master? The following patch should at least compile. Kurt From rt at openssl.org Thu Dec 10 14:20:02 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 10 Dec 2015 14:20:02 +0000 Subject: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory In-Reply-To: <20151210141954.GA26374@roeckx.be> References: <003a01d13105$d6b66450$84232cf0$@sales@free.fr> <20151210121648.GA13127@roeckx.be> <20151210122738.GA18048@roeckx.be> <20151210141954.GA26374@roeckx.be> Message-ID: On Thu, Dec 10, 2015 at 01:27:38PM +0100, Kurt Roeckx wrote: > On Thu, Dec 10, 2015 at 01:16:48PM +0100, Kurt Roeckx wrote: > > On Mon, Dec 07, 2015 at 03:47:56PM +0000, Michel via RT wrote: > > > Hi, > > > > > > Following my previous mail, here attached is an updated patch against 1.02e > > > to fix the SRP VBASE memory leaks. > > > > Can you confirm that this would be the correct patch for master? > > The following patch should at least compile. I fixed a few more things, cleaned up some things. New patch attached. Kurt -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-SRP-VBASE-memory-leak.patch Type: text/x-diff Size: 4455 bytes Desc: not available URL: From rt at openssl.org Thu Dec 10 14:37:46 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 10 Dec 2015 14:37:46 +0000 Subject: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory In-Reply-To: <20151210143744.GA32207@roeckx.be> References: <003a01d13105$d6b66450$84232cf0$@sales@free.fr> <20151210121648.GA13127@roeckx.be> <20151210122738.GA18048@roeckx.be> <20151210141954.GA26374@roeckx.be> <20151210143744.GA32207@roeckx.be> Message-ID: On Thu, Dec 10, 2015 at 03:19:54PM +0100, Kurt Roeckx wrote: > On Thu, Dec 10, 2015 at 01:27:38PM +0100, Kurt Roeckx wrote: > > On Thu, Dec 10, 2015 at 01:16:48PM +0100, Kurt Roeckx wrote: > > > On Mon, Dec 07, 2015 at 03:47:56PM +0000, Michel via RT wrote: > > > > Hi, > > > > > > > > Following my previous mail, here attached is an updated patch against 1.02e > > > > to fix the SRP VBASE memory leaks. > > > > > > Can you confirm that this would be the correct patch for master? > > > > The following patch should at least compile. > > I fixed a few more things, cleaned up some things. New patch > attached. I think there is something wrong with new SRP_gN_free(). You now also free g and N, and it's not clear to me who the owner of those is. I think the cache is, in which case we should not free them. I think the cache also isn't cleared, we should probably call SRP_VBASE_free() when SRP_VBASE_init() fails. Kurt From rt at openssl.org Thu Dec 10 14:47:02 2015 From: rt at openssl.org (Grandi, Andrea via RT) Date: Thu, 10 Dec 2015 14:47:02 +0000 Subject: [openssl-dev] [openssl.org #4176] Add support for async jobs in OpenSSL speed In-Reply-To: <02DF9A39E1EE92419A8C5BBE62973A231A450CAA@IRSMSX108.ger.corp.intel.com> References: <02DF9A39E1EE92419A8C5BBE62973A231A450CAA@IRSMSX108.ger.corp.intel.com> Message-ID: Hi! This pull request adds support for async jobs in OpenSSL speed: https://github.com/openssl/openssl/pull/501 Summary of the changes: * Move the calls to the crypto operations inside wrapper functions. This is required because ASYNC_start_job() takes a function as an argument. * Add new function run_benchmark() that manages the jobs for all the operations. In the POSIX case it uses a select() to receive the events from the engine and resume the jobs that are paused, while in the WIN case it uses PeekNamedPipe() * Add new option argument async_jobs to enable and specify the number of async jobs Example: openssl speed -engine dasync -elapsed -async_jobs 32 rsa2048 Regards, Andrea Grandi -------------------------------------------------------------- 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 -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From openssl at openssl.org Thu Dec 10 15:01:50 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 10 Dec 2015 15:01:50 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published Message-ID: <20151210150150.GA30915@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.1.0 pre release 1 (alpha) =========================================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 1 has now been made available. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.1.0-notes.html Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. The alpha release is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0-pre1.tar.gz Size: 4990889 SHA1 checksum: a058b999e17e0c40988bd7b9b280c9876f62684e SHA256 checksum: 79da49c38464a19d1b328c2f4a3661849bd2eb3d54a37fdb6a56d9b8a18e87bd The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0-pre1.tar.gz openssl sha256 openssl-1.1.0-pre1.tar.gz Please download and check this alpha release as soon as possible. Bug reports should go to rt at openssl.org. Please check the release notes and mailing lists to avoid duplicate reports of known issues. Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWaYrRAAoJENnE0m0OYESRh5gIAJ8WrkPPV8CW2xWmtyIjAxpz 7FvvpxBWHaBgJcCrvNomh2JJupXa+enWCTsskIyH0+FtS85VeOKNvQg68xbCOvLl I0dWxMNb8SCxuagvEje8xGEnf8by8pZdYaK8ERASlNoGVIgN8CwppiKnY8c1yRYn Ti0dUZLyVZvT5Qm2Q3k4pOvfS/+rvFjHiuUllFzfHlp6mdk4573w5eneoTINQvRK OC8iAnSiINQWQvuiavLVIgw7VFBD1WC2iKWuSA3+31YuM8CUpvbbnJHh2QUfGkIw oNTkflxgQJhk/txwqvCSzZsVddhvQLZtiRZYQcG4WUuskygCENeieJGPOXN6ioI= =LY4X -----END PGP SIGNATURE----- From uri at ll.mit.edu Thu Dec 10 15:38:55 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 10 Dec 2015 15:38:55 +0000 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: <20151210.093931.1997199079828500981.levitte@openssl.org> References: <20151210.093931.1997199079828500981.levitte@openssl.org> Message-ID: On 12/10/15, 3:39 , "openssl-dev on behalf of Richard Levitte" wrote: >This is an odity with 'openssl pkeyutl'. Try this option order: I see! >LOAD_CERT_CTRL=true VERBOSE=7 openssl pkeyutl -engine pkcs11 -sign >-keyform engine -inkey >"pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -out >config.status.sig -in config.status.hash Much better now - but at this time I hit ?unsupported algorithm?. The key in question is RSA-2048, with SHA256. $ LOAD_CERT_CTRL=true VERBOSE=7 openssl pkeyutl -engine pkcs11 -sign -keyform engine -inkey "pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -out config.status.sig -in config.status.hash engine "pkcs11" set. Error initializing context 140735296230224:error:260C0065:engine routines:ENGINE_get_pkey_meth:unimplemented public key method:tb_pkmeth.c:128: 140735296230224:error:0609D09C:digital envelope routines:INT_CTX_NEW:unsupported algorithm:pmeth_lib.c:164: Usage: pkeyutl [options] -in file input file -out file output file -sigfile file signature file (verify operation only) -inkey file input key -keyform arg private key format - default PEM -pubin input is a public key -certin input is a certificate carrying a public key -pkeyopt X:Y public key options -sign sign with private key -verify verify with public key -verifyrecover verify with public key, recover original data -encrypt encrypt with public key -decrypt decrypt with private key -derive derive shared secret -hexdump hex dump output -engine e use engine e, possibly a hardware device. -passin arg pass phrase source $ I observed exactly the same happening with the decryption key. In case it helps: $ pkcs15-tool -k Using reader with a card: Yubico Yubikey NEO OTP+U2F+CCID Private RSA Key [PIV AUTH key] Object Flags : [0x1], private Usage : [0x2E], decrypt, sign, signRecover, unwrap Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local ModLength : 2048 Key ref : 154 (0x9A) Native : yes Auth ID : 01 ID : 01 MD:guid : 0x'303165623538356130633436626635356438343233643936396232336465623700000000 00000000' Private RSA Key [SIGN key] Object Flags : [0x1], private Usage : [0x20E], decrypt, sign, signRecover, nonRepudiation Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local ModLength : 2048 Key ref : 156 (0x9C) Native : yes Auth ID : 01 ID : 02 MD:guid : 0x'303265623538356130633436626635356438343233643936396232336465623700000000 00000000' Private RSA Key [KEY MAN key] Object Flags : [0x1], private Usage : [0x22], decrypt, unwrap Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local ModLength : 2048 Key ref : 157 (0x9D) Native : yes Auth ID : 01 ID : 03 MD:guid : 0x'303365623538356130633436626635356438343233643936396232336465623700000000 00000000' Private RSA Key [CARD AUTH key] Object Flags : [0x0] Usage : [0xC], sign, signRecover Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local ModLength : 2048 Key ref : 158 (0x9E) Native : yes ID : 04 MD:guid : 0x'303465623538356130633436626635356438343233643936396232336465623700000000 00000000' >The reason for this is that pkeyutl (as opposed to most other openssl >subcommands) tries to load the key while parsing the options, so if >'-keyform engine' comes after '-inkey ...', it will try to load the >key before having seen that it should be loaded from engine. > >I think a bugfix for this is in order... I appreciate your willingness to help - and your willingness to fix this even more. By the way, there appears to be another order-related issue also: -pkeyopt must follow -inkey. But in this case pkeyutl at least reports the problem correctly. Thanks! >In message on Wed, 9 Dec 2015 21:24:41 >+0000, "Blumenthal, Uri - 0553 - MITLL" said: > >uri> I?m having a problem, and am not sure whether it?s due to my >uri> ignorance/misuse of the tool (i.e. it should be done differently), or >uri> a bug in the tool, or it?s just not capable of doing what I want it >uri> to. >uri> >uri> What I?m trying to accomplish: use engine_pkcs11 with OpenSSL to sign >uri> and decrypt with private keys on a smart card, accessed as a PKCS#11 >uri> token. To support this engine, I?ve also installed libp11, and of >uri> course OpenSC itself. >uri> >uri> This shows that OpenSC works and accesses the smart card >successfully: >uri> >uri> $ p11tool --provider /Library/OpenSC/lib/opensc-pkcs11.dylib - >uri> -list-privkeys --login >uri> >uri> Token 'PIV_II (PIV Card Holder pin)' with URL >uri> >'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=P >IV_II%20%28PIV%20Card%20Holder%20pin%29' >uri> requires user PIN >uri> >uri> Enter PIN: >uri> >uri> Object 0: >uri> >uri> URL: >uri> >pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=PI >V_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object=PIV%20AUTH%20key;obje >ct-type=private >uri> >uri> Type: Private key >uri> >uri> Label: PIV AUTH key >uri> >uri> Flags: CKA_WRAP/UNWRAP; CKA_PRIVATE; CKA_SENSITIVE; >uri> >uri> ID: 01 >uri> >uri> Object 1: >uri> >uri> URL: >uri> >pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=PI >V_II%20%28PIV%20Card%20Holder%20pin%29;id=%02;object=SIGN%20key;object-typ >e=private >uri> >uri> Type: Private key >uri> >uri> Label: SIGN key >uri> >uri> Flags: CKA_PRIVATE; CKA_SENSITIVE; >uri> >uri> ID: 02 >uri> >uri> Object 2: >uri> >uri> URL: >uri> >pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=PI >V_II%20%28PIV%20Card%20Holder%20pin%29;id=%03;object=KEY%20MAN%20key;objec >t-type=private >uri> >uri> Type: Private key >uri> >uri> Label: KEY MAN key >uri> >uri> Flags: CKA_WRAP/UNWRAP; CKA_PRIVATE; CKA_SENSITIVE; >uri> >uri> ID: 03 >uri> >uri> Object 3: >uri> >uri> URL: >uri> >pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=PI >V_II%20%28PIV%20Card%20Holder%20pin%29;id=%04;object=CARD%20AUTH%20key;obj >ect-type=private >uri> >uri> Type: Private key >uri> >uri> Label: CARD AUTH key >uri> >uri> Flags: CKA_SENSITIVE; >uri> >uri> ID: 04 >uri> >uri> This shows that OpenSSL does seem to load the engine, but fails to >uri> access the key on the smart card: >uri> >uri> $ openssl engine pkcs11 -t >uri> >uri> (pkcs11) pkcs11 engine >uri> >uri> [ available ] >uri> >uri> $ openssl req -engine pkcs11 -new -key >uri> >"pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=??..;token=P >IV_II%20%28PIV%20Card%20Holder%20pin%29;id=%02;object=SIGN%20key;object-ty >pe=private;pin-value=123456" >uri> -keyform engine -out req.pem -text -x509 -subj "/CN=Tester" >uri> >uri> engine "pkcs11" set. >uri> >uri> specified object not found >uri> >uri> PKCS11_get_private_key returned NULL >uri> >uri> cannot load Private Key from engine >uri> >uri> 140735296230224:error:26096080:engine >uri> routines:ENGINE_load_private_key:failed loading private >uri> key:eng_pkey.c:124: >uri> >uri> unable to load Private Key >uri> >uri> $ LOAD_CERT_CTRL=true VERBOSE=7 openssl pkeyutl -engine pkcs11 -sign >- >uri> inkey >"pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" - >uri> keyform engine -out config.status.sig -in config.status.hash >uri> >uri> engine "pkcs11" set. >uri> >uri> Error opening Private Key >uri> pkcs11:object=SIGN%20key;object-type=private;pin-value=123456 >uri> >uri> 140735296230224:error:02001002:system library:fopen:No such file or >uri> directory:bss_file.c:398:fopen >uri> ('pkcs11:object=SIGN%20key;object-type=private;pin-value=123456','r') >uri> >uri> 140735296230224:error:20074002:BIO routines:FILE_CTRL:system >uri> lib:bss_file.c:400: >uri> >uri> unable to load Private Key >uri> >uri> Error initializing context >uri> >uri> Usage: pkeyutl [options] >uri> >uri> -in file input file >uri> >uri> -out file output file >uri> >uri> -sigfile file signature file (verify operation only) >uri> >uri> -inkey file input key >uri> >uri> -keyform arg private key format - default PEM >uri> >uri> -pubin input is a public key >uri> >uri> -certin input is a certificate carrying a public key >uri> >uri> -pkeyopt X:Y public key options >uri> >uri> -sign sign with private key >uri> >uri> -verify verify with public key >uri> >uri> -verifyrecover verify with public key, recover original data >uri> >uri> -encrypt encrypt with public key >uri> >uri> -decrypt decrypt with private key >uri> >uri> -derive derive shared secret >uri> >uri> -hexdump hex dump output >uri> >uri> -engine e use engine e, possibly a hardware device. >uri> >uri> -passin arg pass phrase source >uri> >uri> $ >uri> >uri> I would appreciate guidance regarding how to accomplish what I?m >uri> trying to do, and whether it is possible to do so staying within the >uri> OpenSSL CLI. >uri> >uri> Thanks! >uri> >uri> P.S. I followed the README from >uri> https://github.com/OpenSC/engine_pkcs11 as an example of how to use >uri> OpenSSL with engine_pkcs11 and the token. >uri> -- >uri> Regards, >uri> Uri Blumenthal >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From michel.sales at free.fr Thu Dec 10 15:59:38 2015 From: michel.sales at free.fr (Michel) Date: Thu, 10 Dec 2015 16:59:38 +0100 Subject: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory In-Reply-To: References: <003a01d13105$d6b66450$84232cf0$@sales@free.fr> <20151210121648.GA13127@roeckx.be> <20151210122738.GA18048@roeckx.be> <20151210141954.GA26374@roeckx.be> <20151210143744.GA32207@roeckx.be> Message-ID: <005701d13363$c710c940$55325bc0$@sales@free.fr> Hi Kurt, At first glance, it's a fact that your patch is better. :-) I should have thought to some of your improvement, like SRP_gN_new(). I will test it tonight and come back to you. Many for thanks for your interrest in this matter, Michel. -----Message d'origine----- De : Kurt Roeckx via RT [mailto:rt at openssl.org] Envoy? : jeudi 10 d?cembre 2015 15:38 ? : michel.sales at free.fr Cc : openssl-dev at openssl.org Objet : Re: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory On Thu, Dec 10, 2015 at 03:19:54PM +0100, Kurt Roeckx wrote: > On Thu, Dec 10, 2015 at 01:27:38PM +0100, Kurt Roeckx wrote: > > On Thu, Dec 10, 2015 at 01:16:48PM +0100, Kurt Roeckx wrote: > > > On Mon, Dec 07, 2015 at 03:47:56PM +0000, Michel via RT wrote: > > > > Hi, > > > > > > > > Following my previous mail, here attached is an updated patch > > > > against 1.02e to fix the SRP VBASE memory leaks. > > > > > > Can you confirm that this would be the correct patch for master? > > > > The following patch should at least compile. > > I fixed a few more things, cleaned up some things. New patch > attached. I think there is something wrong with new SRP_gN_free(). You now also free g and N, and it's not clear to me who the owner of those is. I think the cache is, in which case we should not free them. I think the cache also isn't cleared, we should probably call SRP_VBASE_free() when SRP_VBASE_init() fails. Kurt From rt at openssl.org Thu Dec 10 16:00:06 2015 From: rt at openssl.org (Michel via RT) Date: Thu, 10 Dec 2015 16:00:06 +0000 Subject: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory In-Reply-To: <005701d13363$c710c940$55325bc0$@sales@free.fr> References: <003a01d13105$d6b66450$84232cf0$@sales@free.fr> <20151210121648.GA13127@roeckx.be> <20151210122738.GA18048@roeckx.be> <20151210141954.GA26374@roeckx.be> <20151210143744.GA32207@roeckx.be> <005701d13363$c710c940$55325bc0$@sales@free.fr> Message-ID: Hi Kurt, At first glance, it's a fact that your patch is better. :-) I should have thought to some of your improvement, like SRP_gN_new(). I will test it tonight and come back to you. Many for thanks for your interrest in this matter, Michel. -----Message d'origine----- De : Kurt Roeckx via RT [mailto:rt at openssl.org] Envoy? : jeudi 10 d?cembre 2015 15:38 ? : michel.sales at free.fr Cc : openssl-dev at openssl.org Objet : Re: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory On Thu, Dec 10, 2015 at 03:19:54PM +0100, Kurt Roeckx wrote: > On Thu, Dec 10, 2015 at 01:27:38PM +0100, Kurt Roeckx wrote: > > On Thu, Dec 10, 2015 at 01:16:48PM +0100, Kurt Roeckx wrote: > > > On Mon, Dec 07, 2015 at 03:47:56PM +0000, Michel via RT wrote: > > > > Hi, > > > > > > > > Following my previous mail, here attached is an updated patch > > > > against 1.02e to fix the SRP VBASE memory leaks. > > > > > > Can you confirm that this would be the correct patch for master? > > > > The following patch should at least compile. > > I fixed a few more things, cleaned up some things. New patch > attached. I think there is something wrong with new SRP_gN_free(). You now also free g and N, and it's not clear to me who the owner of those is. I think the cache is, in which case we should not free them. I think the cache also isn't cleared, we should probably call SRP_VBASE_free() when SRP_VBASE_init() fails. Kurt From rt at openssl.org Thu Dec 10 16:28:39 2015 From: rt at openssl.org (Daniel Stenberg via RT) Date: Thu, 10 Dec 2015 16:28:39 +0000 Subject: [openssl-dev] [openssl.org #4177] opaque X509 struct issues In-Reply-To: References: Message-ID: Hey, In the curl project we're accessing the 'cert_info' to find the 'signature->algorithm' fields from the X509 and X509_CINF structs [*] and we can't build with openssl git master or the 1.1.0-pre release. How can we reach that info using a "proper" API? Making all in lib CC vtls/libcurl_la-openssl.lo vtls/openssl.c: In function 'get_cert_chain': vtls/openssl.c:2347:13: error: dereferencing pointer to incomplete type 'X509 {aka struct x509_s\ t}' cinf = x->cert_info; ^ vtls/openssl.c:2349:30: error: dereferencing pointer to incomplete type 'X509_CINF {aka struct x\ 509_cinf_st}' i2a_ASN1_OBJECT(mem, cinf->signature->algorithm); ^ Makefile:1868: recipe for target 'vtls/libcurl_la-openssl.lo' failed We support building with OpenSSL 0.9.7+ and we're looking for a way to keep that while at the same time support the latest versions! [*] = https://github.com/bagder/curl/blob/master/lib/vtls/openssl.c#L2346 -- / daniel.haxx.se _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Dec 10 16:39:03 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Thu, 10 Dec 2015 16:39:03 +0000 Subject: [openssl-dev] [openssl.org #4177] opaque X509 struct issues In-Reply-To: References: Message-ID: On Thu Dec 10 16:28:39 2015, daniel at haxx.se wrote: > > In the curl project we're accessing the 'cert_info' to find the > 'signature->algorithm' fields from the X509 and X509_CINF structs [*] > and we > can't build with openssl git master or the 1.1.0-pre release. > > How can we reach that info using a "proper" API? > You can retrieve the outer signature and algorithm using X509_get0_signature(). The inner form inside the to be signed portion can be obtained with X509_get0_tbs_sigalg(). See: https://www.openssl.org/docs/manmaster/crypto/X509_get0_signature.html Note that both of these take an X509 structure. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From uri at ll.mit.edu Thu Dec 10 16:59:04 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 10 Dec 2015 16:59:04 +0000 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: References: <20151210.093931.1997199079828500981.levitte@openssl.org> Message-ID: I want to add that apparently some openssl commands work OK with this token and pkcs11 engine: $ openssl version OpenSSL 1.0.2e 3 Dec 2015 $ openssl dgst -engine pkcs11 -keyform engine -sign "pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -sha256 -out t.sig < config.h engine "pkcs11" set. $ ll t.sig -rw-r--r-- 1 ur20980 MITLL\Domain Users 256 Dec 10 11:52 t.sig $ openssl dgst -verify pub.key -keyform PEM -signature t.sig -sha256 < config.h Verified OK $ But I need to also be able to use ?encrypt? (well, ?decrypt? to be precise :) and ?derive? (for ECDH key)? Thanks! -- Regards, Uri Blumenthal On 12/10/15, 10:38 , "openssl-dev on behalf of Blumenthal, Uri - 0553 - MITLL" wrote: >On 12/10/15, 3:39 , "openssl-dev on behalf of Richard Levitte" > wrote: > >>This is an odity with 'openssl pkeyutl'. Try this option order: > >I see! > >>LOAD_CERT_CTRL=true VERBOSE=7 openssl pkeyutl -engine pkcs11 -sign >>-keyform engine -inkey >>"pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -out >>config.status.sig -in config.status.hash > >Much better now - but at this time I hit ?unsupported algorithm?. The key >in question is RSA-2048, with SHA256. > >$ LOAD_CERT_CTRL=true VERBOSE=7 openssl pkeyutl -engine pkcs11 -sign >-keyform engine -inkey >"pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -out >config.status.sig -in config.status.hash >engine "pkcs11" set. >Error initializing context >140735296230224:error:260C0065:engine >routines:ENGINE_get_pkey_meth:unimplemented public key >method:tb_pkmeth.c:128: >140735296230224:error:0609D09C:digital envelope >routines:INT_CTX_NEW:unsupported algorithm:pmeth_lib.c:164: >Usage: pkeyutl [options] >-in file input file >-out file output file >-sigfile file signature file (verify operation only) >-inkey file input key >-keyform arg private key format - default PEM >-pubin input is a public key >-certin input is a certificate carrying a public key >-pkeyopt X:Y public key options >-sign sign with private key >-verify verify with public key >-verifyrecover verify with public key, recover original data >-encrypt encrypt with public key >-decrypt decrypt with private key >-derive derive shared secret >-hexdump hex dump output >-engine e use engine e, possibly a hardware device. >-passin arg pass phrase source >$ > > >I observed exactly the same happening with the decryption key. > >In case it helps: > >$ pkcs15-tool -k >Using reader with a card: Yubico Yubikey NEO OTP+U2F+CCID >Private RSA Key [PIV AUTH key] > Object Flags : [0x1], private > Usage : [0x2E], decrypt, sign, signRecover, unwrap > Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local > ModLength : 2048 > Key ref : 154 (0x9A) > Native : yes > Auth ID : 01 > ID : 01 > MD:guid : >0x'30316562353835613063343662663535643834323364393639623233646562370000000 >0 >00000000' > > >Private RSA Key [SIGN key] > Object Flags : [0x1], private > Usage : [0x20E], decrypt, sign, signRecover, nonRepudiation > Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local > ModLength : 2048 > Key ref : 156 (0x9C) > Native : yes > Auth ID : 01 > ID : 02 > MD:guid : >0x'30326562353835613063343662663535643834323364393639623233646562370000000 >0 >00000000' > > >Private RSA Key [KEY MAN key] > Object Flags : [0x1], private > Usage : [0x22], decrypt, unwrap > Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local > ModLength : 2048 > Key ref : 157 (0x9D) > Native : yes > Auth ID : 01 > ID : 03 > MD:guid : >0x'30336562353835613063343662663535643834323364393639623233646562370000000 >0 >00000000' > > >Private RSA Key [CARD AUTH key] > Object Flags : [0x0] > Usage : [0xC], sign, signRecover > Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local > ModLength : 2048 > Key ref : 158 (0x9E) > Native : yes > ID : 04 > MD:guid : >0x'30346562353835613063343662663535643834323364393639623233646562370000000 >0 >00000000' > > > >>The reason for this is that pkeyutl (as opposed to most other openssl >>subcommands) tries to load the key while parsing the options, so if >>'-keyform engine' comes after '-inkey ...', it will try to load the >>key before having seen that it should be loaded from engine. >> >>I think a bugfix for this is in order... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From deengert at gmail.com Thu Dec 10 16:51:34 2015 From: deengert at gmail.com (Douglas E Engert) Date: Thu, 10 Dec 2015 10:51:34 -0600 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: References: <20151210.093931.1997199079828500981.levitte@openssl.org> Message-ID: <5669AD96.6010606@gmail.com> An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Thu Dec 10 17:16:17 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 10 Dec 2015 17:16:17 +0000 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: <5669AD96.6010606@gmail.com> References: <20151210.093931.1997199079828500981.levitte@openssl.org> <5669AD96.6010606@gmail.com> Message-ID: > From previous private conversations, can you comments on if this is a PIV or > NEO with a PIV applet? I certainly can ? this is NEO with a PIV applet. But side-stepping ? note that openssl dgst appeared to work fine. See my other posting to this list, and duplicated here: $ pkcs15-tool --read-public-key 02 -o pub.key Using reader with a card: Yubico Yubikey NEO OTP+U2F+CCID Please enter PIN [PIV Card Holder pin]: $ openssl dgst -engine pkcs11 -keyform engine -sign "pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -sha256 -out t.sig < config.h engine "pkcs11" set. $ openssl dgst -verify pub.key -keyform PEM -signature t.sig -sha256 < config.h Verified OK > Did you generate a key on the card using the piv-tool or NEO tool? At this moment (test setting) the keys were generated off-card, and loaded on the token using NEO tools. For production, of course they?ll be generated on the card (except for the KEY MAN key) and certified elsewhere. > Did you create a certificate and load it on the card? I assume not. For production this assumption would be correct. But not for this case (testing, "feeling the water", so to say). But in any case, fully-configured certificates with all the necessary attributes (Key Usage, Extended Key Usage, etc.) have been loaded. > There is a chicken and egg problem with the PIV. To determine if a key is on > the card, and its attributes, > the public key that was saved during key generate step is needed. In normal > use the public key is in the certificate, > on the card. But if there is NO certificate on the card, as when you are > trying to generate the certificate, the OpenSC > low level routines will look for the public key from a file off the card. Got it. This will be very useful once I move to ?real? from ?testing?. > https://github.com/OpenSC/OpenSC/wiki/PivTool#generate-a-certificate-request > > shows setting of the PIV_9A_KEY = environment variable. > In your case because you are using the "SIGN key" you would need to set > PIV_9C_KEY=path.to.pubkey.file.der > This should work with other programs like openssl pkeyutl too. > > Once the certificate is then loaded, the PIV_9X_KEY environment variable will > not be used. Got it. Thanks! On 12/10/2015 9:38 AM, Blumenthal, Uri - 0553 - MITLL wrote: > On 12/10/15, 3:39 , "openssl-dev on behalf of Richard Levitte" > > wrote: > >> This is an odity with 'openssl pkeyutl'. Try this option order: > I see! > >> LOAD_CERT_CTRL=true VERBOSE=7 openssl pkeyutl -engine pkcs11 -sign >> -keyform engine -inkey >> "pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -out >> config.status.sig -in config.status.hash > Much better now - but at this time I hit ?unsupported algorithm?. The key > in question is RSA-2048, with SHA256. > > $ LOAD_CERT_CTRL=true VERBOSE=7 openssl pkeyutl -engine pkcs11 -sign > -keyform engine -inkey > "pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -out > config.status.sig -in config.status.hash > engine "pkcs11" set. > Error initializing context > 140735296230224:error:260C0065:engine > routines:ENGINE_get_pkey_meth:unimplemented public key > method:tb_pkmeth.c:128: > 140735296230224:error:0609D09C:digital envelope > routines:INT_CTX_NEW:unsupported algorithm:pmeth_lib.c:164: > Usage: pkeyutl [options] > -in file input file > -out file output file > -sigfile file signature file (verify operation only) > -inkey file input key > -keyform arg private key format - default PEM > -pubin input is a public key > -certin input is a certificate carrying a public key > -pkeyopt X:Y public key options > -sign sign with private key > -verify verify with public key > -verifyrecover verify with public key, recover original data > -encrypt encrypt with public key > -decrypt decrypt with private key > -derive derive shared secret > -hexdump hex dump output > -engine e use engine e, possibly a hardware device. > -passin arg pass phrase source > $ > > > I observed exactly the same happening with the decryption key. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From ron.jordan at oracle.com Thu Dec 10 17:23:50 2015 From: ron.jordan at oracle.com (Ron Jordan) Date: Thu, 10 Dec 2015 09:23:50 -0800 Subject: [openssl-dev] Where are include/openssl symbolic links created? In-Reply-To: <3A4C70BC-C033-43A4-8350-247BD5332008@openssl.org> References: <5668CD57.4070800@oracle.com> <3A4C70BC-C033-43A4-8350-247BD5332008@openssl.org> Message-ID: <5669B526.5000502@oracle.com> Thank you for the reply, I'll see what this leads to... On 12/9/2015 4:57 PM, Richard Levitte wrote: > . /Configure probably said you need to run 'make depend'. I suggest you do just that. > > Cheers > Richard > > > On December 10, 2015 1:54:47 AM GMT+01:00, Ron Jordan wrote: >> Hi Folks, >> >> I have test workspace on Solaris 10 where I was able to build >> openssl-1.0.1p. I'm attempting to update to openssl-1.0.1q and am >> running into issues. Some of the header file symbolic links in >> include/openssl (ec.h, ecdh.h, idea.h, mcd2.h, seed.h, whrlpool.h) are >> >> not being created and I'm seeing errors like the following: >> >> ar: creating ../libcrypto.a >> gmake[3]: *** No rule to make target `../../include/openssl/ec.h', >> needed by `hm_pmeth.o'. >> gmake[3]: *** No rule to make target `../../include/openssl/ecdh.h', >> needed by `hm_pmeth.o'. >> gmake[3]: *** No rule to make target `../../include/openssl/ecdsa.h', >> needed by `hm_pmeth.o'. >> gmake[3]: Target `all' not remade because of errors. >> gmake[2]: *** [subdirs] Error 1 >> gmake[2]: Target `all' not remade because of errors. >> gmake[1]: *** [build_crypto] Error 1 >> >> >> This is due to my workspace environment I'm sure, but I haven't been >> able to find where the symbolic links in include/openssl are created. >> I >> still have some digging to do, but if anyone can point me to the >> make/config/install file that creates them, I'd appreciate it. Thank >> you! >> >> >> Ron Jordan >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From steve at openssl.org Thu Dec 10 17:32:44 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 10 Dec 2015 17:32:44 +0000 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: References: <20151210.093931.1997199079828500981.levitte@openssl.org> Message-ID: <20151210173244.GA938@openssl.org> On Thu, Dec 10, 2015, Blumenthal, Uri - 0553 - MITLL wrote: > Much better now - but at this time I hit ???unsupported algorithm???. The key > in question is RSA-2048, with SHA256. > > $ LOAD_CERT_CTRL=true VERBOSE=7 openssl pkeyutl -engine pkcs11 -sign > -keyform engine -inkey > "pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -out > config.status.sig -in config.status.hash > engine "pkcs11" set. > Error initializing context > 140735296230224:error:260C0065:engine > routines:ENGINE_get_pkey_meth:unimplemented public key > method:tb_pkmeth.c:128: > 140735296230224:error:0609D09C:digital envelope > routines:INT_CTX_NEW:unsupported algorithm:pmeth_lib.c:164: The reason for that is because the -engine option sets the ENGINE to use for everything and the PKCS#11 ENGINE doesn't support that public key method. What we need is a way to load the private key from an ENGINE but not attempt to use that for the actual operations. Temporary fix is to set the second argument in EVP_PKEY_CTX_new to NULL in pkeyutl.c Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Thu Dec 10 18:20:10 2015 From: rt at openssl.org (Daniel Stenberg via RT) Date: Thu, 10 Dec 2015 18:20:10 +0000 Subject: [openssl-dev] [openssl.org #4177] opaque X509 struct issues In-Reply-To: References: Message-ID: On Thu, 10 Dec 2015, Stephen Henson via RT wrote: > You can retrieve the outer signature and algorithm using > X509_get0_signature(). The inner form inside the to be signed portion can be > obtained with X509_get0_tbs_sigalg(). See: Thanks! I also noticed I need X509_get0_extensions() for the extensions, and this function seems to be undocumented but was added in 1.1.0-pre1 (commit 748118a8). -- / daniel.haxx.se From openssl-users at dukhovni.org Thu Dec 10 18:30:45 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 10 Dec 2015 18:30:45 +0000 Subject: [openssl-dev] [openssl.org #4177] opaque X509 struct issues In-Reply-To: References: Message-ID: <20151210183045.GM11836@mournblade.imrryr.org> On Thu, Dec 10, 2015 at 06:20:10PM +0000, Daniel Stenberg via RT wrote: > On Thu, 10 Dec 2015, Stephen Henson via RT wrote: > > > You can retrieve the outer signature and algorithm using > > X509_get0_signature(). The inner form inside the to be signed portion can be > > obtained with X509_get0_tbs_sigalg(). See: > > Thanks! > > I also noticed I need X509_get0_extensions() for the extensions, and this > function seems to be undocumented but was added in 1.1.0-pre1 (commit > 748118a8). Yes, we also need to document X509_add_ext(). Could you file an RT with these, and other missing manpages you find? -- Viktor. From uri at ll.mit.edu Thu Dec 10 19:00:23 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 10 Dec 2015 19:00:23 +0000 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: <20151210173244.GA938@openssl.org> References: <20151210.093931.1997199079828500981.levitte@openssl.org> <20151210173244.GA938@openssl.org> Message-ID: On 12/10/15, 12:32 , "openssl-dev on behalf of Dr. Stephen Henson" wrote: >The reason for that is because the -engine option sets the ENGINE to use >for >everything and the PKCS#11 ENGINE doesn't support that public key method. I?m afraid I don?t understand. What good is a PKCS#11 engine if it doesn?t support at least ?sign? and ?decrypt? methods? >What we need is a way to load the private key from an ENGINE but not >attempt >to use that for the actual operations. Could you please clarify what you mean by ?load the private key?? >Temporary fix is to set the second argument in EVP_PKEY_CTX_new to NULL >in pkeyutl.c With your proposed (temporary) fix, the signature both generated and verified successfully (see below). Could I ask to push this fix to the master, and maybe/hopefully to 1_0_2 branch? $ apps/openssl version OpenSSL 1.0.2f-dev xx XXX xxxx (Library: OpenSSL 1.0.2e 3 Dec 2015) $ LOAD_CERT_CTRL=true VERBOSE=7 apps/openssl pkeyutl -engine pkcs11 -sign -keyform engine -inkey "pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -out ~/src/OpenSC/engine_pkcs11/config.status.sig -in ~/src/OpenSC/engine_pkcs11/config.status.hash engine "pkcs11" set. $ apps/openssl pkeyutl -verify -pubin -inkey ~/src/OpenSC/engine_pkcs11/pub.key -sigfile ~/src/OpenSC/engine_pkcs11/config.status.sig -in ~/src/OpenSC/engine_pkcs11/config.status.hash Signature Verified Successfully $ Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From steve at openssl.org Thu Dec 10 21:56:57 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 10 Dec 2015 21:56:57 +0000 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: References: <20151210.093931.1997199079828500981.levitte@openssl.org> <20151210173244.GA938@openssl.org> Message-ID: <20151210215657.GA7104@openssl.org> On Thu, Dec 10, 2015, Blumenthal, Uri - 0553 - MITLL wrote: > On 12/10/15, 12:32 , "openssl-dev on behalf of Dr. Stephen Henson" > wrote: > > >The reason for that is because the -engine option sets the ENGINE to use > >for > >everything and the PKCS#11 ENGINE doesn't support that public key method. > > I???m afraid I don???t understand. What good is a PKCS#11 engine if it doesn???t > support at least ???sign??? and ???decrypt??? methods? > It does provide a method but it's not of the type pkeyutl needs. There are two separate levels of method in use one is a higher level using the EVP_PKEY and the other a lower level using RSA_METHOD. It is the latter which the engine (in common with most others) uses. Currently when you use the -engine argument to pkeyutl it tries to use the EVP_PKEY method from the engine which doesn't exist. You want it to use OpenSSL for the EVP_PKEY method which then gets redirected at a lower level using the engines RSA_METHOD. > >What we need is a way to load the private key from an ENGINE but not > >attempt > >to use that for the actual operations. > > Could you please clarify what you mean by ???load the private key???? > I mean request an EVP_PKEY structure for the key from the engine: this does not necessartily load physical key components. Typically it will store the handle of the key in the structure and include a method which redirects operations through the engine. > >Temporary fix is to set the second argument in EVP_PKEY_CTX_new to NULL > >in pkeyutl.c > > With your proposed (temporary) fix, the signature both generated and > verified successfully (see below). Could I ask to push this fix to the > master, and maybe/hopefully to 1_0_2 branch? > As I indicated the fix I suggested it temporary. Sometimes a user will want that behaviour so we'd need a new command line option indicating the private key engine only. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From uri at ll.mit.edu Thu Dec 10 22:17:15 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 10 Dec 2015 22:17:15 +0000 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: <20151210215657.GA7104@openssl.org> References: <20151210.093931.1997199079828500981.levitte@openssl.org> <20151210173244.GA938@openssl.org> <20151210215657.GA7104@openssl.org> Message-ID: On 12/10/15, 16:56 , "openssl-dev on behalf of Dr. Stephen Henson" wrote: >>>Temporary fix is to set the second argument in EVP_PKEY_CTX_new to NULL >> >in pkeyutl.c >> >> With your proposed (temporary) fix, the signature both generated and >> verified successfully (see below). Could I ask to push this fix to the >> master, and maybe/hopefully to 1_0_2 branch? >> > >As I indicated the fix I suggested it temporary. Sometimes a user will >want >that behaviour so we'd need a new command line option indicating the >private >key engine only. Ideally engine_pkcs11 should do it automatically, but I see your point. Perhaps the code in pkeyutl.c could check if (a) engine is set, and (b) the engine is PKCS11? And if so - automatically do the right thing? Do you envision other engines with similar needs? My assumption was that the only engine that talks to smart cards is pkcs11... In the meanwhile, in your opinion should rsautl need a similar patch, or would it work out of box, like dgst did? Thank you! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From rt at openssl.org Thu Dec 10 22:37:07 2015 From: rt at openssl.org (Michel via RT) Date: Thu, 10 Dec 2015 22:37:07 +0000 Subject: [openssl-dev] TR: [openssl.org #4172] SRP VBASE stuff still leaking memory In-Reply-To: <00b301d1339b$40143a70$c03caf50$@sales@free.fr> References: <00b301d1339b$40143a70$c03caf50$@sales@free.fr> Message-ID: Hello Kurt, I was not able to 'configure' the master branch for debug-VC-WIN32. I got the error message 'pick os/compiler from: ... However I succeeded with VC-WIN32. I guess this is something related to the new configure perl script and debug/non-debug options, but I am lost with perl. Could you please help for this ? Michel. -----Message d'origine----- De : openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Michel via RT Envoy? : jeudi 10 d?cembre 2015 17:00 Cc : openssl-dev at openssl.org Objet : Re: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory Hi Kurt, At first glance, it's a fact that your patch is better. :-) I should have thought to some of your improvement, like SRP_gN_new(). I will test it tonight and come back to you. Many for thanks for your interrest in this matter, Michel. -----Message d'origine----- De : Kurt Roeckx via RT [mailto:rt at openssl.org] Envoy : jeudi 10 d cembre 2015 15:38 : michel.sales at free.fr Cc : openssl-dev at openssl.org Objet : Re: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory On Thu, Dec 10, 2015 at 03:19:54PM +0100, Kurt Roeckx wrote: > On Thu, Dec 10, 2015 at 01:27:38PM +0100, Kurt Roeckx wrote: > > On Thu, Dec 10, 2015 at 01:16:48PM +0100, Kurt Roeckx wrote: > > > On Mon, Dec 07, 2015 at 03:47:56PM +0000, Michel via RT wrote: > > > > Hi, > > > > > > > > Following my previous mail, here attached is an updated patch > > > > against 1.02e to fix the SRP VBASE memory leaks. > > > > > > Can you confirm that this would be the correct patch for master? > > > > The following patch should at least compile. > > I fixed a few more things, cleaned up some things. New patch > attached. I think there is something wrong with new SRP_gN_free(). You now also free g and N, and it's not clear to me who the owner of those is. I think the cache is, in which case we should not free them. I think the cache also isn't cleared, we should probably call SRP_VBASE_free() when SRP_VBASE_init() fails. Kurt _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From deengert at gmail.com Thu Dec 10 22:47:46 2015 From: deengert at gmail.com (Douglas E Engert) Date: Thu, 10 Dec 2015 16:47:46 -0600 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: References: <20151210.093931.1997199079828500981.levitte@openssl.org> Message-ID: <566A0112.5060606@gmail.com> An HTML attachment was scrubbed... URL: From deengert at gmail.com Thu Dec 10 22:51:28 2015 From: deengert at gmail.com (Douglas E Engert) Date: Thu, 10 Dec 2015 16:51:28 -0600 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: References: <20151210.093931.1997199079828500981.levitte@openssl.org> <5669AD96.6010606@gmail.com> Message-ID: <566A01F0.8080602@gmail.com> An HTML attachment was scrubbed... URL: From steve at openssl.org Thu Dec 10 23:09:55 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 10 Dec 2015 23:09:55 +0000 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: References: <20151210.093931.1997199079828500981.levitte@openssl.org> <20151210173244.GA938@openssl.org> <20151210215657.GA7104@openssl.org> Message-ID: <20151210230955.GA9049@openssl.org> On Thu, Dec 10, 2015, Blumenthal, Uri - 0553 - MITLL wrote: > On 12/10/15, 16:56 , "openssl-dev on behalf of Dr. Stephen Henson" > wrote: > > > > >As I indicated the fix I suggested it temporary. Sometimes a user will > >want > >that behaviour so we'd need a new command line option indicating the > >private > >key engine only. > > Ideally engine_pkcs11 should do it automatically, but I see your point. > Perhaps the code in pkeyutl.c could check if (a) engine is set, and (b) > the engine is PKCS11? And if so - automatically do the right thing? Do you > envision other engines with similar needs? My assumption was that the only > engine that talks to smart cards is pkcs11... The CryptoAPI ENGINE can also talk to smart cards. > > In the meanwhile, in your opinion should rsautl need a similar patch, or > would it work out of box, like dgst did? > It should yes: rsautl uses the lower level RSA functions only. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From pw178860 at gmail.com Fri Dec 11 11:57:44 2015 From: pw178860 at gmail.com (=?UTF-8?B?UGF3ZcWCIFdpdGFz?=) Date: Fri, 11 Dec 2015 12:57:44 +0100 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: <20151210173244.GA938@openssl.org> References: <20151210.093931.1997199079828500981.levitte@openssl.org> <20151210173244.GA938@openssl.org> Message-ID: Hello again. I implemented this "temporary fix" in OpenSSL dynamically linked library and engine_pkcs11.dll (with statically linked OpenSSL) and libp11-2.dll (with statically linked OpenSSL), all compiled by mingw. Unfortunatelly OpenSSL started crashing during my test key operations: openssl req -engine pkcs11 -new -key slot_0-id_d7f4b99792cc4dd708e408d3eb91b566e0a06c02 -keyform engine -x509 -out req.pem -text -days 365 -subj "/C=PL/ST=woj./L=miejscowosc/O=firma/OU=dzial/CN=nazwisko/emailAddress= ktos at domena.pl" openssl x509 -engine pkcs11 -signkey slot_0-id_d7f4b99792cc4dd708e408d3eb91b566e0a06c02 -keyform engine -in req.pem -out test.pem When I reverted this fix, OpenSSL stopped crashing and above operations succeeded. So this fix is unacceptable for me. Regards Pawel On Thu, Dec 10, 2015 at 6:32 PM, Dr. Stephen Henson wrote: > On Thu, Dec 10, 2015, Blumenthal, Uri - 0553 - MITLL wrote: > > > Much better now - but at this time I hit ???unsupported algorithm???. > The key > > in question is RSA-2048, with SHA256. > > > > $ LOAD_CERT_CTRL=true VERBOSE=7 openssl pkeyutl -engine pkcs11 -sign > > -keyform engine -inkey > > "pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -out > > config.status.sig -in config.status.hash > > engine "pkcs11" set. > > Error initializing context > > 140735296230224:error:260C0065:engine > > routines:ENGINE_get_pkey_meth:unimplemented public key > > method:tb_pkmeth.c:128: > > 140735296230224:error:0609D09C:digital envelope > > routines:INT_CTX_NEW:unsupported algorithm:pmeth_lib.c:164: > > The reason for that is because the -engine option sets the ENGINE to use > for > everything and the PKCS#11 ENGINE doesn't support that public key method. > > What we need is a way to load the private key from an ENGINE but not > attempt > to use that for the actual operations. Temporary fix is to set the second > argument in EVP_PKEY_CTX_new to NULL in pkeyutl.c > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pw178860 at gmail.com Fri Dec 11 13:49:18 2015 From: pw178860 at gmail.com (=?UTF-8?B?UGF3ZcWCIFdpdGFz?=) Date: Fri, 11 Dec 2015 14:49:18 +0100 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: References: <20151210.093931.1997199079828500981.levitte@openssl.org> <20151210173244.GA938@openssl.org> Message-ID: Hmm, please ignore my previous post, I did this test again and it works, it was an interference with OpenSSL compiled by VS2012, that installed itself in my test directory. On Fri, Dec 11, 2015 at 12:57 PM, Pawe? Witas wrote: > Hello again. > I implemented this "temporary fix" in OpenSSL dynamically linked library > and engine_pkcs11.dll (with statically linked OpenSSL) and libp11-2.dll > (with statically linked OpenSSL), all compiled by mingw. > Unfortunatelly OpenSSL started crashing during my test key operations: > > openssl req -engine pkcs11 -new -key > slot_0-id_d7f4b99792cc4dd708e408d3eb91b566e0a06c02 -keyform engine -x509 > -out req.pem -text -days 365 -subj > "/C=PL/ST=woj./L=miejscowosc/O=firma/OU=dzial/CN=nazwisko/emailAddress= > ktos at domena.pl" > > openssl x509 -engine pkcs11 -signkey > slot_0-id_d7f4b99792cc4dd708e408d3eb91b566e0a06c02 -keyform engine -in > req.pem -out test.pem > > When I reverted this fix, OpenSSL stopped crashing and above operations > succeeded. > So this fix is unacceptable for me. > > Regards > Pawel > > On Thu, Dec 10, 2015 at 6:32 PM, Dr. Stephen Henson > wrote: > >> On Thu, Dec 10, 2015, Blumenthal, Uri - 0553 - MITLL wrote: >> >> > Much better now - but at this time I hit ???unsupported algorithm???. >> The key >> > in question is RSA-2048, with SHA256. >> > >> > $ LOAD_CERT_CTRL=true VERBOSE=7 openssl pkeyutl -engine pkcs11 -sign >> > -keyform engine -inkey >> > "pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -out >> > config.status.sig -in config.status.hash >> > engine "pkcs11" set. >> > Error initializing context >> > 140735296230224:error:260C0065:engine >> > routines:ENGINE_get_pkey_meth:unimplemented public key >> > method:tb_pkmeth.c:128: >> > 140735296230224:error:0609D09C:digital envelope >> > routines:INT_CTX_NEW:unsupported algorithm:pmeth_lib.c:164: >> >> The reason for that is because the -engine option sets the ENGINE to use >> for >> everything and the PKCS#11 ENGINE doesn't support that public key method. >> >> What we need is a way to load the private key from an ENGINE but not >> attempt >> to use that for the actual operations. Temporary fix is to set the second >> argument in EVP_PKEY_CTX_new to NULL in pkeyutl.c >> >> Steve. >> -- >> Dr Stephen N. Henson. OpenSSL project core developer. >> Commercial tech support now available see: http://www.openssl.org >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alukin at gmail.com Fri Dec 11 14:56:50 2015 From: alukin at gmail.com (Oleksiy Lukin) Date: Fri, 11 Dec 2015 16:56:50 +0200 Subject: [openssl-dev] Linux kernel API and OpenSSL Blowfish compatibility? Message-ID: <566AE432.1050208@gmail.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kcapi_test.tgz Type: application/x-compressed-tar Size: 2619 bytes Desc: not available URL: From matt at openssl.org Fri Dec 11 16:31:32 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 11 Dec 2015 16:31:32 +0000 Subject: [openssl-dev] OSTIF Message-ID: <566AFA64.9030400@openssl.org> Hi all I've had some emails recently from Derek at OSTIF who has been talking to me about their plans to do an audit (separate to the current CII one) of OpenSSL next year. OSTIF is not associated or affiliated with OpenSSL, but if you're interested you can learn more here: https://ostif.org/ Regards Matt From agostrer at gmail.com Fri Dec 11 17:03:20 2015 From: agostrer at gmail.com (Alexander Gostrer) Date: Fri, 11 Dec 2015 09:03:20 -0800 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: <566A0112.5060606@gmail.com> References: <20151210.093931.1997199079828500981.levitte@openssl.org> <566A0112.5060606@gmail.com> Message-ID: <200ADAEF-9E18-473C-8DF5-7C36AD423284@gmail.com> Hi Doug, John and I implemented an ECDSA/ECDH/ECDHE engine. We are in the process of final testing and cleaning up. Changes to OpenSSL were pretty minor. Would you like to review this code? We are planing to publish it on github in a week or so. Regards. Alex Sent from my iPhone > On Dec 10, 2015, at 2:47 PM, Douglas E Engert wrote: > > The OpenSC engine code does not support ECDH. It is on the TODO list. > It took forever to get the ECDSA changes needed into OpenSSL to work with engines, that I never > got to doing the ECDH in engine and libp11. > >> On 12/10/2015 10:59 AM, Blumenthal, Uri - 0553 - MITLL wrote: >> I want to add that apparently some openssl commands work OK with this >> token and pkcs11 engine: >> >> $ openssl version >> OpenSSL 1.0.2e 3 Dec 2015 >> $ openssl dgst -engine pkcs11 -keyform engine -sign >> "pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -sha256 >> -out t.sig < config.h >> engine "pkcs11" set. >> $ ll t.sig >> -rw-r--r-- 1 ur20980 MITLL\Domain Users 256 Dec 10 11:52 t.sig >> $ openssl dgst -verify pub.key -keyform PEM -signature t.sig -sha256 < >> config.h >> Verified OK >> $ >> >> >> >> >> But I need to also be able to use ?encrypt? (well, ?decrypt? to be precise >> :) and ?derive? (for ECDH key)? >> >> Thanks! >> >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -- > > Douglas E. Engert > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Dec 11 23:40:56 2015 From: rt at openssl.org (Michel via RT) Date: Fri, 11 Dec 2015 23:40:56 +0000 Subject: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory In-Reply-To: <003601d1346d$4d65eca0$e831c5e0$@sales@free.fr> References: <00b301d1339b$40143a70$c03caf50$@sales@free.fr> <003601d1346d$4d65eca0$e831c5e0$@sales@free.fr> Message-ID: Hello Kurt, I finally managed to compile a debug 1.1.0 version. (I manually modified the makefile) :-( Anyway, I can confirm the patch you send to me fixes the first memory leak case. BUT, You are right, we should not free g and N, because they are shared/referenced by the VBASE cache. They will be freed by SRP_VBASE_free(); BUT (again) we need to free the *ID* of g and N, which was allocated and no longer in use or referenced elsewhere. I believe the data structures should have been made differently such that they do not share only part of internal data. That's why I did not call sk_SRP_gN_pop_free() in my first patch. Here attached is an updated version of your patch that, I hope, can meet our first requirement. As long as the memory is in a stable state, I think it is not mandatory to free immediatly the VBASE data in case of error. We can let the caller decide what he wants to do. But it is just my opinion. Thanks again, Regards, Michel -----Message d'origine----- De : openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Michel via RT Envoy? : jeudi 10 d?cembre 2015 23:37 Cc : openssl-dev at openssl.org Objet : [openssl-dev] TR: [openssl.org #4172] SRP VBASE stuff still leaking memory Hello Kurt, I was not able to 'configure' the master branch for debug-VC-WIN32. I got the error message 'pick os/compiler from: ... However I succeeded with VC-WIN32. I guess this is something related to the new configure perl script and debug/non-debug options, but I am lost with perl. Could you please help for this ? Michel. -----Message d'origine----- De : openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Michel via RT Envoy : jeudi 10 d cembre 2015 17:00 Cc : openssl-dev at openssl.org Objet : Re: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory Hi Kurt, At first glance, it's a fact that your patch is better. :-) I should have thought to some of your improvement, like SRP_gN_new(). I will test it tonight and come back to you. Many for thanks for your interrest in this matter, Michel. -----Message d'origine----- De : Kurt Roeckx via RT [mailto:rt at openssl.org] Envoy : jeudi 10 d cembre 2015 15:38 : michel.sales at free.fr Cc : openssl-dev at openssl.org Objet : Re: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory On Thu, Dec 10, 2015 at 03:19:54PM +0100, Kurt Roeckx wrote: > On Thu, Dec 10, 2015 at 01:27:38PM +0100, Kurt Roeckx wrote: > > On Thu, Dec 10, 2015 at 01:16:48PM +0100, Kurt Roeckx wrote: > > > On Mon, Dec 07, 2015 at 03:47:56PM +0000, Michel via RT wrote: > > > > Hi, > > > > > > > > Following my previous mail, here attached is an updated patch > > > > against 1.02e to fix the SRP VBASE memory leaks. > > > > > > Can you confirm that this would be the correct patch for master? > > > > The following patch should at least compile. > > I fixed a few more things, cleaned up some things. New patch > attached. I think there is something wrong with new SRP_gN_free(). You now also free g and N, and it's not clear to me who the owner of those is. I think the cache is, in which case we should not free them. I think the cache also isn't cleared, we should probably call SRP_VBASE_free() when SRP_VBASE_init() fails. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: srp_vfy-1.1.0.patch Type: application/octet-stream Size: 4452 bytes Desc: not available URL: From rt at openssl.org Fri Dec 11 23:50:14 2015 From: rt at openssl.org (Michel via RT) Date: Fri, 11 Dec 2015 23:50:14 +0000 Subject: [openssl-dev] [openssl.org #4178] [patch] OpenSSL 1.1.0 fails when configure with no-nextproto In-Reply-To: <000001d1346e$9d894140$d89bc3c0$@sales@free.fr> References: <000001d1346e$9d894140$d89bc3c0$@sales@free.fr> Message-ID: Hi, When configured with the no-nextproto option, compilation fails (OpenSSL 1.1.0, Windows 7 64). This updated patch just add a #ifdef directive around targeted lines. Regards, Michel. -------------- next part -------------- A non-text attachment was scrubbed... Name: no-nextproto-1.1.patch Type: application/octet-stream Size: 1059 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From deengert at gmail.com Sat Dec 12 01:07:38 2015 From: deengert at gmail.com (Douglas E Engert) Date: Fri, 11 Dec 2015 19:07:38 -0600 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: <200ADAEF-9E18-473C-8DF5-7C36AD423284@gmail.com> References: <20151210.093931.1997199079828500981.levitte@openssl.org> <566A0112.5060606@gmail.com> <200ADAEF-9E18-473C-8DF5-7C36AD423284@gmail.com> Message-ID: <566B735A.9020609@gmail.com> An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sat Dec 12 15:08:30 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 12 Dec 2015 15:08:30 +0000 Subject: [openssl-dev] [openssl.org #4178] [patch] OpenSSL 1.1.0 fails when configure with no-nextproto In-Reply-To: References: <000001d1346e$9d894140$d89bc3c0$@sales@free.fr> Message-ID: <44d96c6d95a94d039f2c347ce37b34c0@usma1ex-dag1mb1.msg.corp.akamai.com> Should we support no-nextproto? The #ifdef's complicate the code, and the implementation is very small. From rt at openssl.org Sat Dec 12 15:08:39 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Sat, 12 Dec 2015 15:08:39 +0000 Subject: [openssl-dev] [openssl.org #4178] [patch] OpenSSL 1.1.0 fails when configure with no-nextproto In-Reply-To: <44d96c6d95a94d039f2c347ce37b34c0@usma1ex-dag1mb1.msg.corp.akamai.com> References: <000001d1346e$9d894140$d89bc3c0$@sales@free.fr> <44d96c6d95a94d039f2c347ce37b34c0@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Should we support no-nextproto? The #ifdef's complicate the code, and the implementation is very small. From nitheshkb12 at gmail.com Sat Dec 12 18:10:24 2015 From: nitheshkb12 at gmail.com (Nithesh Kb) Date: Sat, 12 Dec 2015 23:40:24 +0530 Subject: [openssl-dev] Need Steps to build FIPS Enabled openssl for Solaris 64 bit sparc machine. Message-ID: Hello OpennSSL Experts, Someone please share the steps to build FIPS enabled openssl for Solaris 64 bit sparc machine. Actually, I have successfully built it on Linux platform. But on Solaris i have tried many steps using gcc and solaris sun studio compilers but i could not able succeed. also i'm not an experience guy at compiler level :( So finally thought of asking OpenSSL experts. Please help me. Thanks and regards, Nit -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sat Dec 12 19:59:16 2015 From: rt at openssl.org (Michel via RT) Date: Sat, 12 Dec 2015 19:59:16 +0000 Subject: [openssl-dev] [openssl.org #4178] [patch] OpenSSL 1.1.0 fails when configure with no-nextproto In-Reply-To: <000601d13517$851b3dd0$8f51b970$@sales@free.fr> References: <000001d1346e$9d894140$d89bc3c0$@sales@free.fr> <44d96c6d95a94d039f2c347ce37b34c0@usma1ex-dag1mb1.msg.corp.akamai.com> <000601d13517$851b3dd0$8f51b970$@sales@free.fr> Message-ID: In anycase, *NOT* just for me ! :-) I used it because it was available and I tried to avoid unneeded code in software. -----Message d'origine----- De : Salz, Rich via RT [mailto:rt at openssl.org] Envoy? : samedi 12 d?cembre 2015 16:09 ? : michel.sales at free.fr Cc : openssl-dev at openssl.org Objet : RE: [openssl-dev] [openssl.org #4178] [patch] OpenSSL 1.1.0 fails when configure with no-nextproto Should we support no-nextproto? The #ifdef's complicate the code, and the implementation is very small. From rt at openssl.org Sun Dec 13 15:07:00 2015 From: rt at openssl.org (Kazuki Yamaguchi via RT) Date: Sun, 13 Dec 2015 15:07:00 +0000 Subject: [openssl-dev] [openssl.org #4179] fix a bug in ssl_next_proto_validate (ssl/t1_lib.c) [GitHub PR #506] In-Reply-To: <566C473C.2050304@rhe.jp> References: <566C473C.2050304@rhe.jp> Message-ID: By commit 50932c4af2fdd1da01203e9fabe176f9c106882b, ssl_next_proto_validate (in ssl/t1_lib.c) is not validating the length of each advertised protocol name. GitHub Pull Request: https://github.com/openssl/openssl/pull/506 -- Kazuki Yamaguchi _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Dec 14 13:45:21 2015 From: rt at openssl.org (Srinivas Koripella via RT) Date: Mon, 14 Dec 2015 13:45:21 +0000 Subject: [openssl-dev] [openssl.org #4180] Isses with respect to malloc failures handling. In-Reply-To: References: Message-ID: Hello all, Found a handful of issues w.r.t to malloc failures handling in openssl code. Please note that all of these happen when the malloc has failed and returned NULL. ======================================================================================== Issue 1) We could have failed to allocate the ctx->cipher_data in EVP_CipherInit_ex ctx->cipher_data = OPENSSL_malloc(ctx->cipher->ctx_size); if (!ctx->cipher_data) { EVPerr(EVP_F_EVP_CIPHERINIT_EX, ERR_R_MALLOC_FAILURE); return 0; } We do subsequently return error from EVP_CipherInit_ex. However during shutdown because of this error we are not checking for the NULL cipher_data causing cores with the below bt. The bt is as below. (gdb) bt 0 0x0000000001486ed0 in rc4_hmac_md5_ctrl (ctx=0x7692e020, type=, arg=13, ptr=0x7fba15ffe9a0) at ../../../../../../src/crypto/openssl/crypto/evp/e_rc4_hmac_md5.c:274 1 0x00000000014ae3c4 in EVP_CIPHER_CTX_ctrl (ctx=0x7692e020, type=369093024, arg=2, ptr=0x7fba15ffe9a0) at ../../../../../../src/crypto/openssl/crypto/evp/evp_enc.c:606 2 0x00000000013a4e85 in tls1_enc (s=0x7ddbba10, send=1) at ../../../../../../src/crypto/openssl/ssl/t1_enc.c:828 3 0x00000000013954e3 in do_ssl3_write (s=0x7ddbba10, type=21, buf=0x7e477148 "\001", len=2, create_empty_fragment=0) at ../../../../../../src/crypto/openssl/ssl/s3_pkt.c:951 4 0x000000000139566d in ssl3_dispatch_alert (s=0x7692e020) at ../../../../../../src/crypto/openssl/ssl/s3_pkt.c:1704 5 0x0000000001394e73 in ssl3_send_alert (s=0x7ddbba10, level=1, desc=0) at ../../../../../../src/crypto/openssl/ssl/s3_pkt.c:1690 6 0x0000000001398378 in ssl3_shutdown (s=0x7692e020) at ../../../../../../src/crypto/openssl/ssl/s3_lib.c:4205 7 0x0000000001391755 in SSL_shutdown (s=0x7ddbba10) ======================================================================================== Issue 2 In file pmeth_gn.c function EVP_PKEY_keygen, openssl code tries to allocate EVP_PKEY using EVP_PKEY_new and immediately follows with a dereference of the same in the below path without checking if the allocation was successful or not. (gdb) bt at ../../../../../../src/crypto/openssl/crypto/evp/p_lib.c:258 at ../../../../../../src/crypto/openssl/crypto/hmac/hm_pmeth.c:140 at ../../../../../../src/crypto/openssl/crypto/evp/pmeth_gn.c:150 key=0x7779ff14 "\[L \\351\\302\\202M\\"\\326 \\b\\361\\275\\267\\n\\300\\205I\\277\\023\\344\\346D\\341+K5\\331d\\327(\\177\\"\\237\\027\\065\\273TT\\346\\335\\246\\343\\242\\256", keylen=48) at ../../../../../../src/crypto/openssl/crypto/evp/pmeth_gn.c:209 seed5=, seed4_len=, seed4=, seed3_len=, seed3=, seed2_len=, seed2=, seed1_len=, seed1=, sec_len=, sec=, md=) at ../../../../../../src/crypto/openssl/ssl/t1_enc.c:177 ====================================================================================== Issue 3: In file s3_enc.c in function ssl3_digest_cached_records, EVP_DigestInit_ex is called to initialize the EVP digest. Internally to EVP_DigestInit_ex ctx->md_data is allocated and if it fails an error is returned. However in ssl3_digest_cached_records the return value is not checked, causing a null dereference with the below backtrace. at ../../../../../../src/crypto/openssl/crypto/evp/m_sha1.c:127 at ../../../../../../src/crypto/openssl/crypto/evp/digest.c:251 at ../../../../../../src/crypto/openssl/ssl/s3_enc.c:660 ======================================================================================= Issue 4: In file ssl_lib.c, in function ssl_replace_hash, an EVP_MD_CTX is created using EVP_MD_CTX_create. However, the return value of this allocation is not checked and a dereference is made just below in EVP_DigestInit_ex causing a core. ======================================================================================= Issue 5: In tl_enc.c, in function tls1_enc in the case of /\* Explicit IV length, block ciphers and TLS version 1.1 or later \*/ openssl tries to dereference cipher after getting the value of cipher from s->enc_write_ctx. However cipher can be null. This can happen because we returned NULL in Issue 4) above and s->enc_write_ctx->cipher might not have been set. Typically s->enc_write_ctx->cipher would have been set in the below path but because of Issue 4 above we did not set s->enc_write_ctx->cipher. key=0x7789d9e0 "Y\\376\\b\\362w\\332)\\246\\203z3\\366F\\255\\030 \\302\\202\\037\\313om\\342\\317\\304+\\016\\347\\314\\071\\334\\016\`\\301ji\\325\\342\\272r\\202\\025\\312 at s\\241\\271q\\346@/A\\310Os\\223iFm\\356\\257\\314\\241\\331\\355%\\370t\\325\\026R\\306x\\344\\001/\\030\\063\\224/\\250\\205\\067\*\\\\\\241\\277\\250\\\\ \\216h\\226\\251\\350\\351", iv=0x7789da20 "\\355%\\370t\\325\\026R\\306x\\344\\001/\\030\\063\\224/\\250\\205\\067\*\\\\\\241\\277\\250\\\\ \\216h\\226\\251\\350\\351", enc=1) at ../../../../../../src/crypto/openssl/crypto/evp/evp_enc.c:176 at ../../../../../../src/crypto/openssl/ssl/t1_enc.c:576 ======================================================================================== Issue 6: Similar issue as above exists in s3_pkt.c function do_ssl3_write in the case /\* Explicit IV length, block ciphers and TLS version 1.1 or later \*/ where again s->enc_write_ctx->cipher can be NULL. ======================================================================================= Issue 7: In file t1_enc.c, in function tls1_mac, openssl after calling EVP_DigestSignFinal has an assert on the return value to be greater than 0. However, EVP_DigestSignFinal internally allocates memory and if this memory allocation fails, an error is returned. Hence this assert is overaggressive for low memory cases. So Pls see if instead of coring, the error can be handled gracefully. ======================================================================================== Issue 8: In file t1_enc.c, in function tls1_setup_key_block, memory is allocated twice for the keyblock through p1 and p2. If p1 succeeds but p2 fails, p1 is freed but the freed pointer p1 is left dangling inside s->s3->tmp.key_block which is later attempted to be freed while freeing s->s3 resulting in a double free. The fix would be to set the s->s3->tmp.key_block to NULL ======================================================================================== -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From fw at deneb.enyo.de Tue Dec 15 12:24:12 2015 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 15 Dec 2015 13:24:12 +0100 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151208172200.GC23318@localhost> (Nico Williams's message of "Tue, 8 Dec 2015 11:22:01 -0600") References: <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <20151123204824.GC9363@localhost> <20151123220832.GA17864@roeckx.be> <5655A355.4060501@redhat.com> <20151125174834.GA7307@roeckx.be> <56658C8F.1010305@redhat.com> <20151207205055.GN23318@localhost> <20151207210229.GO23318@localhost> <87fuzdgs3v.fsf@mid.deneb.enyo.de> <20151208172200.GC23318@localhost> Message-ID: <87bn9rnbmb.fsf@mid.deneb.enyo.de> * Nico Williams: > On Tue, Dec 08, 2015 at 11:19:32AM +0100, Florian Weimer wrote: >> > Maybe http://trac.mpich.org/projects/openpa/ would fit the bill? >> >> It seems to have trouble to keep up with new architectures. > > New architectures are not really a problem because between a) decent > compilers with C11 and/or non-C11 atomic intrinsics, Not on Windows. > What's the alternative anyways? Using C++11. From rt at openssl.org Tue Dec 15 12:37:46 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Tue, 15 Dec 2015 12:37:46 +0000 Subject: [openssl-dev] [openssl.org #4181] Error building openssl with REF_PRINT In-Reply-To: References: Message-ID: Hello OpenSSL team, I get errors when I build openssl 1.0.2e with -DREF_PRINT -DREF_CHECK ./config -ggdb -DREF_PRINT -DREF_CHECK make ec_key.c: In function 'EC_KEY_free': ec_key.c:115:14: error: called object is not a function or function pointer REF_PRINT("EC_KEY", r); ^ ec_key.c: In function 'EC_KEY_up_ref': ec_key.c:219:14: error: called object is not a function or function pointer REF_PRINT("EC_KEY", r); ^ make[2]: *** [ec_key.o] Error 1 make[2]: Leaving directory `/home/beldmit/openssl-1.0.2e/crypto/ec' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/beldmit/openssl-1.0.2e/crypto' make: *** [build_crypto] Error 1 -- SY, Dmitry Belyavsky -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From kurt at roeckx.be Tue Dec 15 12:43:31 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 15 Dec 2015 13:43:31 +0100 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <87bn9rnbmb.fsf@mid.deneb.enyo.de> References: <20151123204824.GC9363@localhost> <20151123220832.GA17864@roeckx.be> <5655A355.4060501@redhat.com> <20151125174834.GA7307@roeckx.be> <56658C8F.1010305@redhat.com> <20151207205055.GN23318@localhost> <20151207210229.GO23318@localhost> <87fuzdgs3v.fsf@mid.deneb.enyo.de> <20151208172200.GC23318@localhost> <87bn9rnbmb.fsf@mid.deneb.enyo.de> Message-ID: <20151215124331.GA20213@roeckx.be> On Tue, Dec 15, 2015 at 01:24:12PM +0100, Florian Weimer wrote: > * Nico Williams: > > > On Tue, Dec 08, 2015 at 11:19:32AM +0100, Florian Weimer wrote: > >> > Maybe http://trac.mpich.org/projects/openpa/ would fit the bill? > >> > >> It seems to have trouble to keep up with new architectures. > > > > New architectures are not really a problem because between a) decent > > compilers with C11 and/or non-C11 atomic intrinsics, > > Not on Windows. > > > What's the alternative anyways? > > Using C++11. I think this is a relevant article: http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ Kurt From rt at openssl.org Tue Dec 15 14:06:33 2015 From: rt at openssl.org (Jonas Maebe via RT) Date: Tue, 15 Dec 2015 14:06:33 +0000 Subject: [openssl-dev] [openssl.org #3198] [PATCH] Fix missing NULL pointer checks and memory leaks in crypto/asn1 files In-Reply-To: <56701CFD.4070800@elis.ugent.be> References: <4C6658EA-B8F0-4002-AA4F-E02D8FF6389A@elis.ugent.be> <53975F5C.3050602@elis.ugent.be> <56701CFD.4070800@elis.ugent.be> Message-ID: On 10/06/14 21:48, Jonas Maebe via RT wrote: > On 13/12/13 11:54, The default queue via RT wrote: > >> In attachment you can find 7 patches against git master (generated via git format-patch) to fix a number of memory leaks (in case of failures) and missing NULL pointer checks (generally for malloc results) for source files under crypto/asn1. I've tried to follow the coding conventions of the surrounding code. >> >> I have about 50 more similar patches to various other parts of OpenSSL, but I'll wait with submitting them in case you'd like something different about the way I'm grouping/formatting/splitting them. > > I've rebased those 7 patches and all of my other similar patches against > current git HEAD and pushed them to a fork on github. I've created a > pull request for them at https://github.com/openssl/openssl/pull/131 All of my patches have been applied or superseded by other patches in the mean time. I've created a pull request for the four remaining, relevant patches at https://github.com/openssl/openssl/pull/511 Jonas From rt at openssl.org Tue Dec 15 15:03:28 2015 From: rt at openssl.org (Mohammed M. Al-Otaibi via RT) Date: Tue, 15 Dec 2015 15:03:28 +0000 Subject: [openssl-dev] [openssl.org #4182] Error in generating my certificate In-Reply-To: References: Message-ID: Dear Sirs I have run the open ssl The first step has executed successfully: OpenSSL> genrsa 1024 > myID -key.pem But when attempt to execute the next step which is req -new -days 365 -key myID -key.pem -out myID -csr.pem Then the following error appear so Please please advise regarding this issue in order to be solved which telling that the myID.pem has not generated : Error opening Private Key myID -key.pem 3344:error:02001002:system library:fopen:No such file or directory:.\crypto\bio\bss_file.c:356:fopen('myID.pem','rb') 3344:error:20074002:BIO routines:FILE_CTRL:system lib:.\crypto\bio\bss_file.c:358: Best Regards, Mohammed Al-Otaibi, MSc CS [OCA_JavaSE7Programmer_clr][cid:image002.png at 01D0AE85.EC6C0550][itil3] Senior Java Developer E-Solutions Department Memeber of Talal Abu-Ghazaleh Organization (TAGorg) Telephone No.: +962 6 5100900 ext:1399 Email: malotaibi at tagorg.com Website: www.tagorg.com MMO [Description: Description: Description: C:\Users\azar\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.Outlook\4S0OOK20\label-tagiti.png] TAGORG.com: The Global organization for professional services and education. We work hard to stay first -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 4696 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 4874 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 9983 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 6742 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From bkaduk at akamai.com Tue Dec 15 15:57:32 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 15 Dec 2015 09:57:32 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151215124331.GA20213@roeckx.be> References: <20151123204824.GC9363@localhost> <20151123220832.GA17864@roeckx.be> <5655A355.4060501@redhat.com> <20151125174834.GA7307@roeckx.be> <56658C8F.1010305@redhat.com> <20151207205055.GN23318@localhost> <20151207210229.GO23318@localhost> <87fuzdgs3v.fsf@mid.deneb.enyo.de> <20151208172200.GC23318@localhost> <87bn9rnbmb.fsf@mid.deneb.enyo.de> <20151215124331.GA20213@roeckx.be> Message-ID: <5670386C.8000301@akamai.com> On 12/15/2015 06:43 AM, Kurt Roeckx wrote: > On Tue, Dec 15, 2015 at 01:24:12PM +0100, Florian Weimer wrote: >> * Nico Williams: >> Not on Windows. >> >>> What's the alternative anyways? >> Using C++11. > I think this is a relevant article: > http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ > I think an article from 2012 is no longer current; something like http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx might be a better source. -Ben From nico at cryptonector.com Tue Dec 15 16:41:45 2015 From: nico at cryptonector.com (Nico Williams) Date: Tue, 15 Dec 2015 10:41:45 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <87bn9rnbmb.fsf@mid.deneb.enyo.de> References: <20151123204824.GC9363@localhost> <20151123220832.GA17864@roeckx.be> <5655A355.4060501@redhat.com> <20151125174834.GA7307@roeckx.be> <56658C8F.1010305@redhat.com> <20151207205055.GN23318@localhost> <20151207210229.GO23318@localhost> <87fuzdgs3v.fsf@mid.deneb.enyo.de> <20151208172200.GC23318@localhost> <87bn9rnbmb.fsf@mid.deneb.enyo.de> Message-ID: <20151215164144.GB8156@localhost> On Tue, Dec 15, 2015 at 01:24:12PM +0100, Florian Weimer wrote: > * Nico Williams: > > > On Tue, Dec 08, 2015 at 11:19:32AM +0100, Florian Weimer wrote: > >> > Maybe http://trac.mpich.org/projects/openpa/ would fit the bill? > >> > >> It seems to have trouble to keep up with new architectures. > > > > New architectures are not really a problem because between a) decent > > compilers with C11 and/or non-C11 atomic intrinsics, > > Not on Windows. Windows has a family of functions for atomic addition, compare-and-swap, etcetera: https://msdn.microsoft.com/en-us/library/windows/desktop/ms686360%28v=vs.85%29.aspx#interlocked_functions Solaris/Illumos has its own as well. Linux has several atomics libraries. And there are several open-source portable atomics libraries as well. I.e., between compiler non-C11 atomic intrinsics, C11 intrinsics, OS atomic function libraries, and portable open-source atomics libraries, we can cover almost all the bases. > > What's the alternative anyways? > > Using C++11. Sure, but only for a C atomics library for the rest of OpenSSL. So that makes five alternatives, plus the two stub implementations (one with global locks, one with no locking/atomics). Any platform not covered will get one of the stub implementations and its users will have to contribute a better implementation. We have a surfeit of options, not a dearth of them. I don't think lack of atomics primitives is remotely a concern. We should use atomic primitives in OpenSSL. Nico -- From nico at cryptonector.com Tue Dec 15 16:43:59 2015 From: nico at cryptonector.com (Nico Williams) Date: Tue, 15 Dec 2015 10:43:59 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <5670386C.8000301@akamai.com> References: <5655A355.4060501@redhat.com> <20151125174834.GA7307@roeckx.be> <56658C8F.1010305@redhat.com> <20151207205055.GN23318@localhost> <20151207210229.GO23318@localhost> <87fuzdgs3v.fsf@mid.deneb.enyo.de> <20151208172200.GC23318@localhost> <87bn9rnbmb.fsf@mid.deneb.enyo.de> <20151215124331.GA20213@roeckx.be> <5670386C.8000301@akamai.com> Message-ID: <20151215164358.GC8156@localhost> On Tue, Dec 15, 2015 at 09:57:32AM -0600, Benjamin Kaduk wrote: > On 12/15/2015 06:43 AM, Kurt Roeckx wrote: > > On Tue, Dec 15, 2015 at 01:24:12PM +0100, Florian Weimer wrote: > >> Using C++11. > > I think this is a relevant article: > > http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ > > > > I think an article from 2012 is no longer current; something like > http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx > might be a better source. Yes, but not everyone will have the latest and greatest compilers. Still, the Windows interlocked function family is enough. See my other post just now. Nico -- From nitheshkb12 at gmail.com Tue Dec 15 16:51:00 2015 From: nitheshkb12 at gmail.com (Nithesh Kb) Date: Tue, 15 Dec 2015 22:21:00 +0530 Subject: [openssl-dev] Need Steps to build FIPS Enabled openssl for Solaris 64 bit sparc machine. In-Reply-To: References: Message-ID: Hello OpennSSL Experts, Someone please share the steps to build FIPS enabled openssl for Solaris 64 bit sparc machine. Actually, I have successfully built it on Linux platform. But on Solaris i have tried many steps using gcc and solaris sun studio compilers but i could not able succeed. also i'm not an experience guy at compiler level :( So finally thought of asking OpenSSL experts. Please help me. Thanks and regards, Nit On Sat, Dec 12, 2015 at 11:40 PM, Nithesh Kb wrote: > Hello OpennSSL Experts, > Someone please share the steps to build FIPS enabled openssl for Solaris > 64 bit sparc machine. > > Actually, I have successfully built it on Linux platform. But on Solaris i > have tried many steps using gcc and solaris sun studio compilers but i > could not able succeed. also i'm not an experience guy at compiler level :( > > So finally thought of asking OpenSSL experts. > > Please help me. > > Thanks and regards, > Nit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Dec 15 18:15:32 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 15 Dec 2015 18:15:32 +0000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151215164144.GB8156@localhost> References: <20151123204824.GC9363@localhost> <20151123220832.GA17864@roeckx.be> <5655A355.4060501@redhat.com> <20151125174834.GA7307@roeckx.be> <56658C8F.1010305@redhat.com> <20151207205055.GN23318@localhost> <20151207210229.GO23318@localhost> <87fuzdgs3v.fsf@mid.deneb.enyo.de> <20151208172200.GC23318@localhost> <87bn9rnbmb.fsf@mid.deneb.enyo.de> <20151215164144.GB8156@localhost> Message-ID: > I.e., between compiler non-C11 atomic intrinsics, C11 intrinsics, OS atomic > function libraries, and portable open-source atomics libraries, we can cover > almost all the bases. Agreed. > We have a surfeit of options, not a dearth of them. I don't think lack of > atomics primitives is remotely a concern. We should use atomic primitives in > OpenSSL. Yes. It would be great if we could start collecting snippets so that it can easily be put into the next 1.1 alpha release. Perhaps on the wiki: https://wiki.openssl.org/index.php/Examples From kurt at roeckx.be Tue Dec 15 18:54:35 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 15 Dec 2015 19:54:35 +0100 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <5670386C.8000301@akamai.com> References: <5655A355.4060501@redhat.com> <20151125174834.GA7307@roeckx.be> <56658C8F.1010305@redhat.com> <20151207205055.GN23318@localhost> <20151207210229.GO23318@localhost> <87fuzdgs3v.fsf@mid.deneb.enyo.de> <20151208172200.GC23318@localhost> <87bn9rnbmb.fsf@mid.deneb.enyo.de> <20151215124331.GA20213@roeckx.be> <5670386C.8000301@akamai.com> Message-ID: <20151215185435.GA21237@roeckx.be> On Tue, Dec 15, 2015 at 09:57:32AM -0600, Benjamin Kaduk wrote: > On 12/15/2015 06:43 AM, Kurt Roeckx wrote: > > On Tue, Dec 15, 2015 at 01:24:12PM +0100, Florian Weimer wrote: > >> * Nico Williams: > >> Not on Windows. > >> > >>> What's the alternative anyways? > >> Using C++11. > > I think this is a relevant article: > > http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ > > > > I think an article from 2012 is no longer current; something like > http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx > might be a better source. That's all about C++, except for library functions from C99, offsetof, __func__, and "long long" that are now also part of C++. The point of the article I pointed to is that they only do C90. They have no intention of adding support for newer C standards except for the cases where C++ just happens to be compatible. And the C++11 and C11 atomics are compatible, they just have a slightly different syntax, and as the URL I pointed to says are implemented in it. Also, if you want to use atomics we really want the C11 / C++11 memory model which prevents certain important optimazations. Kurt From nico at cryptonector.com Tue Dec 15 19:29:17 2015 From: nico at cryptonector.com (Nico Williams) Date: Tue, 15 Dec 2015 13:29:17 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: References: <5655A355.4060501@redhat.com> <20151125174834.GA7307@roeckx.be> <56658C8F.1010305@redhat.com> <20151207205055.GN23318@localhost> <20151207210229.GO23318@localhost> <87fuzdgs3v.fsf@mid.deneb.enyo.de> <20151208172200.GC23318@localhost> <87bn9rnbmb.fsf@mid.deneb.enyo.de> <20151215164144.GB8156@localhost> Message-ID: <20151215192915.GD8156@localhost> On Tue, Dec 15, 2015 at 06:15:32PM +0000, Salz, Rich wrote: > > I.e., between compiler non-C11 atomic intrinsics, C11 intrinsics, OS atomic > > function libraries, and portable open-source atomics libraries, we can cover > > almost all the bases. > > Agreed. Thanks. This is helpful. I now think we'll have an easy road to consensus on how to get thread-safety in OpenSSL. I will try to contribute infrastructure, but there's a lot of heavy lifting to do that will take a long time, and I can't do it all. Nico -- From nico at cryptonector.com Tue Dec 15 19:36:12 2015 From: nico at cryptonector.com (Nico Williams) Date: Tue, 15 Dec 2015 13:36:12 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151215185435.GA21237@roeckx.be> References: <20151125174834.GA7307@roeckx.be> <56658C8F.1010305@redhat.com> <20151207205055.GN23318@localhost> <20151207210229.GO23318@localhost> <87fuzdgs3v.fsf@mid.deneb.enyo.de> <20151208172200.GC23318@localhost> <87bn9rnbmb.fsf@mid.deneb.enyo.de> <20151215124331.GA20213@roeckx.be> <5670386C.8000301@akamai.com> <20151215185435.GA21237@roeckx.be> Message-ID: <20151215193611.GE8156@localhost> On Tue, Dec 15, 2015 at 07:54:35PM +0100, Kurt Roeckx wrote: > Also, if you want to use atomics we really want the C11 / C++11 > memory model which prevents certain important optimazations. Right, because compilers can reorder some operations. But we've been living with this pre-C11 for decades. We can't yet require C11 (though I'd sure like to). BTW, there's this: http://blogs.msdn.com/b/vcblog/archive/2015/05/01/bringing-clang-to-windows.aspx which, IIUC means we can get C11 on Windows with MSVC with a clang frontend. So maybe Windows is a non-issue, and maybe C11 is a non-issue. Though I'm sure there's platforms where OpenSSL can't expect C11 yet, so I suspect we're stuck with C90+ for a while. Nico -- From uri at ll.mit.edu Tue Dec 15 20:04:45 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 15 Dec 2015 20:04:45 +0000 Subject: [openssl-dev] Cannot verify self-signed certificates? Message-ID: It appears that openssl verify refuses to deal with self-signed certificates? Is it the expected/intended behavior? I can easily imagine circumstances when a user would be happy with a ?partial? validation, i.e. with validating as much as practically possible ? like consistency, correctness of the options/extensions encoding, expiration dates, etc. So if this is intended, I?d like to ask to relax this, or to at least make it possible (via an appropriate option/flag) to validate self-signed certs as far as possible. Here?s what I get: $ openssl verify -verbose -purpose sslclient -purpose smimesign test2.pem test2.pem: CN = test2, C = US error 20 at 0 depth lookup:unable to get local issuer certificate $ openssl x509 -noout -text -inform PEM -in test2.pem Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: CN=test2, C=US Validity Not Before: Dec 15 19:56:58 2015 GMT Not After : Dec 14 19:56:58 2016 GMT Subject: CN=test2, C=US Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:b1:9a:8f:d8:79:41:f0:8b:26:ab:f8:3c:b3:a0: af:e6:a9:31:1c:de:78:5a:18:08:d4:31:9d:9f:4a: 6e:53:9c:4c:e2:cf:13:09:13:71:12:62:37:b4:08: 88:33:ab:09:55:35:25:85:e0:eb:84:4a:8a:24:60: 66:9c:17:df:d1:f9:e2:67:e7:c1:6b:9f:33:83:82: 56:ac:98:33:0b:c5:42:bc:91:61:85:4e:42:25:4a: 92:fb:d9:cb:55:6d:94:7d:6b:12:46:18:24:d1:0e: eb:42:17:31:4c:cd:a7:6c:9c:35:c4:32:6a:06:00: f2:c2:48:aa:d0:f0:31:5d:53:29:97:49:4b:73:a4: a6:8d:36:58:28:1b:65:ad:f7:99:10:17:b0:2c:5b: 2e:44:1c:17:2e:50:9c:80:17:ff:74:1c:d0:3c:6c: 58:61:f6:3b:df:5e:1d:5b:df:93:7d:9f:a4:bc:d8: 89:0d:db:a4:4e:7d:ac:da:6d:c5:ff:25:19:63:c6: 6e:23:81:f2:83:ce:bc:2d:fe:7a:77:98:49:2b:0f: d7:de:b1:88:90:b7:08:09:7c:6c:a3:8e:96:60:12: 8e:3d:79:c6:70:44:46:a1:7b:4a:26:03:c7:20:f3: d3:4c:b8:76:38:d1:13:7a:3c:d7:3b:b4:88:d0:83: d7:b1 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Non Repudiation X509v3 Extended Key Usage: E-mail Protection, TLS Web Client Authentication X509v3 Subject Alternative Name: email:tihs at house.com Signature Algorithm: sha256WithRSAEncryption 06:c0:93:cf:03:3e:1e:3b:c3:41:70:9f:3e:e7:12:a9:ca:af: 77:17:c9:b1:46:4d:31:13:7d:45:91:64:6b:c1:ae:32:90:5b: c6:12:06:75:32:e8:c3:c4:8e:29:12:08:ab:34:5d:ce:70:80: 29:fe:12:3d:9e:32:e6:73:32:39:09:07:2c:62:88:45:c8:cc: 9d:97:e7:26:4c:63:ca:3f:3a:79:4c:48:04:05:50:3f:b9:4a: 45:c6:64:8f:e5:1d:44:4d:9e:6a:41:03:d7:58:d1:a3:21:44: 01:a5:db:62:fa:9a:fd:9c:02:22:63:8b:20:a4:a1:d8:35:b6: 85:f9:6f:a5:7d:2c:75:f2:17:f3:d2:8e:41:57:3d:55:ef:6f: 01:06:a7:26:d1:e3:8e:cd:b1:6e:7f:3a:57:52:76:15:f7:38: 6d:cb:0c:ae:4e:dd:a1:fa:e6:a1:8c:09:56:b3:40:e3:0c:db: ad:60:ca:1d:f8:d6:d8:d5:f6:57:62:41:2b:cc:67:10:34:93: cb:0b:53:b9:57:fb:a0:46:46:18:a6:3e:d7:23:2b:82:ca:92: db:66:82:ee:c3:94:b5:4c:2a:3b:f1:9d:d1:4b:09:89:a3:2f: 2e:18:c9:83:64:b7:6b:62:c5:42:4d:76:f5:62:6b:33:50:8c: e5:73:82:bf $ cat test2.pem -----BEGIN CERTIFICATE----- MIIDEjCCAfqgAwIBAgIBATANBgkqhkiG9w0BAQsFADAdMQ4wDAYDVQQDDAV0ZXN0 MjELMAkGA1UEBhMCVVMwHhcNMTUxMjE1MTk1NjU4WhcNMTYxMjE0MTk1NjU4WjAd MQ4wDAYDVQQDDAV0ZXN0MjELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCxmo/YeUHwiyar+DyzoK/mqTEc3nhaGAjUMZ2fSm5TnEzi zxMJE3ESYje0CIgzqwlVNSWF4OuESookYGacF9/R+eJn58FrnzODglasmDMLxUK8 kWGFTkIlSpL72ctVbZR9axJGGCTRDutCFzFMzadsnDXEMmoGAPLCSKrQ8DFdUymX SUtzpKaNNlgoG2Wt95kQF7AsWy5EHBcuUJyAF/90HNA8bFhh9jvfXh1b35N9n6S8 2IkN26ROfazabcX/JRljxm4jgfKDzrwt/np3mEkrD9fesYiQtwgJfGyjjpZgEo49 ecZwREahe0omA8cg89NMuHY40RN6PNc7tIjQg9exAgMBAAGjXTBbMA8GA1UdEwEB /wQFMAMBAQAwDgYDVR0PAQH/BAQDAgbAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAZBgNVHREEEjAQgQ50aWhzQGhvdXNlLmNvbTANBgkqhkiG9w0BAQsF AAOCAQEABsCTzwM+HjvDQXCfPucSqcqvdxfJsUZNMRN9RZFka8GuMpBbxhIGdTLo w8SOKRIIqzRdznCAKf4SPZ4y5nMyOQkHLGKIRcjMnZfnJkxjyj86eUxIBAVQP7lK RcZkj+UdRE2eakED11jRoyFEAaXbYvqa/ZwCImOLIKSh2DW2hflvpX0sdfIX89KO QVc9Ve9vAQanJtHjjs2xbn86V1J2Ffc4bcsMrk7dofrmoYwJVrNA4wzbrWDKHfjW 2NX2V2JBK8xnEDSTywtTuVf7oEZGGKY+1yMrgsqS22aC7sOUtUwqO/Gd0UsJiaMv LhjJg2S3a2LFQk129WJrM1CM5XOCvw== -----END CERTIFICATE----- $ -- Regards, Uri Blumenthal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From openssl-users at dukhovni.org Tue Dec 15 20:34:08 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 15 Dec 2015 20:34:08 +0000 Subject: [openssl-dev] Cannot verify self-signed certificates? In-Reply-To: References: Message-ID: <20151215203408.GC11836@mournblade.imrryr.org> On Tue, Dec 15, 2015 at 08:04:45PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > It appears that openssl verify refuses to deal with self-signed > certificates? You mean the command-line utility? $ openssl x509 -in rootcert.pem -subject -issuer subject= CN = Root CA issuer= CN = Root CA -----BEGIN CERTIFICATE----- MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9 1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3 bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF -----END CERTIFICATE----- $ openssl verify -CAfile rootcert.pem rootcert.pem rootcert.pem: OK > Here?s what I get: > > $ openssl verify -verbose -purpose sslclient -purpose smimesign test2.pem > > test2.pem: CN = test2, C = US > > error 20 at 0 depth lookup:unable to get local issuer certificate No CAfile, no trust. And your particular certificate has: X509v3 Basic Constraints: critical CA:FALSE which does prevent it from verifying itself. The "CA:FALSE" constraint is only really useful in certificates issued from a different key. No security benefit in setin it in self-signed certificates. $ openssl x509 -text -noout < References: <43503317.9070600@uni-mainz.de> Message-ID: This feature is now available in master (1.1.0). Closing this ticket. Matt From kandy_pal at yahoo.com Tue Dec 15 21:08:30 2015 From: kandy_pal at yahoo.com (Kandy Palanisamy) Date: Tue, 15 Dec 2015 21:08:30 +0000 (UTC) Subject: [openssl-dev] CMP Patch References: <1301102869.1376788.1450213710022.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1301102869.1376788.1450213710022.JavaMail.yahoo@mail.yahoo.com> Miikka, I would like to get the CMP patch for openssl-1.0.1p, openssl-1.0.1q? I tried to apply the patch from your message to openssl-dev on 29 Jul 2015. It does not patch cleanly on these. Could you please point me to where I can get a patch from? Also, do you know if there is a plan to get this integrated into the openssl? Thanks a lot, Kandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Tue Dec 15 21:21:52 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 15 Dec 2015 21:21:52 +0000 Subject: [openssl-dev] Cannot verify self-signed certificates? In-Reply-To: <20151215203408.GC11836@mournblade.imrryr.org> References: <20151215203408.GC11836@mournblade.imrryr.org> Message-ID: On 12/15/15, 15:34 , "openssl-dev on behalf of Viktor Dukhovni" wrote: >On Tue, Dec 15, 2015 at 08:04:45PM +0000, Blumenthal, Uri - 0553 - MITLL >wrote: >> It appears that openssl verify refuses to deal with self-signed >> certificates? > >You mean the command-line utility? Yes. >>$ openssl verify -verbose -purpose sslclient -purpose smimesign test2.pem >> >> test2.pem: CN = test2, C = US >> >> error 20 at 0 depth lookup:unable to get local issuer certificate > >No CAfile, no trust. > >And your particular certificate has: > > X509v3 Basic Constraints: critical > CA:FALSE > >which does prevent it from verifying itself. The "CA:FALSE" >constraint is only really useful in certificates issued from a >different key. No security benefit in setin it in self-signed >certificates. I see. So what you?re saying is if I want self-signed certs to be verifiable that way - they must not have that ?non-CA? constraint. Makes sense. If I want to ?partially? verify a certificate via the command-line utility - e.g. when I don?t have the issuing certificate at hand, is there a way to tell openssl tool to go just as far as it can *without* climbing up the cert chain? I understand and agree that it significantly reduces the value of the verification - but in some [of my use] cases it is sufficient. If it is not supported now - would it be possible to add such capability as an option? Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From fw at deneb.enyo.de Tue Dec 15 21:35:58 2015 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 15 Dec 2015 22:35:58 +0100 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151215124331.GA20213@roeckx.be> (Kurt Roeckx's message of "Tue, 15 Dec 2015 13:43:31 +0100") References: <20151123204824.GC9363@localhost> <20151123220832.GA17864@roeckx.be> <5655A355.4060501@redhat.com> <20151125174834.GA7307@roeckx.be> <56658C8F.1010305@redhat.com> <20151207205055.GN23318@localhost> <20151207210229.GO23318@localhost> <87fuzdgs3v.fsf@mid.deneb.enyo.de> <20151208172200.GC23318@localhost> <87bn9rnbmb.fsf@mid.deneb.enyo.de> <20151215124331.GA20213@roeckx.be> Message-ID: <87a8pbl7i9.fsf@mid.deneb.enyo.de> * Kurt Roeckx: > On Tue, Dec 15, 2015 at 01:24:12PM +0100, Florian Weimer wrote: >> * Nico Williams: >> >> > On Tue, Dec 08, 2015 at 11:19:32AM +0100, Florian Weimer wrote: >> >> > Maybe http://trac.mpich.org/projects/openpa/ would fit the bill? >> >> >> >> It seems to have trouble to keep up with new architectures. >> > >> > New architectures are not really a problem because between a) decent >> > compilers with C11 and/or non-C11 atomic intrinsics, >> >> Not on Windows. >> >> > What's the alternative anyways? >> >> Using C++11. > > I think this is a relevant article: > http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ Based on the MSDN documentation, this (e.g. C++11 features implemented in the MSVC C compiler) has not actually happened: From openssl-users at dukhovni.org Tue Dec 15 21:36:13 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 15 Dec 2015 16:36:13 -0500 Subject: [openssl-dev] Cannot verify self-signed certificates? In-Reply-To: References: <20151215203408.GC11836@mournblade.imrryr.org> Message-ID: <720A20CE-0457-4490-8804-4B690F493D0D@dukhovni.org> > On Dec 15, 2015, at 4:21 PM, Blumenthal, Uri - 0553 - MITLL wrote: > >> And your particular certificate has: >> >> X509v3 Basic Constraints: critical >> CA:FALSE >> >> which does prevent it from verifying itself. The "CA:FALSE" >> constraint is only really useful in certificates issued from a >> different key. No security benefit in setin it in self-signed >> certificates. > > I see. So what you?re saying is if I want self-signed certs to be > verifiable that way - they must not have that ?non-CA? constraint. Makes > sense. Yes, that's what I'm saying. > If I want to ?partially? verify a certificate via the command-line utility > - e.g. when I don?t have the issuing certificate at hand, is there a way > to tell openssl tool to go just as far as it can *without* climbing up the > cert chain? I understand and agree that it significantly reduces the value > of the verification - but in some [of my use] cases it is sufficient. If > it is not supported now - would it be possible to add such capability as > an option? What does "partially verify mean? Without the issuer's public key, you can't check the signature, so all you can do is *parse* the certificate, but you can't *verify* it. The "x509" utility parses certificates, what do you want to do that goes beyond parsing, but stops short of checking the issuer signature? -- Viktor. From kurt at roeckx.be Tue Dec 15 22:04:28 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 15 Dec 2015 23:04:28 +0100 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <87a8pbl7i9.fsf@mid.deneb.enyo.de> References: <5655A355.4060501@redhat.com> <20151125174834.GA7307@roeckx.be> <56658C8F.1010305@redhat.com> <20151207205055.GN23318@localhost> <20151207210229.GO23318@localhost> <87fuzdgs3v.fsf@mid.deneb.enyo.de> <20151208172200.GC23318@localhost> <87bn9rnbmb.fsf@mid.deneb.enyo.de> <20151215124331.GA20213@roeckx.be> <87a8pbl7i9.fsf@mid.deneb.enyo.de> Message-ID: <20151215220428.GA31018@roeckx.be> On Tue, Dec 15, 2015 at 10:35:58PM +0100, Florian Weimer wrote: > * Kurt Roeckx: > > > On Tue, Dec 15, 2015 at 01:24:12PM +0100, Florian Weimer wrote: > >> * Nico Williams: > >> > >> > On Tue, Dec 08, 2015 at 11:19:32AM +0100, Florian Weimer wrote: > >> >> > Maybe http://trac.mpich.org/projects/openpa/ would fit the bill? > >> >> > >> >> It seems to have trouble to keep up with new architectures. > >> > > >> > New architectures are not really a problem because between a) decent > >> > compilers with C11 and/or non-C11 atomic intrinsics, > >> > >> Not on Windows. > >> > >> > What's the alternative anyways? > >> > >> Using C++11. > > > > I think this is a relevant article: > > http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ > > Based on the MSDN documentation, this (e.g. C++11 features implemented > in the MSVC C compiler) has not actually happened: > > And in http://blogs.msdn.com/b/vcblog/archive/2014/06/11/c-11-14-feature-tables-for-visual-studio-14-ctp1.aspx someone mentions that stdatomic.h doesn't exist in the 2014 version. I can't find a reference that says anything in the 2015 changed related to that so I assume it didn't. The only thing I could find is that the C library hasn't been incorparated in the C++ standard. But all the functions actually exist in the C++ . Kurt From nounou.dadoun at avigilon.com Tue Dec 15 22:00:40 2015 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Tue, 15 Dec 2015 22:00:40 +0000 Subject: [openssl-dev] Cannot verify self-signed certificates? In-Reply-To: <720A20CE-0457-4490-8804-4B690F493D0D@dukhovni.org> References: <20151215203408.GC11836@mournblade.imrryr.org> <720A20CE-0457-4490-8804-4B690F493D0D@dukhovni.org> Message-ID: <8149AB08BCB1F54F92680ED6104891A0E01189@mbx027-w1-ca-4.exch027.domain.local> I have actually asked a variant on this question in the path, I would rephrase it as I have a certificate chain which doesn't go all the way back to a self-signed cert. But I "trust" the highest certificate in the chain that I have; is there a way of telling openssl that once it hits this "trusted" certificate, it can stop and return the result. As I recall, the answer was no .. N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 ?|? avigilon.com Follow?Twitter ?|? Follow?LinkedIn This email, including any files attached hereto (the ?email?), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide. -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Tuesday, December 15, 2015 1:36 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Cannot verify self-signed certificates? > On Dec 15, 2015, at 4:21 PM, Blumenthal, Uri - 0553 - MITLL wrote: > >> And your particular certificate has: >> >> X509v3 Basic Constraints: critical >> CA:FALSE >> >> which does prevent it from verifying itself. The "CA:FALSE" >> constraint is only really useful in certificates issued from a >> different key. No security benefit in setin it in self-signed >> certificates. > > I see. So what you?re saying is if I want self-signed certs to be > verifiable that way - they must not have that ?non-CA? constraint. > Makes sense. Yes, that's what I'm saying. > If I want to ?partially? verify a certificate via the command-line > utility > - e.g. when I don?t have the issuing certificate at hand, is there a > way to tell openssl tool to go just as far as it can *without* > climbing up the cert chain? I understand and agree that it > significantly reduces the value of the verification - but in some [of > my use] cases it is sufficient. If it is not supported now - would it > be possible to add such capability as an option? What does "partially verify mean? Without the issuer's public key, you can't check the signature, so all you can do is *parse* the certificate, but you can't *verify* it. The "x509" utility parses certificates, what do you want to do that goes beyond parsing, but stops short of checking the issuer signature? -- Viktor. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From openssl-users at dukhovni.org Tue Dec 15 22:16:37 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 15 Dec 2015 17:16:37 -0500 Subject: [openssl-dev] Cannot verify self-signed certificates? In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E01189@mbx027-w1-ca-4.exch027.domain.local> References: <20151215203408.GC11836@mournblade.imrryr.org> <720A20CE-0457-4490-8804-4B690F493D0D@dukhovni.org> <8149AB08BCB1F54F92680ED6104891A0E01189@mbx027-w1-ca-4.exch027.domain.local> Message-ID: <2CF4657B-1D7E-4D93-959D-D200FDF7D181@dukhovni.org> > On Dec 15, 2015, at 5:00 PM, Nounou Dadoun wrote: > > I have actually asked a variant on this question in the path, I would rephrase it as I have a certificate chain which doesn't go all the way back to a self-signed cert. But I "trust" the highest certificate in the chain that I have; is there a way of telling openssl that once it hits this "trusted" certificate, it can stop and return the result. As I recall, the answer was no .. N With OpenSSL 1.0.2 or greater you can use trust-anchors that are not self-signed. API: X509_VERIFY_PARAM_set_flags(vpm, X509_V_FLAG_PARTIAL_CHAIN); CLI: openssl verify -partial_chain ... -- Viktor. From kandy_pal at yahoo.com Tue Dec 15 22:25:50 2015 From: kandy_pal at yahoo.com (Kandy Palanisamy) Date: Tue, 15 Dec 2015 22:25:50 +0000 (UTC) Subject: [openssl-dev] CMP Patch for openssl-1.0.1p etc References: <321962099.1404293.1450218350677.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <321962099.1404293.1450218350677.JavaMail.yahoo@mail.yahoo.com> I would like to get the CMP patch for openssl-1.0.1p, openssl-1.0.1q? I tried to apply the patch from your message to openssl-dev on 29 Jul 2015. It does not patch cleanly on these. Could you please point me to where I can get a patch from? Also, do you know if there is a plan to get this integrated into the openssl? Thanks a lot, Kandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Tue Dec 15 22:30:33 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 15 Dec 2015 22:30:33 +0000 Subject: [openssl-dev] Cannot verify self-signed certificates? In-Reply-To: <720A20CE-0457-4490-8804-4B690F493D0D@dukhovni.org> References: <20151215203408.GC11836@mournblade.imrryr.org> <720A20CE-0457-4490-8804-4B690F493D0D@dukhovni.org> Message-ID: >>If I want to ?partially? verify a certificate via the command-line >>utility >> - e.g. when I don?t have the issuing certificate at hand, is there a way >> to tell openssl tool to go just as far as it can *without* climbing up >>the >> cert chain? I understand and agree that it significantly reduces the >>value >> of the verification - but in some [of my use] cases it is sufficient. If >> it is not supported now - would it be possible to add such capability as >> an option? > >What does "partially verify mean? Without the issuer's public key, you >can't check the signature, so all you can do is *parse* the certificate, >but you can't *verify* it. Yes, you?re 100% correct. By ?partially verify? I mean ?check for (in)consistencies?, malformed attributes, extensions disagreeing with ?-purpose?, etc. Also, I may not have *all* of the chain available - in which case I?d like this command-line tool to stop at the last *available* certificate of the verification chain, telling me whether the check was OK or not *within the available chain*. >The "x509" utility parses certificates, what do you want to do that goes >beyond parsing, but stops short of checking >the issuer signature? As I said above - match of the extensions to ?-purpose?, for one thing? ?x509? just parses. But I guess you?re correct - if I don?t have the chain to verify signatures, eyeballing the extensions printed with ?-text -noout" would in the end give the same result. Having a tool doing it for me would be more convenient, but I see your point. Also, in your next email you mention ?openssl verify -partial_chain?. Alas, I don?t see this option: $ openssl version OpenSSL 1.0.2e 3 Dec 2015 $ openssl verify --help usage: verify [-verbose] [-CApath path] [-CAfile file] [-purpose purpose] [-crl_check] [-no_alt_chains] [-attime timestamp] [-engine e] cert1 cert2 ... recognized usages: sslclient SSL client sslserver SSL server nssslserver Netscape SSL server smimesign S/MIME signing smimeencrypt S/MIME encryption crlsign CRL signing any Any Purpose ocsphelper OCSP helper timestampsign Time Stamp signing $ man verify NAME verify - Utility to verify certificates. SYNOPSIS openssl verify [-CApath directory] [-CAfile file] [-purpose purpose] [-policy arg] [-ignore_critical] [-attime timestamp] [-check_ss_sig] [-crlfile file] [-crl_download] [-crl_check] [-crl_check_all] [-policy_check] [-explicit_policy] [-inhibit_any] [-inhibit_map] [-x509_strict] [-extended_crl] [-use_deltas] [-policy_print] [-no_alt_chains] [-untrusted file] [-help] [-issuer_checks] [-trusted file] [-verbose] [-] [certificates] DESCRIPTION The verify command verifies certificate chains. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From hanno at hboeck.de Tue Dec 15 22:21:49 2015 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Tue, 15 Dec 2015 23:21:49 +0100 Subject: [openssl-dev] Behavior of OpenSSL EC API regarding point setting Message-ID: <20151215232149.5d33a1cd@pc1> Hi, I experienced some features of the OpenSSL API regarding elliptic curves that I find quite unusual and I want to ask whether that's intended. It's regarding these functions to set curve coordinates: EC_POINT_set_affine_coordinates_GFp EC_POINT_set_compressed_coordinates_GFp It is possible to pass them a parameter for the coordinates that is larger than the curves p parameter. It will automatically reduce them modulo p. One may argue whether that's a wanted behavior by defining that coordinates > p are considered valid. However that might have unintended consequences, for example (I haven't tested this) it is probably possible to send values larger than p in a TLS ECDHE key exchange as the ephemeral key. This could be used as a fingerprinting mechanism (other crypto libs I've tested reject such coordinates). Another thing in general is that the API accepts invalid curve points. Invalid curve points are one of the major implementation pitfalls in ECC and can lead to attacks. OpenSSL properly validates points in the _oct2point functions, but I still find this risky. This looks like an API behavior that could easily lead to desasters if someone not aware of that behavior decided to implement a crypto protocol and use OpenSSL's EC_ functions for it. BoringSSL changed this recently [1]. I would recommend and find it generally a cleaner approach if the curve point setting functions would reject both invalid points and point coordinates larger than p. [1] https://boringssl.googlesource.com/boringssl/+/38feb990a183362397ebc62774cc07374d146c83%5E%21/#F0 -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From openssl-users at dukhovni.org Tue Dec 15 22:51:13 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 15 Dec 2015 17:51:13 -0500 Subject: [openssl-dev] Cannot verify self-signed certificates? In-Reply-To: References: <20151215203408.GC11836@mournblade.imrryr.org> <720A20CE-0457-4490-8804-4B690F493D0D@dukhovni.org> Message-ID: > On Dec 15, 2015, at 5:30 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > Also, in your next email you mention ?openssl verify -partial_chain?. > Alas, I don?t see this option: > > $ openssl version > OpenSSL 1.0.2e 3 Dec 2015 > $ openssl verify --help > usage: verify [-verbose] [-CApath path] [-CAfile file] [-purpose purpose] > [-crl_check] [-no_alt_chains] [-attime timestamp] [-engine e] cert1 cert2 > ... > recognized usages: > sslclient SSL client > sslserver SSL server > nssslserver Netscape SSL server > smimesign S/MIME signing > smimeencrypt S/MIME encryption > crlsign CRL signing > any Any Purpose > ocsphelper OCSP helper > timestampsign Time Stamp signing That's fine, but have you tried it? > $ man verify > > NAME > verify - Utility to verify certificates. > > > SYNOPSIS > openssl verify [-CApath directory] [-CAfile file] [-purpose purpose] [-policy arg] > [-ignore_critical] [-attime timestamp] [-check_ss_sig] [-crlfile file] [-crl_download] > [-crl_check] [-crl_check_all] [-policy_check] [-explicit_policy] [-inhibit_any] [-inhibit_map] > [-x509_strict] [-extended_crl] [-use_deltas] [-policy_print] [-no_alt_chains] [-untrusted > file] [-help] [-issuer_checks] [-trusted file] [-verbose] [-] [certificates] That's fine, but have you tried it? The option is documented in 1.1.0, and not 1.0.2, and yet it is available in both. -- Viktor. From uri at ll.mit.edu Tue Dec 15 22:56:59 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 15 Dec 2015 22:56:59 +0000 Subject: [openssl-dev] Cannot verify self-signed certificates? In-Reply-To: References: <20151215203408.GC11836@mournblade.imrryr.org> <720A20CE-0457-4490-8804-4B690F493D0D@dukhovni.org> Message-ID: On 12/15/15, 17:51 , "openssl-dev on behalf of Viktor Dukhovni" wrote: >>On Dec 15, 2015, at 5:30 PM, Blumenthal, Uri - 0553 - MITLL >> wrote: >> >>$ openssl verify --help >> usage: verify [-verbose] [-CApath path] [-CAfile file] [-purpose >>purpose] >> [-crl_check] [-no_alt_chains] [-attime timestamp] [-engine e] cert1 >>cert2 >> ... > >That's fine, but have you tried it? The option is documented in >1.1.0, and not 1.0.2, and yet it is available in both. Yeah? And it does not complain? Unfortunately, right now most of my cert chains are of length 1, so I can?t give it a good try. :-( And without a decent description of what it is supposed to do, I?m a bit lost... $ openssl verify -verbose -CAfile ~/Certs/RabbitMQ_CA.pem -partial_chain -purpose sslclient RabbitMQ_Dev.pem RabbitMQ_Dev.pem: OK $ openssl verify -verbose -CAfile ~/Certs/RabbitMQ_CA.pem -purpose sslclient RabbitMQ_Dev.pem RabbitMQ_Dev.pem: OK $ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From openssl-users at dukhovni.org Tue Dec 15 23:41:53 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 15 Dec 2015 23:41:53 +0000 Subject: [openssl-dev] Cannot verify self-signed certificates? In-Reply-To: References: <20151215203408.GC11836@mournblade.imrryr.org> <720A20CE-0457-4490-8804-4B690F493D0D@dukhovni.org> Message-ID: <20151215234152.GE11836@mournblade.imrryr.org> On Tue, Dec 15, 2015 at 10:56:59PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > $ openssl verify -verbose -CAfile ~/Certs/RabbitMQ_CA.pem -partial_chain > -purpose sslclient RabbitMQ_Dev.pem > RabbitMQ_Dev.pem: OK Well if that CAfile yields a path to a root CA, the "-partial_chain" option makes no difference. > $ openssl verify -verbose -CAfile ~/Certs/RabbitMQ_CA.pem -purpose > sslclient RabbitMQ_Dev.pem > RabbitMQ_Dev.pem: OK If it is OK without "-partial_chain", then your root CA is in there. $ OpenSSL_1_0_2/bin/openssl verify -CAfile issuer.pem leaf.pem leaf.pem: O = example.com, CN = clica Signing Cert error 2 at 1 depth lookup:unable to get issuer certificate $ OpenSSL_1_0_2/bin/openssl verify -partial_chain -CAfile issuer.pem leaf.pem leaf.pem: OK $ OpenSSL_1_0_2/bin/openssl verify -CAfile root.pem -untrusted chain.pem leaf.pem leaf.pem: OK The entire chain: leaf, issuer, root is in chain.pem. Just the root CA: is in root.pem Just the issuer CA: is in issuer.pem The leaf CA: is the first certificate in leaf.pem (this can just be chain.pem) -- Viktor. From rsalz at akamai.com Wed Dec 16 16:01:02 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 16 Dec 2015 16:01:02 +0000 Subject: [openssl-dev] Behavior of OpenSSL EC API regarding point setting In-Reply-To: <20151215232149.5d33a1cd@pc1> References: <20151215232149.5d33a1cd@pc1> Message-ID: > I would recommend and find it generally a cleaner approach if the curve > point setting functions would reject both invalid points and point coordinates > larger than p. Certainly out-of-range. Not sure about point invalidity. But can you open one or two tickets for this? From swall at redcom.com Wed Dec 16 18:00:04 2015 From: swall at redcom.com (Wall, Stephen) Date: Wed, 16 Dec 2015 13:00:04 -0500 Subject: [openssl-dev] memory leak? Message-ID: <401084E5E73F4241A44F3C9E6FD794280366475FEC@exch-01> This looks like a potential memory leak to me... openssl-1.0.2e/crypto/x509/x509_lu.c: X509_STORE *X509_STORE_new(void) { X509_STORE *ret; if ((ret = (X509_STORE *)OPENSSL_malloc(sizeof(X509_STORE))) == NULL) return NULL; ret->objs = sk_X509_OBJECT_new(x509_object_cmp); ret->cache = 1; ret->get_cert_methods = sk_X509_LOOKUP_new_null(); ret->verify = 0; ret->verify_cb = 0; if ((ret->param = X509_VERIFY_PARAM_new()) == NULL) return NULL; If X509_VERIFY_PARAM_new() fails, function returns NULL without freeing ret. - spw From rt at openssl.org Wed Dec 16 21:27:31 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Wed, 16 Dec 2015 21:27:31 +0000 Subject: [openssl-dev] [openssl.org #4183] No SSL_CIPHER_description() for ChaCha20/Poly1305 In-Reply-To: <5671D73D.9040405@akamai.com> References: <5671D73D.9040405@akamai.com> Message-ID: It looks like SSL_CIPHER_description() will return a bunch of "unknown"s for the recently added chacha20/poly1305 ciphersuites. -Ben _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Dec 16 21:44:28 2015 From: rt at openssl.org (David Benjamin via RT) Date: Wed, 16 Dec 2015 21:44:28 +0000 Subject: [openssl-dev] [openssl.org #4184] Memory leak in DSA redo case In-Reply-To: References: Message-ID: dsa_do_sign retries the operation if |r| or |s| end up zero. This results in leaking the first iteration's value of |ret| since you end up clobbering the previous allocation. https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/dsa/dsa_ossl.c;h=34b4a4ea4a267b62b21916a85ab79350cd276065;hb=HEAD#l135 The fix is to switch the order of the check and allocating |ret|: See https://boringssl.googlesource.com/boringssl/+/2936170d68ec617e1e6f0c2def86728ba29312b7%5E%21/#F0 (This was found via clang's scan-build tool.) David -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Dec 16 23:34:56 2015 From: rt at openssl.org (David Benjamin via RT) Date: Wed, 16 Dec 2015 23:34:56 +0000 Subject: [openssl-dev] [openssl.org #4185] Bug in EVP_MD_CTX_copy_ex's malloc failure handling In-Reply-To: References: Message-ID: EVP_MD_CTX_copy_ex is implemented with memcpy, followed by manually fixing up |out->pctx| and |out->md_data|. https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/evp/digest.c;h=5da0e01039a6da039942db9f1bf8b70753f509f2;hb=HEAD#l292 If allocating |out->md_data| fails, then both |out->pctx| and |in->pctx| may point to the same EVP_PKEY_CTX and freeing |out| will cause problems. We fixed this by not using memcpy. https://boringssl.googlesource.com/boringssl/+/306ece31bcaaed49e0240a2e5555f8901ebb2d45%5E%21/crypto/digest/digest.c David -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From openssl-users at dukhovni.org Wed Dec 16 23:56:59 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 16 Dec 2015 18:56:59 -0500 Subject: [openssl-dev] Cannot verify self-signed certificates? In-Reply-To: References: <20151215203408.GC11836@mournblade.imrryr.org> <720A20CE-0457-4490-8804-4B690F493D0D@dukhovni.org> Message-ID: <361FD538-A292-48C0-A76B-39E4B5967DCC@dukhovni.org> > On Dec 15, 2015, at 5:56 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > And without a decent description of what it is supposed to do, I?m a bit > lost... The "-partial_chain" option is (partially :-) documented at: https://www.openssl.org/docs/manmaster/apps/verify.html -partial_chain Allow partial certificate chain if at least one certificate is in trusted store. Note, that you typically also need to use the "-untrusted" option to provide the rest of the chain, since only the first certificate is read from the file containing the target certificate (perhaps a misfeature, the rest should likely automatically be added as "untrusted"). As a final note, with "-partial_chain" any certificate always verifies against itself regardless of purpose or basic constraints. Thus, for example: $ openssl verify -partial_chain -purpose crlsign foo.pem foo.pem will always succeed, provided foo.pem contains a certificate that does not fail to parse. I'm not quite sure why the purpose is ignored, it might be more useful if the purpose were still checked (after any explicit auxiliary trust settings via "BEGIN TRUSTED CERTIFICATE"). For example, with the certificate below in CAfile checking itself, one might expect "-purpose sslclient" to succeed, and "-purpose smimesign" to fail, or at perhaps "-purpose sslserver" to succeed and "smimesign" to fail. It is not obvious whether the extended key usage should be used at all, or used only in the absence of explicit trust settings, ... or whether the current behaviour is correct (all in the context of -partial_chain). Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2) Signature Algorithm: ecdsa-with-SHA256 Issuer: CN = Issuer CA Validity Not Before: Dec 13 23:23:52 2015 GMT Not After : Apr 15 23:23:52 3015 GMT Subject: CN = example.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:66:49:95:f4:7b:de:35:e7:b4:de:48:b2:58:e9: e8:a0:7a:de:bb:db:86:3b:3d:06:f4:81:a1:94:6c: 83:da:9f:56:cf:f4:d9:38:9b:85:5d:2f:36:4b:15: 85:b0:c7:34:fc:fa:26:30:26:96:4f:f5:a4:30:8b: 3f:c8:79:bd:b8 ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Subject Key Identifier: 5B:20:CA:41:7D:90:88:C7:A4:C0:17:CB:6C:0C:1C:73:9B:B0:7D:8A X509v3 Authority Key Identifier: keyid:7A:B7:5A:3C:D2:95:CA:5D:F7:C5:15:09:16:E1:8F:F5:CC:37:6A:15 X509v3 Basic Constraints: CA:FALSE X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Subject Alternative Name: DNS:example.com Signature Algorithm: ecdsa-with-SHA256 30:44:02:1f:21:c9:03:2a:5c:8a:93:87:2d:3f:4a:ef:32:1a: 95:74:dd:95:6d:43:bd:93:c3:69:94:4c:72:d6:90:28:58:02: 21:00:c8:b3:29:0d:7a:f3:7e:57:1a:84:d7:04:db:ad:33:9d: 29:87:d4:18:52:dc:59:36:f2:12:94:70:63:91:11:81 Trusted Uses: TLS Web Client Authentication Rejected Uses: E-mail Protection -----BEGIN TRUSTED CERTIFICATE----- MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0 3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X GoTXBNutM50ph9QYUtxZNvISlHBjkRGBMBgwCgYIKwYBBQUHAwKgCgYIKwYBBQUH AwQ= -----END TRUSTED CERTIFICATE----- -- Viktor. From openssl-users at dukhovni.org Thu Dec 17 01:17:02 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 17 Dec 2015 01:17:02 +0000 Subject: [openssl-dev] Cannot verify self-signed certificates? In-Reply-To: <361FD538-A292-48C0-A76B-39E4B5967DCC@dukhovni.org> References: <20151215203408.GC11836@mournblade.imrryr.org> <720A20CE-0457-4490-8804-4B690F493D0D@dukhovni.org> <361FD538-A292-48C0-A76B-39E4B5967DCC@dukhovni.org> Message-ID: <20151217011702.GS24882@mournblade.imrryr.org> On Wed, Dec 16, 2015 at 06:56:59PM -0500, Viktor Dukhovni wrote: > As a final note, with "-partial_chain" any certificate always verifies against > itself regardless of purpose or basic constraints. Thus, for example: > > $ openssl verify -partial_chain -purpose crlsign foo.pem foo.pem > > will always succeed, provided foo.pem contains a certificate that does not > fail to parse. > > I'm not quite sure why the purpose is ignored, it might be more useful > if the purpose were still checked (after any explicit auxiliary trust > settings via "BEGIN TRUSTED CERTIFICATE"). It is easy to restore checking the purpose, it seems likely that suppression of that check was an oversight. However, I think that if the leaf certificate is actually trusted and has auxiliary trust settings, those probably should kick in, so the patch below is likely not quite the whole story. diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c index 3acb374..864283e 100644 --- a/crypto/x509/x509_vfy.c +++ b/crypto/x509/x509_vfy.c @@ -617,8 +617,8 @@ static int check_chain_extensions(X509_STORE_CTX *ctx) purpose = ctx->param->purpose; } - /* Check all untrusted certificates */ - for (i = 0; i < ctx->last_untrusted; i++) { + /* Check all untrusted certificates, and always the leaf cert */ + for (i = 0; i == 0 || i < ctx->last_untrusted; i++) { int ret; x = sk_X509_value(ctx->chain, i); if (!(ctx->param->flags & X509_V_FLAG_IGNORE_CRITICAL) -- Viktor. From nico at cryptonector.com Thu Dec 17 07:07:18 2015 From: nico at cryptonector.com (Nico Williams) Date: Thu, 17 Dec 2015 01:07:18 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <87a8pbl7i9.fsf@mid.deneb.enyo.de> References: <5655A355.4060501@redhat.com> <20151125174834.GA7307@roeckx.be> <56658C8F.1010305@redhat.com> <20151207205055.GN23318@localhost> <20151207210229.GO23318@localhost> <87fuzdgs3v.fsf@mid.deneb.enyo.de> <20151208172200.GC23318@localhost> <87bn9rnbmb.fsf@mid.deneb.enyo.de> <20151215124331.GA20213@roeckx.be> <87a8pbl7i9.fsf@mid.deneb.enyo.de> Message-ID: <20151217070717.GK8156@localhost> Another interesting portable atomics library is https://github.com/mintomic/mintomic FYI, I took a stab at a simple portable atomics that uses GCC/clang __atomic, or __sync, or Win32 Interlocked*, or a single global lock, and with a fallback to unsafe, non-atomic implementations for no-threads configurations; adding C11 support will be trivial. For just incremdent/decrement and CAS this is really small, and I think that's enough for OpenSSL for starters. From rsalz at akamai.com Thu Dec 17 09:28:28 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 17 Dec 2015 09:28:28 +0000 Subject: [openssl-dev] Changing malloc/debug stuff Message-ID: <4ed0909e6fd749c3b4bf1568d3432a6f@usma1ex-dag1mb1.msg.corp.akamai.com> I want to change the memory alloc/debug things. Right now there are several undocumented functions to allow you to swap-out the malloc/realloc/free routines, wrappers that call those routines, debug versions of those wrappers, and functions to set the set-options versions of those functions. Yes, really :) Is anyone using that stuff? I want to change the model so that there are three wrappers around malloc/realloc/free, and that the only thing you can do is change that wrapper. This is vastly simpler and easier to understand. I also documented it. A version can be found at https://github.com/openssl/openssl/pull/450 I've posted about this before. But I'm asking again if this kind of change will cause problems for anyone. Thanks. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.grandi at intel.com Thu Dec 17 13:31:48 2015 From: andrea.grandi at intel.com (Grandi, Andrea) Date: Thu, 17 Dec 2015 13:31:48 +0000 Subject: [openssl-dev] [openssl.org #4176] Add support for async jobs in OpenSSL speed In-Reply-To: References: <02DF9A39E1EE92419A8C5BBE62973A231A450CAA@IRSMSX108.ger.corp.intel.com> Message-ID: <02DF9A39E1EE92419A8C5BBE62973A231A4543C1@IRSMSX108.ger.corp.intel.com> Hi! I have just pushed an updated version of the patch that addresses the comments of the pull request: https://github.com/openssl/openssl/pull/501 Regards, Andrea -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Grandi, Andrea via RT Sent: Thursday, December 10, 2015 2:47 PM Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #4176] Add support for async jobs in OpenSSL speed Hi! This pull request adds support for async jobs in OpenSSL speed: https://github.com/openssl/openssl/pull/501 Summary of the changes: * Move the calls to the crypto operations inside wrapper functions. This is required because ASYNC_start_job() takes a function as an argument. * Add new function run_benchmark() that manages the jobs for all the operations. In the POSIX case it uses a select() to receive the events from the engine and resume the jobs that are paused, while in the WIN case it uses PeekNamedPipe() * Add new option argument async_jobs to enable and specify the number of async jobs Example: openssl speed -engine dasync -elapsed -async_jobs 32 rsa2048 Regards, Andrea Grandi -------------------------------------------------------------- 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. -------------------------------------------------------------- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From rt at openssl.org Thu Dec 17 13:43:12 2015 From: rt at openssl.org (Grandi, Andrea via RT) Date: Thu, 17 Dec 2015 13:43:12 +0000 Subject: [openssl-dev] [openssl.org #4176] Add support for async jobs in OpenSSL speed In-Reply-To: <02DF9A39E1EE92419A8C5BBE62973A231A4543C1@IRSMSX108.ger.corp.intel.com> References: <02DF9A39E1EE92419A8C5BBE62973A231A450CAA@IRSMSX108.ger.corp.intel.com> <02DF9A39E1EE92419A8C5BBE62973A231A4543C1@IRSMSX108.ger.corp.intel.com> Message-ID: Hi! I have just pushed an updated version of the patch that addresses the comments of the pull request: https://github.com/openssl/openssl/pull/501 Regards, Andrea -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Grandi, Andrea via RT Sent: Thursday, December 10, 2015 2:47 PM Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #4176] Add support for async jobs in OpenSSL speed Hi! This pull request adds support for async jobs in OpenSSL speed: https://github.com/openssl/openssl/pull/501 Summary of the changes: * Move the calls to the crypto operations inside wrapper functions. This is required because ASYNC_start_job() takes a function as an argument. * Add new function run_benchmark() that manages the jobs for all the operations. In the POSIX case it uses a select() to receive the events from the engine and resume the jobs that are paused, while in the WIN case it uses PeekNamedPipe() * Add new option argument async_jobs to enable and specify the number of async jobs Example: openssl speed -engine dasync -elapsed -async_jobs 32 rsa2048 Regards, Andrea Grandi -------------------------------------------------------------- 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. -------------------------------------------------------------- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From openssl-users at dukhovni.org Thu Dec 17 16:53:10 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 17 Dec 2015 16:53:10 +0000 Subject: [openssl-dev] [openssl-users] Changing malloc/debug stuff In-Reply-To: <4ed0909e6fd749c3b4bf1568d3432a6f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <4ed0909e6fd749c3b4bf1568d3432a6f@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20151217165310.GJ11836@mournblade.imrryr.org> On Thu, Dec 17, 2015 at 09:28:28AM +0000, Salz, Rich wrote: > I want to change the model so that there are three wrappers around > malloc/realloc/free, and that the only thing you can do is change that > wrapper. This is vastly simpler and easier to understand. I also > documented it. A version can be found at > https://github.com/openssl/openssl/pull/450 > > I've posted about this before. But I'm asking again if this kind of change will cause problems for anyone. Does CRYPTO_mem_leaks(bio_err) continue to work after the change? It is used in the test-suite and is fairly useful for that. -- Viktor. From rsalz at akamai.com Thu Dec 17 17:55:12 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 17 Dec 2015 17:55:12 +0000 Subject: [openssl-dev] [openssl-users] Changing malloc/debug stuff In-Reply-To: <20151217165310.GJ11836@mournblade.imrryr.org> References: <4ed0909e6fd749c3b4bf1568d3432a6f@usma1ex-dag1mb1.msg.corp.akamai.com> <20151217165310.GJ11836@mournblade.imrryr.org> Message-ID: <5a16077e36aa413a82fc83139eb10b43@usma1ex-dag1mb1.msg.corp.akamai.com> > Does CRYPTO_mem_leaks(bio_err) continue to work after the change? > It is used in the test-suite and is fairly useful for that. Yes it does! From rt at openssl.org Thu Dec 17 19:43:25 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 17 Dec 2015 19:43:25 +0000 Subject: [openssl-dev] [openssl.org #4185] Bug in EVP_MD_CTX_copy_ex's malloc failure handling In-Reply-To: <20151217194326.GA2435@roeckx.be> References: <20151217194326.GA2435@roeckx.be> Message-ID: On Wed, Dec 16, 2015 at 11:34:56PM +0000, David Benjamin via RT wrote: > EVP_MD_CTX_copy_ex is implemented with memcpy, followed by manually fixing > up |out->pctx| and |out->md_data|. > > https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/evp/digest.c;h=5da0e01039a6da039942db9f1bf8b70753f509f2;hb=HEAD#l292 > > If allocating |out->md_data| fails, then both |out->pctx| and |in->pctx| > may point to the same EVP_PKEY_CTX and freeing |out| will cause problems. > > We fixed this by not using memcpy. > https://boringssl.googlesource.com/boringssl/+/306ece31bcaaed49e0240a2e5555f8901ebb2d45%5E%21/crypto/digest/digest.c This patch won't apply as is since we have more fields (engine, flags). We also don't have pctx_ops, but have update instead, but already seem to copy that anyway. Kurt From rt at openssl.org Thu Dec 17 19:58:49 2015 From: rt at openssl.org (David Benjamin via RT) Date: Thu, 17 Dec 2015 19:58:49 +0000 Subject: [openssl-dev] [openssl.org #4185] Bug in EVP_MD_CTX_copy_ex's malloc failure handling In-Reply-To: References: <20151217194326.GA2435@roeckx.be> Message-ID: On Thu, Dec 17, 2015 at 2:43 PM Kurt Roeckx via RT wrote: > On Wed, Dec 16, 2015 at 11:34:56PM +0000, David Benjamin via RT wrote: > > EVP_MD_CTX_copy_ex is implemented with memcpy, followed by manually > fixing > > up |out->pctx| and |out->md_data|. > > > > > https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/evp/digest.c;h=5da0e01039a6da039942db9f1bf8b70753f509f2;hb=HEAD#l292 > > > > If allocating |out->md_data| fails, then both |out->pctx| and |in->pctx| > > may point to the same EVP_PKEY_CTX and freeing |out| will cause problems. > > > > We fixed this by not using memcpy. > > > https://boringssl.googlesource.com/boringssl/+/306ece31bcaaed49e0240a2e5555f8901ebb2d45%5E%21/crypto/digest/digest.c > > This patch won't apply as is since we have more fields (engine, > flags). > > We also don't have pctx_ops, but have update instead, but already > seem to copy that anyway. > Right, we've diverged enough at this point that patches not applying as-is is the norm. :-) That was meant as a reference, but someone will need to do the equivalent change in OpenSSL if you all like the approach. David From nico at cryptonector.com Thu Dec 17 20:13:43 2015 From: nico at cryptonector.com (Nico Williams) Date: Thu, 17 Dec 2015 14:13:43 -0600 Subject: [openssl-dev] [openssl-users] Changing malloc/debug stuff In-Reply-To: <4ed0909e6fd749c3b4bf1568d3432a6f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <4ed0909e6fd749c3b4bf1568d3432a6f@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20151217201341.GL8156@localhost> On Thu, Dec 17, 2015 at 09:28:28AM +0000, Salz, Rich wrote: > I want to change the memory alloc/debug things. > > Right now there are several undocumented functions to allow you to > swap-out the malloc/realloc/free routines, wrappers that call those > routines, debug versions of those wrappers, and functions to set the > set-options versions of those functions. Yes, really :) Is anyone > using that stuff? This is another one of those things that isn't easy to deal with sanely the way OpenSSL is actually used (i.e., by other libraries as well as by apps). > I want to change the model so that there are three wrappers around > malloc/realloc/free, and that the only thing you can do is change that > wrapper. This is vastly simpler and easier to understand. I also > documented it. A version can be found at > https://github.com/openssl/openssl/pull/450 This seems much more sane. Nico -- From rsalz at akamai.com Thu Dec 17 20:16:50 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 17 Dec 2015 20:16:50 +0000 Subject: [openssl-dev] [openssl-users] Changing malloc/debug stuff In-Reply-To: <20151217201341.GL8156@localhost> References: <4ed0909e6fd749c3b4bf1568d3432a6f@usma1ex-dag1mb1.msg.corp.akamai.com> <20151217201341.GL8156@localhost> Message-ID: <21fa57e661474b2ca5cb81b8072295a5@usma1ex-dag1mb1.msg.corp.akamai.com> > > https://github.com/openssl/openssl/pull/450 > > This seems much more sane. I'll settle for less insane :) From rt at openssl.org Thu Dec 17 20:45:52 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Thu, 17 Dec 2015 20:45:52 +0000 Subject: [openssl-dev] [openssl.org #4185] Bug in EVP_MD_CTX_copy_ex's malloc failure handling In-Reply-To: References: <20151217194326.GA2435@roeckx.be> Message-ID: Considering we just had a substantial change in digest.c et al, inspiration is the way to go. I figured that these two lines after the first memcpy() would be good enough, as those are the variables that get populated afterward: out->md_data = NULL; out->pctx = NULL; Cheers, Richard Vid Thu, 17 Dec 2015 kl. 19.58.49, skrev davidben at google.com: > On Thu, Dec 17, 2015 at 2:43 PM Kurt Roeckx via RT > wrote: > > > On Wed, Dec 16, 2015 at 11:34:56PM +0000, David Benjamin via RT > > wrote: > > > EVP_MD_CTX_copy_ex is implemented with memcpy, followed by manually > > fixing > > > up |out->pctx| and |out->md_data|. > > > > > > > > https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/evp/digest.c;h=5da0e01039a6da039942db9f1bf8b70753f509f2;hb=HEAD#l292 > > > > > > If allocating |out->md_data| fails, then both |out->pctx| and |in- > > > >pctx| > > > may point to the same EVP_PKEY_CTX and freeing |out| will cause > > > problems. > > > > > > We fixed this by not using memcpy. > > > > > https://boringssl.googlesource.com/boringssl/+/306ece31bcaaed49e0240a2e5555f8901ebb2d45%5E%21/crypto/digest/digest.c > > > > This patch won't apply as is since we have more fields (engine, > > flags). > > > > We also don't have pctx_ops, but have update instead, but already > > seem to copy that anyway. > > > > Right, we've diverged enough at this point that patches not applying > as-is > is the norm. :-) That was meant as a reference, but someone will need > to do > the equivalent change in OpenSSL if you all like the approach. > > David -- Richard Levitte levitte at openssl.org From uri at ll.mit.edu Thu Dec 17 22:06:20 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 17 Dec 2015 22:06:20 +0000 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: References: <20151210.093931.1997199079828500981.levitte@openssl.org> <20151210173244.GA938@openssl.org> <20151210215657.GA7104@openssl.org> Message-ID: I?m playing with RSA-PSS and PKCS11 engine (in OpenSSL, of course :). This works: $ openssl dgst -engine pkcs11 -keyform engine -sign "pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -sha256 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -out sig1.out ~/src/wtls-verifier engine "pkcs11" set. $ pkcs15-tool --read-public-key 02 -o 02.pem Using reader with a card: Yubico Yubikey NEO OTP+U2F+CCID Please enter PIN [PIV Card Holder pin]: $ openssl dgst -keyform PEM -verify 02.pem -sha256 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -signature sig1.out ~/src/wtls-verifier Verified OK $ But this doesn?t: $ openssl dgst -engine pkcs11 -keyform engine -verify "pkcs11:object=SIGN%20pubkey;object-type=public" -sha256 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -signature sig1.out ~/src/wtls-verifier engine "pkcs11" set. The key ID is not a valid PKCS#11 URI as defined by RFC7512. PKCS11_load_public_key returned NULL unable to load key file $ And this one doesn?t either: $ openssl dgst -engine pkcs11 -keyform engine -verify "pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=6d87283aaed2e 6a5;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%02;object=SIGN%20pub key;object-type=public" -sha256 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -signature sig1.out ~/src/wtls-verifier engine "pkcs11" set. The key ID is not a valid PKCS#11 URI as defined by RFC7512. PKCS11_load_public_key returned NULL unable to load key file $ openssl dgst -engine pkcs11 -keyform engine -verify "pkcs11:object=SIGN%20pubkey;type=public" -sha256 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -signature sig1.out ~/src/wtls-verifier engine "pkcs11" set. The key ID is not a valid PKCS#11 URI as defined by RFC7512. PKCS11_load_public_key returned NULL unable to load key file Is it a bug, or what am I doing wrong? Thanks! -- Regards, Uri Blumenthal On 12/10/15, 17:17 , "openssl-dev on behalf of Blumenthal, Uri - 0553 - MITLL" wrote: >On 12/10/15, 16:56 , "openssl-dev on behalf of Dr. Stephen Henson" > wrote: > >>>>Temporary fix is to set the second argument in EVP_PKEY_CTX_new to NULL >>> >in pkeyutl.c >>> >>> With your proposed (temporary) fix, the signature both generated and >>> verified successfully (see below). Could I ask to push this fix to the >>> master, and maybe/hopefully to 1_0_2 branch? >>> >> >>As I indicated the fix I suggested it temporary. Sometimes a user will >>want that behaviour so we'd need a new command line option indicating the >>private key engine only. > >Ideally engine_pkcs11 should do it automatically, but I see your point. >Perhaps the code in pkeyutl.c could check if (a) engine is set, and (b) >the engine is PKCS11? And if so - automatically do the right thing? Do you >envision other engines with similar needs? My assumption was that the only >engine that talks to smart cards is pkcs11... > >In the meanwhile, in your opinion should rsautl need a similar patch, or >would it work out of box, like dgst did? > >Thank you! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From nico at cryptonector.com Thu Dec 17 22:37:56 2015 From: nico at cryptonector.com (Nico Williams) Date: Thu, 17 Dec 2015 16:37:56 -0600 Subject: [openssl-dev] [openssl-users] Changing malloc/debug stuff In-Reply-To: <21fa57e661474b2ca5cb81b8072295a5@usma1ex-dag1mb1.msg.corp.akamai.com> References: <4ed0909e6fd749c3b4bf1568d3432a6f@usma1ex-dag1mb1.msg.corp.akamai.com> <20151217201341.GL8156@localhost> <21fa57e661474b2ca5cb81b8072295a5@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20151217223755.GM8156@localhost> On Thu, Dec 17, 2015 at 08:16:50PM +0000, Salz, Rich wrote: > > > https://github.com/openssl/openssl/pull/450 > > > > This seems much more sane. > > I'll settle for less insane :) That is, I think, the best you can do. Some allocations might have taken place by the time a wrapper or alternative allocator is installed, in which case something bad will happen. In the case of alternative allocators the something bad is "it blows up", while in the case of a wrapper the something bad is "some state/whatever will be off". A fully sane approach would be to have every allocated object internally point to its destructor, and then always destroy by calling that destructor instead of a global one. (Or call a global one that knows how to find the object's private destructor pointer, and then calls that.) If you wish, something more OO-ish. But for many allocations that's not possible because they aren't "objects" in the sense that matters. You could always wrap allocations so that they always have room at the front for the corresponding destructor, then return the offset of the end of that pointer, but this will be very heavy-duty for many allocations. So, all in all, I like and prefer your approach. Nico -- From deengert at gmail.com Fri Dec 18 01:21:53 2015 From: deengert at gmail.com (Douglas E Engert) Date: Thu, 17 Dec 2015 19:21:53 -0600 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: References: <20151210.093931.1997199079828500981.levitte@openssl.org> <20151210173244.GA938@openssl.org> <20151210215657.GA7104@openssl.org> Message-ID: <56735FB1.60500@gmail.com> An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Dec 18 15:27:21 2015 From: rt at openssl.org (Short, Todd via RT) Date: Fri, 18 Dec 2015 15:27:21 +0000 Subject: [openssl-dev] [openssl.org #4186] [Patch] DSA_dup() function missing in master In-Reply-To: References: Message-ID: Hello OpenSSL Organization: With the subsequent changes in master branch to make structures opaque, there is no way to duplicate a DSA object. This patch adds DSA_dup() to OpenSSL. Github link: https://github.com/akamai/openssl/commit/83cf0487d5c673fca96fe8544599032fe08f77f2 -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Dec 18 15:29:50 2015 From: rt at openssl.org (Short, Todd via RT) Date: Fri, 18 Dec 2015 15:29:50 +0000 Subject: [openssl-dev] [openssl.org #4187] [Patch] Secure memory subsystem does not report actual size In-Reply-To: References: Message-ID: Hello OpenSSL Organization: This patch updates the secure memory allocator to allow callers to determine the actual size of the secure memory allocation. This can be used by applications to report accurate memory usage. Github link: https://github.com/akamai/openssl/commit/6d0b49bd810e0ae36d934c34cab8ad37089ca6ef -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Dec 18 15:32:33 2015 From: rt at openssl.org (Short, Todd via RT) Date: Fri, 18 Dec 2015 15:32:33 +0000 Subject: [openssl-dev] [openssl.org #4188] [Patch/Fix] s_server.c does not compile when no-srtp is configured In-Reply-To: <512C3057-9DF0-4551-8CB5-F71D012E8582@akamai.com> References: <512C3057-9DF0-4551-8CB5-F71D012E8582@akamai.com> Message-ID: Hello OpenSSL Organization: When ?no-srtp? is configured, the s_server.c application does not successfully compile. The undefined variable srtp_profiles is referenced. This patch fixes the issue. Github link: https://github.com/akamai/openssl/commit/f78119f39621d02bee31c9427b2be3a9d2cff26f -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From nmav at redhat.com Fri Dec 18 15:46:48 2015 From: nmav at redhat.com (Nikos Mavrogiannopoulos) Date: Fri, 18 Dec 2015 16:46:48 +0100 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: References: <20151210.093931.1997199079828500981.levitte@openssl.org> <20151210173244.GA938@openssl.org> <20151210215657.GA7104@openssl.org> Message-ID: <1450453608.20562.35.camel@redhat.com> On Thu, 2015-12-17 at 22:06 +0000, Blumenthal, Uri - 0553 - MITLL wrote: > I?m playing with RSA-PSS and PKCS11 engine (in OpenSSL, of course :). [...] > But this doesn?t: > > $ openssl dgst -engine pkcs11 -keyform engine -verify > "pkcs11:object=SIGN%20pubkey;object-type=public" -sha256 -sigopt The current implementation of engine_pkcs11 seems to work with private keys and certificates only. I've added a fix in engine_pkcs11, but it seems that public key types were never tested for PKCS#11 URLs. regards, Nikos From rt at openssl.org Fri Dec 18 15:53:06 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Fri, 18 Dec 2015 15:53:06 +0000 Subject: [openssl-dev] [openssl.org #4187] [Patch] Secure memory subsystem does not report actual size In-Reply-To: References: Message-ID: This is good. I changed it to size_t and will merge it as part of other "secmem" API cleanups I have in progress. From uri at ll.mit.edu Fri Dec 18 16:34:57 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 18 Dec 2015 16:34:57 +0000 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: <1450453608.20562.35.camel@redhat.com> References: <20151210.093931.1997199079828500981.levitte@openssl.org> <20151210173244.GA938@openssl.org> <20151210215657.GA7104@openssl.org> <1450453608.20562.35.camel@redhat.com> Message-ID: On 12/18/15, 10:46 , "openssl-dev on behalf of Nikos Mavrogiannopoulos" wrote: >On Thu, 2015-12-17 at 22:06 +0000, Blumenthal, Uri - 0553 - MITLL >wrote: >> I?m playing with RSA-PSS and PKCS11 engine (in OpenSSL, of course :). >[...] >> But this doesn?t: >> >> $ openssl dgst -engine pkcs11 -keyform engine -verify >> "pkcs11:object=SIGN%20pubkey;object-type=public" -sha256 -sigopt > >The current implementation of engine_pkcs11 seems to work with private >keys and certificates only. I've added a fix in engine_pkcs11, but it >seems that public key types were never tested for PKCS#11 URLs. I?ll be happy to help testing your fix(es). Am I correct assuming that the correct behavior would be retrieving the public key (or certificate) from the token? I could not find the code for that, perhaps it needs to be added? Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From uri at ll.mit.edu Fri Dec 18 16:40:30 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 18 Dec 2015 16:40:30 +0000 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: <56735FB1.60500@gmail.com> References: <20151210.093931.1997199079828500981.levitte@openssl.org> <20151210173244.GA938@openssl.org> <20151210215657.GA7104@openssl.org> <56735FB1.60500@gmail.com> Message-ID: > "The key ID is not a valid PKCS#11 URI as defined by" > comes from the OpenSC engine code in ./engine_pkcs11.c Got it, thanks! > looks like type or object-type= will be ignored, but must be cert or private, > but if its not, rv may not be set correctly:?? > > Try removing the "object-type=public" in your tests. Replacing the URL to point at a certificate instead of the pub key, and/or omitting the ?object-type=? altogether did not change the error message. It is still ?Unable to load key file?. I suspect (Doug and Nikos, please correct if I?m wrong!) that since many tokens (mine certainly) do not perform operations with the public keys, when a public key on the token is referred ? it needs to be retrieved and processed entirely in software. So the key needs to be retrieved from the card, and passed to the other components of pkeyutl, rsautl, or dgst? What would be a good location in the code for that addition? Thanks! > On 12/17/2015 4:06 PM, Blumenthal, Uri - 0553 - MITLL wrote: >> I?m playing with RSA-PSS and PKCS11 engine (in OpenSSL, of course :). >> >> This works: >> >> $ openssl dgst -engine pkcs11 -keyform engine -sign >> "pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -sha256 >> -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -out sig1.out >> ~/src/wtls-verifier >> engine "pkcs11" set. >> $ pkcs15-tool --read-public-key 02 -o 02.pem >> Using reader with a card: Yubico Yubikey NEO OTP+U2F+CCID >> Please enter PIN [PIV Card Holder pin]: >> $ openssl dgst -keyform PEM -verify 02.pem -sha256 -sigopt >> rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -signature sig1.out >> ~/src/wtls-verifier >> Verified OK >> $ >> >> >> But this doesn?t: >> >> $ openssl dgst -engine pkcs11 -keyform engine -verify >> "pkcs11:object=SIGN%20pubkey;object-type=public" -sha256 -sigopt >> rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -signature sig1.out >> ~/src/wtls-verifier >> engine "pkcs11" set. >> The key ID is not a valid PKCS#11 URI as defined by >> RFC7512. >> PKCS11_load_public_key returned NULL >> unable to load key file >> $ >> >> >> >> And this one doesn?t either: >> >> $ openssl dgst -engine pkcs11 -keyform engine -verify >> "pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=6d87283aaed2e >> 6a5;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%02;object=SIGN%20pub >> key;object-type=public" -sha256 -sigopt rsa_padding_mode:pss -sigopt >> rsa_pss_saltlen:-1 -signature sig1.out ~/src/wtls-verifier >> engine "pkcs11" set. >> The key ID is not a valid PKCS#11 URI as defined by >> RFC7512. >> PKCS11_load_public_key returned NULL >> unable to load key file >> >> >> $ openssl dgst -engine pkcs11 -keyform engine -verify >> "pkcs11:object=SIGN%20pubkey;type=public" -sha256 -sigopt >> rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -signature sig1.out >> ~/src/wtls-verifier >> engine "pkcs11" set. >> The key ID is not a valid PKCS#11 URI as defined by >> RFC7512. >> PKCS11_load_public_key returned NULL >> unable to load key file >> >> >> Is it a bug, or what am I doing wrong? >> >> Thanks! >> >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -- > > Douglas E. Engert > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From agostrer at gmail.com Sat Dec 19 03:33:26 2015 From: agostrer at gmail.com (Alexander Gostrer) Date: Fri, 18 Dec 2015 19:33:26 -0800 Subject: [openssl-dev] ECDH engine Message-ID: Hi Steve, John and I completed writing an ECDH engine based on the OpenSSL_1_0_2-stable branch. We were planning to expand it to the master but found some major changes made by you recently. What is the status of this task? Is it stable enough to follow it? Are you planning another changes? Is there a design document that we can use in our work? Thank you, Alex Gostrer -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwmw2 at infradead.org Sat Dec 19 09:23:28 2015 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 19 Dec 2015 09:23:28 +0000 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: <1450453608.20562.35.camel@redhat.com> References: <20151210.093931.1997199079828500981.levitte@openssl.org> <20151210173244.GA938@openssl.org> <20151210215657.GA7104@openssl.org> <1450453608.20562.35.camel@redhat.com> Message-ID: <1450517008.4267.100.camel@infradead.org> On Fri, 2015-12-18 at 16:46 +0100, Nikos Mavrogiannopoulos wrote: > On Thu, 2015-12-17 at 22:06 +0000, Blumenthal, Uri - 0553 - MITLL > wrote: > > I?m playing with RSA-PSS and PKCS11 engine (in OpenSSL, of course :). > [...] > > But this doesn?t: > > > > $ openssl dgst -engine pkcs11 -keyform engine -verify > > "pkcs11:object=SIGN%20pubkey;object-type=public" -sha256 -sigopt > > The current implementation of engine_pkcs11 seems to work with private > keys and certificates only. I've added a fix in engine_pkcs11, but it > seems that public key types were never tested for PKCS#11 URLs. Yes, mea culpa. I added the basic PKCS#11 URI parsing, and failed to test it with public keys. I still suspect we should be using p11kit and not reimplementing the PKCS#11 URI parsing for ourselves. But really I want the whole engine to die and PKCS#11 to be supported as a first-class citizen within OpenSSL in crypto/p11/... -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From steve at openssl.org Sat Dec 19 20:49:17 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Sat, 19 Dec 2015 20:49:17 +0000 Subject: [openssl-dev] ECDH engine In-Reply-To: References: Message-ID: <20151219204917.GA1814@openssl.org> On Fri, Dec 18, 2015, Alexander Gostrer wrote: > Hi Steve, > > John and I completed writing an ECDH engine based on the > OpenSSL_1_0_2-stable branch. We were planning to expand it to the master > but found some major changes made by you recently. What is the status of > this task? Is it stable enough to follow it? Are you planning another > changes? Is there a design document that we can use in our work? > The version in master shouldn't change much any more. Documentation will be available in the near future. The changes were meant to remove some of the weird "quirks" of ECC compared to other algortihms and to permit future expansion to a wider range of curves. In the meantime it shouldn't be too hard to follow how the new code works. Instead of separate ECDH/ECDSA methods with weird locking and ex_data and minimal ENGINE support everything is combined into a single EC_KEY_METHOD which can contain ECDSA, ECDH and key generation (something which was impossible with the old code) and be tied directly to an ENGINE. Most of the primary APIs such as ECDH_compute_key can be redirected directly through an engine supplied function in EC_KEY_METHOD. Having said that the code is very new and may have the odd bug that needs to be fixed. If you have any problems let me know and I'll look into them. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From agostrer at gmail.com Sat Dec 19 21:39:14 2015 From: agostrer at gmail.com (Alexander Gostrer) Date: Sat, 19 Dec 2015 13:39:14 -0800 Subject: [openssl-dev] ECDH engine In-Reply-To: <20151219204917.GA1814@openssl.org> References: <20151219204917.GA1814@openssl.org> Message-ID: <454F1DBD-0876-441D-A03C-1B5DF785584A@gmail.com> Hi Steve, I see. The 1.0.2 didn't work off-the-shelve but we found few fixes that made the engine working. Will it be acceptable to submit patches against the stable version? But I agree that the code was odd and probably our fixes will look odd as well. Thank you, Alex Sent from my iPhone > On Dec 19, 2015, at 12:49 PM, Dr. Stephen Henson wrote: > >> On Fri, Dec 18, 2015, Alexander Gostrer wrote: >> >> Hi Steve, >> >> John and I completed writing an ECDH engine based on the >> OpenSSL_1_0_2-stable branch. We were planning to expand it to the master >> but found some major changes made by you recently. What is the status of >> this task? Is it stable enough to follow it? Are you planning another >> changes? Is there a design document that we can use in our work? > > The version in master shouldn't change much any more. Documentation will be > available in the near future. The changes were meant to remove some of the > weird "quirks" of ECC compared to other algortihms and to permit future > expansion to a wider range of curves. > > In the meantime it shouldn't be too hard to follow how the new code works. > Instead of separate ECDH/ECDSA methods with weird locking and ex_data and > minimal ENGINE support everything is combined into a single EC_KEY_METHOD > which can contain ECDSA, ECDH and key generation (something which was > impossible with the old code) and be tied directly to an ENGINE. > > Most of the primary APIs such as ECDH_compute_key can be redirected directly > through an engine supplied function in EC_KEY_METHOD. > > Having said that the code is very new and may have the odd bug that needs to > be fixed. If you have any problems let me know and I'll look into them. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Mon Dec 21 11:07:25 2015 From: rt at openssl.org (Joey Yandle via RT) Date: Mon, 21 Dec 2015 11:07:25 +0000 Subject: [openssl-dev] [openssl.org #4189] PR #512: Clean up Windows RNG In-Reply-To: <56778878.20505@dancingdragon.be> References: <56778878.20505@dancingdragon.be> Message-ID: https://github.com/openssl/openssl/pull/512 This PR removes all of the dangerous Windows entropy gathering routines in favor of standard CryptGenRandom calls, as was discussed in the "Improving OpenSSL default RNG" thread on openssl-dev. This fixes common, repeatable crashes that happen when running openssl under the VS debugger. _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Dec 21 11:07:25 2015 From: rt at openssl.org (Felix via RT) Date: Mon, 21 Dec 2015 11:07:25 +0000 Subject: [openssl-dev] [openssl.org #4190] Missing Check for duplicate Prime-Value of p and q in openssl 0.9.8o In-Reply-To: <5677DBC1.6050805@gmx.de> References: <5677DBC1.6050805@gmx.de> Message-ID: Hello, I found out, that in openssl 0.9.8 a check is missing for duplicate primes of p and q, see below. This is relevant when generating RSA-Keys: root at debian6:/home/felix/Downloads/openssl-0.9.8o/apps# ./openssl genrsa 128 Generating RSA private key, 128 bit long modulus .......+++++++++++++++++++++++++++ .+++++++++++++++++++++++++++ e is 65537 (0x10001) p:DBF7DA8B44ADCDD1 Phase 1 q:DBF7DA8B44ADCDD1 -----BEGIN RSA PRIVATE KEY----- MGICAQACEQC+ePfpNx2CzoNDm/Aejm7HAgMBAAECEF/t7vYfUxaga1+R+6EPYiEC CQDdrD6E0hkhFwIJANv32otErc3RAgkAz2HVG21zFQECCEW9PRKugZQhAgg9HQ6/ Pr0Uvg== -----END RSA PRIVATE KEY----- root at debian6:/home/felix/Downloads/openssl-0.9.8o/apps# ./openssl genrsa 128 Generating RSA private key, 128 bit long modulus .+++++++++++++++++++++++++++ .+++++++++++++++++++++++++++ e is 65537 (0x10001) p:DC32B965793AF86F Phase 1 q:C6F919F7AAA5EC71 -----BEGIN RSA PRIVATE KEY----- MGUCAQACEQCrJX8Qy0q3bw5VN6G1mPz/AgMBAAECEQCbPCOI5BwdTE4K+TuIwOaB AgkA3DK5ZXk6+G8CCQDG+Rn3qqXscQIJAKbu/YZkRcSZAgkAnE+DS+K+uLECCQCu HHeujcFd/Q== -----END RSA PRIVATE KEY----- root at debian6:/home/felix/Downloads/openssl-0.9.8o/apps# ./openssl genrsa 128 Generating RSA private key, 128 bit long modulus .........+++++++++++++++++++++++++++ ...+++++++++++++++++++++++++++ e is 65537 (0x10001) p:EFAB9BC12A217257 Phase 1 q:C4B0A783D183DA55 -----BEGIN RSA PRIVATE KEY----- MGMCAQACEQC4JMYPVKDUPrZfVf8B/gzjAgMBAAECEQCd8r0IbVi+c84EAM4bn4jR AgkA76ubwSohclcCCQDEsKeD0YPaVQIIaHDg8+E3KAsCCELVeAZdof0FAgkAyqHj yqUIUes= -----END RSA PRIVATE KEY----- root at debian6:/home/felix/Downloads/openssl-0.9.8o/apps# ./openssl genrsa 128 Generating RSA private key, 128 bit long modulus ..+++++++++++++++++++++++++++ .+++++++++++++++++++++++++++ e is 65537 (0x10001) p:CA1A6069FBCE0E6B Phase 1 q:CA1A6069FBCE0E6B -----BEGIN RSA PRIVATE KEY----- MGUCAQACEQDIjp/x7uVVrCNdf9Y1SpStAgMBAAECEQCyNiIkPe7lN1KFh4ubrk8V AgkA/gq1dP5Y/0cCCQDKGmBp+84OawIJALlWjL4XFkzfAgkArBEa5wD4pXMCCQDW mLQFBXBWbw== -----END RSA PRIVATE KEY----- root at debian6:/home/felix/Downloads/openssl-0.9.8o/apps# ./openssl genrsa 128 Generating RSA private key, 128 bit long modulus ...+++++++++++++++++++++++++++ .+++++++++++++++++++++++++++ e is 65537 (0x10001) p:F4D74AA8BE84C4A3 Phase 1 q:D83D57FC191345D1 -----BEGIN RSA PRIVATE KEY----- MGICAQACEQDO0FJxcT23cfxgf5/WfXgTAgMBAAECECNo7cS4o92FmsN9eYgtFiEC CQD010qovoTEowIJANg9V/wZE0XRAghhDEkqk8HakwIJAKFKKD12qqRxAggvO+Uz yUnU6g== -----END RSA PRIVATE KEY----- root at debian6:/home/felix/Downloads/openssl-0.9.8o/apps# As, in my environment, p qnd q are identical in about 50% of the cases, this is in my opinion a big security hole, because p and q can be determined from N by calculating the square-root of N. I will try to test this with a newer release of openssl as well. Thank you. Regards, Felix _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Dec 21 11:52:29 2015 From: rt at openssl.org (Felix via RT) Date: Mon, 21 Dec 2015 11:52:29 +0000 Subject: [openssl-dev] [openssl.org #4191] Re: Missing Check for duplicate Prime-Value of p and q in openssl 0.9.8o In-Reply-To: <5677E774.9070103@gmx.de> References: <5677DBC1.6050805@gmx.de> <5677E774.9070103@gmx.de> Message-ID: P.S. Problem still exists in Version 0.9.8zh. Regards, Felix Am 21.12.2015 12:00, schrieb Felix: > Hello, > > I found out, that in openssl 0.9.8 a check is missing for duplicate > primes of p and q, see below. This is relevant when generating RSA-Keys: > > > root at debian6:/home/felix/Downloads/openssl-0.9.8o/apps# ./openssl > genrsa 128 > Generating RSA private key, 128 bit long modulus > .......+++++++++++++++++++++++++++ > .+++++++++++++++++++++++++++ > e is 65537 (0x10001) > p:DBF7DA8B44ADCDD1 Phase 1 q:DBF7DA8B44ADCDD1 -----BEGIN RSA PRIVATE > KEY----- > MGICAQACEQC+ePfpNx2CzoNDm/Aejm7HAgMBAAECEF/t7vYfUxaga1+R+6EPYiEC > CQDdrD6E0hkhFwIJANv32otErc3RAgkAz2HVG21zFQECCEW9PRKugZQhAgg9HQ6/ > Pr0Uvg== > -----END RSA PRIVATE KEY----- > root at debian6:/home/felix/Downloads/openssl-0.9.8o/apps# ./openssl > genrsa 128 > Generating RSA private key, 128 bit long modulus > .+++++++++++++++++++++++++++ > .+++++++++++++++++++++++++++ > e is 65537 (0x10001) > p:DC32B965793AF86F Phase 1 q:C6F919F7AAA5EC71 -----BEGIN RSA PRIVATE > KEY----- > MGUCAQACEQCrJX8Qy0q3bw5VN6G1mPz/AgMBAAECEQCbPCOI5BwdTE4K+TuIwOaB > AgkA3DK5ZXk6+G8CCQDG+Rn3qqXscQIJAKbu/YZkRcSZAgkAnE+DS+K+uLECCQCu > HHeujcFd/Q== > -----END RSA PRIVATE KEY----- > root at debian6:/home/felix/Downloads/openssl-0.9.8o/apps# ./openssl > genrsa 128 > Generating RSA private key, 128 bit long modulus > .........+++++++++++++++++++++++++++ > ...+++++++++++++++++++++++++++ > e is 65537 (0x10001) > p:EFAB9BC12A217257 Phase 1 q:C4B0A783D183DA55 -----BEGIN RSA PRIVATE > KEY----- > MGMCAQACEQC4JMYPVKDUPrZfVf8B/gzjAgMBAAECEQCd8r0IbVi+c84EAM4bn4jR > AgkA76ubwSohclcCCQDEsKeD0YPaVQIIaHDg8+E3KAsCCELVeAZdof0FAgkAyqHj > yqUIUes= > -----END RSA PRIVATE KEY----- > root at debian6:/home/felix/Downloads/openssl-0.9.8o/apps# ./openssl > genrsa 128 > Generating RSA private key, 128 bit long modulus > ..+++++++++++++++++++++++++++ > .+++++++++++++++++++++++++++ > e is 65537 (0x10001) > p:CA1A6069FBCE0E6B Phase 1 q:CA1A6069FBCE0E6B -----BEGIN RSA PRIVATE > KEY----- > MGUCAQACEQDIjp/x7uVVrCNdf9Y1SpStAgMBAAECEQCyNiIkPe7lN1KFh4ubrk8V > AgkA/gq1dP5Y/0cCCQDKGmBp+84OawIJALlWjL4XFkzfAgkArBEa5wD4pXMCCQDW > mLQFBXBWbw== > -----END RSA PRIVATE KEY----- > root at debian6:/home/felix/Downloads/openssl-0.9.8o/apps# ./openssl > genrsa 128 > Generating RSA private key, 128 bit long modulus > ...+++++++++++++++++++++++++++ > .+++++++++++++++++++++++++++ > e is 65537 (0x10001) > p:F4D74AA8BE84C4A3 Phase 1 q:D83D57FC191345D1 -----BEGIN RSA PRIVATE > KEY----- > MGICAQACEQDO0FJxcT23cfxgf5/WfXgTAgMBAAECECNo7cS4o92FmsN9eYgtFiEC > CQD010qovoTEowIJANg9V/wZE0XRAghhDEkqk8HakwIJAKFKKD12qqRxAggvO+Uz > yUnU6g== > -----END RSA PRIVATE KEY----- > root at debian6:/home/felix/Downloads/openssl-0.9.8o/apps# > > > As, in my environment, p qnd q are identical in about 50% of the > cases, this is in my opinion a big security hole, because p and q can > be determined from N by calculating the square-root of N. > > I will try to test this with a newer release of openssl as well. > > Thank you. > > Regards, > > Felix _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From a.yousar at informatik.hu-berlin.de Mon Dec 21 11:41:38 2015 From: a.yousar at informatik.hu-berlin.de (Ann) Date: Mon, 21 Dec 2015 12:41:38 +0100 Subject: [openssl-dev] [openssl.org #4190] Missing Check for duplicate Prime-Value of p and q in openssl 0.9.8o In-Reply-To: References: <5677DBC1.6050805@gmx.de> Message-ID: <5677E572.30403@informatik.hu-berlin.de> Felix, the real security hole is your key length. For a key length greater 1024 p and q should never be identical. The chance of p being not a prime is probably greater. In case p=q the Euler function will be p(p-1), whereas OpenSSL uses (p-1)(q-1) , i.e. (p-1)^2. In this case RSA, i.e. c:=m^e, m:=c^d, will not work. /Ann. From rt at openssl.org Mon Dec 21 12:26:32 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 21 Dec 2015 12:26:32 +0000 Subject: [openssl-dev] [openssl.org #3810] [PATCH] Improved P256 ECC performance by means of a dedicated function for modular inversion modulo the P256 group order In-Reply-To: <5677EFF5.9070608@openssl.org> References: <3DE91BD01FD68540858FC917201D9B9939BD3C4B@hasmsx107.ger.corp.intel.com> <5677EFF5.9070608@openssl.org> Message-ID: Hi, > This patch is a contribution to OpenSSL. > > It concerns the P256 ECC implementation. > > The patch improves upon our previous submission, by providing a dedicated function to perform modular inversion modulo the P256 group order. > > Results: > The performance improvements, for single threaded applications, compared to the current (development) version of OpenSSL are as follows. > > (measured by "openssl speed" utility) > > > On Architecture Codename Haswell: > ECDSA sign: 1.28X > ECDSA verify: 1.10X > > On Architecture Broadwell: > ECDSA sign: 1.42X > ECDSA verify: 1.18X > > We license the whole submission under BSD license. > > Developers and authors: > *************************************************************************** > Shay Gueron (1, 2), and Vlad Krasnov (3) > (1) University of Haifa, Israel > (2) Intel Corporation, Israel Development Center, Haifa, Israel > (3) CloudFlare, Inc. > *************************************************************************** Attached is version refactored for updated layout. It's few percent faster than original (for several small reasons, e.g. avoiding excessive %rip-relative addressing because it doesn't fuse, optimizing back-to-back value passing through registers in squaring) and probably more readable (for example squaring uses $acc6 and $acc7). Then I've got nervous around possibility of unaccounted carry and rearranged reduction step in manner that precludes it. To be more specific here is fragment of original reduction step: mov 8*1+.Lord(%rip), $t4 mul $t0 add $t1, $acc1 adc \$0, $t3 add $t4, $acc1 mov $t0, $t1 adc $t3, $acc2 adc \$0, $t1 sub $t0, $acc2 sbb \$0, $t1 Concern was that if $t0 happens to be all-ones, then you risk unaccounted carry in last adc above. Well, upon closer look concern appears to be false, but as it's a bit counter-intuitive alternative is provided anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: ecp_nistz256_inv_ord.diff Type: text/x-patch Size: 38647 bytes Desc: not available URL: From rt at openssl.org Mon Dec 21 13:46:33 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 21 Dec 2015 13:46:33 +0000 Subject: [openssl-dev] [openssl.org #4190] Missing Check for duplicate Prime-Value of p and q in openssl 0.9.8o In-Reply-To: <5677DBC1.6050805@gmx.de> References: <5677DBC1.6050805@gmx.de> Message-ID: As Ann points out, 128 bits is way too small, and this ticket does not justify a new release for 0.9.8 Please update 0.9.8 is end of life. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Dec 21 13:51:45 2015 From: rt at openssl.org (Felix via RT) Date: Mon, 21 Dec 2015 13:51:45 +0000 Subject: [openssl-dev] [openssl.org #4190] Missing Check for duplicate Prime-Value of p and q in openssl 0.9.8o In-Reply-To: <56780411.5040502@gmx.de> References: <5677DBC1.6050805@gmx.de> <56780411.5040502@gmx.de> Message-ID: That does not matter from a technical point of view. The Problem ist the same with 2048-Bit RSA. It?s a general problem of the program-mechanism that could be changed very easily. Openssl 1.0.X ist still too buggy for me... BTW: The mechanisms in 1.10 ist still the same.... Still no duplicate-check in source-code.... Regards, Felix Am 21.12.2015 14:46, schrieb Rich Salz via RT: > As Ann points out, 128 bits is way too small, and this ticket does not justify > a new release for 0.9.8 > Please update 0.9.8 is end of life. > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org > > From rt at openssl.org Mon Dec 21 14:08:24 2015 From: rt at openssl.org (Daniel Kahn Gillmor via RT) Date: Mon, 21 Dec 2015 14:08:24 +0000 Subject: [openssl-dev] [openssl.org #4192] [PATCH] differentiate SSL_* from from SSL_CTX_* in documentation In-Reply-To: <1450644911-16118-1-git-send-email-dkg@fifthhorseman.net> References: <1450644911-16118-1-git-send-email-dkg@fifthhorseman.net> Message-ID: A couple places in the OpenSSL documentation claims that SSL_foo() takes an SSL_CTX* instead of an SSL*. i've corrected those here. --- doc/ssl/SSL_CTX_set1_verify_cert_store.pod | 8 ++++---- doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/ssl/SSL_CTX_set1_verify_cert_store.pod b/doc/ssl/SSL_CTX_set1_verify_cert_store.pod index af09f88..fbdd314 100644 --- a/doc/ssl/SSL_CTX_set1_verify_cert_store.pod +++ b/doc/ssl/SSL_CTX_set1_verify_cert_store.pod @@ -17,10 +17,10 @@ verification or chain store int SSL_CTX_set0_chain_cert_store(SSL_CTX *ctx, X509_STORE *st); int SSL_CTX_set1_chain_cert_store(SSL_CTX *ctx, X509_STORE *st); - int SSL_set0_verify_cert_store(SSL_CTX *ctx, X509_STORE *st); - int SSL_set1_verify_cert_store(SSL_CTX *ctx, X509_STORE *st); - int SSL_set0_chain_cert_store(SSL_CTX *ctx, X509_STORE *st); - int SSL_set1_chain_cert_store(SSL_CTX *ctx, X509_STORE *st); + int SSL_set0_verify_cert_store(SSL *ssl, X509_STORE *st); + int SSL_set1_verify_cert_store(SSL *ssl, X509_STORE *st); + int SSL_set0_chain_cert_store(SSL *ssl, X509_STORE *st); + int SSL_set1_chain_cert_store(SSL *ssl, X509_STORE *st); =head1 DESCRIPTION diff --git a/doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod b/doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod index 296699d..ea2ce5f 100644 --- a/doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod +++ b/doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod @@ -13,7 +13,7 @@ SSL_CTX_set_tmp_rsa_callback, SSL_CTX_set_tmp_rsa, SSL_CTX_need_tmp_rsa, SSL_set long SSL_CTX_set_tmp_rsa(SSL_CTX *ctx, RSA *rsa); long SSL_CTX_need_tmp_rsa(SSL_CTX *ctx); - void SSL_set_tmp_rsa_callback(SSL_CTX *ctx, + void SSL_set_tmp_rsa_callback(SSL *ssl, RSA *(*tmp_rsa_callback)(SSL *ssl, int is_export, int keylength)); long SSL_set_tmp_rsa(SSL *ssl, RSA *rsa) long SSL_need_tmp_rsa(SSL *ssl) -- 2.6.4 _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From zoli at polarhome.com Mon Dec 21 19:36:13 2015 From: zoli at polarhome.com (Zoltan Arpadffy) Date: Mon, 21 Dec 2015 20:36:13 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published In-Reply-To: <20151210150150.GA30915@openssl.org> References: <20151210150150.GA30915@openssl.org> Message-ID: <001001d13c26$da55e0a0$8f01a1e0$@com> Hi, I am sorry, but because of the relocation of the header files the 1.1.0 does not build on OpenVMS. Please, allow some time to fix the OpenVMS build scripts. Thank you. Regards, Z -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of OpenSSL Sent: den 10 december 2015 16:02 To: OpenSSL Developer ML; OpenSSL User Support ML; OpenSSL Announce ML Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.1.0 pre release 1 (alpha) =========================================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 1 has now been made available. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.1.0-notes.html Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. The alpha release is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0-pre1.tar.gz Size: 4990889 SHA1 checksum: a058b999e17e0c40988bd7b9b280c9876f62684e SHA256 checksum: 79da49c38464a19d1b328c2f4a3661849bd2eb3d54a37fdb6a56d9b8a18e87bd The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0-pre1.tar.gz openssl sha256 openssl-1.1.0-pre1.tar.gz Please download and check this alpha release as soon as possible. Bug reports should go to rt at openssl.org. Please check the release notes and mailing lists to avoid duplicate reports of known issues. Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWaYrRAAoJENnE0m0OYESRh5gIAJ8WrkPPV8CW2xWmtyIjAxpz 7FvvpxBWHaBgJcCrvNomh2JJupXa+enWCTsskIyH0+FtS85VeOKNvQg68xbCOvLl I0dWxMNb8SCxuagvEje8xGEnf8by8pZdYaK8ERASlNoGVIgN8CwppiKnY8c1yRYn Ti0dUZLyVZvT5Qm2Q3k4pOvfS/+rvFjHiuUllFzfHlp6mdk4573w5eneoTINQvRK OC8iAnSiINQWQvuiavLVIgw7VFBD1WC2iKWuSA3+31YuM8CUpvbbnJHh2QUfGkIw oNTkflxgQJhk/txwqvCSzZsVddhvQLZtiRZYQcG4WUuskygCENeieJGPOXN6ioI= =LY4X -----END PGP SIGNATURE----- _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Mon Dec 21 20:38:15 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Mon, 21 Dec 2015 20:38:15 +0000 Subject: [openssl-dev] [openssl.org #4190] Missing Check for duplicate Prime-Value of p and q in openssl 0.9.8o In-Reply-To: <20151221203817.GA9747@roeckx.be> References: <5677DBC1.6050805@gmx.de> <56780411.5040502@gmx.de> <20151221203817.GA9747@roeckx.be> Message-ID: On Mon, Dec 21, 2015 at 01:51:45PM +0000, Felix via RT wrote: > That does not matter from a technical point of view. > > The Problem ist the same with 2048-Bit RSA. If you're worried that p and q might be the same random number, I think you should have other concerns. Kurt From levitte at openssl.org Mon Dec 21 20:50:55 2015 From: levitte at openssl.org (Richard Levitte) Date: Mon, 21 Dec 2015 21:50:55 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published In-Reply-To: <001001d13c26$da55e0a0$8f01a1e0$@com> References: <20151210150150.GA30915@openssl.org> <001001d13c26$da55e0a0$8f01a1e0$@com> Message-ID: <1DB21B8B-DD44-43FA-97E6-01EF1E6F7F45@openssl.org> The building scripts are not at all updated, it's beyond repair. I'm (slowly) working on a new solution that doesn't require the separate update hell... Cheers Richard Zoltan Arpadffy skrev: (21 december 2015 20:36:13 CET) >Hi, > >I am sorry, but because of the relocation of the header files the 1.1.0 >does >not build on OpenVMS. >Please, allow some time to fix the OpenVMS build scripts. > >Thank you. >Regards, >Z > >-----Original Message----- >From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of >OpenSSL >Sent: den 10 december 2015 16:02 >To: OpenSSL Developer ML; OpenSSL User Support ML; OpenSSL Announce ML >Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > OpenSSL version 1.1.0 pre release 1 (alpha) > =========================================== > > OpenSSL - The Open Source toolkit for SSL/TLS > http://www.openssl.org/ > >OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 1 has >now > been made available. For details of changes and known issues see the > release notes at: > > http://www.openssl.org/news/openssl-1.1.0-notes.html > > Note: This OpenSSL pre-release has been provided for testing ONLY. > It should NOT be used for security critical purposes. > > The alpha release is available for download via HTTP and FTP from the > following master locations (you can find the various FTP mirrors under > http://www.openssl.org/source/mirror.html): > > * http://www.openssl.org/source/ > * ftp://ftp.openssl.org/source/ > > The distribution file name is: > > o openssl-1.1.0-pre1.tar.gz > Size: 4990889 > SHA1 checksum: a058b999e17e0c40988bd7b9b280c9876f62684e > SHA256 checksum: >79da49c38464a19d1b328c2f4a3661849bd2eb3d54a37fdb6a56d9b8a18e87bd > > The checksums were calculated using the following commands: > > openssl sha1 openssl-1.1.0-pre1.tar.gz > openssl sha256 openssl-1.1.0-pre1.tar.gz > > Please download and check this alpha release as soon as possible. Bug >reports > should go to rt at openssl.org. Please check the release notes > and mailing lists to avoid duplicate reports of known issues. > > Yours, > > The OpenSSL Project Team. > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1 > >iQEcBAEBAgAGBQJWaYrRAAoJENnE0m0OYESRh5gIAJ8WrkPPV8CW2xWmtyIjAxpz >7FvvpxBWHaBgJcCrvNomh2JJupXa+enWCTsskIyH0+FtS85VeOKNvQg68xbCOvLl >I0dWxMNb8SCxuagvEje8xGEnf8by8pZdYaK8ERASlNoGVIgN8CwppiKnY8c1yRYn >Ti0dUZLyVZvT5Qm2Q3k4pOvfS/+rvFjHiuUllFzfHlp6mdk4573w5eneoTINQvRK >OC8iAnSiINQWQvuiavLVIgw7VFBD1WC2iKWuSA3+31YuM8CUpvbbnJHh2QUfGkIw >oNTkflxgQJhk/txwqvCSzZsVddhvQLZtiRZYQcG4WUuskygCENeieJGPOXN6ioI= >=LY4X >-----END PGP SIGNATURE----- >_______________________________________________ >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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From rt at openssl.org Mon Dec 21 21:36:11 2015 From: rt at openssl.org (Felix via RT) Date: Mon, 21 Dec 2015 21:36:11 +0000 Subject: [openssl-dev] [openssl.org #4190] Missing Check for duplicate Prime-Value of p and q in openssl 0.9.8o In-Reply-To: <56787113.7000602@gmx.de> References: <5677DBC1.6050805@gmx.de> <56780411.5040502@gmx.de> <20151221203817.GA9747@roeckx.be> <56787113.7000602@gmx.de> Message-ID: Hello, I found the reason for the problem, it?s definately a program error: The reason for it is in sub-program rsa_gen.c if (BN_cmp(rsa->p, rsa->q) < 0) { printf("Doppelt!") ; tmp = rsa->p; rsa->p = rsa->q; rsa->q = tmp; } Here p and q should be switched if p > q. But this does not work, probably due to type-incompatible Variable "tmp". So rsa->p gets the value of rsa->q but not vice versa: root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl genrsa 128 Generating RSA private key, 128 bit long modulus ..+++++++++++++++++++++++++++ ...+++++++++++++++++++++++++++ e is 65537 (0x10001) p:C2F7ECB8D2F59273 Doppelt!q:C2F7ECB8D2F59273-----BEGIN RSA PRIVATE KEY----- MGECAQACEQCxt/Mo0epqolFmAH7AinLnAgMBAAECECOQd0W09F9QNJjnYUzTA2kC CQDpWa3+afRcvQIJAML37LjS9ZJzAggdBqK1+sgCoQIICN5IGTwXSXsCCEaUjQ+2 1lSi -----END RSA PRIVATE KEY----- root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl genrsa 128 Generating RSA private key, 128 bit long modulus ...+++++++++++++++++++++++++++ ..+++++++++++++++++++++++++++ e is 65537 (0x10001) p:EA361C8BFA9BA779 q:D5E2C6BB9B8BA893-----BEGIN RSA PRIVATE KEY----- MGQCAQACEQDDrn9XKQBmujmYfSQ++5J7AgMBAAECEQCKoOvL9ts26ogA0yMVZFKx AgkA6jYci/qbp3kCCQDV4sa7m4uokwIJAI6c+HD73n/xAggx7tN+kP21yQIJANCs iuyMFDkp -----END RSA PRIVATE KEY----- root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl genrsa 128 Generating RSA private key, 128 bit long modulus .+++++++++++++++++++++++++++ .+++++++++++++++++++++++++++ e is 65537 (0x10001) p:C3412FF6A7505B29 Doppelt!q:C3412FF6A7505B29-----BEGIN RSA PRIVATE KEY----- MGMCAQACEQCyfg3MCsahBogjE8RM+6yPAgMBAAECEEO3HMbfA7IMpHc7MT6WJZEC CQDqBdvZfYT49wIJAMNBL/anUFspAgkAo33OVsZLFIcCCHPy1A6/EOLxAgkAj5Jg TT5Qxxw= -----END RSA PRIVATE KEY----- root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl genrsa 128 Generating RSA private key, 128 bit long modulus .+++++++++++++++++++++++++++ .+++++++++++++++++++++++++++ e is 65537 (0x10001) p:C90F0AF5C806456F Doppelt!q:C90F0AF5C806456F-----BEGIN RSA PRIVATE KEY----- MGMCAQACEQC5Blnuh/rwj672TEtpnqBbAgMBAAECEHWgVAwQ5reHi1vT7Mv8AgEC CQDrlal9i7dV1QIJAMkPCvXIBkVvAgkAlW1jiUdyrVUCCF/WSswjP1IDAgkA6DRY CoYAsOE= -----END RSA PRIVATE KEY----- root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl genrsa 128 Generating RSA private key, 128 bit long modulus ...+++++++++++++++++++++++++++ ..+++++++++++++++++++++++++++ e is 65537 (0x10001) p:DFE0EAAEF64A9ED3 q:DA49968E614FC9E9-----BEGIN RSA PRIVATE KEY----- MGECAQACEQC+5eKmNv53y2Hn+t22uzkLAgMBAAECEHmAtlbW7/ZsapBlxpZlu1EC CQDf4Oqu9kqe0wIJANpJlo5hT8npAggWUvAz6B1CvwIIYCU9fST7gdECCGudR6xt O4sU -----END RSA PRIVATE KEY---- The code is still the same, even in Pre-Version 1.1.0 Regards, Felix Am 21.12.2015 21:38, schrieb Kurt Roeckx via RT: > On Mon, Dec 21, 2015 at 01:51:45PM +0000, Felix via RT wrote: >> That does not matter from a technical point of view. >> >> The Problem ist the same with 2048-Bit RSA. > If you're worried that p and q might be the same random number, I > think you should have other concerns. > > > Kurt > > > From uri at ll.mit.edu Mon Dec 21 22:15:45 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 21 Dec 2015 22:15:45 +0000 Subject: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token? In-Reply-To: <1450517008.4267.100.camel@infradead.org> References: <20151210.093931.1997199079828500981.levitte@openssl.org> <20151210173244.GA938@openssl.org> <20151210215657.GA7104@openssl.org> <1450453608.20562.35.camel@redhat.com> <1450517008.4267.100.camel@infradead.org> Message-ID: >>> $ openssl dgst -engine pkcs11 -keyform engine -verify >> > "pkcs11:object=SIGN%20pubkey;object-type=public" -sha256 -sigopt >> >> The current implementation of engine_pkcs11 seems to work with private >> keys and certificates only. I've added a fix in engine_pkcs11, but it >> seems that public key types were never tested for PKCS#11 URLs. > >Yes, mea culpa. I added the basic PKCS#11 URI parsing, and failed to >test it with public keys. Could you please point me at the code that needs fixing? I?m trying to accomplish two goals: - make all (most of?) the openssl commands work with ?pkcs11:?? URL; - make openssl (through engine_pkcs11) to stop prompting for the PIN to access public keys. >I still suspect we should be using p11kit and not reimplementing the >PKCS#11 URI parsing for ourselves. But really I want the whole engine >to die and PKCS#11 to be supported as a first-class citizen within >OpenSSL in crypto/p11/... In the ideal world - yes. As it is though, I think we'd better get engine_pkcs11 fixed. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From openssl-users at dukhovni.org Mon Dec 21 22:24:04 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 21 Dec 2015 22:24:04 +0000 Subject: [openssl-dev] [openssl.org #4190] Missing Check for duplicate Prime-Value of p and q in openssl 0.9.8o In-Reply-To: References: <5677DBC1.6050805@gmx.de> <56780411.5040502@gmx.de> <20151221203817.GA9747@roeckx.be> <56787113.7000602@gmx.de> Message-ID: <20151221222404.GC18704@mournblade.imrryr.org> On Mon, Dec 21, 2015 at 09:36:11PM +0000, Felix via RT wrote: > I found the reason for the problem, it?s definately a program error: Pilot error. > The reason for it is in sub-program rsa_gen.c > > if (BN_cmp(rsa->p, rsa->q) < 0) { > tmp = rsa->p; > rsa->p = rsa->q; > rsa->q = tmp; > } The code is just fine. > # ./openssl genrsa 128 > ..+++++++++++++++++++++++++++ > ...+++++++++++++++++++++++++++ > e is 65537 (0x10001) > p:C2F7ECB8D2F59273 Doppelt!q:C2F7ECB8D2F59273 No idea what's printing the output above, but the private key below: > -----BEGIN RSA PRIVATE KEY----- > MGECAQACEQCxt/Mo0epqolFmAH7AinLnAgMBAAECECOQd0W09F9QNJjnYUzTA2kC > CQDpWa3+afRcvQIJAML37LjS9ZJzAggdBqK1+sgCoQIICN5IGTwXSXsCCEaUjQ+2 > 1lSi > -----END RSA PRIVATE KEY----- in fact has distinct p/q: $ openssl rsa -noout -text <<-EOF -----BEGIN RSA PRIVATE KEY----- MGECAQACEQCxt/Mo0epqolFmAH7AinLnAgMBAAECECOQd0W09F9QNJjnYUzTA2kC CQDpWa3+afRcvQIJAML37LjS9ZJzAggdBqK1+sgCoQIICN5IGTwXSXsCCEaUjQ+2 1lSi -----END RSA PRIVATE KEY----- EOF Private-Key: (128 bit) modulus: 00:b1:b7:f3:28:d1:ea:6a:a2:51:66:00:7e:c0:8a: 72:e7 publicExponent: 65537 (0x10001) privateExponent: 23:90:77:45:b4:f4:5f:50:34:98:e7:61:4c:d3:03: 69 prime1: 16814661991975378109 (0xe959adfe69f45cbd) prime2: 14048957841162998387 (0xc2f7ecb8d2f59273) exponent1: 2091537979440366241 (0x1d06a2b5fac802a1) exponent2: 639027470352730491 (0x8de48193c17497b) coefficient: 5085844977839658146 (0x46948d0fb6d654a2) and prime1 > prime2. This ticket should be closed. -- Viktor. From rt at openssl.org Mon Dec 21 22:42:34 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 21 Dec 2015 22:42:34 +0000 Subject: [openssl-dev] [openssl.org #4190] Missing Check for duplicate Prime-Value of p and q in openssl 0.9.8o In-Reply-To: References: <5677DBC1.6050805@gmx.de> <56780411.5040502@gmx.de> <20151221203817.GA9747@roeckx.be> <56787113.7000602@gmx.de> Message-ID: You're not showing us how you output rsa->p and rsa->q. It doesn't make sense at all that you get "Doppelt!" if they were equal, so there's something wrong with your output. Also, it's been demonstrated (see mail by Viktor on openssl-dev) that the resulting key does have different p and q, with p > q. For all intents and purposes, this seems not to be a bug. Closing this ticket. Cheers, Richard Vid Mon, 21 Dec 2015 kl. 21.36.10, skrev felix.wiedenroth at gmx.de: > Hello, > > I found the reason for the problem, it?s definately a program error: > > The reason for it is in sub-program rsa_gen.c > > if (BN_cmp(rsa->p, rsa->q) < 0) { > printf("Doppelt!") ; > tmp = rsa->p; > rsa->p = rsa->q; > rsa->q = tmp; > } > > Here p and q should be switched if p > q. But this does not work, > probably due to type-incompatible Variable "tmp". > > So rsa->p gets the value of rsa->q but not vice versa: > > root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl > genrsa 128 > Generating RSA private key, 128 bit long modulus > ..+++++++++++++++++++++++++++ > ...+++++++++++++++++++++++++++ > e is 65537 (0x10001) > p:C2F7ECB8D2F59273 Doppelt!q:C2F7ECB8D2F59273-----BEGIN RSA PRIVATE > KEY----- > MGECAQACEQCxt/Mo0epqolFmAH7AinLnAgMBAAECECOQd0W09F9QNJjnYUzTA2kC > CQDpWa3+afRcvQIJAML37LjS9ZJzAggdBqK1+sgCoQIICN5IGTwXSXsCCEaUjQ+2 > 1lSi > -----END RSA PRIVATE KEY----- > root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl > genrsa 128 > Generating RSA private key, 128 bit long modulus > ...+++++++++++++++++++++++++++ > ..+++++++++++++++++++++++++++ > e is 65537 (0x10001) > p:EA361C8BFA9BA779 q:D5E2C6BB9B8BA893-----BEGIN RSA PRIVATE KEY----- > MGQCAQACEQDDrn9XKQBmujmYfSQ++5J7AgMBAAECEQCKoOvL9ts26ogA0yMVZFKx > AgkA6jYci/qbp3kCCQDV4sa7m4uokwIJAI6c+HD73n/xAggx7tN+kP21yQIJANCs > iuyMFDkp > -----END RSA PRIVATE KEY----- > root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl > genrsa 128 > Generating RSA private key, 128 bit long modulus > .+++++++++++++++++++++++++++ > .+++++++++++++++++++++++++++ > e is 65537 (0x10001) > p:C3412FF6A7505B29 Doppelt!q:C3412FF6A7505B29-----BEGIN RSA PRIVATE > KEY----- > MGMCAQACEQCyfg3MCsahBogjE8RM+6yPAgMBAAECEEO3HMbfA7IMpHc7MT6WJZEC > CQDqBdvZfYT49wIJAMNBL/anUFspAgkAo33OVsZLFIcCCHPy1A6/EOLxAgkAj5Jg > TT5Qxxw= > -----END RSA PRIVATE KEY----- > root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl > genrsa 128 > Generating RSA private key, 128 bit long modulus > .+++++++++++++++++++++++++++ > .+++++++++++++++++++++++++++ > e is 65537 (0x10001) > p:C90F0AF5C806456F Doppelt!q:C90F0AF5C806456F-----BEGIN RSA PRIVATE > KEY----- > MGMCAQACEQC5Blnuh/rwj672TEtpnqBbAgMBAAECEHWgVAwQ5reHi1vT7Mv8AgEC > CQDrlal9i7dV1QIJAMkPCvXIBkVvAgkAlW1jiUdyrVUCCF/WSswjP1IDAgkA6DRY > CoYAsOE= > -----END RSA PRIVATE KEY----- > root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl > genrsa 128 > Generating RSA private key, 128 bit long modulus > ...+++++++++++++++++++++++++++ > ..+++++++++++++++++++++++++++ > e is 65537 (0x10001) > p:DFE0EAAEF64A9ED3 q:DA49968E614FC9E9-----BEGIN RSA PRIVATE KEY----- > MGECAQACEQC+5eKmNv53y2Hn+t22uzkLAgMBAAECEHmAtlbW7/ZsapBlxpZlu1EC > CQDf4Oqu9kqe0wIJANpJlo5hT8npAggWUvAz6B1CvwIIYCU9fST7gdECCGudR6xt > O4sU > -----END RSA PRIVATE KEY---- > > The code is still the same, even in Pre-Version 1.1.0 > > Regards, > > Felix > > > Am 21.12.2015 21:38, schrieb Kurt Roeckx via RT: > > On Mon, Dec 21, 2015 at 01:51:45PM +0000, Felix via RT wrote: > >> That does not matter from a technical point of view. > >> > >> The Problem ist the same with 2048-Bit RSA. > > If you're worried that p and q might be the same random number, I > > think you should have other concerns. > > > > > > Kurt > > > > > > > -- Richard Levitte levitte at openssl.org From rt at openssl.org Mon Dec 21 23:00:39 2015 From: rt at openssl.org (Felix via RT) Date: Mon, 21 Dec 2015 23:00:39 +0000 Subject: [openssl-dev] [openssl.org #4190] Missing Check for duplicate Prime-Value of p and q in openssl 0.9.8o In-Reply-To: <5678839F.1050907@gmx.de> References: <5677DBC1.6050805@gmx.de> <56780411.5040502@gmx.de> <20151221203817.GA9747@roeckx.be> <56787113.7000602@gmx.de> <5678839F.1050907@gmx.de> Message-ID: Hello, I "pickup" rsa-p and rsa-q just one source-code-line after they were "filled" and output the variables using the BN_print_fp function. please reopen the ticket. Regards, Felix for (;;) { if (!BN_generate_prime_ex(rsa->p, bitsp, 0, NULL, NULL, cb)) goto err; printf(" p:"); BN_print_fp(stdout,rsa->p); printf(" "); if (!BN_sub(r2, rsa->p, BN_value_one())) goto err; if (!BN_gcd(r1, r2, rsa->e, ctx)) goto err; if (BN_is_one(r1)) break; if (!BN_GENCB_call(cb, 2, n++)) goto err; } if (!BN_GENCB_call(cb, 3, 0)) goto err; for (;;) { /* * When generating ridiculously small keys, we can get stuck * continually regenerating the same prime values. Check for this and * bail if it happens 3 times. */ unsigned int degenerate = 0; do { if (!BN_generate_prime_ex(rsa->q, bitsq, 0, NULL, NULL, cb)) goto err; } while ((BN_cmp(rsa->p, rsa->q) == 0) && (++degenerate < 10)); if (degenerate == 10) { ok = 0; /* we set our own err */ RSAerr(RSA_F_RSA_BUILTIN_KEYGEN, RSA_R_KEY_SIZE_TOO_SMALL); goto err; } if (!BN_sub(r2, rsa->q, BN_value_one())) goto err; if (!BN_gcd(r1, r2, rsa->e, ctx)) goto err; if (BN_is_one(r1)) break; if (!BN_GENCB_call(cb, 2, n++)) goto err; } if (!BN_GENCB_call(cb, 3, 1)) goto err; if (BN_cmp(rsa->p, rsa->q) < 0) { printf("Doppelt!") ; tmp = rsa->p; rsa->p = rsa->q; rsa->q = tmp; } printf("q:"); BN_print_fp(stdout,rsa->q); Am 21.12.2015 23:42, schrieb Richard Levitte via RT: > You're not showing us how you output rsa->p and rsa->q. It doesn't make sense > at all that you get "Doppelt!" if they were equal, so there's something wrong > with your output. Also, it's been demonstrated (see mail by Viktor on > openssl-dev) that the resulting key does have different p and q, with p > q. > > For all intents and purposes, this seems not to be a bug. Closing this ticket. > > Cheers, > Richard > > Vid Mon, 21 Dec 2015 kl. 21.36.10, skrev felix.wiedenroth at gmx.de: >> Hello, >> >> I found the reason for the problem, it?s definately a program error: >> >> The reason for it is in sub-program rsa_gen.c >> >> if (BN_cmp(rsa->p, rsa->q) < 0) { >> printf("Doppelt!") ; >> tmp = rsa->p; >> rsa->p = rsa->q; >> rsa->q = tmp; >> } >> >> Here p and q should be switched if p > q. But this does not work, >> probably due to type-incompatible Variable "tmp". >> >> So rsa->p gets the value of rsa->q but not vice versa: >> >> root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl >> genrsa 128 >> Generating RSA private key, 128 bit long modulus >> ..+++++++++++++++++++++++++++ >> ...+++++++++++++++++++++++++++ >> e is 65537 (0x10001) >> p:C2F7ECB8D2F59273 Doppelt!q:C2F7ECB8D2F59273-----BEGIN RSA PRIVATE >> KEY----- >> MGECAQACEQCxt/Mo0epqolFmAH7AinLnAgMBAAECECOQd0W09F9QNJjnYUzTA2kC >> CQDpWa3+afRcvQIJAML37LjS9ZJzAggdBqK1+sgCoQIICN5IGTwXSXsCCEaUjQ+2 >> 1lSi >> -----END RSA PRIVATE KEY----- >> root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl >> genrsa 128 >> Generating RSA private key, 128 bit long modulus >> ...+++++++++++++++++++++++++++ >> ..+++++++++++++++++++++++++++ >> e is 65537 (0x10001) >> p:EA361C8BFA9BA779 q:D5E2C6BB9B8BA893-----BEGIN RSA PRIVATE KEY----- >> MGQCAQACEQDDrn9XKQBmujmYfSQ++5J7AgMBAAECEQCKoOvL9ts26ogA0yMVZFKx >> AgkA6jYci/qbp3kCCQDV4sa7m4uokwIJAI6c+HD73n/xAggx7tN+kP21yQIJANCs >> iuyMFDkp >> -----END RSA PRIVATE KEY----- >> root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl >> genrsa 128 >> Generating RSA private key, 128 bit long modulus >> .+++++++++++++++++++++++++++ >> .+++++++++++++++++++++++++++ >> e is 65537 (0x10001) >> p:C3412FF6A7505B29 Doppelt!q:C3412FF6A7505B29-----BEGIN RSA PRIVATE >> KEY----- >> MGMCAQACEQCyfg3MCsahBogjE8RM+6yPAgMBAAECEEO3HMbfA7IMpHc7MT6WJZEC >> CQDqBdvZfYT49wIJAMNBL/anUFspAgkAo33OVsZLFIcCCHPy1A6/EOLxAgkAj5Jg >> TT5Qxxw= >> -----END RSA PRIVATE KEY----- >> root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl >> genrsa 128 >> Generating RSA private key, 128 bit long modulus >> .+++++++++++++++++++++++++++ >> .+++++++++++++++++++++++++++ >> e is 65537 (0x10001) >> p:C90F0AF5C806456F Doppelt!q:C90F0AF5C806456F-----BEGIN RSA PRIVATE >> KEY----- >> MGMCAQACEQC5Blnuh/rwj672TEtpnqBbAgMBAAECEHWgVAwQ5reHi1vT7Mv8AgEC >> CQDrlal9i7dV1QIJAMkPCvXIBkVvAgkAlW1jiUdyrVUCCF/WSswjP1IDAgkA6DRY >> CoYAsOE= >> -----END RSA PRIVATE KEY----- >> root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl >> genrsa 128 >> Generating RSA private key, 128 bit long modulus >> ...+++++++++++++++++++++++++++ >> ..+++++++++++++++++++++++++++ >> e is 65537 (0x10001) >> p:DFE0EAAEF64A9ED3 q:DA49968E614FC9E9-----BEGIN RSA PRIVATE KEY----- >> MGECAQACEQC+5eKmNv53y2Hn+t22uzkLAgMBAAECEHmAtlbW7/ZsapBlxpZlu1EC >> CQDf4Oqu9kqe0wIJANpJlo5hT8npAggWUvAz6B1CvwIIYCU9fST7gdECCGudR6xt >> O4sU >> -----END RSA PRIVATE KEY---- >> >> The code is still the same, even in Pre-Version 1.1.0 >> >> Regards, >> >> Felix >> >> >> Am 21.12.2015 21:38, schrieb Kurt Roeckx via RT: >>> On Mon, Dec 21, 2015 at 01:51:45PM +0000, Felix via RT wrote: >>>> That does not matter from a technical point of view. >>>> >>>> The Problem ist the same with 2048-Bit RSA. >>> If you're worried that p and q might be the same random number, I >>> think you should have other concerns. >>> >>> >>> Kurt >>> >>> >>> > > -- > Richard Levitte > levitte at openssl.org > > From rt at openssl.org Mon Dec 21 23:09:48 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 21 Dec 2015 23:09:48 +0000 Subject: [openssl-dev] [openssl.org #4190] Missing Check for duplicate Prime-Value of p and q in openssl 0.9.8o In-Reply-To: References: <20151221203817.GA9747@roeckx.be> Message-ID: You're displaying pre-swap p and post-swap q. If they do get swapped, you must understand that pre-swap p and post-swap q will be the same value. If you really want to demonstrate something, please display *both* p and q before swap, and *both* p and q after swap. Vid Mon, 21 Dec 2015 kl. 23.00.38, skrev felix.wiedenroth at gmx.de: > Hello, > > I "pickup" rsa-p and rsa-q just one source-code-line after they were > "filled" and output the variables using the BN_print_fp function. > > please reopen the ticket. > > Regards, > > Felix > > > for (;;) { > if (!BN_generate_prime_ex(rsa->p, bitsp, 0, NULL, NULL, cb)) > goto err; > printf(" p:"); > BN_print_fp(stdout,rsa->p); > printf(" "); > > if (!BN_sub(r2, rsa->p, BN_value_one())) > goto err; > if (!BN_gcd(r1, r2, rsa->e, ctx)) > goto err; > if (BN_is_one(r1)) > break; > if (!BN_GENCB_call(cb, 2, n++)) > goto err; > } > if (!BN_GENCB_call(cb, 3, 0)) > goto err; > for (;;) { > /* > * When generating ridiculously small keys, we can get stuck > * continually regenerating the same prime values. Check for > this and > * bail if it happens 3 times. > */ > unsigned int degenerate = 0; > do { > if (!BN_generate_prime_ex(rsa->q, bitsq, 0, NULL, NULL, cb)) > goto err; > } > while ((BN_cmp(rsa->p, rsa->q) == 0) && (++degenerate < 10)); > if (degenerate == 10) { > ok = 0; /* we set our own err */ > RSAerr(RSA_F_RSA_BUILTIN_KEYGEN, RSA_R_KEY_SIZE_TOO_SMALL); > goto err; > } > if (!BN_sub(r2, rsa->q, BN_value_one())) > goto err; > if (!BN_gcd(r1, r2, rsa->e, ctx)) > goto err; > if (BN_is_one(r1)) > break; > if (!BN_GENCB_call(cb, 2, n++)) > goto err; > } > if (!BN_GENCB_call(cb, 3, 1)) > goto err; > if (BN_cmp(rsa->p, rsa->q) < 0) { > printf("Doppelt!") ; > tmp = rsa->p; > rsa->p = rsa->q; > rsa->q = tmp; > } > printf("q:"); > BN_print_fp(stdout,rsa->q); > > > > > Am 21.12.2015 23:42, schrieb Richard Levitte via RT: > > You're not showing us how you output rsa->p and rsa->q. It doesn't > > make sense > > at all that you get "Doppelt!" if they were equal, so there's > > something wrong > > with your output. Also, it's been demonstrated (see mail by Viktor on > > openssl-dev) that the resulting key does have different p and q, with > > p > q. > > > > For all intents and purposes, this seems not to be a bug. Closing > > this ticket. > > > > Cheers, > > Richard > > > > Vid Mon, 21 Dec 2015 kl. 21.36.10, skrev felix.wiedenroth at gmx.de: > >> Hello, > >> > >> I found the reason for the problem, it?s definately a program error: > >> > >> The reason for it is in sub-program rsa_gen.c > >> > >> if (BN_cmp(rsa->p, rsa->q) < 0) { > >> printf("Doppelt!") ; > >> tmp = rsa->p; > >> rsa->p = rsa->q; > >> rsa->q = tmp; > >> } > >> > >> Here p and q should be switched if p > q. But this does not work, > >> probably due to type-incompatible Variable "tmp". > >> > >> So rsa->p gets the value of rsa->q but not vice versa: > >> > >> root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl > >> genrsa 128 > >> Generating RSA private key, 128 bit long modulus > >> ..+++++++++++++++++++++++++++ > >> ...+++++++++++++++++++++++++++ > >> e is 65537 (0x10001) > >> p:C2F7ECB8D2F59273 Doppelt!q:C2F7ECB8D2F59273-----BEGIN RSA PRIVATE > >> KEY----- > >> MGECAQACEQCxt/Mo0epqolFmAH7AinLnAgMBAAECECOQd0W09F9QNJjnYUzTA2kC > >> CQDpWa3+afRcvQIJAML37LjS9ZJzAggdBqK1+sgCoQIICN5IGTwXSXsCCEaUjQ+2 > >> 1lSi > >> -----END RSA PRIVATE KEY----- > >> root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl > >> genrsa 128 > >> Generating RSA private key, 128 bit long modulus > >> ...+++++++++++++++++++++++++++ > >> ..+++++++++++++++++++++++++++ > >> e is 65537 (0x10001) > >> p:EA361C8BFA9BA779 q:D5E2C6BB9B8BA893-----BEGIN RSA PRIVATE KEY----- > >> MGQCAQACEQDDrn9XKQBmujmYfSQ++5J7AgMBAAECEQCKoOvL9ts26ogA0yMVZFKx > >> AgkA6jYci/qbp3kCCQDV4sa7m4uokwIJAI6c+HD73n/xAggx7tN+kP21yQIJANCs > >> iuyMFDkp > >> -----END RSA PRIVATE KEY----- > >> root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl > >> genrsa 128 > >> Generating RSA private key, 128 bit long modulus > >> .+++++++++++++++++++++++++++ > >> .+++++++++++++++++++++++++++ > >> e is 65537 (0x10001) > >> p:C3412FF6A7505B29 Doppelt!q:C3412FF6A7505B29-----BEGIN RSA PRIVATE > >> KEY----- > >> MGMCAQACEQCyfg3MCsahBogjE8RM+6yPAgMBAAECEEO3HMbfA7IMpHc7MT6WJZEC > >> CQDqBdvZfYT49wIJAMNBL/anUFspAgkAo33OVsZLFIcCCHPy1A6/EOLxAgkAj5Jg > >> TT5Qxxw= > >> -----END RSA PRIVATE KEY----- > >> root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl > >> genrsa 128 > >> Generating RSA private key, 128 bit long modulus > >> .+++++++++++++++++++++++++++ > >> .+++++++++++++++++++++++++++ > >> e is 65537 (0x10001) > >> p:C90F0AF5C806456F Doppelt!q:C90F0AF5C806456F-----BEGIN RSA PRIVATE > >> KEY----- > >> MGMCAQACEQC5Blnuh/rwj672TEtpnqBbAgMBAAECEHWgVAwQ5reHi1vT7Mv8AgEC > >> CQDrlal9i7dV1QIJAMkPCvXIBkVvAgkAlW1jiUdyrVUCCF/WSswjP1IDAgkA6DRY > >> CoYAsOE= > >> -----END RSA PRIVATE KEY----- > >> root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl > >> genrsa 128 > >> Generating RSA private key, 128 bit long modulus > >> ...+++++++++++++++++++++++++++ > >> ..+++++++++++++++++++++++++++ > >> e is 65537 (0x10001) > >> p:DFE0EAAEF64A9ED3 q:DA49968E614FC9E9-----BEGIN RSA PRIVATE KEY----- > >> MGECAQACEQC+5eKmNv53y2Hn+t22uzkLAgMBAAECEHmAtlbW7/ZsapBlxpZlu1EC > >> CQDf4Oqu9kqe0wIJANpJlo5hT8npAggWUvAz6B1CvwIIYCU9fST7gdECCGudR6xt > >> O4sU > >> -----END RSA PRIVATE KEY---- > >> > >> The code is still the same, even in Pre-Version 1.1.0 > >> > >> Regards, > >> > >> Felix > >> > >> > >> Am 21.12.2015 21:38, schrieb Kurt Roeckx via RT: > >>> On Mon, Dec 21, 2015 at 01:51:45PM +0000, Felix via RT wrote: > >>>> That does not matter from a technical point of view. > >>>> > >>>> The Problem ist the same with 2048-Bit RSA. > >>> If you're worried that p and q might be the same random number, I > >>> think you should have other concerns. > >>> > >>> > >>> Kurt > >>> > >>> > >>> > > > > -- > > Richard Levitte > > levitte at openssl.org > > > > -- Richard Levitte levitte at openssl.org From rt at openssl.org Mon Dec 21 23:27:47 2015 From: rt at openssl.org (Felix via RT) Date: Mon, 21 Dec 2015 23:27:47 +0000 Subject: [openssl-dev] [openssl.org #4190] Missing Check for duplicate Prime-Value of p and q in openssl 0.9.8o In-Reply-To: <56788B37.7040200@gmx.de> References: <20151221203817.GA9747@roeckx.be> <56788B37.7040200@gmx.de> Message-ID: O.K. you are right. please close the ticket... Regards, Felix Am 22.12.2015 00:09, schrieb Richard Levitte via RT: > You're displaying pre-swap p and post-swap q. If they do get swapped, you must > understand that pre-swap p and post-swap q will be the same value. > > If you really want to demonstrate something, please display *both* p and q > before swap, and *both* p and q after swap. > > Vid Mon, 21 Dec 2015 kl. 23.00.38, skrev felix.wiedenroth at gmx.de: >> Hello, >> >> I "pickup" rsa-p and rsa-q just one source-code-line after they were >> "filled" and output the variables using the BN_print_fp function. >> >> please reopen the ticket. >> >> Regards, >> >> Felix >> >> >> for (;;) { >> if (!BN_generate_prime_ex(rsa->p, bitsp, 0, NULL, NULL, cb)) >> goto err; >> printf(" p:"); >> BN_print_fp(stdout,rsa->p); >> printf(" "); >> >> if (!BN_sub(r2, rsa->p, BN_value_one())) >> goto err; >> if (!BN_gcd(r1, r2, rsa->e, ctx)) >> goto err; >> if (BN_is_one(r1)) >> break; >> if (!BN_GENCB_call(cb, 2, n++)) >> goto err; >> } >> if (!BN_GENCB_call(cb, 3, 0)) >> goto err; >> for (;;) { >> /* >> * When generating ridiculously small keys, we can get stuck >> * continually regenerating the same prime values. Check for >> this and >> * bail if it happens 3 times. >> */ >> unsigned int degenerate = 0; >> do { >> if (!BN_generate_prime_ex(rsa->q, bitsq, 0, NULL, NULL, cb)) >> goto err; >> } >> while ((BN_cmp(rsa->p, rsa->q) == 0) && (++degenerate < 10)); >> if (degenerate == 10) { >> ok = 0; /* we set our own err */ >> RSAerr(RSA_F_RSA_BUILTIN_KEYGEN, RSA_R_KEY_SIZE_TOO_SMALL); >> goto err; >> } >> if (!BN_sub(r2, rsa->q, BN_value_one())) >> goto err; >> if (!BN_gcd(r1, r2, rsa->e, ctx)) >> goto err; >> if (BN_is_one(r1)) >> break; >> if (!BN_GENCB_call(cb, 2, n++)) >> goto err; >> } >> if (!BN_GENCB_call(cb, 3, 1)) >> goto err; >> if (BN_cmp(rsa->p, rsa->q) < 0) { >> printf("Doppelt!") ; >> tmp = rsa->p; >> rsa->p = rsa->q; >> rsa->q = tmp; >> } >> printf("q:"); >> BN_print_fp(stdout,rsa->q); >> >> >> >> >> Am 21.12.2015 23:42, schrieb Richard Levitte via RT: >>> You're not showing us how you output rsa->p and rsa->q. It doesn't >>> make sense >>> at all that you get "Doppelt!" if they were equal, so there's >>> something wrong >>> with your output. Also, it's been demonstrated (see mail by Viktor on >>> openssl-dev) that the resulting key does have different p and q, with >>> p > q. >>> >>> For all intents and purposes, this seems not to be a bug. Closing >>> this ticket. >>> >>> Cheers, >>> Richard >>> >>> Vid Mon, 21 Dec 2015 kl. 21.36.10, skrev felix.wiedenroth at gmx.de: >>>> Hello, >>>> >>>> I found the reason for the problem, it?s definately a program error: >>>> >>>> The reason for it is in sub-program rsa_gen.c >>>> >>>> if (BN_cmp(rsa->p, rsa->q) < 0) { >>>> printf("Doppelt!") ; >>>> tmp = rsa->p; >>>> rsa->p = rsa->q; >>>> rsa->q = tmp; >>>> } >>>> >>>> Here p and q should be switched if p > q. But this does not work, >>>> probably due to type-incompatible Variable "tmp". >>>> >>>> So rsa->p gets the value of rsa->q but not vice versa: >>>> >>>> root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl >>>> genrsa 128 >>>> Generating RSA private key, 128 bit long modulus >>>> ..+++++++++++++++++++++++++++ >>>> ...+++++++++++++++++++++++++++ >>>> e is 65537 (0x10001) >>>> p:C2F7ECB8D2F59273 Doppelt!q:C2F7ECB8D2F59273-----BEGIN RSA PRIVATE >>>> KEY----- >>>> MGECAQACEQCxt/Mo0epqolFmAH7AinLnAgMBAAECECOQd0W09F9QNJjnYUzTA2kC >>>> CQDpWa3+afRcvQIJAML37LjS9ZJzAggdBqK1+sgCoQIICN5IGTwXSXsCCEaUjQ+2 >>>> 1lSi >>>> -----END RSA PRIVATE KEY----- >>>> root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl >>>> genrsa 128 >>>> Generating RSA private key, 128 bit long modulus >>>> ...+++++++++++++++++++++++++++ >>>> ..+++++++++++++++++++++++++++ >>>> e is 65537 (0x10001) >>>> p:EA361C8BFA9BA779 q:D5E2C6BB9B8BA893-----BEGIN RSA PRIVATE KEY----- >>>> MGQCAQACEQDDrn9XKQBmujmYfSQ++5J7AgMBAAECEQCKoOvL9ts26ogA0yMVZFKx >>>> AgkA6jYci/qbp3kCCQDV4sa7m4uokwIJAI6c+HD73n/xAggx7tN+kP21yQIJANCs >>>> iuyMFDkp >>>> -----END RSA PRIVATE KEY----- >>>> root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl >>>> genrsa 128 >>>> Generating RSA private key, 128 bit long modulus >>>> .+++++++++++++++++++++++++++ >>>> .+++++++++++++++++++++++++++ >>>> e is 65537 (0x10001) >>>> p:C3412FF6A7505B29 Doppelt!q:C3412FF6A7505B29-----BEGIN RSA PRIVATE >>>> KEY----- >>>> MGMCAQACEQCyfg3MCsahBogjE8RM+6yPAgMBAAECEEO3HMbfA7IMpHc7MT6WJZEC >>>> CQDqBdvZfYT49wIJAMNBL/anUFspAgkAo33OVsZLFIcCCHPy1A6/EOLxAgkAj5Jg >>>> TT5Qxxw= >>>> -----END RSA PRIVATE KEY----- >>>> root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl >>>> genrsa 128 >>>> Generating RSA private key, 128 bit long modulus >>>> .+++++++++++++++++++++++++++ >>>> .+++++++++++++++++++++++++++ >>>> e is 65537 (0x10001) >>>> p:C90F0AF5C806456F Doppelt!q:C90F0AF5C806456F-----BEGIN RSA PRIVATE >>>> KEY----- >>>> MGMCAQACEQC5Blnuh/rwj672TEtpnqBbAgMBAAECEHWgVAwQ5reHi1vT7Mv8AgEC >>>> CQDrlal9i7dV1QIJAMkPCvXIBkVvAgkAlW1jiUdyrVUCCF/WSswjP1IDAgkA6DRY >>>> CoYAsOE= >>>> -----END RSA PRIVATE KEY----- >>>> root at debian6:/home/felix/Downloads/openssl-0.9.8zh/apps# ./openssl >>>> genrsa 128 >>>> Generating RSA private key, 128 bit long modulus >>>> ...+++++++++++++++++++++++++++ >>>> ..+++++++++++++++++++++++++++ >>>> e is 65537 (0x10001) >>>> p:DFE0EAAEF64A9ED3 q:DA49968E614FC9E9-----BEGIN RSA PRIVATE KEY----- >>>> MGECAQACEQC+5eKmNv53y2Hn+t22uzkLAgMBAAECEHmAtlbW7/ZsapBlxpZlu1EC >>>> CQDf4Oqu9kqe0wIJANpJlo5hT8npAggWUvAz6B1CvwIIYCU9fST7gdECCGudR6xt >>>> O4sU >>>> -----END RSA PRIVATE KEY---- >>>> >>>> The code is still the same, even in Pre-Version 1.1.0 >>>> >>>> Regards, >>>> >>>> Felix >>>> >>>> >>>> Am 21.12.2015 21:38, schrieb Kurt Roeckx via RT: >>>>> On Mon, Dec 21, 2015 at 01:51:45PM +0000, Felix via RT wrote: >>>>>> That does not matter from a technical point of view. >>>>>> >>>>>> The Problem ist the same with 2048-Bit RSA. >>>>> If you're worried that p and q might be the same random number, I >>>>> think you should have other concerns. >>>>> >>>>> >>>>> Kurt >>>>> >>>>> >>>>> >>> -- >>> Richard Levitte >>> levitte at openssl.org >>> >>> > > -- > Richard Levitte > levitte at openssl.org > > From rt at openssl.org Tue Dec 22 04:33:45 2015 From: rt at openssl.org (Srinivas Koripella via RT) Date: Tue, 22 Dec 2015 04:33:45 +0000 Subject: [openssl-dev] [openssl.org #4193] Minor Issue with X509_STORE_CTX_init and it's callers. In-Reply-To: References: Message-ID: Hello all, There is a minor issue with X509_STORE_CTX_init and its usage. Most of the callers of X509_STORE_CTX_init use a stack variable and pass its address as the ctx argument to this function. However, X509_STORE_CTX_init in case of an error in the call to CRYPTO_new_ex_data does an OPENSSL_free on this stack variable. This in theory should be ok as the underlying free implementation should probably be a no-op as this address is from the stack. However, on systems that does strict checks on allocated memory heap this can be a problem. One potential fix could be to remove the OPENSSL_free and let the caller take responsibility for his memory. Thanks. Srinivas -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From openssl-users at dukhovni.org Tue Dec 22 06:53:54 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 22 Dec 2015 06:53:54 +0000 Subject: [openssl-dev] [openssl.org #4193] Minor Issue with X509_STORE_CTX_init and it's callers. In-Reply-To: References: Message-ID: <20151222065354.GG18704@mournblade.imrryr.org> On Tue, Dec 22, 2015 at 04:33:45AM +0000, Srinivas Koripella via RT wrote: > There is a minor issue with X509_STORE_CTX_init and its usage. Most of > the callers of X509_STORE_CTX_init use a stack variable and pass its > address as the ctx argument to this function. However, X509_STORE_CTX_init > in case of an error in the call to CRYPTO_new_ex_data does an OPENSSL_free > on this stack variable. This in theory should be ok as the underlying > free implementation should probably be a no-op as this address is from > the stack. Thanks for the report. The bug was introduced way back on 2001/09/01 by commit 79aa04ef27f69a1149d4d0e72d2d2953b6241ef0 and is present in OpenSSL 0.9.8 through 1.0.2. In the "master" development branch the extraneous "free" is gone, but the code is still not quite right, because the memset removed in 2001 really does belong (early) in X509_STORE_CTX_init() and should have been removed from X509_STORE_CTX_cleanup() instead, where zeroing data that is invalidated by cleanup is of course. Try the (lightly tested) patch below my signature. -- Viktor. diff --git a/apps/pkcs12.c b/apps/pkcs12.c index e41b445..cbb75b7 100644 --- a/apps/pkcs12.c +++ b/apps/pkcs12.c @@ -79,7 +79,8 @@ const EVP_CIPHER *enc; # define CLCERTS 0x8 # define CACERTS 0x10 -int get_cert_chain(X509 *cert, X509_STORE *store, STACK_OF(X509) **chain); +static int get_cert_chain(X509 *cert, X509_STORE *store, + STACK_OF(X509) **chain); int dump_certs_keys_p12(BIO *out, PKCS12 *p12, char *pass, int passlen, int options, char *pempass); int dump_certs_pkeys_bags(BIO *out, STACK_OF(PKCS12_SAFEBAG) *bags, @@ -594,7 +595,7 @@ int MAIN(int argc, char **argv) vret = get_cert_chain(ucert, store, &chain2); X509_STORE_free(store); - if (!vret) { + if (vret == X509_V_OK) { /* Exclude verified certificate */ for (i = 1; i < sk_X509_num(chain2); i++) sk_X509_push(certs, sk_X509_value(chain2, i)); @@ -602,7 +603,7 @@ int MAIN(int argc, char **argv) X509_free(sk_X509_value(chain2, 0)); sk_X509_free(chain2); } else { - if (vret >= 0) + if (vret != X509_V_ERR_UNSPECIFIED) BIO_printf(bio_err, "Error %s getting chain.\n", X509_verify_cert_error_string(vret)); else @@ -906,36 +907,25 @@ int dump_certs_pkeys_bag(BIO *out, PKCS12_SAFEBAG *bag, char *pass, /* Given a single certificate return a verified chain or NULL if error */ -/* Hope this is OK .... */ - -int get_cert_chain(X509 *cert, X509_STORE *store, STACK_OF(X509) **chain) +static int get_cert_chain(X509 *cert, X509_STORE *store, + STACK_OF(X509) **chain) { X509_STORE_CTX store_ctx; - STACK_OF(X509) *chn; + STACK_OF(X509) *chn = NULL; int i = 0; - /* - * FIXME: Should really check the return status of X509_STORE_CTX_init - * for an error, but how that fits into the return value of this function - * is less obvious. - */ - X509_STORE_CTX_init(&store_ctx, store, cert, NULL); - if (X509_verify_cert(&store_ctx) <= 0) { - i = X509_STORE_CTX_get_error(&store_ctx); - if (i == 0) - /* - * avoid returning 0 if X509_verify_cert() did not set an - * appropriate error value in the context - */ - i = -1; - chn = NULL; - goto err; - } else + if (!X509_STORE_CTX_init(&store_ctx, store, cert, NULL)) { + *chain = NULL; + return X509_V_ERR_UNSPECIFIED; + } + + if (X509_verify_cert(&store_ctx) > 0) chn = X509_STORE_CTX_get1_chain(&store_ctx); - err: + else if ((i = X509_STORE_CTX_get_error(&store_ctx)) == 0) + i = X509_V_ERR_UNSPECIFIED; + X509_STORE_CTX_cleanup(&store_ctx); *chain = chn; - return i; } diff --git a/crypto/ts/ts_rsp_verify.c b/crypto/ts/ts_rsp_verify.c index da89911..29aa5a4 100644 --- a/crypto/ts/ts_rsp_verify.c +++ b/crypto/ts/ts_rsp_verify.c @@ -255,7 +255,8 @@ static int TS_verify_cert(X509_STORE *store, STACK_OF(X509) *untrusted, /* chain is an out argument. */ *chain = NULL; - X509_STORE_CTX_init(&cert_ctx, store, signer, untrusted); + if (!X509_STORE_CTX_init(&cert_ctx, store, signer, untrusted)) + return 0; X509_STORE_CTX_set_purpose(&cert_ctx, X509_PURPOSE_TIMESTAMP_SIGN); i = X509_verify_cert(&cert_ctx); if (i <= 0) { diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c index ab94948..f44a4a0 100644 --- a/crypto/x509/x509_vfy.c +++ b/crypto/x509/x509_vfy.c @@ -2283,9 +2283,10 @@ int X509_STORE_CTX_init(X509_STORE_CTX *ctx, X509_STORE *store, X509 *x509, ctx->current_reasons = 0; ctx->tree = NULL; ctx->parent = NULL; + /* Zero ex_data to make sure we're cleanup-safe */ + memset(&(ctx->ex_data),0,sizeof(CRYPTO_EX_DATA)); ctx->param = X509_VERIFY_PARAM_new(); - if (!ctx->param) { X509err(X509_F_X509_STORE_CTX_INIT, ERR_R_MALLOC_FAILURE); return 0; @@ -2294,7 +2295,6 @@ int X509_STORE_CTX_init(X509_STORE_CTX *ctx, X509_STORE *store, X509 *x509, /* * Inherit callbacks and flags from X509_STORE if not set use defaults. */ - if (store) ret = X509_VERIFY_PARAM_inherit(ctx->param, store->param); else @@ -2302,6 +2302,7 @@ int X509_STORE_CTX_init(X509_STORE_CTX *ctx, X509_STORE *store, X509 *x509, if (store) { ctx->verify_cb = store->verify_cb; + /* Seems to always be 0 in OpenSSL, else must be idempotent */ ctx->cleanup = store->cleanup; } else ctx->cleanup = 0; @@ -2312,7 +2313,7 @@ int X509_STORE_CTX_init(X509_STORE_CTX *ctx, X509_STORE *store, X509 *x509, if (ret == 0) { X509err(X509_F_X509_STORE_CTX_INIT, ERR_R_MALLOC_FAILURE); - return 0; + goto err; } if (store && store->check_issued) @@ -2367,19 +2368,18 @@ int X509_STORE_CTX_init(X509_STORE_CTX *ctx, X509_STORE *store, X509 *x509, ctx->check_policy = check_policy; + if (CRYPTO_new_ex_data(CRYPTO_EX_INDEX_X509_STORE_CTX, ctx, + &(ctx->ex_data))) + return 1; + X509err(X509_F_X509_STORE_CTX_INIT, ERR_R_MALLOC_FAILURE); + + err: /* - * This memset() can't make any sense anyway, so it's removed. As - * X509_STORE_CTX_cleanup does a proper "free" on the ex_data, we put a - * corresponding "new" here and remove this bogus initialisation. + * On error clean up allocated storage, if the store context was not + * allocated with X509_STORE_CTX_new() this is our last chance to do so. */ - /* memset(&(ctx->ex_data),0,sizeof(CRYPTO_EX_DATA)); */ - if (!CRYPTO_new_ex_data(CRYPTO_EX_INDEX_X509_STORE_CTX, ctx, - &(ctx->ex_data))) { - OPENSSL_free(ctx); - X509err(X509_F_X509_STORE_CTX_INIT, ERR_R_MALLOC_FAILURE); - return 0; - } - return 1; + X509_STORE_CTX_cleanup(ctx); + return 0; } /* @@ -2395,6 +2395,13 @@ void X509_STORE_CTX_trusted_stack(X509_STORE_CTX *ctx, STACK_OF(X509) *sk) void X509_STORE_CTX_cleanup(X509_STORE_CTX *ctx) { + /* + * We need to be idempotent because, unfortunately, free() also calls + * cleanup(), so the natural call sequence new(), init(), cleanup(), free() + * calls cleanup() for the same object twice! Thus we must zero the + * pointers below after they're freed! + */ + /* Seems to always be 0 in OpenSSL, else must be idempotent */ if (ctx->cleanup) ctx->cleanup(ctx); if (ctx->param != NULL) { diff --git a/crypto/x509/x509_vfy.h b/crypto/x509/x509_vfy.h index bd8613c..2663e1c 100644 --- a/crypto/x509/x509_vfy.h +++ b/crypto/x509/x509_vfy.h @@ -313,7 +313,7 @@ void X509_STORE_CTX_set_depth(X509_STORE_CTX *ctx, int depth); X509_LOOKUP_ctrl((x),X509_L_ADD_DIR,(name),(long)(type),NULL) # define X509_V_OK 0 -/* illegal error (for uninitialized values, to avoid X509_V_OK): 1 */ +# define X509_V_ERR_UNSPECIFIED 1 # define X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT 2 # define X509_V_ERR_UNABLE_TO_GET_CRL 3 From openssl-users at dukhovni.org Tue Dec 22 07:24:52 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 22 Dec 2015 07:24:52 +0000 Subject: [openssl-dev] [openssl.org #4193] Minor Issue with X509_STORE_CTX_init and it's callers. In-Reply-To: <20151222065354.GG18704@mournblade.imrryr.org> References: <20151222065354.GG18704@mournblade.imrryr.org> Message-ID: <20151222072452.GH18704@mournblade.imrryr.org> On Tue, Dec 22, 2015 at 06:53:54AM +0000, Viktor Dukhovni wrote: > On Tue, Dec 22, 2015 at 04:33:45AM +0000, Srinivas Koripella via RT wrote: > > > There is a minor issue with X509_STORE_CTX_init and its usage. Most of > > the callers of X509_STORE_CTX_init use a stack variable and pass its > > address as the ctx argument to this function. However, X509_STORE_CTX_init > > in case of an error in the call to CRYPTO_new_ex_data does an OPENSSL_free > > on this stack variable. This in theory should be ok as the underlying > > free implementation should probably be a no-op as this address is from > > the stack. > > Thanks for the report. The bug was introduced way back on 2001/09/01 > by commit 79aa04ef27f69a1149d4d0e72d2d2953b6241ef0 and is present > in OpenSSL 0.9.8 through 1.0.2. > > In the "master" development branch the extraneous "free" is gone, > but the code is still not quite right, because the memset removed > in 2001 really does belong (early) in X509_STORE_CTX_init() and > should have been removed from X509_STORE_CTX_cleanup() instead, > where zeroing data that is invalidated by cleanup is of course. > > Try the (lightly tested) patch below my signature. Note, that patch was for 1.0.2e. No idea how cleanly it applies to other releases. -- Viktor. From rt at openssl.org Tue Dec 22 07:30:37 2015 From: rt at openssl.org (Roumen Petrov via RT) Date: Tue, 22 Dec 2015 07:30:37 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: <5678F551.8000406@roumenpetrov.info> References: <5678F551.8000406@roumenpetrov.info> Message-ID: Hello, OpenSSL engine command allows user to specify cryptographic module name at any position. For instance README.ENGINE recommend following: openssl engine dynamic \ -pre SO_PATH:/lib/libfoo.so \ .... The master branch (future 1.1) requires engine names to be specified after all options. This is regression introduced by new common " option-parsing". Also new summary lack information for engine name as command line argument. Regards, Roumen Petrov _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From openssl at roumenpetrov.info Tue Dec 22 07:52:05 2015 From: openssl at roumenpetrov.info (Roumen Petrov) Date: Tue, 22 Dec 2015 09:52:05 +0200 Subject: [openssl-dev] about "Rename some BUF_xxx to OPENSSL_xxx" Message-ID: <56790125.2050304@roumenpetrov.info> Hello, After modification OPENSSL_strlcpy is declared twice. Regards, Roumen -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-redundant-redeclaration-of-OPENSSL_strlcpy.patch Type: text/x-diff Size: 825 bytes Desc: not available URL: From openssl at roumenpetrov.info Tue Dec 22 08:03:02 2015 From: openssl at roumenpetrov.info (Roumen Petrov) Date: Tue, 22 Dec 2015 10:03:02 +0200 Subject: [openssl-dev] extra data for ec keys Message-ID: <567903B6.9070805@roumenpetrov.info> Hello, After merge of ECDH and ECDSA and associating method to EC_KEY I would like to request some additional functionality. External cryptographic modules may store addition information to key. What about to define CRYPTO_EX_DATA for ec keys? Proposed patch "0008-extra-data-for-EC_KEY.patch" - note that index CRYPTO_EX_INDEX is with gap in numbering but I would like patch to be minimal. I would like to request external applications to be able to change method - see attached patch "0009-access-EC_KEY-method-property.patch". Regards, Roumen Petrov -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-extra-data-for-EC_KEY.patch Type: text/x-diff Size: 3235 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0009-access-EC_KEY-method-property.patch Type: text/x-diff Size: 2459 bytes Desc: not available URL: From openssl at roumenpetrov.info Tue Dec 22 07:46:37 2015 From: openssl at roumenpetrov.info (Roumen Petrov) Date: Tue, 22 Dec 2015 09:46:37 +0200 Subject: [openssl-dev] __STDC_VERSION__ is not defined Message-ID: <5678FFDD.6020807@roumenpetrov.info> Hello, Compilation of an application with current master branch and c89 compiler produce a lot of warnings. Proposed patch "0001-__STDC_VERSION__-is-not-defined-for-c89-compilers.patch" fix them. Regards, Roumen -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-__STDC_VERSION__-is-not-defined-for-c89-compilers.patch Type: text/x-diff Size: 815 bytes Desc: not available URL: From rt at openssl.org Tue Dec 22 09:03:56 2015 From: rt at openssl.org (Roumen Petrov via RT) Date: Tue, 22 Dec 2015 09:03:56 +0000 Subject: [openssl-dev] [openssl.org #4195] remove duplicates in util/libeay.num In-Reply-To: <567911F7.40403@roumenpetrov.info> References: <567911F7.40403@roumenpetrov.info> Message-ID: Hello, After remove of some global variables in export file left double information for non existent functions. For instance before: X509_CERT_PAIR_it 3534 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE: X509_CERT_PAIR_it 3534 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION: current: X509_CERT_PAIR_it 3534 1_1_0 NOEXIST::FUNCTION: X509_CERT_PAIR_it 3534 1_1_0 NOEXIST::FUNCTION: Proposed patch removes duplicates. Regards, Roumen Petrov -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-remove-duplicates-in-util-libeay.num.patch Type: text/x-diff Size: 8082 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From zoli at polarhome.com Tue Dec 22 09:14:34 2015 From: zoli at polarhome.com (Zoltan Arpadffy) Date: Tue, 22 Dec 2015 10:14:34 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published In-Reply-To: <1DB21B8B-DD44-43FA-97E6-01EF1E6F7F45@openssl.org> References: <20151210150150.GA30915@openssl.org> <001001d13c26$da55e0a0$8f01a1e0$@com> <1DB21B8B-DD44-43FA-97E6-01EF1E6F7F45@openssl.org> Message-ID: <20151222101434.116043c95betfssa@www.polarhome.com> Thank you Richard. What "slowly" means? Will you be able to commit the OpenVMS build scripts before the 1.1.0's release? Do you need some help with coding, testing? Should I try to repair the old build scripts? Thanks, Z Quoting Richard Levitte : > The building scripts are not at all updated, it's beyond repair. I'm > (slowly) working on a new solution that doesn't require the separate > update hell... > > Cheers > Richard > > Zoltan Arpadffy skrev: (21 december 2015 20:36:13 CET) >> Hi, >> >> I am sorry, but because of the relocation of the header files the 1.1.0 >> does >> not build on OpenVMS. >> Please, allow some time to fix the OpenVMS build scripts. >> >> Thank you. >> Regards, >> Z >> >> -----Original Message----- >> From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of >> OpenSSL >> Sent: den 10 december 2015 16:02 >> To: OpenSSL Developer ML; OpenSSL User Support ML; OpenSSL Announce ML >> Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> OpenSSL version 1.1.0 pre release 1 (alpha) >> =========================================== >> >> OpenSSL - The Open Source toolkit for SSL/TLS >> http://www.openssl.org/ >> >> OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 1 has >> now >> been made available. For details of changes and known issues see the >> release notes at: >> >> http://www.openssl.org/news/openssl-1.1.0-notes.html >> >> Note: This OpenSSL pre-release has been provided for testing ONLY. >> It should NOT be used for security critical purposes. >> >> The alpha release is available for download via HTTP and FTP from the >> following master locations (you can find the various FTP mirrors under >> http://www.openssl.org/source/mirror.html): >> >> * http://www.openssl.org/source/ >> * ftp://ftp.openssl.org/source/ >> >> The distribution file name is: >> >> o openssl-1.1.0-pre1.tar.gz >> Size: 4990889 >> SHA1 checksum: a058b999e17e0c40988bd7b9b280c9876f62684e >> SHA256 checksum: >> 79da49c38464a19d1b328c2f4a3661849bd2eb3d54a37fdb6a56d9b8a18e87bd >> >> The checksums were calculated using the following commands: >> >> openssl sha1 openssl-1.1.0-pre1.tar.gz >> openssl sha256 openssl-1.1.0-pre1.tar.gz >> >> Please download and check this alpha release as soon as possible. Bug >> reports >> should go to rt at openssl.org. Please check the release notes >> and mailing lists to avoid duplicate reports of known issues. >> >> Yours, >> >> The OpenSSL Project Team. >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >> >> iQEcBAEBAgAGBQJWaYrRAAoJENnE0m0OYESRh5gIAJ8WrkPPV8CW2xWmtyIjAxpz >> 7FvvpxBWHaBgJcCrvNomh2JJupXa+enWCTsskIyH0+FtS85VeOKNvQg68xbCOvLl >> I0dWxMNb8SCxuagvEje8xGEnf8by8pZdYaK8ERASlNoGVIgN8CwppiKnY8c1yRYn >> Ti0dUZLyVZvT5Qm2Q3k4pOvfS/+rvFjHiuUllFzfHlp6mdk4573w5eneoTINQvRK >> OC8iAnSiINQWQvuiavLVIgw7VFBD1WC2iKWuSA3+31YuM8CUpvbbnJHh2QUfGkIw >> oNTkflxgQJhk/txwqvCSzZsVddhvQLZtiRZYQcG4WUuskygCENeieJGPOXN6ioI= >> =LY4X >> -----END PGP SIGNATURE----- >> _______________________________________________ >> 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 > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > --- WebMail, polarhome.com From levitte at openssl.org Tue Dec 22 09:34:38 2015 From: levitte at openssl.org (Richard Levitte) Date: Tue, 22 Dec 2015 10:34:38 +0100 (CET) Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published In-Reply-To: <20151222101434.116043c95betfssa@www.polarhome.com> References: <001001d13c26$da55e0a0$8f01a1e0$@com> <1DB21B8B-DD44-43FA-97E6-01EF1E6F7F45@openssl.org> <20151222101434.116043c95betfssa@www.polarhome.com> Message-ID: <20151222.103438.1921729300738985635.levitte@openssl.org> In message <20151222101434.116043c95betfssa at www.polarhome.com> on Tue, 22 Dec 2015 10:14:34 +0100, Zoltan Arpadffy said: zoli> Thank you Richard. zoli> zoli> What "slowly" means? Will you be able to commit the OpenVMS build zoli> scripts before the 1.1.0's release? Yes. At the latest, it should be fully present in alpha3. See the end of https://openssl.org/policies/releasestrat.html for planned release dates. zoli> Do you need some help with coding, testing? Yes please. zoli> Should I try to repair the old build scripts? No. Thanks for the reminder, they should all go. My plan for "new and shiny" is based on perl, running Configure and have it generate a top level descrip.mms. Requirements will be a perl installation (minimum version 5.12) plus Text::Template. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From zoli at polarhome.com Tue Dec 22 10:10:22 2015 From: zoli at polarhome.com (Zoltan Arpadffy) Date: Tue, 22 Dec 2015 11:10:22 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published In-Reply-To: <20151222.103438.1921729300738985635.levitte@openssl.org> References: <001001d13c26$da55e0a0$8f01a1e0$@com> <1DB21B8B-DD44-43FA-97E6-01EF1E6F7F45@openssl.org> <20151222101434.116043c95betfssa@www.polarhome.com> <20151222.103438.1921729300738985635.levitte@openssl.org> Message-ID: <20151222111022.44086nc6688vq6by@www.polarhome.com> Richard, > My plan for "new and shiny" is based on perl, running Configure and > have it generate a top level descrip.mms. Requirements will be a perl > installation (minimum version 5.12) plus Text::Template. Thank you for the information. I am aware that having perl installed on a modern operating system is not a very tough requirement - but experience shows that external dependencies often cause problems on OpenVMS. I would suggest to include/commit the perl scripts into the OpenSSL source code (for developers convenience only), but they should be ran and commit the OpenVMS descrip.mms build files matching the current code base - as a step in the OpenSSL source code release process. Unix make files are also made in forehand. Right? What is your opinion about this? > zoli> Do you need some help with coding, testing? > > Yes please. Please, let me know how... or should I just wait for the make files release? Thank you. Z --- WebMail, polarhome.com From levitte at openssl.org Tue Dec 22 10:33:47 2015 From: levitte at openssl.org (Richard Levitte) Date: Tue, 22 Dec 2015 11:33:47 +0100 (CET) Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published In-Reply-To: <20151222111022.44086nc6688vq6by@www.polarhome.com> References: <20151222101434.116043c95betfssa@www.polarhome.com> <20151222.103438.1921729300738985635.levitte@openssl.org> <20151222111022.44086nc6688vq6by@www.polarhome.com> Message-ID: <20151222.113347.192842763316310346.levitte@openssl.org> In message <20151222111022.44086nc6688vq6by at www.polarhome.com> on Tue, 22 Dec 2015 11:10:22 +0100, Zoltan Arpadffy said: zoli> Richard, zoli> zoli> > My plan for "new and shiny" is based on perl, running Configure and zoli> > have it generate a top level descrip.mms. Requirements will be a perl zoli> > installation (minimum version 5.12) plus Text::Template. zoli> zoli> Thank you for the information. zoli> zoli> I am aware that having perl installed on a modern operating system is zoli> not a very tough requirement - but experience shows that external zoli> dependencies often cause problems on OpenVMS. For perl, it's not that hard: http://sourceforge.net/projects/vmsperlkit/files/ zoli> I would suggest to include/commit the perl scripts into the OpenSSL zoli> source code (for developers convenience only), but they should be ran zoli> and commit the OpenVMS descrip.mms build files matching the current zoli> code base - as a step in the OpenSSL source code release process. I was thinking that it might be a good idea to bundle Text::Template, if that's what you meant. We try to make sure to only use core perl modules, but considering there's no template module among the core ones and I hardly want to reinvent the wheel, I might make an exception there. I haven't decided, though, it's not like it's very hard to do a "cpan download Text::Template" and then install it (unfortunately, "cpan install Text::Template" doesn't work because there's a lack of action lines in the test: target it its Makefile, and mms isn't too happy about that...) zoli> Unix make files are also made in forehand. Right? Nope. zoli> What is your opinion about this? Considering there's Alpha, IA64 and VSI is building VMS for x86_64, and let's not forget pointer size options, the different possible configurations is already not a small number, and will only increase. How many variants of descrip.mms did you want? So, uhmm, nah. Frankly, it's time (it's been time for long) for the OpenVMS community to catch up with the rest of the world re open source building... or for someone to produce OpenSSL install kits (it's possible that the vms-ports effort will do so, possibly by yours truly... no promises, though). zoli> > zoli> Do you need some help with coding, testing? zoli> > zoli> > Yes please. zoli> zoli> Please, let me know how... or should I just wait for the make files zoli> release? I'll have a branch in git at github.com:levitte/openssl.git I'll get back when it starts going live. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Tue Dec 22 10:55:28 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Tue, 22 Dec 2015 10:55:28 +0000 Subject: [openssl-dev] [openssl.org #4184] Memory leak in DSA redo case In-Reply-To: <20151222105538.GA22382@roeckx.be> References: <20151222105538.GA22382@roeckx.be> Message-ID: Fixed. Kurt From zoli at polarhome.com Tue Dec 22 11:23:49 2015 From: zoli at polarhome.com (Zoltan Arpadffy) Date: Tue, 22 Dec 2015 12:23:49 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published In-Reply-To: <20151222.113347.192842763316310346.levitte@openssl.org> References: <20151222101434.116043c95betfssa@www.polarhome.com> <20151222.103438.1921729300738985635.levitte@openssl.org> <20151222111022.44086nc6688vq6by@www.polarhome.com> <20151222.113347.192842763316310346.levitte@openssl.org> Message-ID: <20151222122349.916552ojkzhe5sqt@www.polarhome.com> Hi, > zoli> I am aware that having perl installed on a modern operating system is > zoli> not a very tough requirement - but experience shows that external > zoli> dependencies often cause problems on OpenVMS. > > For perl, it's not that hard: > http://sourceforge.net/projects/vmsperlkit/files/ > (unfortunately, "cpan install Text::Template" doesn't work because > there's a lack of action lines in the test: target it its Makefile, > and mms isn't too happy about that...) > So, uhmm, nah. Frankly, it's time (it's been time for long) for the > OpenVMS community to catch up with the rest of the world re open > source building... Please, do not misunderstand me - I am on your side and I would be the most happy if that would work. But there is a problem: The files currently featured are kits for installing Perl 5.22.1 on OpenVMS Alpha or Itanium v8.3 and later. (from the home page)... but many OpenVMS systems are not on v8.3 yet. Here is an unofficial usage statistics for OpenSSL and Vim users VAX - 7.1 or older 29.82 % (167) VAX - 7.2 or newer 6.96 % (39) Alpha - 7.2 or older 5.54 % (31) Alpha - 7.3 or newer 29.64 % (166) Itanium - 8.0 or newer 23.39 % (131) I do not use OpenVMS 3.57 % (20) I do not know 1.07 % (6) Total votes: 560 The most probable reason for keeping OpenVMS systems not updated is the HP's ECO packages availability as well the OpenVMS excellent backwards compatibility that allows old builds to run in new systems. This is not good - I know. But this is a fact we need to face when we develop for this system. > Considering there's Alpha, IA64 and VSI is building VMS for x86_64, > and let's not forget pointer size options, the different possible > configurations is already not a small number, and will only increase. > How many variants of descrip.mms did you want? One descript.mms file would be enough. Thank you for asking :) MMS/MMK accepts parameters that could be used within the descript file making possible the different choices - if it is written on that way, especially that architecture and some other parameters can be successfully guessed within the MMS file. > zoli> > zoli> Do you need some help with coding, testing? > > I'll have a branch in git at github.com:levitte/openssl.git > I'll get back when it starts going live. Thank you, Richard. I am looking forward to help you. Regards, Z --- WebMail, polarhome.com From levitte at openssl.org Tue Dec 22 11:50:06 2015 From: levitte at openssl.org (Richard Levitte) Date: Tue, 22 Dec 2015 12:50:06 +0100 (CET) Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published In-Reply-To: <20151222122349.916552ojkzhe5sqt@www.polarhome.com> References: <20151222111022.44086nc6688vq6by@www.polarhome.com> <20151222.113347.192842763316310346.levitte@openssl.org> <20151222122349.916552ojkzhe5sqt@www.polarhome.com> Message-ID: <20151222.125006.191704225380070406.levitte@openssl.org> In message <20151222122349.916552ojkzhe5sqt at www.polarhome.com> on Tue, 22 Dec 2015 12:23:49 +0100, Zoltan Arpadffy said: zoli> Hi, zoli> zoli> > zoli> I am aware that having perl installed on a modern operating zoli> > system is zoli> > zoli> not a very tough requirement - but experience shows that zoli> > external zoli> > zoli> dependencies often cause problems on OpenVMS. zoli> > zoli> > For perl, it's not that hard: zoli> > http://sourceforge.net/projects/vmsperlkit/files/ zoli> zoli> > (unfortunately, "cpan install Text::Template" doesn't work because zoli> > there's a lack of action lines in the test: target it its Makefile, zoli> > and mms isn't too happy about that...) zoli> zoli> > So, uhmm, nah. Frankly, it's time (it's been time for long) for the zoli> > OpenVMS community to catch up with the rest of the world re open zoli> > source building... zoli> zoli> Please, do not misunderstand me - I am on your side and I would be the zoli> most happy if that would work. zoli> zoli> But there is a problem: zoli> The files currently featured are kits for installing zoli> Perl 5.22.1 on OpenVMS Alpha or Itanium v8.3 and later. (from the home zoli> page)... but many OpenVMS systems are not on v8.3 yet. There are older kits in the Archive folder. I don't know for the moment what VMS version they're built for. zoli> This is not good - I know. But this is a fact we need to face when we zoli> develop for this system. That's tough, unfortunately... I've only access to a V8.4 cluster (Alpha and IA64), so I don't know how to help you further. Of course, there's the option to build perl from source, which isn't very hard at all (I've done so a few times). zoli> One descript.mms file would be enough. Thank you for asking :) zoli> MMS/MMK accepts parameters that could be used within the descript file zoli> making possible the different choices - if it is written on that way, zoli> especially that architecture and some other parameters can be zoli> successfully guessed within the MMS file. Well, the aim is to have a common structure to build from on all architectures we claim to support. You've seen for yourself how the scripts for VMS builds were lagging behind, and quite frankly, it's hellish to keep them up to date (I've completely dropped the ball for 1.1). That's not something I'm willing to have us do all over again. zoli> > zoli> > zoli> Do you need some help with coding, testing? zoli> > zoli> > I'll have a branch in git at github.com:levitte/openssl.git zoli> > I'll get back when it starts going live. zoli> zoli> Thank you, Richard. zoli> I am looking forward to help you. Thanks :-) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From zoli at polarhome.com Tue Dec 22 12:47:41 2015 From: zoli at polarhome.com (Zoltan Arpadffy) Date: Tue, 22 Dec 2015 13:47:41 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published In-Reply-To: <20151222.125006.191704225380070406.levitte@openssl.org> References: <20151222111022.44086nc6688vq6by@www.polarhome.com> <20151222.113347.192842763316310346.levitte@openssl.org> <20151222122349.916552ojkzhe5sqt@www.polarhome.com> <20151222.125006.191704225380070406.levitte@openssl.org> Message-ID: <20151222134741.72034a0b79m0zmul@www.polarhome.com> Hi, > zoli> > (unfortunately, "cpan install Text::Template" doesn't work because > zoli> > there's a lack of action lines in the test: target it its Makefile, > zoli> > and mms isn't too happy about that...) > That's tough, unfortunately... I've only access to a V8.4 cluster > (Alpha and IA64), so I don't know how to help you further. Of course, > there's the option to build perl from source, which isn't very hard at > all (I've done so a few times). I do have access to VAX, Alpha and IA64 architectures... on range of 7.3 to 8.3 OpenVMS versions. Also I do have functional perl installed on them. I am not the problem here, but ordinary developers that work on an old system developing for a legacy program and do not have SYSTEM rights - what is the common case. The build solution should be designed to be usable by those developers too. > Well, the aim is to have a common structure to build from on all > architectures we claim to support. You've seen for yourself how the > scripts for VMS builds were lagging behind, and quite frankly, it's > hellish to keep them up to date (I've completely dropped the ball for > 1.1). That's not something I'm willing to have us do all over again. Absolutely agree with you. This is the way forward. May I ask you, if the new build will cover the long names issue ( symhacks.h ) too? Thanks, Z --- WebMail, polarhome.com From rsalz at akamai.com Tue Dec 22 13:12:48 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 22 Dec 2015 13:12:48 +0000 Subject: [openssl-dev] extra data for ec keys In-Reply-To: <567903B6.9070805@roumenpetrov.info> References: <567903B6.9070805@roumenpetrov.info> Message-ID: <8a62b93b720d42b4a295bd51ba8fbd5e@usma1ex-dag1mb1.msg.corp.akamai.com> > External cryptographic modules may store addition information to key. > What about to define CRYPTO_EX_DATA for ec keys? That is the plan -- we will remove EX_EX_DATA and the internal API and just use the standard crypto_ex_data stuff. Want to make a more complete patch as a github pull request? :) Otherwise I'll get to it soon. From rt at openssl.org Tue Dec 22 13:13:00 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Tue, 22 Dec 2015 13:13:00 +0000 Subject: [openssl-dev] [openssl.org #4196] BeagleBone Black detected as ARMv4 In-Reply-To: References: Message-ID: This seems like an odd result considering the BeagleBone Black processor is closer to a NEON. This particular BBB is running a Debian 8.2 based image. I also believe CFLAGS should include hard-floats (i.e., -mfloat-abi=hard). Without it, entropy estimates for some of the RAND_ functions could produce incorrect results. ********** $ cat /etc/dogtag BeagleBoard.org Debian Image 2015-12-20 $ uname -a Linux beaglebone 4.1.13-ti-r36 #1 SMP PREEMPT Fri Dec 11 00:44:56 UTC 2015 armv7l GNU/Linux $ gcc --version gcc (Debian 4.9.2-10) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. ********** $ cpp -dM < /dev/null | grep __ARM | sort #define __ARMEL__ 1 #define __ARM_32BIT_STATE 1 #define __ARM_ARCH 7 #define __ARM_ARCH_7A__ 1 #define __ARM_ARCH_ISA_ARM 1 #define __ARM_ARCH_ISA_THUMB 2 #define __ARM_ARCH_PROFILE 65 #define __ARM_EABI__ 1 #define __ARM_FEATURE_CLZ 1 #define __ARM_FEATURE_DSP 1 #define __ARM_FEATURE_LDREX 15 #define __ARM_FEATURE_QBIT 1 #define __ARM_FEATURE_SAT 1 #define __ARM_FEATURE_SIMD32 1 #define __ARM_FEATURE_UNALIGNED 1 #define __ARM_FP 12 #define __ARM_NEON_FP 4 #define __ARM_PCS_VFP 1 #define __ARM_SIZEOF_MINIMAL_ENUM 4 #define __ARM_SIZEOF_WCHAR_T 32 ********** $ cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 2 (v7l) BogoMIPS : 996.14 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part : 0xc08 CPU revision : 2 Hardware : Generic AM33XX (Flattened Device Tree) Revision : 0000 Serial : ... ********** beaglebone:~/openssl-1.0.2e$ ./config Operating system: armv7l-whatever-linux2 Configuring for linux-armv4 Configuring for linux-armv4 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-shared [default] no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-store [experimental] OPENSSL_NO_STORE (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-zlib [default] no-zlib-dynamic [default] IsMK1MF=0 CC =gcc CFLAG =-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -march=armv7-a -Wa,--noexecstack -O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM EX_LIBS =-ldl CPUID_OBJ =armcap.o armv4cpuid.o BN_ASM =bn_asm.o armv4-mont.o armv4-gf2m.o EC_ASM = DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o BF_ENC =bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4_enc.o rc4_skey.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM = SHA1_OBJ_ASM =sha1-armv4-large.o sha256-armv4.o sha512-armv4.o RMD160_OBJ_ASM= CMLL_ENC =camellia.o cmll_misc.o cmll_cbc.o MODES_OBJ =ghash-armv4.o ghashv8-armx.o ENGINES_OBJ = PROCESSOR = RANLIB =/usr/bin/ranlib ARFLAGS = PERL =/usr/bin/perl THIRTY_TWO_BIT mode DES_UNROLL used DES_INT used BN_LLONG mode RC4 uses uchar RC4_CHUNK is unsigned long BF_PTR used created directory `include/openssl' e_os2.h => include/openssl/e_os2.h making links in crypto... make[1]: Entering directory '/.../openssl-1.0.2e/crypto' crypto.h => ../include/openssl/crypto.h opensslv.h => ../include/openssl/opensslv.h opensslconf.h => ../include/openssl/opensslconf.h ebcdic.h => ../include/openssl/ebcdic.h symhacks.h => ../include/openssl/symhacks.h ossl_typ.h => ../include/openssl/ossl_typ.h constant_time_test.c => ../test/constant_time_test.c making links in crypto/objects... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/objects' objects.h => ../../include/openssl/objects.h obj_mac.h => ../../include/openssl/obj_mac.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/objects' making links in crypto/md4... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/md4' md4.h => ../../include/openssl/md4.h md4test.c => ../../test/md4test.c md4.c => ../../apps/md4.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/md4' making links in crypto/md5... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/md5' md5.h => ../../include/openssl/md5.h md5test.c => ../../test/md5test.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/md5' making links in crypto/sha... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/sha' sha.h => ../../include/openssl/sha.h shatest.c => ../../test/shatest.c sha1test.c => ../../test/sha1test.c sha256t.c => ../../test/sha256t.c sha512t.c => ../../test/sha512t.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/sha' making links in crypto/mdc2... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/mdc2' mdc2.h => ../../include/openssl/mdc2.h mdc2test.c => ../../test/mdc2test.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/mdc2' making links in crypto/hmac... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/hmac' hmac.h => ../../include/openssl/hmac.h hmactest.c => ../../test/hmactest.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/hmac' making links in crypto/ripemd... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/ripemd' ripemd.h => ../../include/openssl/ripemd.h rmdtest.c => ../../test/rmdtest.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/ripemd' making links in crypto/whrlpool... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/whrlpool' whrlpool.h => ../../include/openssl/whrlpool.h wp_test.c => ../../test/wp_test.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/whrlpool' making links in crypto/des... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/des' des.h => ../../include/openssl/des.h des_old.h => ../../include/openssl/des_old.h destest.c => ../../test/destest.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/des' making links in crypto/aes... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/aes' aes.h => ../../include/openssl/aes.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/aes' making links in crypto/rc2... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/rc2' rc2.h => ../../include/openssl/rc2.h rc2test.c => ../../test/rc2test.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/rc2' making links in crypto/rc4... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/rc4' rc4.h => ../../include/openssl/rc4.h rc4test.c => ../../test/rc4test.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/rc4' making links in crypto/idea... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/idea' idea.h => ../../include/openssl/idea.h ideatest.c => ../../test/ideatest.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/idea' making links in crypto/bf... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/bf' blowfish.h => ../../include/openssl/blowfish.h bftest.c => ../../test/bftest.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/bf' making links in crypto/cast... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/cast' cast.h => ../../include/openssl/cast.h casttest.c => ../../test/casttest.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/cast' making links in crypto/camellia... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/camellia' camellia.h => ../../include/openssl/camellia.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/camellia' making links in crypto/seed... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/seed' seed.h => ../../include/openssl/seed.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/seed' making links in crypto/modes... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/modes' modes.h => ../../include/openssl/modes.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/modes' making links in crypto/bn... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/bn' bn.h => ../../include/openssl/bn.h bntest.c => ../../test/bntest.c exptest.c => ../../test/exptest.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/bn' making links in crypto/ec... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/ec' ec.h => ../../include/openssl/ec.h ectest.c => ../../test/ectest.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/ec' making links in crypto/rsa... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/rsa' rsa.h => ../../include/openssl/rsa.h rsa_test.c => ../../test/rsa_test.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/rsa' making links in crypto/dsa... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/dsa' dsa.h => ../../include/openssl/dsa.h dsatest.c => ../../test/dsatest.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/dsa' making links in crypto/ecdsa... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/ecdsa' ecdsa.h => ../../include/openssl/ecdsa.h ecdsatest.c => ../../test/ecdsatest.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/ecdsa' making links in crypto/dh... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/dh' dh.h => ../../include/openssl/dh.h dhtest.c => ../../test/dhtest.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/dh' making links in crypto/ecdh... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/ecdh' ecdh.h => ../../include/openssl/ecdh.h ecdhtest.c => ../../test/ecdhtest.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/ecdh' making links in crypto/dso... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/dso' dso.h => ../../include/openssl/dso.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/dso' making links in crypto/engine... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/engine' engine.h => ../../include/openssl/engine.h enginetest.c => ../../test/enginetest.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/engine' making links in crypto/buffer... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/buffer' buffer.h => ../../include/openssl/buffer.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/buffer' making links in crypto/bio... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/bio' bio.h => ../../include/openssl/bio.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/bio' making links in crypto/stack... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/stack' stack.h => ../../include/openssl/stack.h safestack.h => ../../include/openssl/safestack.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/stack' making links in crypto/lhash... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/lhash' lhash.h => ../../include/openssl/lhash.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/lhash' making links in crypto/rand... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/rand' rand.h => ../../include/openssl/rand.h randtest.c => ../../test/randtest.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/rand' making links in crypto/err... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/err' err.h => ../../include/openssl/err.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/err' making links in crypto/evp... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/evp' evp.h => ../../include/openssl/evp.h evp_test.c => ../../test/evp_test.c evp_extra_test.c => ../../test/evp_extra_test.c evptests.txt -> ../../test/evptests.txt make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/evp' making links in crypto/asn1... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/asn1' asn1.h => ../../include/openssl/asn1.h asn1_mac.h => ../../include/openssl/asn1_mac.h asn1t.h => ../../include/openssl/asn1t.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/asn1' making links in crypto/pem... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/pem' pem.h => ../../include/openssl/pem.h pem2.h => ../../include/openssl/pem2.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/pem' making links in crypto/x509... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/x509' x509.h => ../../include/openssl/x509.h x509_vfy.h => ../../include/openssl/x509_vfy.h verify_extra_test.c => ../../test/verify_extra_test.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/x509' making links in crypto/x509v3... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/x509v3' x509v3.h => ../../include/openssl/x509v3.h v3nametest.c => ../../test/v3nametest.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/x509v3' making links in crypto/conf... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/conf' conf.h => ../../include/openssl/conf.h conf_api.h => ../../include/openssl/conf_api.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/conf' making links in crypto/txt_db... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/txt_db' txt_db.h => ../../include/openssl/txt_db.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/txt_db' making links in crypto/pkcs7... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/pkcs7' pkcs7.h => ../../include/openssl/pkcs7.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/pkcs7' making links in crypto/pkcs12... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/pkcs12' pkcs12.h => ../../include/openssl/pkcs12.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/pkcs12' making links in crypto/comp... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/comp' comp.h => ../../include/openssl/comp.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/comp' making links in crypto/ocsp... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/ocsp' ocsp.h => ../../include/openssl/ocsp.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/ocsp' making links in crypto/ui... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/ui' ui.h => ../../include/openssl/ui.h ui_compat.h => ../../include/openssl/ui_compat.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/ui' making links in crypto/krb5... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/krb5' krb5_asn.h => ../../include/openssl/krb5_asn.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/krb5' making links in crypto/cms... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/cms' cms.h => ../../include/openssl/cms.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/cms' making links in crypto/pqueue... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/pqueue' pqueue.h => ../../include/openssl/pqueue.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/pqueue' making links in crypto/ts... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/ts' ts.h => ../../include/openssl/ts.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/ts' making links in crypto/srp... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/srp' srp.h => ../../include/openssl/srp.h srptest.c => ../../test/srptest.c make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/srp' making links in crypto/cmac... make[2]: Entering directory '/.../openssl-1.0.2e/crypto/cmac' cmac.h => ../../include/openssl/cmac.h make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/cmac' make[1]: Leaving directory '/.../openssl-1.0.2e/crypto' making links in ssl... make[1]: Entering directory '/.../openssl-1.0.2e/ssl' ssl.h => ../include/openssl/ssl.h ssl2.h => ../include/openssl/ssl2.h ssl3.h => ../include/openssl/ssl3.h ssl23.h => ../include/openssl/ssl23.h tls1.h => ../include/openssl/tls1.h dtls1.h => ../include/openssl/dtls1.h kssl.h => ../include/openssl/kssl.h srtp.h => ../include/openssl/srtp.h ssltest.c => ../test/ssltest.c heartbeat_test.c => ../test/heartbeat_test.c clienthellotest.c => ../test/clienthellotest.c make[1]: Leaving directory '/.../openssl-1.0.2e/ssl' making links in engines... make[1]: Entering directory '/.../openssl-1.0.2e/engines' making links in engines/ccgost... make[2]: Entering directory '/.../openssl-1.0.2e/engines/ccgost' make[2]: Nothing to be done for 'links'. make[2]: Leaving directory '/.../openssl-1.0.2e/engines/ccgost' make[1]: Leaving directory '/.../openssl-1.0.2e/engines' making links in apps... make[1]: Entering directory '/.../openssl-1.0.2e/apps' make[1]: Nothing to be done for 'links'. make[1]: Leaving directory '/.../openssl-1.0.2e/apps' making links in test... make[1]: Entering directory '/.../openssl-1.0.2e/test' make[1]: Nothing to be done for 'links'. make[1]: Leaving directory '/.../openssl-1.0.2e/test' making links in tools... make[1]: Entering directory '/.../openssl-1.0.2e/tools' make[1]: Nothing to be done for 'links'. make[1]: Leaving directory '/.../openssl-1.0.2e/tools' generating dummy tests (if needed)... make[1]: Entering directory '/.../openssl-1.0.2e/test' md2test.c => dummytest.c rc5test.c => dummytest.c jpaketest.c => dummytest.c make[1]: Leaving directory '/.../openssl-1.0.2e/test' Configured for linux-armv4. _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Dec 22 13:15:32 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 22 Dec 2015 13:15:32 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: <35ef115027374dea901dee71d12072cd@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5678F551.8000406@roumenpetrov.info> <35ef115027374dea901dee71d12072cd@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: I don't know that I would call it a regression, but rather a difference. :) I'll fix the summary but not the old uncommon behavior. From levitte at openssl.org Tue Dec 22 13:52:43 2015 From: levitte at openssl.org (Richard Levitte) Date: Tue, 22 Dec 2015 14:52:43 +0100 (CET) Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published In-Reply-To: <20151222134741.72034a0b79m0zmul@www.polarhome.com> References: <20151222122349.916552ojkzhe5sqt@www.polarhome.com> <20151222.125006.191704225380070406.levitte@openssl.org> <20151222134741.72034a0b79m0zmul@www.polarhome.com> Message-ID: <20151222.145243.137914380935727041.levitte@openssl.org> In message <20151222134741.72034a0b79m0zmul at www.polarhome.com> on Tue, 22 Dec 2015 13:47:41 +0100, Zoltan Arpadffy said: zoli> Hi, zoli> zoli> > zoli> > (unfortunately, "cpan install Text::Template" doesn't work zoli> > because zoli> > zoli> > there's a lack of action lines in the test: target it its zoli> > Makefile, zoli> > zoli> > and mms isn't too happy about that...) zoli> zoli> > That's tough, unfortunately... I've only access to a V8.4 cluster zoli> > (Alpha and IA64), so I don't know how to help you further. Of course, zoli> > there's the option to build perl from source, which isn't very hard at zoli> > all (I've done so a few times). zoli> zoli> I do have access to VAX, Alpha and IA64 architectures... on range of zoli> 7.3 to 8.3 OpenVMS versions. zoli> Also I do have functional perl installed on them. zoli> I am not the problem here, but ordinary developers that work on an old zoli> system developing for a legacy program and do not have SYSTEM rights - zoli> what is the common case. zoli> The build solution should be designed to be usable by those developers zoli> too. Is perl still that uncommon on VMS? I'm sorry to say that's gonna be tough, then. Just as an example, the old test scripts are gone, and have been replaced with Test::More / Test::Harness recipes, and I'm pretty sure VMS devs who're building OpenSSL are just as eager to run the test scripts as anyone. I could argue that for a developer to work, he/she needs a functional development environment. In this day and age, that should include perl. Pressure on the sysadmin! (having been a VMS sysadmin, I'm saying that very much toungue in cheak ;-)) zoli> > Well, the aim is to have a common structure to build from on all zoli> > architectures we claim to support. You've seen for yourself how the zoli> > scripts for VMS builds were lagging behind, and quite frankly, it's zoli> > hellish to keep them up to date (I've completely dropped the ball for zoli> > 1.1). That's not something I'm willing to have us do all over again. zoli> zoli> Absolutely agree with you. This is the way forward. Good :-) zoli> May I ask you, if the new build will cover the long names issue ( zoli> symhacks.h ) too? It's been pointed out to me by the vms-ports folks that it should be possible to solve using the compiler's "#pragma names shortened" rather than maintaining symhacks... Then, it's just a matter of doing the same thing manually when producing the SYMBOL_VECTOR for a shareable image. I'm also thinking that "#pragma names as_is" should be norm and that we could produce upper case aliases in SYMBOL_VECTOR (you know how that's done, right?). Does that sound like a way forward to you? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From zoli at polarhome.com Tue Dec 22 14:34:37 2015 From: zoli at polarhome.com (Zoltan Arpadffy) Date: Tue, 22 Dec 2015 15:34:37 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published In-Reply-To: <20151222.145243.137914380935727041.levitte@openssl.org> References: <20151222122349.916552ojkzhe5sqt@www.polarhome.com> <20151222.125006.191704225380070406.levitte@openssl.org> <20151222134741.72034a0b79m0zmul@www.polarhome.com> <20151222.145243.137914380935727041.levitte@openssl.org> Message-ID: <20151222153437.192023un5jh69v25@www.polarhome.com> Hi, > zoli> May I ask you, if the new build will cover the long names issue ( > zoli> symhacks.h ) too? > > It's been pointed out to me by the vms-ports folks that it should be > possible to solve using the compiler's "#pragma names shortened" > rather than maintaining symhacks... Then, it's just a matter of doing > the same thing manually when producing the SYMBOL_VECTOR for a > shareable image. I'm also thinking that "#pragma names as_is" should > be norm and that we could produce upper case aliases in SYMBOL_VECTOR > (you know how that's done, right?). Does that sound like a way > forward to you? It is not my decision, but I don't like either of these approaches. The code itself needs to be written that it is as much as possible portable. It is not impossible to maintain a code base that uses up to 32 char long function names - without losing the readability of the code. I agree that it requires some extra focus from the developers side - but coding a security software needs that (and even more) focus anyway. Thanks, Z --- WebMail, polarhome.com From rsalz at akamai.com Tue Dec 22 14:41:16 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 22 Dec 2015 14:41:16 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published In-Reply-To: <20151222153437.192023un5jh69v25@www.polarhome.com> References: <20151222122349.916552ojkzhe5sqt@www.polarhome.com> <20151222.125006.191704225380070406.levitte@openssl.org> <20151222134741.72034a0b79m0zmul@www.polarhome.com> <20151222.145243.137914380935727041.levitte@openssl.org> <20151222153437.192023un5jh69v25@www.polarhome.com> Message-ID: > It is not impossible to maintain a code base that uses up to 32 char long > function names - without losing the readability of the code. > I agree that it requires some extra focus from the developers side - but > coding a security software needs that (and even more) focus anyway. Yes, but symbol names are a distraction from the main focus of security. Many of the >32 char names are auto-generated via #define's an ASN1 parsing. Most of the others follow common convention used elsewhere in the code. Consistency is more important than support for old platforms :) From levitte at openssl.org Tue Dec 22 14:49:01 2015 From: levitte at openssl.org (Richard Levitte) Date: Tue, 22 Dec 2015 15:49:01 +0100 (CET) Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published In-Reply-To: <20151222153437.192023un5jh69v25@www.polarhome.com> References: <20151222134741.72034a0b79m0zmul@www.polarhome.com> <20151222.145243.137914380935727041.levitte@openssl.org> <20151222153437.192023un5jh69v25@www.polarhome.com> Message-ID: <20151222.154901.1731330255701806309.levitte@openssl.org> In message <20151222153437.192023un5jh69v25 at www.polarhome.com> on Tue, 22 Dec 2015 15:34:37 +0100, Zoltan Arpadffy said: zoli> Hi, zoli> zoli> > zoli> May I ask you, if the new build will cover the long names issue zoli> > ( zoli> > zoli> symhacks.h ) too? zoli> > zoli> > It's been pointed out to me by the vms-ports folks that it should be zoli> > possible to solve using the compiler's "#pragma names shortened" zoli> > rather than maintaining symhacks... Then, it's just a matter of doing zoli> > the same thing manually when producing the SYMBOL_VECTOR for a zoli> > shareable image. I'm also thinking that "#pragma names as_is" should zoli> > be norm and that we could produce upper case aliases in SYMBOL_VECTOR zoli> > (you know how that's done, right?). Does that sound like a way zoli> > forward to you? zoli> zoli> It is not my decision, but I don't like either of these approaches. zoli> zoli> The code itself needs to be written that it is as much as possible zoli> portable. In the end, this is a LINKER vs rest of the world issue. In this day and age, the 31 char limitation is a bit aged, and LINKER should really be updated to allow longer symbol names. If nothing else, C++ symbol munging would require it. I certainly hope VSI receives the messages and starts dealing with it. Either way, we're dealing with C, with case sensitive symbols and symbols longer than 31 chars. The names pragmas are helpful portability tools, the smoothest at this point is to put them to good use. zoli> It is not impossible to maintain a code base that uses up to 32 char zoli> long function names - without losing the readability of the code. zoli> I agree that it requires some extra focus from the developers side - zoli> but coding a security software needs that (and even more) focus zoli> anyway. That can certainly be argued... Again, that's more of a LINKER issue than anything else. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Tue Dec 22 14:51:43 2015 From: levitte at openssl.org (Richard Levitte) Date: Tue, 22 Dec 2015 15:51:43 +0100 (CET) Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published In-Reply-To: References: <20151222.145243.137914380935727041.levitte@openssl.org> <20151222153437.192023un5jh69v25@www.polarhome.com> Message-ID: <20151222.155143.2026935875883838593.levitte@openssl.org> In message on Tue, 22 Dec 2015 14:41:16 +0000, "Salz, Rich" said: rsalz> Consistency is more important than support for old platforms :) Side note: I'd like it if we skipped the age slurs, especially since we're commonly working on operating systems that come from a decade more history than VMS. ;-) Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Tue Dec 22 17:02:07 2015 From: rt at openssl.org (Short, Todd via RT) Date: Tue, 22 Dec 2015 17:02:07 +0000 Subject: [openssl-dev] [openssl.org #4197] [PATCH] Memory leak in state machine in error path In-Reply-To: References: Message-ID: Hello OpenSSL org: I found the following issue via code inspection. In tls_process_client_key_exchange(), when EC is disabled, and an error occurs in ssl_generate_master_secret() or RAND_bytes(), the error path does not free rsa_decrypt. Note that rsa_decrypt is not conditionally defined by OPENSSL_NO_RSA, so I did not wrap the free with that conditional. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Memory-leak-in-state-machine-in-error-path.patch Type: application/octet-stream Size: 927 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Dec 23 03:54:19 2015 From: rt at openssl.org (Dave Baggett via RT) Date: Wed, 23 Dec 2015 03:54:19 +0000 Subject: [openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake In-Reply-To: References: Message-ID: Openssl Version 1.1.0 (master as of 22-DEC-15) Mac OS X 10.11.2 Connection to my SMTP server, which has a 4096-bit RSA key, fails with: Traceback (most recent call last): File "tls/_openssl.py", line 359, in handshake error: [Errno 5] 1: TLS handshake with server peer failed: error:14160098:SSL routines:READ_STATE_MACHINE:excessive message size Note that this is via my own Python C extension. However, this connection succeeds with openssl 1.0.2. This appears to be a reappearance of this bug: https://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=319 Dave Sent with inky -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Dec 23 11:04:33 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 23 Dec 2015 11:04:33 +0000 Subject: [openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake In-Reply-To: References: Message-ID: On Wed Dec 23 03:54:19 2015, dmb at inky.com wrote: > Openssl Version 1.1.0 (master as of 22-DEC-15) > Mac OS X 10.11.2 > > Connection to my SMTP server, which has a 4096-bit RSA key, fails > with: > > Traceback (most recent call last): > File "tls/_openssl.py", line 359, in handshake > error: [Errno 5] 1: TLS handshake with server peer failed: > error:14160098:SSL routines:READ_STATE_MACHINE:excessive message size I've just tried this with s_server/s_client and a 4096 bit RSA key and I am unable to recreate this issue. Are you able to send a wireshark packet capture? Thanks Matt From rt at openssl.org Wed Dec 23 13:36:49 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 23 Dec 2015 13:36:49 +0000 Subject: [openssl-dev] [openssl.org #4197] [PATCH] Memory leak in state machine in error path In-Reply-To: References: Message-ID: On Tue Dec 22 17:02:07 2015, tshort at akamai.com wrote: > Hello OpenSSL org: > > I found the following issue via code inspection. In > tls_process_client_key_exchange(), when EC is disabled, and an error > occurs in ssl_generate_master_secret() or RAND_bytes(), the error path > does not free rsa_decrypt. Patch applied. Many thanks. Matt From deengert at gmail.com Wed Dec 23 14:14:09 2015 From: deengert at gmail.com (Douglas E Engert) Date: Wed, 23 Dec 2015 08:14:09 -0600 Subject: [openssl-dev] extra data for ec keys In-Reply-To: <567903B6.9070805@roumenpetrov.info> References: <567903B6.9070805@roumenpetrov.info> Message-ID: <567AAC31.4020904@gmail.com> An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Dec 23 15:25:51 2015 From: rt at openssl.org (Dave Baggett via RT) Date: Wed, 23 Dec 2015 15:25:51 +0000 Subject: [openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake In-Reply-To: <1a5m-xgq6VvKNmAJFEJeAWfNwQ9O6geGVi2Mz9SJXLvwUS4RI@outlook.office365.com> References: <1a5m-xgq6VvKNmAJFEJeAWfNwQ9O6geGVi2Mz9SJXLvwUS4RI@outlook.office365.com> Message-ID: OK, let me rebuild against 1.1 and see if I can get you a reproducer or, failing that, a wireshark dump. Dave Sent with inky "Matt Caswell via RT" wrote: On Wed Dec 23 03:54:19 2015, dmb at inky.com wrote: > Openssl Version 1.1.0 (master as of 22-DEC-15) > Mac OS X 10.11.2 > > Connection to my SMTP server, which has a 4096-bit RSA key, fails > with: > > Traceback (most recent call last): > File "tls/_openssl.py", line 359, in handshake > error: [Errno 5] 1: TLS handshake with server peer failed: > error:14160098:SSL routines:READ_STATE_MACHINE:excessive message size I've just tried this with s_server/s_client and a 4096 bit RSA key and I am unable to recreate this issue. Are you able to send a wireshark packet capture? Thanks Matt From rt at openssl.org Wed Dec 23 15:42:54 2015 From: rt at openssl.org (Dave Baggett via RT) Date: Wed, 23 Dec 2015 15:42:54 +0000 Subject: [openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake In-Reply-To: References: Message-ID: Using the current master (head) code, this reproduces it: openssl s_client -connect mail.baggett.org:465 This is my own personal mail server, so feel free to poke and prod it. Dave Sent with inky "Matt Caswell via RT" wrote: On Wed Dec 23 03:54:19 2015, dmb at inky.com wrote: > Openssl Version 1.1.0 (master as of 22-DEC-15) > Mac OS X 10.11.2 > > Connection to my SMTP server, which has a 4096-bit RSA key, fails > with: > > Traceback (most recent call last): > File "tls/_openssl.py", line 359, in handshake > error: [Errno 5] 1: TLS handshake with server peer failed: > error:14160098:SSL routines:READ_STATE_MACHINE:excessive message size I've just tried this with s_server/s_client and a 4096 bit RSA key and I am unable to recreate this issue. Are you able to send a wireshark packet capture? Thanks Matt From rt at openssl.org Wed Dec 23 16:48:20 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 23 Dec 2015 16:48:20 +0000 Subject: [openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake In-Reply-To: References: Message-ID: On Wed Dec 23 15:42:54 2015, dmb at inky.com wrote: > Using the current master (head) code, this reproduces it: > > openssl s_client -connect mail.baggett.org:465 > > This is my own personal mail server, so feel free to poke and prod it. > Great, thanks. I can reproduce this now. The problem is that the server has been configured to allow client auth. The CertificateRequest message coming from the server seems very long (nearly 20k). This is primarily made up of a long list of acceptable CA names. The master code has the max size limit for this message as being SSL3_RT_MAX_PLAIN_LENGTH (16384 bytes). This is the maximum that can be put into a single TLS record. Previous versions had it set to s->max_cert_list which is a configurable value that by default is 100k. The attached patch should resolve this issue (it just reverts the size limit to what it was before). Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: cert-req-size.patch Type: text/x-patch Size: 1422 bytes Desc: not available URL: From openssl-users at dukhovni.org Wed Dec 23 17:21:09 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 23 Dec 2015 17:21:09 +0000 Subject: [openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake In-Reply-To: References: Message-ID: <20151223172108.GS18704@mournblade.imrryr.org> On Wed, Dec 23, 2015 at 04:48:20PM +0000, Matt Caswell via RT wrote: > The problem is that the server has been configured to allow client auth. The > CertificateRequest message coming from the server seems very long (nearly 20k). > This is primarily made up of a long list of acceptable CA names. Probably the entire CA bundle was loaded into memory as a CAfile, rather than as a CApath, and now the server is spewing out a complete list of the DNs of its trusted CAs on every connection. I am very tempted to say that this misconfiguration *should fail, it is far better to send an *empty* list of trusted CAs than send the Vladivostok phone directory. > The master code has the max size limit for this message as being > SSL3_RT_MAX_PLAIN_LENGTH (16384 bytes). This is the maximum that can be put > into a single TLS record. Previous versions had it set to s->max_cert_list > which is a configurable value that by default is 100k. > > The attached patch should resolve this issue (it just reverts the size limit to > what it was before). Perhaps OpenSSL should suppress the default use of the contents of CAfile as a list of DNs to send in certificate requests when that list is longer than say 16 elements. Applications can explicitly specify the list of CAs for the client certificate request as needed. Sending the whole bundle to every client is not a good idea. The empty list works much better in every respect. We could set the limit to 0 instead of the arbitrary 16, thereby requiring the list of client auth CAs to always be set explicitly. With any luck as a result a lot fewer applications will end up sending the phone directory. -- Viktor. From rsalz at akamai.com Wed Dec 23 17:26:42 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 23 Dec 2015 17:26:42 +0000 Subject: [openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake In-Reply-To: <20151223172108.GS18704@mournblade.imrryr.org> References: <20151223172108.GS18704@mournblade.imrryr.org> Message-ID: <8ed59cdab90d455ea62155d52b3f194a@usma1ex-dag1mb1.msg.corp.akamai.com> > I am very tempted to say that this misconfiguration *should fail, it is far > better to send an *empty* list of trusted CAs than send the Vladivostok > phone directory. Agree. From rt at openssl.org Wed Dec 23 17:29:49 2015 From: rt at openssl.org (S. Robert Elman via RT) Date: Wed, 23 Dec 2015 17:29:49 +0000 Subject: [openssl-dev] [openssl.org #4199] Fwd: OpenSSL build for 64-bit Cygwin using "config" script In-Reply-To: References: Message-ID: I sent the following report/fix to apache at apache.org (following the comment in the script being patched) and got a response indicating I probably should have sent it to rt at openssl.org. I was attempting to do a build of OpenSSL 1.0.2e under 64-bit Cygwin. The attachment is a context diff for the build script 'config' that enables such a build to succeed. ---------- Forwarded message ---------- From: S. Robert Elman Date: Wed, Dec 23, 2015 at 4:02 PM Subject: OpenSSL build for 64-bit Cygwin using "config" script To: jim at jagunet.com Cc: apache at apache.org ? To do a 64-bit Cygwin build of OpenSSL using the 'config' script, we need to add an appropriate line. Here's a context diff showing the fix as an addition: *** 853,856 **** --- 853,857 ---- mips-sony-newsos4) OUT="newsos4-gcc" ;; *-*-cygwin_pre1.3) OUT="Cygwin-pre1.3" ;; + x86_64-*-cygwin) OUT="Cygwin-x86_64" ;; *-*-cygwin) OUT="Cygwin" ;; t3e-cray-unicosmk) OUT="cray-t3e" ;; Without this fix, it tries to do a "Cygwin", i.e., 32-bit, build in which gcc complains that the -march=i486 option is incompatible with a 64-bit build. The build works fine with this one-line addition to file config. Bob Elman Principal Engineer Elcadom, Ltd. -------------- next part -------------- *** 853,856 **** --- 853,857 ---- mips-sony-newsos4) OUT="newsos4-gcc" ;; *-*-cygwin_pre1.3) OUT="Cygwin-pre1.3" ;; + x86_64-*-cygwin) OUT="Cygwin-x86_64" ;; *-*-cygwin) OUT="Cygwin" ;; t3e-cray-unicosmk) OUT="cray-t3e" ;; -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From beldmit at gmail.com Wed Dec 23 18:40:35 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 23 Dec 2015 21:40:35 +0300 Subject: [openssl-dev] Variable length of digest Message-ID: Hello OpenSSL Team, I have a question. I need to implement a digest with variable length of output. The length of output can be easily specified by the control function, but EVP functions expect the constant length of the digest result. Is there a good solution how to fix it and will the patch providing such a solution be acceptable? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Dec 23 19:44:59 2015 From: rt at openssl.org (Dave Baggett via RT) Date: Wed, 23 Dec 2015 19:44:59 +0000 Subject: [openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake In-Reply-To: <9nnLt0xZ93sKmm4t3E0eIW1K92p-JgYGOi6M39qJ8LiwaUTIg@outlook.office365.com> References: <9nnLt0xZ93sKmm4t3E0eIW1K92p-JgYGOi6M39qJ8LiwaUTIg@outlook.office365.com> Message-ID: Thanks! Sent with inky "Matt Caswell via RT" wrote: On Wed Dec 23 15:42:54 2015, dmb at inky.com wrote: > Using the current master (head) code, this reproduces it: > > openssl s_client -connect mail.baggett.org:465 > > This is my own personal mail server, so feel free to poke and prod it. > Great, thanks. I can reproduce this now. The problem is that the server has been configured to allow client auth. The CertificateRequest message coming from the server seems very long (nearly 20k). This is primarily made up of a long list of acceptable CA names. The master code has the max size limit for this message as being SSL3_RT_MAX_PLAIN_LENGTH (16384 bytes). This is the maximum that can be put into a single TLS record. Previous versions had it set to s->max_cert_list which is a configurable value that by default is 100k. The attached patch should resolve this issue (it just reverts the size limit to what it was before). Matt From rt at openssl.org Wed Dec 23 19:45:15 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Wed, 23 Dec 2015 19:45:15 +0000 Subject: [openssl-dev] [openssl.org #4155] In function int_thread_del_item, when hash == int_thread_hash, one is passed to free and the other is used in a comparison In-Reply-To: <20151223194522.GA21623@roeckx.be> References: <20151130201253.GA22084@roeckx.be> <20151223194522.GA21623@roeckx.be> Message-ID: On Mon, Nov 30, 2015 at 08:12:58PM +0000, Kurt Roeckx via RT wrote: > On Tue, Nov 24, 2015 at 11:06:44AM +0000, Pascal Cuoq via RT wrote: > > This issue is similar in nature to 4151 (http://www.mail-archive.com/openssl-dev at openssl.org/msg40950.html ): it is about a dangling pointer being used, but not used for dereferencing, so it's not a memory error. The dangling pointer is used in a comparison. > > > > The function int_thread_del_item can reach the point were it calls "lh_ERR_STATE_free(int_thread_hash);" with hash == int_thread_hash. That attached patch prints a message like "hash == int_thread_hash == 0xb2a6d0" when this happens. Just after the call to lh_ERR_STATE_free, both hash and int_thread_hash contain dangling pointers. The variable int_thread_hash is immediately set to NULL. > > > > The problem that I am reporting is that just afterwards, &hash is passed to the function int_thread_release: > > > > https://github.com/openssl/openssl/blob/079a1a9014b89661f0a612a5a9724ad9c77f21a3/crypto/err/err.c#L412 > > > > In that function, the argument "hash" points to the local variable "hash" of int_thread_del_item (which contains a dangling pointer). > > Thus the comparison "*hash == NULL" involves a dangling pointer: > > I think the following untested patch should fix that: The patch has been applied. Kurt From rt at openssl.org Wed Dec 23 19:45:30 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Wed, 23 Dec 2015 19:45:30 +0000 Subject: [openssl-dev] [openssl.org #4195] remove duplicates in util/libeay.num In-Reply-To: <20151223194545.GB21623@roeckx.be> References: <567911F7.40403@roumenpetrov.info> <20151223194545.GB21623@roeckx.be> Message-ID: On Tue, Dec 22, 2015 at 09:03:56AM +0000, Roumen Petrov via RT wrote: > Hello, > > After remove of some global variables in export file left double Patch applied. Kurt From kurt at roeckx.be Wed Dec 23 19:46:09 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 23 Dec 2015 20:46:09 +0100 Subject: [openssl-dev] __STDC_VERSION__ is not defined In-Reply-To: <5678FFDD.6020807@roumenpetrov.info> References: <5678FFDD.6020807@roumenpetrov.info> Message-ID: <20151223194609.GC21623@roeckx.be> On Tue, Dec 22, 2015 at 09:46:37AM +0200, Roumen Petrov wrote: > Hello, > > Compilation of an application with current master branch and c89 compiler > produce a lot of warnings. > Proposed patch > "0001-__STDC_VERSION__-is-not-defined-for-c89-compilers.patch" fix them. Patch applied. Kurt From kurt at roeckx.be Wed Dec 23 19:47:48 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 23 Dec 2015 20:47:48 +0100 Subject: [openssl-dev] about "Rename some BUF_xxx to OPENSSL_xxx" In-Reply-To: <56790125.2050304@roumenpetrov.info> References: <56790125.2050304@roumenpetrov.info> Message-ID: <20151223194748.GD21623@roeckx.be> On Tue, Dec 22, 2015 at 09:52:05AM +0200, Roumen Petrov wrote: > Hello, > > After modification OPENSSL_strlcpy is declared twice. Patch applied. Kurt From rt at openssl.org Wed Dec 23 21:36:36 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Wed, 23 Dec 2015 21:36:36 +0000 Subject: [openssl-dev] [openssl.org #4192] [PATCH] differentiate SSL_* from from SSL_CTX_* in documentation In-Reply-To: <20151223213649.GA1851@roeckx.be> References: <1450644911-16118-1-git-send-email-dkg@fifthhorseman.net> <20151223213649.GA1851@roeckx.be> Message-ID: The SSL_CTX_set1_verify_cert_store.pod changes have been applied in the master and 1.0.2 branch, doesn't exist in other branches. SSL_set_tmp_rsa_callback has been removed, so I didn't fix that. Kurt From rsalz at akamai.com Wed Dec 23 21:37:36 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 23 Dec 2015 21:37:36 +0000 Subject: [openssl-dev] extra data for ec keys In-Reply-To: <567903B6.9070805@roumenpetrov.info> References: <567903B6.9070805@roumenpetrov.info> Message-ID: <1063e197a7bc440eae6d15d7cc2cf9f4@usma1ex-dag1mb1.msg.corp.akamai.com> > Proposed patch "0008-extra-data-for-EC_KEY.patch" - note that index > CRYPTO_EX_INDEX is with gap in numbering but I would like patch to be > minimal. Yeah, I'll fix that. > I would like to request external applications to be able to change method - > see attached patch "0009-access-EC_KEY-method-property.patch". Can you say how this would be used? Since the key method is opaque... From steve at openssl.org Wed Dec 23 22:18:55 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 23 Dec 2015 22:18:55 +0000 Subject: [openssl-dev] Variable length of digest In-Reply-To: References: Message-ID: <20151223221855.GA10957@openssl.org> On Wed, Dec 23, 2015, Dmitry Belyavsky wrote: > Hello OpenSSL Team, > > I have a question. > > I need to implement a digest with variable length of output. The length of > output can be easily specified by the control function, but EVP functions > expect the constant length of the digest result. > > Is there a good solution how to fix it and will the patch providing such a > solution be acceptable? > That's an interesting question. What digest requires this? Is the output length arbitrary or do the standards specify a maximum size? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From openssl-users at dukhovni.org Wed Dec 23 22:37:57 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 23 Dec 2015 22:37:57 +0000 Subject: [openssl-dev] Variable length of digest In-Reply-To: <20151223221855.GA10957@openssl.org> References: <20151223221855.GA10957@openssl.org> Message-ID: <20151223223757.GX18704@mournblade.imrryr.org> On Wed, Dec 23, 2015 at 10:18:55PM +0000, Dr. Stephen Henson wrote: > That's an interesting question. What digest requires this? Is the output > length arbitrary or do the standards specify a maximum size? With SHA3, NIST differentiates between fixed-length hash functions and variable-length XOFs. Introduction of variable length digests into OpenSSL would break applications that expect the EVP_MD family of functions to produce fixed length (input data indepdendent) results. If there's a new construct whose output size depends on the input data, that probably requires a new family of functions. -- Viktor. From beldmit at gmail.com Thu Dec 24 07:45:37 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 24 Dec 2015 10:45:37 +0300 Subject: [openssl-dev] Variable length of digest In-Reply-To: <20151223223757.GX18704@mournblade.imrryr.org> References: <20151223221855.GA10957@openssl.org> <20151223223757.GX18704@mournblade.imrryr.org> Message-ID: Dear Stephen and Victor, On Thu, Dec 24, 2015 at 1:37 AM, Viktor Dukhovni wrote: > On Wed, Dec 23, 2015 at 10:18:55PM +0000, Dr. Stephen Henson wrote: > > > That's an interesting question. What digest requires this? Is the output > > length arbitrary or do the standards specify a maximum size? > I mean the gost-mac digest (implemented in the ccgost engine, engines/ccgost/gost_crypt.c). It allows the output to vary from 1 to 8 bytes, though 4 bytes is the most common value. We've added the control values implementing the variable length in our repository (https://github.com/gost-engine/engine) > > With SHA3, NIST differentiates between fixed-length hash functions > and variable-length XOFs. > > Introduction of variable length digests into OpenSSL would break > applications that expect the EVP_MD family of functions to produce > fixed length (input data indepdendent) results. > > If there's a new construct whose output size depends on the input > data, that probably requires a new family of functions. > Well, the gost-mac is treated specially itself and may be it can be simplified introducing the new construction. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Dec 24 08:00:08 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 24 Dec 2015 08:00:08 +0000 Subject: [openssl-dev] Variable length of digest In-Reply-To: References: <20151223221855.GA10957@openssl.org> <20151223223757.GX18704@mournblade.imrryr.org> Message-ID: <20151224080008.GB18704@mournblade.imrryr.org> On Thu, Dec 24, 2015 at 10:45:37AM +0300, Dmitry Belyavsky wrote: > > > That's an interesting question. What digest requires this? Is the output > > > length arbitrary or do the standards specify a maximum size? > > I mean the gost-mac digest (implemented in the ccgost engine, > engines/ccgost/gost_crypt.c). > It allows the output to vary from 1 to 8 bytes, though 4 bytes is the most > common value. This is surely much too short to be a stand-alone cryptographic hash algorithm. It sounds more like a mac for an AEAD construction, in which case EVP_MD is not the right interface I think. Would this be better handled as a new block cipher "mode"? What sort of beast is this, and what actually determines the length? -- Viktor. From vitus at wagner.pp.ru Thu Dec 24 08:02:15 2015 From: vitus at wagner.pp.ru (Victor Wagner) Date: Thu, 24 Dec 2015 11:02:15 +0300 Subject: [openssl-dev] Variable length of digest In-Reply-To: References: <20151223221855.GA10957@openssl.org> <20151223223757.GX18704@mournblade.imrryr.org> Message-ID: <20151224110215.1cf02234@fafnir.local.vm> On Thu, 24 Dec 2015 10:45:37 +0300 Dmitry Belyavsky wrote: > > > > If there's a new construct whose output size depends on the input > > data, that probably requires a new family of functions. > > > > Well, the gost-mac is treated specially itself and may be it can be > simplified introducing the new construction. Really it is MAC. I.e. it is combination of digest and pkey algorithms, and digest itself is never seen by any application. Applications only access MAC value via EVP_DigestSignFinal interface. And it already allows variable size of signature. From beldmit at gmail.com Thu Dec 24 08:24:37 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 24 Dec 2015 11:24:37 +0300 Subject: [openssl-dev] Variable length of digest In-Reply-To: <20151224110215.1cf02234@fafnir.local.vm> References: <20151223221855.GA10957@openssl.org> <20151223223757.GX18704@mournblade.imrryr.org> <20151224110215.1cf02234@fafnir.local.vm> Message-ID: Dear Victor, On Thu, Dec 24, 2015 at 11:02 AM, Victor Wagner wrote: > On Thu, 24 Dec 2015 10:45:37 +0300 > Dmitry Belyavsky wrote: > > > > > > > > If there's a new construct whose output size depends on the input > > > data, that probably requires a new family of functions. > > > > > > > Well, the gost-mac is treated specially itself and may be it can be > > simplified introducing the new construction. > > Really it is MAC. I.e. it is combination of digest and pkey algorithms, > and digest itself is never seen by any application. Applications only > access MAC value via EVP_DigestSignFinal interface. And it already > allows variable size of signature. > If you try to change the output length via the -macopt option of the dgst command, you'll see that the text output will be 4 bytes. It seems to happen because of the internal call to the EVP_MD_size() function. If we change the EVP_MD_CTX_size() definition from a macro to a function trying to call the ctrl function and then to fallback to the result of the EVP_MD_size() function, it should improve the situation. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu Dec 24 08:40:37 2015 From: rt at openssl.org (Roumen Petrov via RT) Date: Thu, 24 Dec 2015 08:40:37 +0000 Subject: [openssl-dev] [openssl.org #4200] extra data for ec keys In-Reply-To: <567BAF78.8070608@roumenpetrov.info> References: <567903B6.9070805@roumenpetrov.info> <8a62b93b720d42b4a295bd51ba8fbd5e@usma1ex-dag1mb1.msg.corp.akamai.com> <567BAF78.8070608@roumenpetrov.info> Message-ID: Update patch sent to request tracker - without gap for CRYPTO_EX_INDEX Salz, Rich wrote: >> External cryptographic modules may store addition information to key. >> What about to define CRYPTO_EX_DATA for ec keys? > That is the plan -- we will remove EX_EX_DATA and the internal API and just use the standard crypto_ex_data stuff. Want to make a more complete patch as a github pull request? :) Otherwise I'll get to it soon. > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-extra-data-for-EC_KEY.patch Type: text/x-diff Size: 3827 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From a.yousar at informatik.hu-berlin.de Thu Dec 24 08:54:02 2015 From: a.yousar at informatik.hu-berlin.de (Ann) Date: Thu, 24 Dec 2015 09:54:02 +0100 Subject: [openssl-dev] Variable length of digest In-Reply-To: <20151223221855.GA10957@openssl.org> References: <20151223221855.GA10957@openssl.org> Message-ID: <567BB2AA.8010807@informatik.hu-berlin.de> Am 23.12.2015 um 23:18 schrieb Dr. Stephen Henson: > That's an interesting question. What digest requires this? Is the output > length arbitrary or do the standards specify a maximum size? > > Is e.g. SHA-512/t (see 5.3.6 of FIPS 180-4) an appropriate example? Here t is any positive integer without a leading zero such that t< 512, and t is not 384. /Ann. From openssl at roumenpetrov.info Thu Dec 24 10:28:46 2015 From: openssl at roumenpetrov.info (Roumen Petrov) Date: Thu, 24 Dec 2015 12:28:46 +0200 Subject: [openssl-dev] access-EC_KEY-method-property In-Reply-To: <1063e197a7bc440eae6d15d7cc2cf9f4@usma1ex-dag1mb1.msg.corp.akamai.com> References: <567903B6.9070805@roumenpetrov.info> <1063e197a7bc440eae6d15d7cc2cf9f4@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <567BC8DE.4090000@roumenpetrov.info> Salz, Rich wrote: > [SNIP] >> I would like to request external applications to be able to change method - >> see attached patch "0009-access-EC_KEY-method-property.patch". > Can you say how this would be used? Since the key method is opaque... Yes but a number of functions (see below) allow implementation as external to openssl cryptographic module: $ grep EC_KEY_ME util/libeay.num EC_KEY_METHOD_set_compute_key 5060 1_1_0 EXIST::FUNCTION:EC EC_KEY_METHOD_set_verify 5064 1_1_0 EXIST::FUNCTION:EC EC_KEY_METHOD_set_init 5065 1_1_0 EXIST::FUNCTION:EC EC_KEY_METHOD_get_init 5071 1_1_0 EXIST::FUNCTION:EC EC_KEY_METHOD_get_keygen 5072 1_1_0 EXIST::FUNCTION:EC EC_KEY_METHOD_free 5073 1_1_0 EXIST::FUNCTION:EC EC_KEY_METHOD_new 5074 1_1_0 EXIST::FUNCTION:EC EC_KEY_METHOD_set_sign 5076 1_1_0 EXIST::FUNCTION:EC EC_KEY_METHOD_set_keygen 5078 1_1_0 EXIST::FUNCTION:EC EC_KEY_METHOD_get_verify 5079 1_1_0 EXIST::FUNCTION:EC EC_KEY_METHOD_get_sign 5081 1_1_0 EXIST::FUNCTION:EC EC_KEY_METHOD_get_compute_key 5082 1_1_0 EXIST::FUNCTION:EC I have working prototype that use... _new, ..._init, ..._sing and ..._verify. A cryptographic module (engine) could be registered a method as default. In general engine that use externally stored keys should refuse to be register methods as default. Lets engine load method use d2i_PUBKEY to decode "external" der encoded public key. Result is EVP_KEY with KEY(public) with default method. 1) If default method match engine method then application could register(associate) extra data with key and to finish loading. 2) If methods differ then application: a) could create new key with FOO_new_method(ENGINE) to duplicate public part to "new key" to associate "new key" to EVP_KEY with EVP_PKEY_set1_FOO b) could change key method must associate engine with key After above may register(associate) extra data with key and finally to finish loading. Proposed patch adds EC_KEY_get_method that could be used in 1). It seems to me this is required part. Under question is EC_KEY_set_method. If a) recommended then EC_KEY_set_method is useless. I could drop from patch. If b) is acceptable then in addition to EC_KEY_set_method API must support set engine method for opaque keys. a) requires more memory, i.e. code to transfer(recreate) public key with engine b) it is simple. For instance for rsa keys we could write: .... RSA_set_method(pkey_rsa, meth); pkey_rsa->engine = eng; ENGINE_up_ref(eng); .... Let me know how to proceed with this request. Roumen Petrov From steve at openssl.org Thu Dec 24 13:10:03 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 24 Dec 2015 13:10:03 +0000 Subject: [openssl-dev] Variable length of digest In-Reply-To: References: <20151223221855.GA10957@openssl.org> <20151223223757.GX18704@mournblade.imrryr.org> <20151224110215.1cf02234@fafnir.local.vm> Message-ID: <20151224131003.GA19958@openssl.org> On Thu, Dec 24, 2015, Dmitry Belyavsky wrote: > > If you try to change the output length via the -macopt option of the dgst > command, you'll see that the text output will be 4 bytes. > It seems to happen because of the internal call to the EVP_MD_size() > function. > > If we change the EVP_MD_CTX_size() definition from a macro to a function > trying to call the ctrl function and then to fallback to the result of the > EVP_MD_size() function, it should improve the situation. > If you're using it as a MAC via EVP_DigestSign*() you shouldn't need to do any of that. The MAC size is indicated via EVP_DigestSignFinal, looking through the code of the dgst application this should already work (though no current MAC does this) as long as the digest implementation handles things appropriately. By "appropriately" you have to specify "signctx" in the underlying EVP_PKEY_METHOD: see the source for EVP_DigestSignFinal(). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Thu Dec 24 14:09:21 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 24 Dec 2015 14:09:21 +0000 Subject: [openssl-dev] [openssl.org #4200] extra data for ec keys In-Reply-To: References: <567903B6.9070805@roumenpetrov.info> <8a62b93b720d42b4a295bd51ba8fbd5e@usma1ex-dag1mb1.msg.corp.akamai.com> <567BAF78.8070608@roumenpetrov.info> Message-ID: I fixed that, added docs. It's in code review now. Thanks! From rsalz at akamai.com Thu Dec 24 14:10:36 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 24 Dec 2015 14:10:36 +0000 Subject: [openssl-dev] access-EC_KEY-method-property In-Reply-To: <567BC8DE.4090000@roumenpetrov.info> References: <567903B6.9070805@roumenpetrov.info> <1063e197a7bc440eae6d15d7cc2cf9f4@usma1ex-dag1mb1.msg.corp.akamai.com> <567BC8DE.4090000@roumenpetrov.info> Message-ID: > Yes but a number of functions (see below) allow implementation as external > to openssl cryptographic module: Yes, I figured that out after I sent the mail :( Patch is in code review now, thanks! From vitus at wagner.pp.ru Thu Dec 24 14:57:48 2015 From: vitus at wagner.pp.ru (Victor Wagner) Date: Thu, 24 Dec 2015 17:57:48 +0300 Subject: [openssl-dev] Variable length of digest In-Reply-To: References: <20151223221855.GA10957@openssl.org> <20151223223757.GX18704@mournblade.imrryr.org> <20151224110215.1cf02234@fafnir.local.vm> Message-ID: <20151224175748.1bb0b9ca@fafnir.local.vm> On Thu, 24 Dec 2015 11:24:37 +0300 Dmitry Belyavsky wrote: > > If you try to change the output length via the -macopt option of the > dgst command, you'll see that the text output will be 4 bytes. It is misfeature of dgst command. You have to use -signopt, not -macopt, because dgst command doesn't keep EVP_PKEY_CTX during all the MAC operation. -macopt is used to configure EVP_PKEY_CTX, which is used during EVP_DigestSignInit operation and then destroyed, and -signopt - to configure context, which is used durint EVP_DigestSignFinal. Forutnately, we don't need to configure GOST-MAC algorithm during init state. Internal state is always 64 bit, and is truncated only on the finalization stage. When using API (such as python ctypescrypto.mac module) and preserving same EVP_PKEY_CTX for the lifetime of digest, this problem doesn't occur. From beldmit at gmail.com Thu Dec 24 18:12:07 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 24 Dec 2015 21:12:07 +0300 Subject: [openssl-dev] Variable length of digest In-Reply-To: <20151224175748.1bb0b9ca@fafnir.local.vm> References: <20151223221855.GA10957@openssl.org> <20151223223757.GX18704@mournblade.imrryr.org> <20151224110215.1cf02234@fafnir.local.vm> <20151224175748.1bb0b9ca@fafnir.local.vm> Message-ID: Hello Victor, On Thu, Dec 24, 2015 at 5:57 PM, Victor Wagner wrote: > On Thu, 24 Dec 2015 11:24:37 +0300 > Dmitry Belyavsky wrote: > > > > > > If you try to change the output length via the -macopt option of the > > dgst command, you'll see that the text output will be 4 bytes. > > It is misfeature of dgst command. You have to use -signopt, not -macopt, > because dgst command doesn't keep EVP_PKEY_CTX during all the MAC > operation. > Thank you! It works. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Dec 25 16:50:09 2015 From: rt at openssl.org (Cory Benfield via RT) Date: Fri, 25 Dec 2015 16:50:09 +0000 Subject: [openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format In-Reply-To: References: Message-ID: Many HTTPS browsers support dumping keys for TLS sessions to a text file to allow analysis tools to decrypt captured TLS sessions. This is an extremely useful debugging tool for working with services that only expose encrypted interfaces. This support exists in Firefox and Chrome: in Firefox?s case using NSS, and in Chrome?s case using their BoringSSL fork of OpenSSL. Both tools dump the keys in the same format, defined here[0]. As a developer of a HTTP(S) library that uses OpenSSL directly for TLS, I would like to support the same ad hoc standard for dumping TLS session keys. However, as far as I?m aware OpenSSL has no support for accessing those keys. It would be extremely helpful if OpenSSL added this support. A possible starting point for this work would be a series of patches applied by David Benjamin to BoringSSL. The first of these can be found here[1], though the eventual interface for this changed to use a callback, and it would probably be better to mimic that interface than to use the BIO-based one shown in this specific patch. Is there any interest in adding this support to OpenSSL? Cory [0]: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format [1]: https://boringssl.googlesource.com/boringssl/+/859ec3cc09f244348f3c919693817acb01064535%5E%21/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Dec 25 16:51:03 2015 From: rt at openssl.org (=?UTF-8?B?0JrRg9C00YDRj9Cy0YbQtdCyINCS0LDRgdC40LvQuNC5INCR0L7RgNC40YE=?= =?UTF-8?B?0L7QstC40Yc=?= via RT) Date: Fri, 25 Dec 2015 16:51:03 +0000 Subject: [openssl-dev] [openssl.org #4202] RT link does not work In-Reply-To: References: Message-ID: Hello! ? the link (https://www.openssl.org/support/rt.html) , mentioned (https://github.com/openssl/openssl/tree/master)?on github, does not work ? Please, fix ? Thank you! ? ? Vasiliy -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sat Dec 26 20:26:24 2015 From: rt at openssl.org (Anton Prytkov via RT) Date: Sat, 26 Dec 2015 20:26:24 +0000 Subject: [openssl-dev] [openssl.org #4203] OpenSSL 1.0.2e. Failed build due to (possibly) wrong include of dummytest.c In-Reply-To: <567E7056.2050005@prytkov.com> References: <567E7056.2050005@prytkov.com> Message-ID: Hello, Contents: 1. Build environment 2. Build steps 3. Problem 4. Solution 1. Build environment: Core i7-3632QM Windows 10 x64 MinGW-w64 x86_64-5.2.0-release-posix-seh-rt_v4-rev1 ActivePerl-5.20.2.2002-MSWin32-x64-299195 2. Build steps: perl Configure mingw64 shared no-asm --prefix=c:/openssl/1.0.2e make depend make 3. Build fails at c:/openssl/1.0.2e/test/md2test.c, line 1 Can not parse. 4. Solution: change line 1: openssl-1.0.2e/dummytest.c to: #include "dummytest.c" -- Best regards, Anton Prytkov _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sat Dec 26 20:27:37 2015 From: rt at openssl.org (Anton Prytkov via RT) Date: Sat, 26 Dec 2015 20:27:37 +0000 Subject: [openssl-dev] [openssl.org #4204] Re: OpenSSL 1.0.2e. Failed build due to (possibly) wrong include of dummytest.c In-Reply-To: <567E7159.5050903@prytkov.com> References: <567E7056.2050005@prytkov.com> <567E7159.5050903@prytkov.com> Message-ID: The same problem for openssl-1.0.2e/test/{jpaketest.c, md2test.c, rc5test.c} On 2015-12-26 13:47, Anton Prytkov wrote: > Hello, > > Contents: > 1. Build environment > 2. Build steps > 3. Problem > 4. Solution > > 1. Build environment: > Core i7-3632QM > Windows 10 x64 > MinGW-w64 x86_64-5.2.0-release-posix-seh-rt_v4-rev1 > ActivePerl-5.20.2.2002-MSWin32-x64-299195 > > 2. Build steps: > perl Configure mingw64 shared no-asm --prefix=c:/openssl/1.0.2e > make depend > make > > 3. Build fails at c:/openssl/1.0.2e/test/md2test.c, line 1 > Can not parse. > > 4. Solution: > change line 1: > openssl-1.0.2e/dummytest.c > to: > #include "dummytest.c" > _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sat Dec 26 20:28:46 2015 From: rt at openssl.org (TJ Saunders via RT) Date: Sat, 26 Dec 2015 20:28:46 +0000 Subject: [openssl-dev] [openssl.org #4205] Improve the default TLS session ticket key In-Reply-To: <1451082436.2231057.476360850.74E50237@webmail.messagingengine.com> References: <1451082436.2231057.476360850.74E50237@webmail.messagingengine.com> Message-ID: The default TLS session ticket key used by OpenSSL uses AES128-CBC-SHA256; considering the security offered by newer ciphersuites, the TLS session ticket key algorithm should be updated/improved, at least to AES256-CBC-SHA256. See: https://github.com/openssl/openssl/issues/514 Cheers, TJ _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sat Dec 26 20:53:59 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Sat, 26 Dec 2015 20:53:59 +0000 Subject: [openssl-dev] [openssl.org #4202] RT link does not work In-Reply-To: References: Message-ID: This link is the right one, we'll fix the code, thanks: https://www.openssl.org/community/index.html#bugs From rt at openssl.org Sat Dec 26 21:03:04 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Sat, 26 Dec 2015 21:03:04 +0000 Subject: [openssl-dev] [openssl.org #4203] OpenSSL 1.0.2e. Failed build due to (possibly) wrong include of dummytest.c In-Reply-To: <20151226210322.GA791@roeckx.be> References: <567E7056.2050005@prytkov.com> <20151226210322.GA791@roeckx.be> Message-ID: On Sat, Dec 26, 2015 at 08:26:24PM +0000, Anton Prytkov via RT wrote: > 3. Build fails at c:/openssl/1.0.2e/test/md2test.c, line 1 > Can not parse. It says: #include Why can't that be parsed? > 4. Solution: > change line 1: > openssl-1.0.2e/dummytest.c > to: > #include "dummytest.c" There is no openssl-1.0.2e/dummytest.c file. There is one in the test directory. Why should it include itself? Kurt From rt at openssl.org Sat Dec 26 21:36:36 2015 From: rt at openssl.org (Anton Prytkov via RT) Date: Sat, 26 Dec 2015 21:36:36 +0000 Subject: [openssl-dev] [openssl.org #4203] OpenSSL 1.0.2e. Failed build due to (possibly) wrong include of dummytest.c In-Reply-To: <567F080C.4040505@prytkov.com> References: <567E7056.2050005@prytkov.com> <20151226210322.GA791@roeckx.be> <567F080C.4040505@prytkov.com> Message-ID: Maybe that's my English. I'll try to rephrase. 1. When I tried to build openssl, the build process stopped with error when compiling file "md2test.c" from "test" directory. The error was something like "too many decimal points in a number" (I don't remember well). The contents of that file (named "md2test.c") was just a text "openssl-1.0.2e/dummytest.c" (without quotes). Nothing before or after this string. The same is for jpaketest.c, md2test.c, rc5test.c. 2. After I changed the content of that three files to "#include "dummytest.c" (instead of "openssl-1.0.2e/dummytest.c") I was able to successfully build OpenSSL. P.S. I just checked the file "md2test.c" in openssl-1.0.2e.tar.gz. It's a 26-byte long file with "openssl-1.0.2e/dummytest.c" inside. No "#include " or anything else. On 2015-12-27 00:03, Kurt Roeckx via RT wrote: > On Sat, Dec 26, 2015 at 08:26:24PM +0000, Anton Prytkov via RT wrote: >> 3. Build fails at c:/openssl/1.0.2e/test/md2test.c, line 1 >> Can not parse. > It says: > #include > > Why can't that be parsed? > >> 4. Solution: >> change line 1: >> openssl-1.0.2e/dummytest.c >> to: >> #include "dummytest.c" > There is no openssl-1.0.2e/dummytest.c file. There is one in the > test directory. > > Why should it include itself? > > > Kurt > > From phpdev at ehrhardt.nl Sat Dec 26 23:37:46 2015 From: phpdev at ehrhardt.nl (Jan Ehrhardt) Date: Sun, 27 Dec 2015 00:37:46 +0100 Subject: [openssl-dev] [openssl.org #4203] OpenSSL 1.0.2e. Failed build due to (possibly) wrong include of dummytest.c References: <567E7056.2050005@prytkov.com> <20151226210322.GA791@roeckx.be> <567F080C.4040505@prytkov.com> Message-ID: Anton Prytkov via RT in gmane.comp.encryption.openssl.devel (Sat, 26 Dec): >P.S. I just checked the file "md2test.c" in openssl-1.0.2e.tar.gz. It's >a 26-byte long file with "openssl-1.0.2e/dummytest.c" inside. >No "#include " or anything else. It is a symlink. Standard Windows decompressors do not recognize that. I always use 'tar' from Cygwin: c:\cygwin\bin\tar xvf openssl-1.0.2e.tar.gz -- Jan From rt at openssl.org Sat Dec 26 23:53:55 2015 From: rt at openssl.org (Jan Ehrhardt via RT) Date: Sat, 26 Dec 2015 23:53:55 +0000 Subject: [openssl-dev] [openssl.org #4203] OpenSSL 1.0.2e. Failed build due to (possibly) wrong include of dummytest.c In-Reply-To: <9l9u7b9chjcqlqpk4caph7d2bb35lmrrld@4ax.com> References: <567E7056.2050005@prytkov.com> <20151226210322.GA791@roeckx.be> <567F080C.4040505@prytkov.com> <9l9u7b9chjcqlqpk4caph7d2bb35lmrrld@4ax.com> Message-ID: Anton Prytkov via RT in gmane.comp.encryption.openssl.devel (Sat, 26 Dec): >P.S. I just checked the file "md2test.c" in openssl-1.0.2e.tar.gz. It's >a 26-byte long file with "openssl-1.0.2e/dummytest.c" inside. >No "#include " or anything else. It is a symlink. Standard Windows decompressors do not recognize that. I always use 'tar' from Cygwin: c:\cygwin\bin\tar xvf openssl-1.0.2e.tar.gz -- Jan From rt at openssl.org Sun Dec 27 00:04:25 2015 From: rt at openssl.org (Anton Prytkov via RT) Date: Sun, 27 Dec 2015 00:04:25 +0000 Subject: [openssl-dev] [openssl.org #4203] OpenSSL 1.0.2e. Failed build due to (possibly) wrong include of dummytest.c In-Reply-To: <151e0bfe860.279f.7285ccf289670e2234e61a2fa8b0a4db@prytkov.com> References: <567E7056.2050005@prytkov.com> <20151226210322.GA791@roeckx.be> <567F080C.4040505@prytkov.com> <9l9u7b9chjcqlqpk4caph7d2bb35lmrrld@4ax.com> <151e0bfe860.279f.7285ccf289670e2234e61a2fa8b0a4db@prytkov.com> Message-ID: Yes, thank you. I was using 7zip for decompression. Sent from mobile device. Please excuse my brevity and typos. --- Best regards, Anton Prytkov On December 27, 2015 2:55:40 AM Jan Ehrhardt via RT wrote: > Anton Prytkov via RT in gmane.comp.encryption.openssl.devel (Sat, 26 Dec): >>P.S. I just checked the file "md2test.c" in openssl-1.0.2e.tar.gz. It's >>a 26-byte long file with "openssl-1.0.2e/dummytest.c" inside. >>No "#include " or anything else. > > It is a symlink. Standard Windows decompressors do not recognize that. I > always use 'tar' from Cygwin: > > c:\cygwin\bin\tar xvf openssl-1.0.2e.tar.gz > -- > Jan > > From rt at openssl.org Sun Dec 27 22:10:37 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Sun, 27 Dec 2015 22:10:37 +0000 Subject: [openssl-dev] [openssl.org #4120] CertificateStatus message is optional In-Reply-To: References: Message-ID: Thanks for the report David. This has now been fixed in master/1.0.2/1.0.1 Matt From matt at openssl.org Sun Dec 27 22:20:41 2015 From: matt at openssl.org (Matt Caswell) Date: Sun, 27 Dec 2015 22:20:41 +0000 Subject: [openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake In-Reply-To: <20151223172108.GS18704@mournblade.imrryr.org> References: <20151223172108.GS18704@mournblade.imrryr.org> Message-ID: <56806439.7020503@openssl.org> On 23/12/15 17:21, Viktor Dukhovni wrote: > On Wed, Dec 23, 2015 at 04:48:20PM +0000, Matt Caswell via RT wrote: > >> The problem is that the server has been configured to allow client auth. The >> CertificateRequest message coming from the server seems very long (nearly 20k). >> This is primarily made up of a long list of acceptable CA names. > > Probably the entire CA bundle was loaded into memory as a CAfile, > rather than as a CApath, and now the server is spewing out a complete > list of the DNs of its trusted CAs on every connection. > > I am very tempted to say that this misconfiguration *should fail, > it is far better to send an *empty* list of trusted CAs than send > the Vladivostok phone directory. I strongly disagree. As a supplier of a library for client side use (in the scenario we are talking about), it is *not* our responsibility to police server side configuration. I strongly suspect that no browser (taking a browser use case as an example) would fail when presented with such an over long CertificateRequest message so neither should we. From a client side perspective it does little harm to the client to accept a long message, but it does harm the client to reject (it prevents the client from using that server). We have in previous versions accepted this, so IMO we should as a minimum support what we used to support. > >> The master code has the max size limit for this message as being >> SSL3_RT_MAX_PLAIN_LENGTH (16384 bytes). This is the maximum that can be put >> into a single TLS record. Previous versions had it set to s->max_cert_list >> which is a configurable value that by default is 100k. >> >> The attached patch should resolve this issue (it just reverts the size limit to >> what it was before). > > Perhaps OpenSSL should suppress the default use of the contents of > CAfile as a list of DNs to send in certificate requests when that > list is longer than say 16 elements. Applications can explicitly > specify the list of CAs for the client certificate request as > needed. > > Sending the whole bundle to every client is not a good idea. The > empty list works much better in every respect. We could set the > limit to 0 instead of the arbitrary 16, thereby requiring the list > of client auth CAs to always be set explicitly. With any luck as > a result a lot fewer applications will end up sending the phone > directory. > This might be worthwhile as a *server side* solution. It should not prevent us from accepting long CertifcateRequests on the client. Matt From openssl-users at dukhovni.org Sun Dec 27 22:24:04 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 27 Dec 2015 22:24:04 +0000 Subject: [openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake In-Reply-To: <56806439.7020503@openssl.org> References: <20151223172108.GS18704@mournblade.imrryr.org> <56806439.7020503@openssl.org> Message-ID: <20151227222404.GQ18704@mournblade.imrryr.org> On Sun, Dec 27, 2015 at 10:20:41PM +0000, Matt Caswell wrote: > > I am very tempted to say that this misconfiguration *should fail, > > it is far better to send an *empty* list of trusted CAs than send > > the Vladivostok phone directory. > > I strongly disagree. I did say *tempted*. In practice, I too would oppose that maximalist stance. > > Sending the whole bundle to every client is not a good idea. The > > empty list works much better in every respect. > > This might be worthwhile as a *server side* solution. It should not > prevent us from accepting long CertifcateRequests on the client. We're on the same page, see the discussion on your MR in gitlab. -- Viktor. From rt at openssl.org Sun Dec 27 23:04:11 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Sun, 27 Dec 2015 23:04:11 +0000 Subject: [openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake In-Reply-To: References: Message-ID: On Wed Dec 23 16:48:20 2015, matt wrote: > On Wed Dec 23 15:42:54 2015, dmb at inky.com wrote: > > Using the current master (head) code, this reproduces it: > > > > openssl s_client -connect mail.baggett.org:465 > > > > This is my own personal mail server, so feel free to poke and prod > > it. > > > > Great, thanks. I can reproduce this now. > > The problem is that the server has been configured to allow client > auth. The > CertificateRequest message coming from the server seems very long > (nearly 20k). > This is primarily made up of a long list of acceptable CA names. > > The master code has the max size limit for this message as being > SSL3_RT_MAX_PLAIN_LENGTH (16384 bytes). This is the maximum that can > be put > into a single TLS record. Previous versions had it set to s- > >max_cert_list > which is a configurable value that by default is 100k. > > The attached patch should resolve this issue (it just reverts the size > limit to > what it was before). This patch has now been applied. Closing ticket. Matt From rt at openssl.org Mon Dec 28 15:01:28 2015 From: rt at openssl.org (Short, Todd via RT) Date: Mon, 28 Dec 2015 15:01:28 +0000 Subject: [openssl-dev] [openssl.org #4206] [PATCH] Add cipher alias for ChaCha20 In-Reply-To: <049086E0-8A54-4B2A-B830-677C29344D7C@akamai.com> References: <049086E0-8A54-4B2A-B830-677C29344D7C@akamai.com> Message-ID: Hello OpenSSL.org: This is a patch for the master branch. The changes in master to add ChaCha20 to OpenSSL do not include an alias for the cipher in the ?openssl cipher? command, nor in the cipher functions., even though the necessary constants have been defined. The attached patch adds that alias. The following openssl commands now behave as expected: openssl ciphers CHACHA20 openssl ciphers CHACHA20:AES Thanks, -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-CHACHA20-alias-for-ciphers.patch Type: application/octet-stream Size: 785 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Dec 28 15:28:26 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Mon, 28 Dec 2015 15:28:26 +0000 Subject: [openssl-dev] [openssl.org #4206] [PATCH] Add cipher alias for ChaCha20 In-Reply-To: <20151228152843.GA4796@roeckx.be> References: <049086E0-8A54-4B2A-B830-677C29344D7C@akamai.com> <20151228152843.GA4796@roeckx.be> Message-ID: On Mon, Dec 28, 2015 at 03:01:28PM +0000, Short, Todd via RT wrote: > Hello OpenSSL.org: > > This is a patch for the master branch. The changes in master to add ChaCha20 to OpenSSL do not include an alias for the cipher in the "openssl cipher" command, nor in the cipher functions., even though the necessary constants have been defined. The attached patch adds that alias. > > The following openssl commands now behave as expected: > > openssl ciphers CHACHA20 > openssl ciphers CHACHA20:AES Please at least also update the documentation, like ciphers.pod. I'm also not sure if CHACHA20 should only select those in combination with Poly1305, even if those are currently the only supported. Kurt From tshort at akamai.com Mon Dec 28 16:03:33 2015 From: tshort at akamai.com (Short, Todd) Date: Mon, 28 Dec 2015 16:03:33 +0000 Subject: [openssl-dev] [openssl.org #4206] [PATCH] Add cipher alias for ChaCha20 In-Reply-To: References: <049086E0-8A54-4B2A-B830-677C29344D7C@akamai.com> <20151228152843.GA4796@roeckx.be> Message-ID: <5098D1DC-98F2-4285-A44A-E3EA504A98EF@akamai.com> True, but there?s currently no flag defined for just ?ChaCha20? ciphers, just SSL_CHACHA20POLY1305. My understanding is that CHACHA20POLY1305 is considered AEAD, so the two will always be linked. That being said, nothing prevents CHACHA20 from referencing additional CHACHA20 ciphers, nor precludes adding CHACHA20POLY1305 as a cipher string. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Dec 28, 2015, at 10:28 AM, Kurt Roeckx via RT > wrote: On Mon, Dec 28, 2015 at 03:01:28PM +0000, Short, Todd via RT wrote: Hello OpenSSL.org: This is a patch for the master branch. The changes in master to add ChaCha20 to OpenSSL do not include an alias for the cipher in the "openssl cipher" command, nor in the cipher functions., even though the necessary constants have been defined. The attached patch adds that alias. The following openssl commands now behave as expected: openssl ciphers CHACHA20 openssl ciphers CHACHA20:AES Please at least also update the documentation, like ciphers.pod. I'm also not sure if CHACHA20 should only select those in combination with Poly1305, even if those are currently the only supported. Kurt -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Dec 28 16:03:39 2015 From: rt at openssl.org (Short, Todd via RT) Date: Mon, 28 Dec 2015 16:03:39 +0000 Subject: [openssl-dev] [openssl.org #4206] [PATCH] Add cipher alias for ChaCha20 In-Reply-To: <5098D1DC-98F2-4285-A44A-E3EA504A98EF@akamai.com> References: <049086E0-8A54-4B2A-B830-677C29344D7C@akamai.com> <20151228152843.GA4796@roeckx.be> <5098D1DC-98F2-4285-A44A-E3EA504A98EF@akamai.com> Message-ID: True, but there?s currently no flag defined for just ?ChaCha20? ciphers, just SSL_CHACHA20POLY1305. My understanding is that CHACHA20POLY1305 is considered AEAD, so the two will always be linked. That being said, nothing prevents CHACHA20 from referencing additional CHACHA20 ciphers, nor precludes adding CHACHA20POLY1305 as a cipher string. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Dec 28, 2015, at 10:28 AM, Kurt Roeckx via RT > wrote: On Mon, Dec 28, 2015 at 03:01:28PM +0000, Short, Todd via RT wrote: Hello OpenSSL.org: This is a patch for the master branch. The changes in master to add ChaCha20 to OpenSSL do not include an alias for the cipher in the "openssl cipher" command, nor in the cipher functions., even though the necessary constants have been defined. The attached patch adds that alias. The following openssl commands now behave as expected: openssl ciphers CHACHA20 openssl ciphers CHACHA20:AES Please at least also update the documentation, like ciphers.pod. I'm also not sure if CHACHA20 should only select those in combination with Poly1305, even if those are currently the only supported. Kurt From rt at openssl.org Mon Dec 28 16:55:31 2015 From: rt at openssl.org (Short, Todd via RT) Date: Mon, 28 Dec 2015 16:55:31 +0000 Subject: [openssl-dev] [openssl.org #4206] [PATCH] Add cipher alias for ChaCha20 In-Reply-To: References: <049086E0-8A54-4B2A-B830-677C29344D7C@akamai.com> Message-ID: Updated patch. Updates documentation (ciphers.pod), and lays some groundwork in case ChaCha20 is used with something other than Poly1305. (Also updates the Camellia cipher alias to use an existing #define.) -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-CHACHA20-alias-for-ciphers.patch Type: application/octet-stream Size: 2828 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Dec 28 21:42:56 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 28 Dec 2015 21:42:56 +0000 Subject: [openssl-dev] [openssl.org #4202] RT link does not work In-Reply-To: References: Message-ID: update the links in README and INSTALL for master, 1.0.2 and 1.0.1; closing ticket, thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rsalz at akamai.com Mon Dec 28 22:00:59 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 28 Dec 2015 22:00:59 +0000 Subject: [openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format In-Reply-To: References: Message-ID: Yes we would be interested in this but someone would almost definitely have to be provided as a complete patch because it seems unlikely anyone on the team will get around to doing it by 1.1 release. From rt at openssl.org Mon Dec 28 22:01:04 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 28 Dec 2015 22:01:04 +0000 Subject: [openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format In-Reply-To: References: Message-ID: Yes we would be interested in this but someone would almost definitely have to be provided as a complete patch because it seems unlikely anyone on the team will get around to doing it by 1.1 release. From rt at openssl.org Mon Dec 28 23:53:03 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 28 Dec 2015 23:53:03 +0000 Subject: [openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format In-Reply-To: References: Message-ID: On Mon Dec 28 22:01:04 2015, rsalz at akamai.com wrote: > Yes we would be interested in this but someone would almost definitely > have to be provided as a complete patch because it seems unlikely > anyone on the team will get around to doing it by 1.1 release. > Actually I think this capability is already in 1.1.0...or rather it *was* but now seems to be broken. See commit 189ae368d91 and RT ticket 3352. I suspect the big apps cleanup broke it. Matt From sugu.ece28 at gmail.com Tue Dec 29 09:25:48 2015 From: sugu.ece28 at gmail.com (suguacl28) Date: Tue, 29 Dec 2015 02:25:48 -0700 (MST) Subject: [openssl-dev] RSA Public Encryption and Decryption Message-ID: <1451381148970-61934.post@n7.nabble.com> Hi, Lets assume i have a RSA public key file (xyz_file.pem) and cipher text that is encrypted using same RSA public key file (xyz_file.pem) now i want to decrypt the cipher text using same RSA public key file (xyz_file.pem). Ya i know its not a correct way of encryption and decryption concept. Just i need to know the security vulnerability in this concept!!! -- View this message in context: http://openssl.6102.n7.nabble.com/RSA-Public-Encryption-and-Decryption-tp61934.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. From rt at openssl.org Tue Dec 29 15:31:27 2015 From: rt at openssl.org (Roumen Petrov via RT) Date: Tue, 29 Dec 2015 15:31:27 +0000 Subject: [openssl-dev] [openssl.org #4207] engine key format in 1.1 In-Reply-To: <5682A73C.70305@roumenpetrov.info> References: <5682A73C.70305@roumenpetrov.info> Message-ID: Hi, Implementation of common option processing for OpenSSL commands broke ENGINE key format. The patches attached to this email are only for tested command. 1) dgst command (see 0003-dgst-cmd-restore-keys-from-engine.patch) Key form is described as any but value type of input ('<') is too restrictive - change input to string type. 2) rsa command (see 0004-rsa-cmd-restore-keys-from-engine.patch) Similar as dgst. 3) dsa command (see 0005-dsa-cmd-implement-keys-from-engine.patch) New. Implementation of engine format is simple with common command processing. 4) ec command (see 0006-ec-cmd-implement-keys-from-engine.patch) New. Implementation of engine format requires specific load of input to be replaced to use load_pubkey or load_key functions. Then modification is similar as dsa. 5) rsautl command (see 0007-rsautl-cmd-restore-keys-from-engine.patch) Key form input type 'f'(any) instead 'F' and input is from string type. 6) pkeyutl command (see 0008-pkeyutl-cmd-restore-keys-from-engine.patch) Use key form input type 'f' instead 'F' . Other commands are not tested yet. Regards, Roumen -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-dgst-cmd-restore-keys-from-engine.patch Type: text/x-diff Size: 1287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-rsa-cmd-restore-keys-from-engine.patch Type: text/x-diff Size: 896 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-dsa-cmd-implement-keys-from-engine.patch Type: text/x-diff Size: 1309 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-ec-cmd-implement-keys-from-engine.patch Type: text/x-diff Size: 3404 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-rsautl-cmd-restore-keys-from-engine.patch Type: text/x-diff Size: 1369 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-pkeyutl-cmd-restore-keys-from-engine.patch Type: text/x-diff Size: 1272 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Dec 29 19:04:23 2015 From: rt at openssl.org (Roumen Petrov via RT) Date: Tue, 29 Dec 2015 19:04:23 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: <5682D931.1030800@roumenpetrov.info> References: <5678F551.8000406@roumenpetrov.info> <35ef115027374dea901dee71d12072cd@usma1ex-dag1mb1.msg.corp.akamai.com> <5682D931.1030800@roumenpetrov.info> Message-ID: Salz, Rich via RT wrote: > I don't know that I would call it a regression, but rather a difference. :) > I'll fix the summary but not the old uncommon behavior. Unlike other commands engine is flexible and documented behaviour (see previous post with quoted text). As result in samples first is engine name then commands. Just search in internet for samples - expect some recent openssl tutorial almost all other samples use name before options. Request is only for engine. It is not for speed command for example. This is reason to call issue regression. Regards, Roumen Petrov From rsalz at akamai.com Tue Dec 29 19:34:27 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 29 Dec 2015 19:34:27 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: References: <5678F551.8000406@roumenpetrov.info> <35ef115027374dea901dee71d12072cd@usma1ex-dag1mb1.msg.corp.akamai.com> <5682D931.1030800@roumenpetrov.info> Message-ID: Does this diff fix it? ; g diff apps/engine.c diff --git a/apps/engine.c b/apps/engine.c index c373df5..3c0ff96 100644 --- a/apps/engine.c +++ b/apps/engine.c @@ -312,12 +312,17 @@ int engine_main(int argc, char **argv) BIO *out; const char *indent = " "; OPTION_CHOICE o; - char *prog; + char *prog, *argv1; out = dup_bio_out(FORMAT_TEXT); prog = opt_init(argc, argv, engine_options); if (!engines || !pre_cmds || !post_cmds) goto end; + while ((argv1 = argv[1]) != NULL && *argv1 != '-') { + sk_OPENSSL_STRING_push(engines, *argv1); + argc--; + argv++; + } while ((o = opt_next()) != OPT_EOF) { switch (o) { case OPT_EOF: From rt at openssl.org Tue Dec 29 19:34:30 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 29 Dec 2015 19:34:30 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: References: <5678F551.8000406@roumenpetrov.info> <35ef115027374dea901dee71d12072cd@usma1ex-dag1mb1.msg.corp.akamai.com> <5682D931.1030800@roumenpetrov.info> Message-ID: Does this diff fix it? ; g diff apps/engine.c diff --git a/apps/engine.c b/apps/engine.c index c373df5..3c0ff96 100644 --- a/apps/engine.c +++ b/apps/engine.c @@ -312,12 +312,17 @@ int engine_main(int argc, char **argv) BIO *out; const char *indent = " "; OPTION_CHOICE o; - char *prog; + char *prog, *argv1; out = dup_bio_out(FORMAT_TEXT); prog = opt_init(argc, argv, engine_options); if (!engines || !pre_cmds || !post_cmds) goto end; + while ((argv1 = argv[1]) != NULL && *argv1 != '-') { + sk_OPENSSL_STRING_push(engines, *argv1); + argc--; + argv++; + } while ((o = opt_next()) != OPT_EOF) { switch (o) { case OPT_EOF: From rt at openssl.org Tue Dec 29 19:43:06 2015 From: rt at openssl.org (Juan Manuel Guerrero via RT) Date: Tue, 29 Dec 2015 19:43:06 +0000 Subject: [openssl-dev] [openssl.org #4208] [PATCH] Some DJGPP specific fixes and improvements for OpenSSL_1_0_1-stable and OpenSSL_1_0_2-stable. In-Reply-To: <5682CFF6.20801@gmx.de> References: <5682CFF6.20801@gmx.de> Message-ID: I have been using the DJGPP port of OpenSSL for a couple of years and I would like to propose some fixes and improvements. No one of the proporsed changes have impact on any other port. I supply two patches, one for today's OpenSSL_1_0_1-stable and one for today's openssl-OpenSSL_1_0_2-stable. Patching the master branch is not so straight forward so it will follow later. Both patches will fix/improve the following issues: 1) In Configure: For some reason -DTERMIO is set but DJGPP has never offered TERMIO making the build fail. I have changed this to -DTERMIOS as is used to be. 2) In crypto/bio/bss_dgram.c: I have removed superflous macro definitions of sock_write, sock_read and sock_puts enclosed by WATT32. 3) In crypto/bio/bss_sock.c: Here the existing macro definitions for sock_write, sock_read and sock_puts are necessary and must be kept but they must be undefined before they can be defined. This is because newer versions of Watt-32 also redefine them. 4) In crypto/conf/conf_def.c: If this port is used on MS-DOS or FreeDOS it becomes necessary to check if the underlying file system supports long file names (aka LFN) or not. If it does not then file names with a leading dot like ".rnd" or ".ca_certs" are ilicit. In function def_load_bio, the macros IS_RANDFILE and IS_CERT_DIR are used to check if the file system offers LFN support so that the file names with leading dots are licit. If the tests fail then the new function dosify_filename is called and will substitute invalid characters in the file name by valid ones before using them. This check and the call of dosify_filename is enclosed by OPENSSL_SYS_MSDOS. 5) In e_os.h: In the DJGPP section the macros IS_RANDFILE and IS_CERT_DIR are defined. Also some auxiliar macros like HAS_LFN_SUPPORT and FILE_EXISTS are defined. Because neither MS-DOS nor FreeDOS provide 'egd' sockets, the DEVRANDOM_EGD macro is undefined. This shall inhibit the compilation of code that does not work on MS-DOS/FreeDOS. 6) In util/mklink.pl: Neither MS-DOS nor FreeDOS provide symlink support so copy files instead. I have checked the modified versions of OpenSSL_1_0_1-stable and OpenSSL_1_0_2-stable on linux and Cygwin. They are no issues. This is no surprise because the changes are either enclosed by the __DJGPP__ or OPENSSL_SYS_MSDOS macros. If more informaton is required please mail me. I have attached the patches as gzip'ed files. Regards, Juan M. Guerrero -------------- next part -------------- A non-text attachment was scrubbed... Name: djgpp-OpenSSL_1_0_1-stable.patch.txt.gz Type: application/x-gzip Size: 2615 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: djgpp-OpenSSL_1_0_2-stable.patch.txt.gz Type: application/x-gzip Size: 2615 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Dec 29 22:40:05 2015 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 29 Dec 2015 22:40:05 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: <5678F551.8000406@roumenpetrov.info> References: <5678F551.8000406@roumenpetrov.info> Message-ID: The patch is wrong, this one is better. diff --git a/apps/engine.c b/apps/engine.c index c373df5..ab663ea 100644 --- a/apps/engine.c +++ b/apps/engine.c @@ -312,12 +312,17 @@ int engine_main(int argc, char **argv) BIO *out; const char *indent = " "; OPTION_CHOICE o; - char *prog; + char *prog, *argv1; out = dup_bio_out(FORMAT_TEXT); - prog = opt_init(argc, argv, engine_options); if (!engines || !pre_cmds || !post_cmds) goto end; + while ((argv1 = argv[1]) != NULL && *argv1 != '-') { + sk_OPENSSL_STRING_push(engines, *argv1); + argc--; + argv++; + } + prog = opt_init(argc, argv, engine_options); while ((o = opt_next()) != OPT_EOF) { switch (o) { case OPT_EOF: -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Wed Dec 30 14:21:35 2015 From: rt at openssl.org (Ray Satiro via RT) Date: Wed, 30 Dec 2015 14:21:35 +0000 Subject: [openssl-dev] [openssl.org #4209] OpenSSL RT website redirect http -> https not working properly In-Reply-To: <56830E84.3000307@yahoo.com> References: <56830E84.3000307@yahoo.com> Message-ID: It looks like the hostname is missing the trailing slash. GET http://rt.openssl.org/Ticket/Display.html?id=3621 HTTP/1.1 Host: rt.openssl.org User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive HTTP/1.1 302 Found Date: Tue, 29 Dec 2015 22:43:21 GMT Server: Apache/2.4.7 (Ubuntu) Location: https://rt.openssl.orgTicket/Display.html?id=3621 Content-Length: 312 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1 _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Dec 30 14:41:55 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 30 Dec 2015 14:41:55 +0000 Subject: [openssl-dev] [openssl.org #4209] OpenSSL RT website redirect http -> https not working properly In-Reply-To: <56830E84.3000307@yahoo.com> References: <56830E84.3000307@yahoo.com> Message-ID: You are entirely correct. Fortunately, the fix was very easy. Thanks for the help! Cheers, Richard Vid Ons, 30 Dec 2015 kl. 14.21.35, skrev raysatiro at yahoo.com: > It looks like the hostname is missing the trailing slash. > > > GET http://rt.openssl.org/Ticket/Display.html?id=3621 HTTP/1.1 > Host: rt.openssl.org > User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 > Firefox/38.0 > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > Accept-Language: en-US,en;q=0.5 > Accept-Encoding: gzip, deflate > Connection: keep-alive > > > HTTP/1.1 302 Found > Date: Tue, 29 Dec 2015 22:43:21 GMT > Server: Apache/2.4.7 (Ubuntu) > Location: https://rt.openssl.orgTicket/Display.html?id=3621 > Content-Length: 312 > Keep-Alive: timeout=5, max=100 > Connection: Keep-Alive > Content-Type: text/html; charset=iso-8859-1 > > _______________________________________________ > openssl-bugs-mod mailing list > openssl-bugs-mod at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod -- Richard Levitte levitte at openssl.org From doctor at doctor.nl2k.ab.ca Wed Dec 30 16:35:21 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 30 Dec 2015 09:35:21 -0700 Subject: [openssl-dev] Openssl 1.1 Message-ID: <20151230163521.GA8088@doctor.nl2k.ab.ca> All right, I did get this to start working on my 'ancient' BSD box. Couple of issues did catch my attention. Are Openssh, DNS developers, SMTP/POP3/IMAP developers, FTP devleopers, HTTPD developers and LDAP developers aware of changes coming down the pipe? If not, they should be informed. Also the libraries for libcrypto and libssl are suffixed as 1.1 instead of 1.1.0 any reason? Finally for the Configurations/10-main.conf I propose a slight amendment to the bsdi section "bsdi-elf-gcc" => { inherit_from => [ asm("x86_elf_asm") ], cc => "gcc", cflags => "-DPERL5 -DL_ENDIAN -fomit-frame-pointer -O2 -march =i486 -Wall", thread_cflag => "(unknown)", lflags => "-ldl", bn_ops => "BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}", dso_scheme => "dlfcn", shared_target => "bsd-gcc-shared", shared_cflag => "-fPIC", shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", }, "debug-bsdi-x86-elf" => { inherit_from => [ asm("x86_elf_asm") ], cc => "gcc", cflags => "-DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=i486 -Wall -g", thread_cflag => "-pthread -D_THREAD_SAFE -D_REENTRANT", lflags => "-ldl -lgmp -lm -lc -lz", bn_ops => "THIRTY_TWO_BIT_LONG RC4_CHUNK BN_LLONG ${x86_gcc_d es} ${x86_gcc_opts}", dso_scheme => "dlfcn", shared_target => "bsd-gcc-shared", shared_cflag => "-fPIC", shared_extension => ".so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", }, -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Happy Christmas 2015 and Merry New Year 2016 -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Happy Christmas 2015 and Merry New Year 2016 From rsalz at akamai.com Wed Dec 30 17:02:14 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 30 Dec 2015 17:02:14 +0000 Subject: [openssl-dev] Openssl 1.1 In-Reply-To: <20151230163521.GA8088@doctor.nl2k.ab.ca> References: <20151230163521.GA8088@doctor.nl2k.ab.ca> Message-ID: <4e8a341c7d7d4f549e98b16222d5f51e@usma1ex-dag1mb1.msg.corp.akamai.com> > Are Openssh, DNS developers, SMTP/POP3/IMAP developers, FTP > devleopers, HTTPD developers and LDAP developers aware of changes > coming down the pipe? > > If not, they should be informed. We've posted about it several times. We're making explicit pre-release testing versions available. We've seen other folks (e.g., CURL) post about their experiences. Do you have any suggestions? We'd hate for 'surprises' to delay people to start using it. From quanah at zimbra.com Wed Dec 30 17:19:50 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Wed, 30 Dec 2015 09:19:50 -0800 Subject: [openssl-dev] Openssl 1.1 In-Reply-To: <4e8a341c7d7d4f549e98b16222d5f51e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20151230163521.GA8088@doctor.nl2k.ab.ca> <4e8a341c7d7d4f549e98b16222d5f51e@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <9CE1D980F3D74F0AB5A7617D@[192.168.1.9]> --On Wednesday, December 30, 2015 5:02 PM +0000 "Salz, Rich" wrote: >> Are Openssh, DNS developers, SMTP/POP3/IMAP developers, FTP >> devleopers, HTTPD developers and LDAP developers aware of changes >> coming down the pipe? >> >> If not, they should be informed. > > We've posted about it several times. We're making explicit pre-release > testing versions available. We've seen other folks (e.g., CURL) post > about their experiences. Do you have any suggestions? We'd hate for > 'surprises' to delay people to start using it. So the term "ldap" caught my eye. What surprises are we talking about? ;) I can do some testing for OpenLDAP. I honestly haven't been paying exceedingly close attention to the 1.1 tree. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From rsalz at akamai.com Wed Dec 30 17:24:46 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 30 Dec 2015 17:24:46 +0000 Subject: [openssl-dev] Openssl 1.1 In-Reply-To: <9CE1D980F3D74F0AB5A7617D@[192.168.1.9]> References: <20151230163521.GA8088@doctor.nl2k.ab.ca> <4e8a341c7d7d4f549e98b16222d5f51e@usma1ex-dag1mb1.msg.corp.akamai.com> <9CE1D980F3D74F0AB5A7617D@[192.168.1.9]> Message-ID: <2fefa670a9674b469a7d72d781351a64@usma1ex-dag1mb1.msg.corp.akamai.com> > So the term "ldap" caught my eye. What surprises are we talking about? ;) I > can do some testing for OpenLDAP. I honestly haven't been paying > exceedingly close attention to the 1.1 tree. We've made many changes to make various structures SSL, SSL_CTX, RSA, EVP objects., etc., opaque. (Among other things, this makes future shared lib updates easier.) So pulling down the master branch and doing a build and seeing what breaks will be helpful. From levitte at openssl.org Wed Dec 30 17:26:53 2015 From: levitte at openssl.org (Richard Levitte) Date: Wed, 30 Dec 2015 18:26:53 +0100 (CET) Subject: [openssl-dev] Openssl 1.1 In-Reply-To: <9CE1D980F3D74F0AB5A7617D@[192.168.1.9]> References: <20151230163521.GA8088@doctor.nl2k.ab.ca> <4e8a341c7d7d4f549e98b16222d5f51e@usma1ex-dag1mb1.msg.corp.akamai.com> <9CE1D980F3D74F0AB5A7617D@[192.168.1.9]> Message-ID: <20151230.182653.1278367056628394731.levitte@openssl.org> In message <9CE1D980F3D74F0AB5A7617D@[192.168.1.9]> on Wed, 30 Dec 2015 09:19:50 -0800, Quanah Gibson-Mount said: quanah> I honestly haven't been paying exceedingly close attention to quanah> the 1.1 tree. I think it's time people start to pay attention (not directed at anyone in particular). Have a look at our release strategy [1] for the upcoming dates. Cheers, Richard [1] https://openssl.org/policies/releasestrat.html -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Wed Dec 30 17:28:23 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 30 Dec 2015 17:28:23 +0000 Subject: [openssl-dev] Openssl 1.1 In-Reply-To: <9CE1D980F3D74F0AB5A7617D@[192.168.1.9]> References: <20151230163521.GA8088@doctor.nl2k.ab.ca> <4e8a341c7d7d4f549e98b16222d5f51e@usma1ex-dag1mb1.msg.corp.akamai.com> <9CE1D980F3D74F0AB5A7617D@[192.168.1.9]> Message-ID: <20151230172823.GV18704@mournblade.imrryr.org> On Wed, Dec 30, 2015 at 09:19:50AM -0800, Quanah Gibson-Mount wrote: > So the term "ldap" caught my eye. What surprises are we talking about? ;) I > can do some testing for OpenLDAP. I honestly haven't been paying > exceedingly close attention to the 1.1 tree. Mostly various structures went opaque and you now need to use the relevant accessors. So some minor source code changes may be needed in some cases. Try to compiled the OpenLDAP code and see if it builds. -- Viktor. From doctor at doctor.nl2k.ab.ca Wed Dec 30 17:23:42 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 30 Dec 2015 10:23:42 -0700 Subject: [openssl-dev] [openssl-users] Openssl 1.1 In-Reply-To: <4e8a341c7d7d4f549e98b16222d5f51e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20151230163521.GA8088@doctor.nl2k.ab.ca> <4e8a341c7d7d4f549e98b16222d5f51e@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20151230172342.GA17006@doctor.nl2k.ab.ca> On Wed, Dec 30, 2015 at 05:02:14PM +0000, Salz, Rich wrote: > > Are Openssh, DNS developers, SMTP/POP3/IMAP developers, FTP > > devleopers, HTTPD developers and LDAP developers aware of changes > > coming down the pipe? > > > > If not, they should be informed. > > We've posted about it several times. We're making explicit pre-release testing versions available. We've seen other folks (e.g., CURL) post about their experiences. Do you have any suggestions? We'd hate for 'surprises' to delay people to start using it. > We do our best to get this informing done. I do not know why yet, but I had a problem with openssh. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Happy Christmas 2015 and Merry New Year 2016 From rsalz at akamai.com Wed Dec 30 17:30:59 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 30 Dec 2015 17:30:59 +0000 Subject: [openssl-dev] [openssl-users] Openssl 1.1 In-Reply-To: <20151230172342.GA17006@doctor.nl2k.ab.ca> References: <20151230163521.GA8088@doctor.nl2k.ab.ca> <4e8a341c7d7d4f549e98b16222d5f51e@usma1ex-dag1mb1.msg.corp.akamai.com> <20151230172342.GA17006@doctor.nl2k.ab.ca> Message-ID: <285dbe4193af455786778e300987b8ca@usma1ex-dag1mb1.msg.corp.akamai.com> > We do our best to get this informing done. > > I do not know why yet, but I had a problem with openssh. Thank you very much for your help! Happy New Year. From quanah at zimbra.com Wed Dec 30 17:44:18 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Wed, 30 Dec 2015 09:44:18 -0800 Subject: [openssl-dev] Openssl 1.1 In-Reply-To: <2fefa670a9674b469a7d72d781351a64@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20151230163521.GA8088@doctor.nl2k.ab.ca> <4e8a341c7d7d4f549e98b16222d5f51e@usma1ex-dag1mb1.msg.corp.akamai.com> <9CE1D980F3D74F0AB5A7617D@[192.168.1.9]> <2fefa670a9674b469a7d72d781351a64@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <37CDA242B618B3FCAD3C67BA@[192.168.1.9]> --On Wednesday, December 30, 2015 5:24 PM +0000 "Salz, Rich" wrote: > >> So the term "ldap" caught my eye. What surprises are we talking about? >> ;) I can do some testing for OpenLDAP. I honestly haven't been paying >> exceedingly close attention to the 1.1 tree. > > We've made many changes to make various structures SSL, SSL_CTX, RSA, EVP > objects., etc., opaque. (Among other things, this makes future shared > lib updates easier.) So pulling down the master branch and doing a build > and seeing what breaks will be helpful. Great, I'll do that. :) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From rt at openssl.org Wed Dec 30 23:29:03 2015 From: rt at openssl.org (Rainer Jung via RT) Date: Wed, 30 Dec 2015 23:29:03 +0000 Subject: [openssl-dev] [openssl.org #4210] Compiler warning for Sparc T4 DES opcodes In-Reply-To: <56846513.5070605@kippdata.de> References: <56846513.5070605@kippdata.de> Message-ID: OpenSSL 1.1.0 Pre 1 Platform: Sparc Solaris 10 Compiler: GCC 4.9.3 Warnings: e_des.c: In function 'des_init_key': e_des.c:239:29: warning: assignment from incompatible pointer type dat->stream.cbc = enc ? des_t4_cbc_encrypt : des_t4_cbc_decrypt; ^ e_des3.c: In function 'des_ede_init_key': e_des3.c:266:29: warning: assignment from incompatible pointer type dat->stream.cbc = enc ? des_t4_ede3_cbc_encrypt : ^ e_des3.c: In function 'des_ede3_init_key': e_des3.c:293:29: warning: assignment from incompatible pointer type dat->stream.cbc = enc ? des_t4_ede3_cbc_encrypt : ^ Definition of stream.cbc is void (*cbc) (const void *, void *, size_t, const void *, void *); and the functions whose pointers are assigned have declarations: void des_t4_cbc_encrypt(const void *inp, void *out, size_t len, DES_key_schedule *ks, unsigned char iv[8]); void des_t4_cbc_decrypt(const void *inp, void *out, size_t len, DES_key_schedule *ks, unsigned char iv[8]); void des_t4_ede3_cbc_encrypt(const void *inp, void *out, size_t len, DES_key_schedule *ks, unsigned char iv[8]); void des_t4_ede3_cbc_decrypt(const void *inp, void *out, size_t len, DES_key_schedule *ks, unsigned char iv[8]); Problem likely introduced with https://github.com/openssl/openssl/commit/c5d975a74313268a36b6a6103cd37221724137c2 in 2013. Regards, Rainer _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Dec 27 11:55:25 2015 From: rt at openssl.org (Anton Prytkov via RT) Date: Sun, 27 Dec 2015 11:55:25 +0000 Subject: [openssl-dev] [openssl.org #4203] OpenSSL 1.0.2e. Failed build due to (possibly) wrong include of dummytest.c In-Reply-To: <1451217418.16256.9.camel@prytkov.com> References: <567E7056.2050005@prytkov.com> <20151226210322.GA791@roeckx.be> <567F080C.4040505@prytkov.com> <9l9u7b9chjcqlqpk4caph7d2bb35lmrrld@4ax.com> <1451217418.16256.9.camel@prytkov.com> Message-ID: It seems that Linux decompressors also have the problem with that symlinks too. Or links are actually broken (md2test.c, for example, points to "openssl-1.0.2e/dummytest.c"). I decompressed the archive with proposed "tar xvf openssl-1.0.2e.tar.gz". OS can't follow the symlinks because "the link is broken". Please see screenshot attached. Debian v8.1, tar v1.27.1 -- Best regards, Anton Prytkov On Sat, 2015-12-26 at 23:53 +0000, Jan Ehrhardt via RT wrote: > Anton Prytkov via RT in gmane.comp.encryption.openssl.devel (Sat, 26 Dec): > >P.S. I just checked the file "md2test.c" in openssl-1.0.2e.tar.gz. It's > >a 26-byte long file with "openssl-1.0.2e/dummytest.c" inside. > >No "#include " or anything else. > > It is a symlink. Standard Windows decompressors do not recognize that. I > always use 'tar' from Cygwin: > > c:\cygwin\bin\tar xvf openssl-1.0.2e.tar.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled.png Type: image/png Size: 101828 bytes Desc: not available URL: