From hubertlvg at gmail.com Sat Jul 1 00:35:11 2017 From: hubertlvg at gmail.com (Hubert Le Van Gong) Date: Fri, 30 Jun 2017 17:35:11 -0700 Subject: [openssl-dev] TLS1.3 NewSessionTicket format Message-ID: Greetings, We're doing some testings around TLS1.3 and in particular we're looking at session resumption. We've captured some of the NewSessionTicket msgs sent by the server (Nginx over openssl 1.1.1-dev) and have a hard time reconciling their format with draft 20 of the TLS1.3 spec. Here's the details: 04 00 00 e4 00 00 02 58 0a 4d cd d9 00 d0 e3 53 f7 54 bf f9 b1 af 89 e1 3f cc 27 4a 20 b6 01 75 2a 5c 1e 1a a0 7b c4 b1 63 a8 89 b4 5f 15 fb 87 02 9f e4 5c 2c d1 cb ca 4a ae 52 45 1a c9 bf 91 a3 47 02 1d 01 4b de f5 23 5e 25 e9 d3 d2 53 6e 98 cb 7c 69 25 db 89 1c c6 3e a6 10 fd ee 18 b3 f4 8a ac 50 d0 17 6c a2 93 fa 36 c5 44 7d 75 1c 98 cb 4f 42 66 3d b1 06 72 16 49 8f 07 05 c1 05 59 48 cc bf e5 12 f1 d4 bd e2 20 df 39 98 cf 29 d5 f5 09 7f df da 48 9d 74 10 19 cd 60 ac 7a c8 db de 1b 96 02 bc 1f 60 2b d5 49 48 ab 0a 45 5f 75 d5 a7 bb 99 ec 84 4c 43 4b 78 de 43 7f 90 e6 87 0a 62 7e ee 66 d1 cb 26 8f 36 9f 1a 09 ec e2 fb 65 5f 3d 0b 19 e1 06 55 09 e2 07 ae 5c 00 08 00 2a 00 04 00 00 40 00 The blue hex numbers (last 10 bytes) do correctly map to the only allowed extension, early_data and contains a max_early_data_size set to 16k). >From the TLS draft 20 spec, the red bytes (8 first bytes) are supposed to correspond to ticket_lifetime and ticket_age_add. The first issue is that the values of these fields seem very weird (04 00 00 e4 for lifetime??). Also, this would lead to the next 2 bytes containing the length of the ticket: 0a 4d i.e. 2637 bytes. This doesn't look right as the ticket length is clearly less than that. I should add that we have captured several NewSessionTicket and they all look similar, albeit with different ticket length value (even though the tickets actually have the same length). Can anyone think of what we are missing? Cheers, Hubert -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Sat Jul 1 16:08:42 2017 From: matt at openssl.org (Matt Caswell) Date: Sat, 1 Jul 2017 17:08:42 +0100 Subject: [openssl-dev] TLS1.3 NewSessionTicket format In-Reply-To: References: Message-ID: <54819cfe-675e-132e-3b5d-f0eeb3eae762@openssl.org> On 01/07/17 01:35, Hubert Le Van Gong wrote: > Greetings, > > We're doing some testings around TLS1.3 and in particular we're looking > at session resumption. > > We've captured some of the NewSessionTicket msgs sent by the server > (Nginx over openssl 1.1.1-dev) and have a hard time reconciling their > format with draft 20 of the TLS1.3 spec. > > Here's the details: > > 04 00 00 e4 00 00 02 58 0a 4d cd d9 00 d0 e3 53 > f7 54 bf f9 b1 af 89 e1 3f cc 27 4a 20 b6 01 75 > 2a 5c 1e 1a a0 7b c4 b1 63 a8 89 b4 5f 15 fb 87 > 02 9f e4 5c 2c d1 cb ca 4a ae 52 45 1a c9 bf 91 > a3 47 02 1d 01 4b de f5 23 5e 25 e9 d3 d2 53 6e > 98 cb 7c 69 25 db 89 1c c6 3e a6 10 fd ee 18 b3 > f4 8a ac 50 d0 17 6c a2 93 fa 36 c5 44 7d 75 1c > 98 cb 4f 42 66 3d b1 06 72 16 49 8f 07 05 c1 05 > 59 48 cc bf e5 12 f1 d4 bd e2 20 df 39 98 cf 29 > d5 f5 09 7f df da 48 9d 74 10 19 cd 60 ac 7a c8 > db de 1b 96 02 bc 1f 60 2b d5 49 48 ab 0a 45 5f > 75 d5 a7 bb 99 ec 84 4c 43 4b 78 de 43 7f 90 e6 > 87 0a 62 7e ee 66 d1 cb 26 8f 36 9f 1a 09 ec e2 > fb 65 5f 3d 0b 19 e1 06 55 09 e2 07 ae 5c 00 08 > 00 2a 00 04 00 00 40 00 > > The blue hex numbers (last 10 bytes) do correctly map to the only > allowed extension, early_data and contains a max_early_data_size set to > 16k). > > From the TLS draft 20 spec, the red bytes (8 first bytes) are supposed > to correspond to ticket_lifetime and ticket_age_add. > The first issue is that the values of these fields seem very weird (04 > 00 00 e4 for lifetime??). What you have captured is the message and the message header. The first byte (04) is the message type (NewSessionTicket) and the next three bytes (00 00 e4) are the message length. The next four bytes are the ticket_lifetime (00 00 02 58) and then the next four are the ticket_age_add (0a 4d cd d9). The next 2 are the length of the ticket (00 d0). Matt From steve at openssl.org Sat Jul 1 19:06:38 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Sat, 1 Jul 2017 19:06:38 +0000 Subject: [openssl-dev] How to define EVP_EncryptUpdate and EVP_EncryptFinal functions for an AES engine? (and a separate question re: padding) In-Reply-To: References: Message-ID: <20170701190638.GA3123@openssl.org> On Mon, Jun 26, 2017, Brett R. Nicholas wrote: > AFAIK (and please correct me if this is wrong) my init_key function is invoked by the EVP interface when I call the EVP_[En/De]cryptInit_ex function, and the do_cipher function is called upon EVP_[En/De]cryptUpdate. But how should I handle the EVP_[En/De]cryptFinal functions? Should I not be implementing them in my engine? Or am I missing something here.... > The do_cipher function is normally the low level block cipher function: it gets handed a multiple of the block size to encrypt/decrypt. The higher level EVP_EncryptUpdate and EVP_EncryptFinal functions perform padding and buffering internally and call the do_cipher function to encrypt a multiple of the block size. I saw "normally" because it is possible to specify the flag EVP_CIPH_FLAG_CUSTOM_CIPHER in the EVP_CIPHER structure and handle padding internally. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Sat Jul 1 19:29:13 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Sat, 1 Jul 2017 19:29:13 +0000 Subject: [openssl-dev] Dynamically adding a NID In-Reply-To: References: Message-ID: <20170701192913.GA4003@openssl.org> On Mon, Jun 26, 2017, Nicola Tuveri wrote: > Hi, > > I'm working on ENGINE development, and I have the need to add an NID for a > custom message digest, and eventually for ciphers and PKEY methods. > Some of the associated object don't (and won't ever) have an associated > OID, but I need to add them dynamically to avoid requiring patches to the > upstream OpenSSL code before being able to use my engine. > > I'm currently (ab)using OBJ_create() [0], but it looks like it requires to > specify a valid OID. > I know it is possible to have NIDs associated with objects without OID > (e.g. NID_siphash) when they are statically defined in OpenSSL source code, > but I cannot find a way to declare similar objects without OID dynamically. > > Before 1.1.0, when structures weren't opaque, I could manipulate the > contents of the created object directly and somehow work around this > limitation, but in 1.1.0 this is not possible. > > Does anyone know of the right way to dynamically create an NID associated > with an object without OID? > What do you want to do with the NID? Does it need to have a valid short name and/or long name associated with it (so OBJ_sn2nid etc work) but no valid OID or do you just need a NID value? You're right that currently OBJ_create() needs a valid OID passed to it: you can't pass a NULL to create an "OIDless NID" as you can by editing objects.txt. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From nicola.tuveri at tut.fi Sat Jul 1 22:20:34 2017 From: nicola.tuveri at tut.fi (Nicola Tuveri) Date: Sun, 2 Jul 2017 01:20:34 +0300 Subject: [openssl-dev] Dynamically adding a NID In-Reply-To: <20170701192913.GA4003@openssl.org> References: <20170701192913.GA4003@openssl.org> Message-ID: > > What do you want to do with the NID? Does it need to have a valid short > name > and/or long name associated with it (so OBJ_sn2nid etc work) but no valid > OID > or do you just need a NID value? > > You're right that currently OBJ_create() needs a valid OID passed to it: > you > can't pass a NULL to create an "OIDless NID" as you can by editing > objects.txt. > > Yes, that is exactly what I'm trying to achieve, an "OIDless OBJ", with NID, shortname and long name associated, but I would need to do that without editing objects.txt (requiring patching and recompilation for anyone willing to use my engine). I tried using OBJ_create() with NULL or an empty string for the OID, but currently it checks that the given OID is actually a valid one. Is there any workaround to avoid this other than issuing my own OID? Thanks, Nicola Tuveri -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sun Jul 2 00:51:09 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 2 Jul 2017 00:51:09 +0000 Subject: [openssl-dev] Dynamically adding a NID In-Reply-To: References: <20170701192913.GA4003@openssl.org> Message-ID: <49957eef9ca942caae969662f5b40b76@usma1ex-dag1mb1.msg.corp.akamai.com> > I tried using OBJ_create() with NULL or an empty string for the OID, but currently it checks that the given OID is actually a valid one. Is there any workaround to avoid this other than issuing my own OID? No. Just get an OID ARC, such as from the IETF Enterprise MIB [it's free] and throw it away. From beldmit at gmail.com Tue Jul 4 08:57:15 2017 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Tue, 4 Jul 2017 11:57:15 +0300 Subject: [openssl-dev] Compiler requirements Message-ID: Hello, What is the minimal version of the compiler to build openssl? Is it still required C89 compatibility or C99 standard can be used? Unfortunately, I did not find these requirements in documentation. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue Jul 4 11:08:21 2017 From: levitte at openssl.org (Richard Levitte) Date: Tue, 04 Jul 2017 13:08:21 +0200 (CEST) Subject: [openssl-dev] Compiler requirements In-Reply-To: References: Message-ID: <20170704.130821.850951500108769650.levitte@openssl.org> In message on Tue, 4 Jul 2017 11:57:15 +0300, Dmitry Belyavsky said: beldmit> Hello, beldmit> beldmit> What is the minimal version of the compiler to build openssl? beldmit> Is it still required C89 compatibility or C99 standard can be used? beldmit> beldmit> Unfortunately, I did not find these requirements in documentation. At the beginning of INSTALL, you will find a set of requirements. On of them is "an ANSI C compiler". Note that this primary covers language syntax. We do use libraries that came later, but then also guard them with a suitable check of __STDC_VERSION__ or similar, and use or provide alternate implementations when necessary. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Tue Jul 4 15:05:06 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 4 Jul 2017 15:05:06 +0000 Subject: [openssl-dev] Compiler requirements In-Reply-To: <20170704.130821.850951500108769650.levitte@openssl.org> References: <20170704.130821.850951500108769650.levitte@openssl.org> Message-ID: <2f548b68de1c47dfaa6a3b0107080a2d@usma1ex-dag1mb1.msg.corp.akamai.com> > beldmit> What is the minimal version of the compiler to build openssl? > beldmit> Is it still required C89 compatibility or C99 standard can be used? > beldmit> > beldmit> Unfortunately, I did not find these requirements in documentation. > > At the beginning of INSTALL, you will find a set of requirements. On of them > is "an ANSI C compiler". That doesn't answer the question :) Which version of ANSI C? I believe C89 is written down somewhere. From levitte at openssl.org Tue Jul 4 15:42:42 2017 From: levitte at openssl.org (Richard Levitte) Date: Tue, 04 Jul 2017 17:42:42 +0200 (CEST) Subject: [openssl-dev] Compiler requirements In-Reply-To: <2f548b68de1c47dfaa6a3b0107080a2d@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170704.130821.850951500108769650.levitte@openssl.org> <2f548b68de1c47dfaa6a3b0107080a2d@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20170704.174242.411944897339548185.levitte@openssl.org> In message <2f548b68de1c47dfaa6a3b0107080a2d at usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 4 Jul 2017 15:05:06 +0000, "Salz, Rich via openssl-dev" said: openssl-dev> > beldmit> What is the minimal version of the compiler to build openssl? openssl-dev> > beldmit> Is it still required C89 compatibility or C99 standard can be used? openssl-dev> > beldmit> openssl-dev> > beldmit> Unfortunately, I did not find these requirements in documentation. openssl-dev> > openssl-dev> > At the beginning of INSTALL, you will find a set of requirements. On of them openssl-dev> > is "an ANSI C compiler". openssl-dev> openssl-dev> That doesn't answer the question :) Which version of ANSI C? Ah, you're right, "ANSI C" is a bit of a loose target depending on who you ask. As far as I know, we refer to C89/C90 (they are essentially the same for our intents and purposes). openssl-dev> I believe C89 is written down somewhere. C89 is written nowhere in the source at least, nor is C90. We should probably clarify that. Speculating a bit, it's probably safe to say that C95 compiler is fine as well. C99, not so much, there's too much risk that we start excluding some platforms if we start using its features. Anyway, I don't think it's safe to upgrade our minimum expectations now. OpenSSL 1.2.0 would be a good time for such re-evaluations. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kurt at roeckx.be Tue Jul 4 17:34:07 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 4 Jul 2017 19:34:07 +0200 Subject: [openssl-dev] Compiler requirements In-Reply-To: <20170704.174242.411944897339548185.levitte@openssl.org> References: <20170704.130821.850951500108769650.levitte@openssl.org> <2f548b68de1c47dfaa6a3b0107080a2d@usma1ex-dag1mb1.msg.corp.akamai.com> <20170704.174242.411944897339548185.levitte@openssl.org> Message-ID: <20170704173406.zqr3rrtu4voigpgx@roeckx.be> On Tue, Jul 04, 2017 at 05:42:42PM +0200, Richard Levitte wrote: > In message <2f548b68de1c47dfaa6a3b0107080a2d at usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 4 Jul 2017 15:05:06 +0000, "Salz, Rich via openssl-dev" said: > > openssl-dev> > beldmit> What is the minimal version of the compiler to build openssl? > openssl-dev> > beldmit> Is it still required C89 compatibility or C99 standard can be used? > openssl-dev> > beldmit> > openssl-dev> > beldmit> Unfortunately, I did not find these requirements in documentation. > openssl-dev> > > openssl-dev> > At the beginning of INSTALL, you will find a set of requirements. On of them > openssl-dev> > is "an ANSI C compiler". > openssl-dev> > openssl-dev> That doesn't answer the question :) Which version of ANSI C? > > Ah, you're right, "ANSI C" is a bit of a loose target depending on who > you ask. As far as I know, we refer to C89/C90 (they are essentially > the same for our intents and purposes). > > openssl-dev> I believe C89 is written down somewhere. > > C89 is written nowhere in the source at least, nor is C90. We should > probably clarify that. > > > Speculating a bit, it's probably safe to say that C95 compiler is fine > as well. C99, not so much, there's too much risk that we start > excluding some platforms if we start using its features. Anyway, I > don't think it's safe to upgrade our minimum expectations now. > OpenSSL 1.2.0 would be a good time for such re-evaluations. I think the minimum requirement is C89 + support for "long long". A newer version shouldn't be a problem, it should work with a compiler that defaults to C11 for instance. Kurt From slonvpalto at gmail.com Wed Jul 5 12:16:12 2017 From: slonvpalto at gmail.com (slon v sobstvennom palto) Date: Wed, 5 Jul 2017 15:16:12 +0300 Subject: [openssl-dev] openssl s_server "-legacy_renegotiation" option was present in version 1.0.1u but removed in version 1.0.2a Message-ID: Hi, openssl command line utility "s_server" command "-legacy_renegotiation" option was present in version 1.0.1u but removed in version 1.0.2a. In the source code of 1.0.2a the option is still present in the on screen help but not parsed and handled in the source code. The source code file is apps/s_server.c I want to fix this and to return back the processing code so the option can be used in the latest openssl, if no objections. Thanks Oleg -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jul 5 12:21:30 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 5 Jul 2017 12:21:30 +0000 Subject: [openssl-dev] openssl s_server "-legacy_renegotiation" option was present in version 1.0.1u but removed in version 1.0.2a In-Reply-To: References: Message-ID: <7a535b584eac46c19fb901e8cf112eeb@usma1ex-dag1mb1.msg.corp.akamai.com> You might find that the SSL library doesn?t have the code to do the old-style insecure renegotiation. If it does, then it probably makes sense to support this as a debugging option. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Jul 5 12:30:51 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 5 Jul 2017 13:30:51 +0100 Subject: [openssl-dev] openssl s_server "-legacy_renegotiation" option was present in version 1.0.1u but removed in version 1.0.2a In-Reply-To: References: Message-ID: On 05/07/17 13:16, slon v sobstvennom palto wrote: > Hi, > openssl command line utility "s_server" command "-legacy_renegotiation" > option was present in version 1.0.1u but removed in version 1.0.2a. In > the source code of 1.0.2a the option is still present in the on screen > help but not parsed and handled in the source code. > > The source code file is apps/s_server.c This is not correct. The command is still processed in 1.0.2. It is handled by this line in s_server.c: https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/apps/s_server.c#L1300 Matt From steve at openssl.org Wed Jul 5 16:56:43 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 5 Jul 2017 16:56:43 +0000 Subject: [openssl-dev] Dynamically adding a NID In-Reply-To: <49957eef9ca942caae969662f5b40b76@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170701192913.GA4003@openssl.org> <49957eef9ca942caae969662f5b40b76@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20170705165643.GA27597@openssl.org> On Sun, Jul 02, 2017, Salz, Rich via openssl-dev wrote: > > I tried using OBJ_create() with NULL or an empty string for the OID, but currently it checks that the given OID is actually a valid one. Is there any workaround to avoid this other than issuing my own OID? > > No. Just get an OID ARC, such as from the IETF Enterprise MIB [it's free] and throw it away. If you create object without an OID it stops it being encoded or decoded as an ASN1_OBJECT: this is sometimes useful. Unfortunately there is currently no way to do this with OBJ_create(). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From mtstickney at gmail.com Sun Jul 9 03:22:28 2017 From: mtstickney at gmail.com (Matthew Stickney) Date: Sat, 8 Jul 2017 23:22:28 -0400 Subject: [openssl-dev] Windows system cert store Message-ID: Back in 2010, there was some discussion on this list of adding code to load certificates from the system cert store on Windows by default, since the default verification paths typically don't point to anything (this was ticket #2158, which was ultimately rejected). I have some interest in picking up where this was left off, but I'm a little out of my depth and have some questions. Last time around, the sticking point was certificate purposes: we don't want to add a certificate that's only trusted for client authentication as trusted for server authentication. I still need to figure out how to extract purposes from the windows certs, but I'm also having a hard time seeing how you'd set x509 purposes in openssl. Where should I be looking? -Matt Stickney From levitte at openssl.org Sun Jul 9 07:15:32 2017 From: levitte at openssl.org (Richard Levitte) Date: Sun, 09 Jul 2017 09:15:32 +0200 (CEST) Subject: [openssl-dev] Windows system cert store In-Reply-To: References: Message-ID: <20170709.091532.1695235345438518912.levitte@openssl.org> In message on Sat, 8 Jul 2017 23:22:28 -0400, Matthew Stickney said: mtstickney> Back in 2010, there was some discussion on this list of adding code to mtstickney> load certificates from the system cert store on Windows by default, mtstickney> since the default verification paths typically don't point to anything mtstickney> (this was ticket #2158, which was ultimately rejected). I have some mtstickney> interest in picking up where this was left off, but I'm a little out mtstickney> of my depth and have some questions. mtstickney> mtstickney> Last time around, the sticking point was certificate purposes: we mtstickney> don't want to add a certificate that's only trusted for client mtstickney> authentication as trusted for server authentication. I still need to mtstickney> figure out how to extract purposes from the windows certs, but I'm mtstickney> also having a hard time seeing how you'd set x509 purposes in openssl. mtstickney> Where should I be looking? I'm don't know the Windows cert API enough to know if there are purpose settings outside of the cert itself, so I won't be able to answer that. However, in the cert itself, there may be an extension called Extended Key Usage. Have a look at RFC 5280, 4.2.1.12 [0] for more info on them. You set them like any other extension, when creating a cert. Also, regarding retrieving arbitrary stuff (like certificates) from arbitrary sources (such as the system cert store), I'd like to point out the CAPI engine (engines/e_capi.c), which does have such functionality (it's quite a hack, in the most positive sense of the word), and to the recently added OSSL_STORE module (which was created for exactly this sort of purpose). The latter is still evolving, but the base line is in place. Cheers, Richard ----- [0] https://tools.ietf.org/html/rfc5280#section-4.2.1.12 -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From alokonmars at gmail.com Sun Jul 9 08:20:07 2017 From: alokonmars at gmail.com (Alok Sharma) Date: Sun, 9 Jul 2017 13:50:07 +0530 Subject: [openssl-dev] Windows system cert store In-Reply-To: References: <20170709.091532.1695235345438518912.levitte@openssl.org> Message-ID: Ljkikh9 On 09-Jul-2017 12:45 PM, "Richard Levitte" wrote: In message on Sat, 8 Jul 2017 23:22:28 -0400, Matthew Stickney < mtstickney at gmail.com> said: mtstickney> Back in 2010, there was some discussion on this list of adding code to mtstickney> load certificates from the system cert store on Windows by default, mtstickney> since the default verification paths typically don't point to anything mtstickney> (this was ticket #2158, which was ultimately rejected). I have some mtstickney> interest in picking up where this was left off, but I'm a little out mtstickney> of my depth and have some questions. mtstickney> mtstickney> Last time around, the sticking point was certificate purposes: we mtstickney> don't want to add a certificate that's only trusted for client mtstickney> authentication as trusted for server authentication. I still need to mtstickney> figure out how to extract purposes from the windows certs, but I'm mtstickney> also having a hard time seeing how you'd set x509 purposes in openssl. mtstickney> Where should I be looking? I'm don't know the Windows cert API enough to know if there are purpose settings outside of the cert itself, so I won't be able to answer that. However, in the cert itself, there may be an extension called Extended Key Usage. Have a look at RFC 5280, 4.2.1.12 [0] for more info on them. You set them like any other extension, when creating a cert. Also, regarding retrieving arbitrary stuff (like certificates) from arbitrary sources (such as the system cert store), I'd like to point out the CAPI engine (engines/e_capi.c), which does have such functionality (it's quite a hack, in the most positive sense of the word), and to the recently added OSSL_STORE module (which was created for exactly this sort of purpose). The latter is still evolving, but the base line is in place. Cheers, Richard ----- [0] https://tools.ietf.org/html/rfc5280#section-4.2.1.12 -- 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 brad at monetra.com Sun Jul 9 10:13:10 2017 From: brad at monetra.com (Brad House) Date: Sun, 9 Jul 2017 06:13:10 -0400 Subject: [openssl-dev] Windows system cert store In-Reply-To: References: Message-ID: On 7/8/17 11:22 PM, Matthew Stickney wrote: > Back in 2010, there was some discussion on this list of adding code to > load certificates from the system cert store on Windows by default, > since the default verification paths typically don't point to anything > (this was ticket #2158, which was ultimately rejected). I have some > interest in picking up where this was left off, but I'm a little out > of my depth and have some questions. > > Last time around, the sticking point was certificate purposes: we > don't want to add a certificate that's only trusted for client > authentication as trusted for server authentication. I still need to > figure out how to extract purposes from the windows certs, but I'm > also having a hard time seeing how you'd set x509 purposes in openssl. > Where should I be looking? > > -Matt Stickney I remember seeing that discussion, I'm not sure if additional certificate validation is necessary if you're just enumerating the ROOT certificate store in Windows. Here's code we use, obviously it would be good to know if this isn't correct for some reason from a security perspective: int SSL_CTX_load_os_trust(SSL_CTX *ctx) { HCERTSTORE hStore; PCCERT_CONTEXT pContext = NULL; X509_STORE *store; size_t count = 0; if (ctx == NULL) return 0; hStore = CertOpenSystemStore(0, "ROOT"); if (hStore == NULL) return 0; store = SSL_CTX_get_cert_store(ctx); while ((pContext=CertEnumCertificatesInStore(hStore, pContext)) != NULL) { X509 *x509 = d2i_X509(NULL, &pContext->pbCertEncoded, (long)pContext->cbCertEncoded); if (x509) { if (X509_STORE_add_cert(store, x509)) count++; X509_free(x509); } } CertFreeCertificateContext(pContext); CertCloseStore(hStore, 0); if (!count) return 0; return 1; } From kurt at roeckx.be Sun Jul 9 11:08:03 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 9 Jul 2017 13:08:03 +0200 Subject: [openssl-dev] Windows system cert store In-Reply-To: <20170709.091532.1695235345438518912.levitte@openssl.org> References: <20170709.091532.1695235345438518912.levitte@openssl.org> Message-ID: <20170709110803.cunfeangt6dyzfgv@roeckx.be> On Sun, Jul 09, 2017 at 09:15:32AM +0200, Richard Levitte wrote: > In message on Sat, 8 Jul 2017 23:22:28 -0400, Matthew Stickney said: > > mtstickney> Back in 2010, there was some discussion on this list of adding code to > mtstickney> load certificates from the system cert store on Windows by default, > mtstickney> since the default verification paths typically don't point to anything > mtstickney> (this was ticket #2158, which was ultimately rejected). I have some > mtstickney> interest in picking up where this was left off, but I'm a little out > mtstickney> of my depth and have some questions. > mtstickney> > mtstickney> Last time around, the sticking point was certificate purposes: we > mtstickney> don't want to add a certificate that's only trusted for client > mtstickney> authentication as trusted for server authentication. I still need to > mtstickney> figure out how to extract purposes from the windows certs, but I'm > mtstickney> also having a hard time seeing how you'd set x509 purposes in openssl. > mtstickney> Where should I be looking? > > I'm don't know the Windows cert API enough to know if there are > purpose settings outside of the cert itself, so I won't be able to > answer that. > > However, in the cert itself, there may be an extension called Extended > Key Usage. Have a look at RFC 5280, 4.2.1.12 [0] for more info on > them. You set them like any other extension, when creating a cert. I think the point is that he wants to have additional contraints on the root certificate that aren't in the X509 certificate itself. The root certificate mostly don't have an EKU. I would like to say that on Linux most people will also not have such additinal restrictions even if the root store provides such restrictions. OpenSSL allows you to set some restrictions with "trusted certificates", which are in a X509_AUX structure. See the x509 man page. Kurt From mtstickney at gmail.com Mon Jul 10 01:03:35 2017 From: mtstickney at gmail.com (Matthew Stickney) Date: Sun, 9 Jul 2017 21:03:35 -0400 Subject: [openssl-dev] Windows system cert store In-Reply-To: <20170709110803.cunfeangt6dyzfgv@roeckx.be> References: <20170709.091532.1695235345438518912.levitte@openssl.org> <20170709110803.cunfeangt6dyzfgv@roeckx.be> Message-ID: The Certificate Manager in Windows does allow you to change the trust settings for root certs (including the purposes reported by openssl x509 -purpose), although those changes don't appear to be reflected in the cert dumped from the store (so they must be stored externally). I think the original concern could have been one of two things (or possibly both): 1) assuming the cert itself has purpose information, that needs to be reflected in its use after being added to the cert store (I assume the verification code is already checking this if it's a property of the cert), or 2) that a user's choice to (un-)trust certain certificates is respected, however unusual. I'm not aware of any facility on Linux to modify the trust status of certs, so I think this is an issue unique to Windows. -Matt Stickney On Sun, Jul 9, 2017 at 7:08 AM, Kurt Roeckx wrote: > On Sun, Jul 09, 2017 at 09:15:32AM +0200, Richard Levitte wrote: >> In message on Sat, 8 Jul 2017 23:22:28 -0400, Matthew Stickney said: >> >> mtstickney> Back in 2010, there was some discussion on this list of adding code to >> mtstickney> load certificates from the system cert store on Windows by default, >> mtstickney> since the default verification paths typically don't point to anything >> mtstickney> (this was ticket #2158, which was ultimately rejected). I have some >> mtstickney> interest in picking up where this was left off, but I'm a little out >> mtstickney> of my depth and have some questions. >> mtstickney> >> mtstickney> Last time around, the sticking point was certificate purposes: we >> mtstickney> don't want to add a certificate that's only trusted for client >> mtstickney> authentication as trusted for server authentication. I still need to >> mtstickney> figure out how to extract purposes from the windows certs, but I'm >> mtstickney> also having a hard time seeing how you'd set x509 purposes in openssl. >> mtstickney> Where should I be looking? >> >> I'm don't know the Windows cert API enough to know if there are >> purpose settings outside of the cert itself, so I won't be able to >> answer that. >> >> However, in the cert itself, there may be an extension called Extended >> Key Usage. Have a look at RFC 5280, 4.2.1.12 [0] for more info on >> them. You set them like any other extension, when creating a cert. > > I think the point is that he wants to have additional contraints > on the root certificate that aren't in the X509 certificate > itself. The root certificate mostly don't have an EKU. > > I would like to say that on Linux most people will also not have > such additinal restrictions even if the root store provides such > restrictions. > > OpenSSL allows you to set some restrictions with "trusted > certificates", which are in a X509_AUX structure. See the x509 man > page. > > > Kurt > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From tshort at akamai.com Tue Jul 11 13:18:24 2017 From: tshort at akamai.com (Short, Todd) Date: Tue, 11 Jul 2017 13:18:24 +0000 Subject: [openssl-dev] Compiler requirements In-Reply-To: <20170704173406.zqr3rrtu4voigpgx@roeckx.be> References: <20170704.130821.850951500108769650.levitte@openssl.org> <2f548b68de1c47dfaa6a3b0107080a2d@usma1ex-dag1mb1.msg.corp.akamai.com> <20170704.174242.411944897339548185.levitte@openssl.org> <20170704173406.zqr3rrtu4voigpgx@roeckx.be> Message-ID: <0515C36D-86FD-40AE-A566-45FBAAA9151C@akamai.com> I think it?s more a matter of using new features in C11 that preclude compilation on older platforms, rather than the use of a C11 compiler itself. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Jul 4, 2017, at 1:34 PM, Kurt Roeckx > wrote: On Tue, Jul 04, 2017 at 05:42:42PM +0200, Richard Levitte wrote: In message <2f548b68de1c47dfaa6a3b0107080a2d at usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 4 Jul 2017 15:05:06 +0000, "Salz, Rich via openssl-dev" > said: openssl-dev> > beldmit> What is the minimal version of the compiler to build openssl? openssl-dev> > beldmit> Is it still required C89 compatibility or C99 standard can be used? openssl-dev> > beldmit> openssl-dev> > beldmit> Unfortunately, I did not find these requirements in documentation. openssl-dev> > openssl-dev> > At the beginning of INSTALL, you will find a set of requirements. On of them openssl-dev> > is "an ANSI C compiler". openssl-dev> openssl-dev> That doesn't answer the question :) Which version of ANSI C? Ah, you're right, "ANSI C" is a bit of a loose target depending on who you ask. As far as I know, we refer to C89/C90 (they are essentially the same for our intents and purposes). openssl-dev> I believe C89 is written down somewhere. C89 is written nowhere in the source at least, nor is C90. We should probably clarify that. Speculating a bit, it's probably safe to say that C95 compiler is fine as well. C99, not so much, there's too much risk that we start excluding some platforms if we start using its features. Anyway, I don't think it's safe to upgrade our minimum expectations now. OpenSSL 1.2.0 would be a good time for such re-evaluations. I think the minimum requirement is C89 + support for "long long". A newer version shouldn't be a problem, it should work with a compiler that defaults to C11 for instance. Kurt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Wed Jul 12 12:48:14 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 12 Jul 2017 12:48:14 +0000 Subject: [openssl-dev] Windows system cert store In-Reply-To: References: <20170709.091532.1695235345438518912.levitte@openssl.org> <20170709110803.cunfeangt6dyzfgv@roeckx.be> Message-ID: <20170712124814.GA9943@openssl.org> On Sun, Jul 09, 2017, Matthew Stickney wrote: > The Certificate Manager in Windows does allow you to change the trust > settings for root certs (including the purposes reported by openssl > x509 -purpose), although those changes don't appear to be reflected in > the cert dumped from the store (so they must be stored externally). > Yes they're external properties. The certificate encoding returned can't be modified of course because that would break the signature. I think I did some experiments with CertGetEnhancedKeyUsage() and CERT_FIND_PROP_ONLY_ENHKEY_USAGE_FLAG before. IIRC this reflected system settings but not those visible in the MSIE dialogs: that is changing the setting in MSIE didn't change the values returned by that API. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From mtstickney at gmail.com Wed Jul 12 15:26:24 2017 From: mtstickney at gmail.com (Matthew Stickney) Date: Wed, 12 Jul 2017 11:26:24 -0400 Subject: [openssl-dev] Windows system cert store In-Reply-To: <20170712124814.GA9943@openssl.org> References: <20170709.091532.1695235345438518912.levitte@openssl.org> <20170709110803.cunfeangt6dyzfgv@roeckx.be> <20170712124814.GA9943@openssl.org> Message-ID: On Wed, Jul 12, 2017 at 8:48 AM, Dr. Stephen Henson wrote: > Yes they're external properties. The certificate encoding returned can't be > modified of course because that would break the signature. That's a good point (I'm a little embarassed to have missed that). > I think I did some experiments with CertGetEnhancedKeyUsage()[...] It looks like another good candidate might be CertGetCertificateContextProperty() with the CERT_CTL_USAGE_PROP_ID flag. At least in principle, that's pulling usage information from the cert context, rather than the cert itself. I'll do some testing after work tonight. -Matt Stickney From utkarsh.tewari at sjsu.edu Wed Jul 12 21:46:43 2017 From: utkarsh.tewari at sjsu.edu (Utkarsh Tewari) Date: Wed, 12 Jul 2017 14:46:43 -0700 Subject: [openssl-dev] Performance test TLSv1.3 vs TLSv1.2 Message-ID: I have been running tests with OpenSSL 1.1.1dev[draft 20]. Here are the results I obtained(not considering early data) With average ping RTT between nodes: 0.32 ms TLSv1.2 full handshake 3.9234 ms TLSv1.3 full handshake 3.5499 ms TLS 1.2 Resumption(in-band) 0.6579 ms *TLSv1.3 Resumption(in-band) 1.3241 ms* Here, TLSv1.3 resumptions take almost double the time taken by TLSv1.2 resumptions. Did anyone else get similar results? I believe the reason is that the messages from the server are encrypted with handshake_traffic_secret and application_traffic_secret, which take additional time. Is that correct? Cheers, Utkarsh Tewari San Jose State University ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtstickney at gmail.com Fri Jul 14 01:43:51 2017 From: mtstickney at gmail.com (Matthew Stickney) Date: Thu, 13 Jul 2017 21:43:51 -0400 Subject: [openssl-dev] Windows system cert store In-Reply-To: References: <20170709.091532.1695235345438518912.levitte@openssl.org> <20170709110803.cunfeangt6dyzfgv@roeckx.be> <20170712124814.GA9943@openssl.org> Message-ID: I should have read the previous post more carefully: CertGetEnhancedKeyUsage() is definitely the function for returning the certificate usages reported by the system store manager (either the ones set in the cert itself, the ones in the "extended property" that can be set at will, or the effective combination of the two depending on the flags passed). You may have been looking at a different version of IE than what I've got on my Windows 7 VM, but at least here IE doesn't allow you to set certificate purposes: it has a dialog that looks just like that (under the "Advanced" button in the certificate list), but that's only used to select the set of usages you want to display if you choose "" in the "Intended Purpose" dropdown at the top (it's effectively just a customizable display filter). I've been reading through OpenSSL's verification code a bit, and from what I'm seeing it looks like purposes could be set for an existing certificate by setting the appropriate bits in the ex_kusage or ex_xkusage fields, at least for standard usages. Is that right? -Matt Stickney On Wed, Jul 12, 2017 at 11:26 AM, Matthew Stickney wrote: > On Wed, Jul 12, 2017 at 8:48 AM, Dr. Stephen Henson wrote: >> Yes they're external properties. The certificate encoding returned can't be >> modified of course because that would break the signature. > > That's a good point (I'm a little embarassed to have missed that). > > >> I think I did some experiments with CertGetEnhancedKeyUsage()[...] > > It looks like another good candidate might be > CertGetCertificateContextProperty() with the CERT_CTL_USAGE_PROP_ID > flag. At least in principle, that's pulling usage information from the > cert context, rather than the cert itself. I'll do some testing after > work tonight. > > -Matt Stickney From Doug.Smith at lairdtech.com Fri Jul 14 17:19:51 2017 From: Doug.Smith at lairdtech.com (Doug Smith) Date: Fri, 14 Jul 2017 17:19:51 +0000 Subject: [openssl-dev] TLS Alert response when certificate is not yet valid Message-ID: Developers, Is openssl sending the correct TLS alert message when certificate validation fails due to the received certificate being not yet valid? During TLS authentication, if certificate validation fails, a TLS alert is sent. If the received certificate has expired, AlertDescription certificate_expired(45) is being sent. If the received certificate is not yet valid, AlertDescription bad_certificate(42) is being sent. However, the TLS1.0 specification certificate_expired description appears to apply to the "not yet valid" case as well. >From the TLS1.0 specification (RFC2246, clause 7.2.2 Error Alerts): "certificate_expired A certificate has expired or is not currently valid." When certificate validation fails due to the certificate being not yet valid, should openssl be modified to send a TLS alert certificate_expired(45)? >From a network administrator perspective, this change would also group the date/time issues to the same TLS alert, assisting in identifying connection issues. Apologies if this issue has already been raised in the past. Regards, Doug PS: Observed with openssl-1.0.2k, using wpa_supplicant connecting to a freeradius server. See also the openssl code: ssl_verify_alarm_type() in trunk: or 1.0.2k:. From steve at openssl.org Fri Jul 14 23:24:55 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 14 Jul 2017 23:24:55 +0000 Subject: [openssl-dev] Windows system cert store In-Reply-To: References: <20170709.091532.1695235345438518912.levitte@openssl.org> <20170709110803.cunfeangt6dyzfgv@roeckx.be> <20170712124814.GA9943@openssl.org> Message-ID: <20170714232455.GA7933@openssl.org> On Thu, Jul 13, 2017, Matthew Stickney wrote: > > You may have been looking at a different version of IE than what I've > got on my Windows 7 VM, but at least here IE doesn't allow you to set > certificate purposes: it has a dialog that looks just like that (under > the "Advanced" button in the certificate list), but that's only used > to select the set of usages you want to display if you choose > "" in the "Intended Purpose" dropdown at the top > (it's effectively just a customizable display filter). > It's been a while since I looked at it yes. IIRC before when you selected a root (or other) certificate under the Details tab you could select "Edit Properties..." now the box is greyed out unless you run as administrator or select a user added certificate. > I've been reading through OpenSSL's verification code a bit, and from > what I'm seeing it looks like purposes could be set for an existing > certificate by setting the appropriate bits in the ex_kusage or > ex_xkusage fields, at least for standard usages. Is that right? > No those are just caches of the contents of the key usage and extended key usage extensions. The function you need to call is X509_add1_trust_object() for each trust setting. You could also call X509_alias_set1 to set the friendly name of the certificate. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rsalz at akamai.com Wed Jul 19 11:00:27 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 19 Jul 2017 11:00:27 +0000 Subject: [openssl-dev] RNG seeding Message-ID: There has been a great deal of useful discussion about how OpenSSL should seed its random number generator (CSPRNG). There's now a pull request that is mostly complete. Please take a look at https://github.com/openssl/openssl/pull/3956 and feel free to comment. In particular, https://github.com/richsalz/openssl/blob/rand-seed/crypto/rand/rand_unix.c has all supported seeding options for linux/unix systems; you can send feedback to me directly or post to the list. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From cristifati0 at gmail.com Thu Jul 20 20:44:42 2017 From: cristifati0 at gmail.com (Cristi Fati) Date: Thu, 20 Jul 2017 23:44:42 +0300 Subject: [openssl-dev] Fwd: openssl-fips build on cygwin 64bit In-Reply-To: References: Message-ID: Apologies for spam, if this isn't the right place: *Details*: - *cygwin* *64bit* running on *Win10* (*CYGWIN_NT-10.0 cfati-e5550-0 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin*) - *openssl-1.0.2l* - irrelevant - *openssl-fips-2.0.16* - can be reproduced with previous versions *make*, after *./config* yields (at the very beginning): " *cryptlib.c:1:0: error: CPU you selected does not support x86-64 instruction set* * /* crypto/cryptlib.c */* * ^* *cryptlib.c:1:0: error: CPU you selected does not support x86-64 instruction set* *make[1]: *** [: cryptlib.o] Error 1* " That is because in *openssl-fips-2.0.16*'s *Configure* (and *config* wrapper), 64bit *cygwin* is not handled. After fixing this, everything builds fine, and (don't mind the paths): " *$ ./bin/openssl.exe version -a* *OpenSSL 1.0.2l-fips 25 May 2017* *built on: Thu Jul 20 11:30:16 2017* *platform: Cygwin-x86_64* *options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)* *compiler: gcc -I. -I.. -I../include -D_WINDLL -DOPENSSL_PIC -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -I/cygdrive/e/Work/Dev/Fati/WinBuild/OPSWopenssl/fips-cyg/fips-build/include -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM* *OPENSSLDIR: "/cygdrive/e/Work/Dev/Fati/WinBuild/OPSWopenssl/fips-cyg/build/openssl"* " while the last lines of *make test*: " *PASS* *test_bad_dtls* *../util/shlib_wrap.sh ./bad_dtls_test* *make[1]: Leaving directory '/cygdrive/e/Work/Dev/Fati/WinBuild/OPSWopenssl/fips-cyg/openssl-1.0.2l/test'* " *Important note*: - Since I don't know (I can't say that I tried very hard to find out) where the code for *openssl-fips* is on GitHub (which branch, or whether it's even there), in order to create a pull request, I'm going to use the old way: attaching a patch. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-fips-2.0.16-cygwin_x86_64.patch Type: application/octet-stream Size: 1552 bytes Desc: not available URL: From steve at openssl.org Thu Jul 20 23:04:22 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 20 Jul 2017 23:04:22 +0000 Subject: [openssl-dev] Fwd: openssl-fips build on cygwin 64bit In-Reply-To: References: Message-ID: <20170720230422.GA17176@openssl.org> On Thu, Jul 20, 2017, Cristi Fati wrote: > Apologies for spam, if this isn't the right place: > > > *Details*: > > - *cygwin* *64bit* running on *Win10* (*CYGWIN_NT-10.0 cfati-e5550-0 > 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin*) > - *openssl-1.0.2l* - irrelevant > - *openssl-fips-2.0.16* - can be reproduced with previous versions > Cygwin is not a supported platform for FIPS builds. > - Since I don't know (I can't say that I tried very hard to find out) > where the code for *openssl-fips* is on GitHub > (which branch, or whether it's even > there), in order to create a pull request, I'm going to use the old way: > attaching a patch. There are two branches relating to the FIPS 2.0 module: OpenSSL-fips-2_0-dev and OpenSSL-fips-2_0-stable but since code changes have to be approved via a change letter or a complete new validation for some changes (both of which cost money) we can't just apply fixes. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From dfnsonfsduifb at gmx.de Fri Jul 21 09:41:00 2017 From: dfnsonfsduifb at gmx.de (Johannes Bauer) Date: Fri, 21 Jul 2017 11:41:00 +0200 Subject: [openssl-dev] Access to ECDSA_METHOD do_verify function from engine Message-ID: Hi list, I'm having the *exact* same issue that Jacques had 2 years ago: https://mta.openssl.org/pipermail/openssl-users/2015-June/001584.html I.e., I'm writing an OpenSSL 1.0.2 engine that does ECDSA signing. In my signing function, I want to verify the signature before leaving the callback. For that I need to use the *default* verification function. The problem is that ECDSA_METHOD is an opaque structure. It's only ever passed through reference (and has been forward-declared), but it's internal structure is defined in a localized crypto/ecdsa/ecs_locl.h header file. So two questions: When OpenSSL sees that the do_verify function in the callback has not been set, why does it not default to the internal definition instead of segfaulting? How do I get the function pointer to the default method do_verify? I.e., how do I do something like: ECDSA_METHOD_set_verify(ecdsa_method, ECDSA_get_default_method()->ecdsa_do_verify); Which currently (because of the opaque structure) results in: usockeng.c: In function ?bind_fn?: usockeng.c:341:66: error: dereferencing pointer to incomplete type ?ECDSA_METHOD {aka const struct ecdsa_method}? There were two replies two years ago, both which don't help me: R?my suggests (https://mta.openssl.org/pipermail/openssl-users/2015-June/001585.html) to define the engine's ECDSA_METHOD structure explicitly, like so: static ECDSA_METHOD my_own_openssl_ecdsa_meth = { "OpenSSL ECDSA method", my_own_ecdsa_do_sign_function, ecdsa_sign_setup_no_digest, ecdsa_do_verify, ... } This does not work (anymore?) because the stucture is opaque. Dmitry suggests (https://mta.openssl.org/pipermail/openssl-users/2015-June/001586.html) to use ECDSA_METHOD_set_sign_setup/ECDSA_METHOD_set_sign -- I don't understand this, since I did define set_sign (and it already works), but I need *verification*. Of course, the butt-ugly workaround would be to copy/paste the local structure definition in my engine code, creating a horribly unportable mess. But what's the *intended* way to solve this issue? Best regards, Johannes From deengert at gmail.com Fri Jul 21 12:00:33 2017 From: deengert at gmail.com (Douglas E Engert) Date: Fri, 21 Jul 2017 07:00:33 -0500 Subject: [openssl-dev] Access to ECDSA_METHOD do_verify function from engine In-Reply-To: References: Message-ID: First of all the ECDSA_METHOD and ECDH_METHOD in 1.0.2 are combined into EC_KEY_METHOD on 1.1. Both versions have a *_new and *_set_verify. "static ECDSA_METHOD my_own_openssl_ecdsa_meth" will not work anymore. Have a look at: https://github.com/OpenSC/libp11/blob/master/src/p11_ec.c It uses either: ops = ECDSA_METHOD_new((ECDSA_METHOD *)ECDSA_OpenSSL()); or ops = EC_KEY_METHOD_new((EC_KEY_METHOD *)EC_KEY_OpenSSL()); which copy the default structure to the new opaque structure. It then sets the routines it wants to change. On 7/21/2017 4:41 AM, Johannes Bauer wrote: > Hi list, > > I'm having the *exact* same issue that Jacques had 2 years ago: > https://mta.openssl.org/pipermail/openssl-users/2015-June/001584.html > > I.e., I'm writing an OpenSSL 1.0.2 engine that does ECDSA signing. In my > signing function, I want to verify the signature before leaving the > callback. For that I need to use the *default* verification function. > > The problem is that ECDSA_METHOD is an opaque structure. It's only ever > passed through reference (and has been forward-declared), but it's > internal structure is defined in a localized crypto/ecdsa/ecs_locl.h > header file. So two questions: > > When OpenSSL sees that the do_verify function in the callback has not > been set, why does it not default to the internal definition instead of > segfaulting? > > How do I get the function pointer to the default method do_verify? I.e., > how do I do something like: > > ECDSA_METHOD_set_verify(ecdsa_method, > ECDSA_get_default_method()->ecdsa_do_verify); > > Which currently (because of the opaque structure) results in: > > usockeng.c: In function ?bind_fn?: > usockeng.c:341:66: error: dereferencing pointer to incomplete type > ?ECDSA_METHOD {aka const struct ecdsa_method}? > > There were two replies two years ago, both which don't help me: > > R?my suggests > (https://mta.openssl.org/pipermail/openssl-users/2015-June/001585.html) > to define the engine's ECDSA_METHOD structure explicitly, like so: > > static ECDSA_METHOD my_own_openssl_ecdsa_meth = { > "OpenSSL ECDSA method", > my_own_ecdsa_do_sign_function, > ecdsa_sign_setup_no_digest, > ecdsa_do_verify, > ... > } > > This does not work (anymore?) because the stucture is opaque. > > Dmitry suggests > (https://mta.openssl.org/pipermail/openssl-users/2015-June/001586.html) > to use ECDSA_METHOD_set_sign_setup/ECDSA_METHOD_set_sign -- I don't > understand this, since I did define set_sign (and it already works), but > I need *verification*. > > Of course, the butt-ugly workaround would be to copy/paste the local > structure definition in my engine code, creating a horribly unportable > mess. But what's the *intended* way to solve this issue? > > Best regards, > Johannes > -- Douglas E. Engert From dfnsonfsduifb at gmx.de Fri Jul 21 12:19:52 2017 From: dfnsonfsduifb at gmx.de (Johannes Bauer) Date: Fri, 21 Jul 2017 14:19:52 +0200 Subject: [openssl-dev] Access to ECDSA_METHOD do_verify function from engine In-Reply-To: References: Message-ID: <87c38668-8ea4-a389-7456-b30b225bca1d@gmx.de> On 21.07.2017 14:00, Douglas E Engert wrote: > It uses either: > ops = ECDSA_METHOD_new((ECDSA_METHOD *)ECDSA_OpenSSL()); > or > ops = EC_KEY_METHOD_new((EC_KEY_METHOD *)EC_KEY_OpenSSL()); > > which copy the default structure to the new opaque structure. > It then sets the routines it wants to change. Ah, I missed this. Works perfectly, thank you very much for the tip. I've also ported the engine to work on both OpenSSL 1.0 and 1.1 -- however the cast to a (mutable) EC_KEY_METHOD* isn't necessary for 1.1 (where the prototype accepts a const EC_KEY_METHOD*). However, when I want to set the sign function for v1.1, I want to override sig_sign, but use the OpenSSL default sign and sign_setup functions. For this, I use EC_KEY_METHOD_get_sign. Unfortunately, for no obvious reason, EC_KEY_METHOD_get_sign requires a EC_KEY_METHOD* instead of a const EC_KEY_METHOD*. Do you happen to know why this is? Looking at the code, there doesn't seem to be a reason for it. Gives an ugly compile-time warning. Cheers, Johannes From deengert at gmail.com Fri Jul 21 13:08:32 2017 From: deengert at gmail.com (Douglas E Engert) Date: Fri, 21 Jul 2017 08:08:32 -0500 Subject: [openssl-dev] Access to ECDSA_METHOD do_verify function from engine In-Reply-To: <87c38668-8ea4-a389-7456-b30b225bca1d@gmx.de> References: <87c38668-8ea4-a389-7456-b30b225bca1d@gmx.de> Message-ID: <02d6c823-7d47-5ac6-9cfa-fe4074a4c049@gmail.com> On 7/21/2017 7:19 AM, Johannes Bauer wrote: > On 21.07.2017 14:00, Douglas E Engert wrote: > >> It uses either: >> ops = ECDSA_METHOD_new((ECDSA_METHOD *)ECDSA_OpenSSL()); >> or >> ops = EC_KEY_METHOD_new((EC_KEY_METHOD *)EC_KEY_OpenSSL()); >> >> which copy the default structure to the new opaque structure. >> It then sets the routines it wants to change. > > Ah, I missed this. Works perfectly, thank you very much for the tip. > > I've also ported the engine to work on both OpenSSL 1.0 and 1.1 -- > however the cast to a (mutable) EC_KEY_METHOD* isn't necessary for 1.1 > (where the prototype accepts a const EC_KEY_METHOD*). > > However, when I want to set the sign function for v1.1, I want to > override sig_sign, but use the OpenSSL default sign and sign_setup > functions. For this, I use EC_KEY_METHOD_get_sign. Unfortunately, for no > obvious reason, EC_KEY_METHOD_get_sign requires a EC_KEY_METHOD* instead > of a const EC_KEY_METHOD*. Do you happen to know why this is? Looking at > the code, there doesn't seem to be a reason for it. Gives an ugly > compile-time warning. I don't see your problem with OpenSSL-1.1.0f. I don't recall seeing it with earlier version either. p11_ec.c does: 647 static EC_KEY_METHOD *ops = NULL; 648 int (*orig_sign)(int, const unsigned char *, int, unsigned char *, 649 unsigned int *, const BIGNUM *, const BIGNUM *, EC_KEY *) = NULL; 653 ops = EC_KEY_METHOD_new((EC_KEY_METHOD *)EC_KEY_OpenSSL()); 654 EC_KEY_METHOD_get_sign(ops, &orig_sign, NULL, NULL); 655 EC_KEY_METHOD_set_sign(ops, orig_sign, NULL, pkcs11_ecdsa_sign_sig); > > Cheers, > Johannes > -- Douglas E. Engert From dfnsonfsduifb at gmx.de Fri Jul 21 13:56:20 2017 From: dfnsonfsduifb at gmx.de (Johannes Bauer) Date: Fri, 21 Jul 2017 15:56:20 +0200 Subject: [openssl-dev] Access to ECDSA_METHOD do_verify function from engine In-Reply-To: <02d6c823-7d47-5ac6-9cfa-fe4074a4c049@gmail.com> References: <87c38668-8ea4-a389-7456-b30b225bca1d@gmx.de> <02d6c823-7d47-5ac6-9cfa-fe4074a4c049@gmail.com> Message-ID: <1b2b67e5-bf9b-ab04-fc9b-d8823314c674@gmx.de> On 21.07.2017 15:08, Douglas E Engert wrote: > I don't see your problem with OpenSSL-1.1.0f. I don't recall seeing it with > earlier version either. p11_ec.c does: > > > 647 static EC_KEY_METHOD *ops = NULL; > 648 int (*orig_sign)(int, const unsigned char *, int, unsigned > char *, > 649 unsigned int *, const BIGNUM *, const BIGNUM *, > EC_KEY *) = NULL; > > 653 ops = EC_KEY_METHOD_new((EC_KEY_METHOD > *)EC_KEY_OpenSSL()); > 654 EC_KEY_METHOD_get_sign(ops, &orig_sign, NULL, NULL); > 655 EC_KEY_METHOD_set_sign(ops, orig_sign, NULL, > pkcs11_ecdsa_sign_sig); Ah, interesting! You call EC_KEY_METHOD_get_sign on the (inherited) copy of the EC_KEY_METHOD. I didn't, but called it on the original source (otherwise, very similar code): int (*openssl_sign)(int type, const unsigned char *dgst, int dlen, unsigned char *sig, unsigned int *siglen, const BIGNUM *kinv, const BIGNUM *r, EC_KEY *eckey) = NULL; int (*openssl_sign_setup)(EC_KEY *eckey, BN_CTX *ctx_in, BIGNUM **kinvp, BIGNUM **rp) = NULL; EC_KEY_METHOD_get_sign((EC_KEY_METHOD*)EC_KEY_OpenSSL(), &openssl_sign, &openssl_sign_setup, NULL); The case of EC_KEY_OpenSSL() from const EC_KEY_METHOD* to EC_KEY_METHOD* gives a -Wqual-cast diagnostic: usockeng.c:245:25: warning: cast discards ?const? qualifier from pointer target type [-Wcast-qual] EC_KEY_METHOD_get_sign((EC_KEY_METHOD*)EC_KEY_OpenSSL(), &openssl_sign, &openssl_sign_setup, NULL); I've changed my code now to also use the (mutable) new EC_KEY_METHOD*, which doesn't give a diagnostic. Regardless, I believe that the first parameter of EC_KEY_METHOD_get_sign should be const EC_KEY_METHOD*, not EC_KEY_METHOD*. Cheers, Johannes From tmraz at redhat.com Fri Jul 21 14:10:57 2017 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 21 Jul 2017 16:10:57 +0200 Subject: [openssl-dev] Access to ECDSA_METHOD do_verify function from engine In-Reply-To: <1b2b67e5-bf9b-ab04-fc9b-d8823314c674@gmx.de> References: <87c38668-8ea4-a389-7456-b30b225bca1d@gmx.de> <02d6c823-7d47-5ac6-9cfa-fe4074a4c049@gmail.com> <1b2b67e5-bf9b-ab04-fc9b-d8823314c674@gmx.de> Message-ID: <1500646257.16982.15.camel@redhat.com> On Fri, 2017-07-21 at 15:56 +0200, Johannes Bauer wrote: > I've changed my code now to also use the (mutable) new > EC_KEY_METHOD*, > which doesn't give a diagnostic. Regardless, I believe that the first > parameter of EC_KEY_METHOD_get_sign should be const EC_KEY_METHOD*, > not > EC_KEY_METHOD*. Just open a github issue or better pull request with this change. -- Tom?? Mr?z Red Hat No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] * Google and NSA associates, this message is none of your business. * Please leave it alone, and consider whether your actions are * authorized by the contract with Red Hat, or by the US constitution. * If you feel you're being encouraged to disregard the limits built * into them, remember Edward Snowden and Wikileaks. From dfnsonfsduifb at gmx.de Fri Jul 21 18:06:51 2017 From: dfnsonfsduifb at gmx.de (Johannes Bauer) Date: Fri, 21 Jul 2017 20:06:51 +0200 Subject: [openssl-dev] Access to ECDSA_METHOD do_verify function from engine In-Reply-To: <1500646257.16982.15.camel@redhat.com> References: <87c38668-8ea4-a389-7456-b30b225bca1d@gmx.de> <02d6c823-7d47-5ac6-9cfa-fe4074a4c049@gmail.com> <1b2b67e5-bf9b-ab04-fc9b-d8823314c674@gmx.de> <1500646257.16982.15.camel@redhat.com> Message-ID: On 21.07.2017 16:10, Tomas Mraz wrote: > On Fri, 2017-07-21 at 15:56 +0200, Johannes Bauer wrote: >> I've changed my code now to also use the (mutable) new >> EC_KEY_METHOD*, >> which doesn't give a diagnostic. Regardless, I believe that the first >> parameter of EC_KEY_METHOD_get_sign should be const EC_KEY_METHOD*, >> not >> EC_KEY_METHOD*. > > Just open a github issue or better pull request with this change. Done. https://github.com/openssl/openssl/pull/3985 Cheers, Johannes From uri at ll.mit.edu Fri Jul 21 22:12:04 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 21 Jul 2017 18:12:04 -0400 Subject: [openssl-dev] Master: test fails Message-ID: <09E62240-8961-4ECF-8EB4-2B300E4A1282@ll.mit.edu> $ make distclean || true $ ./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc enable-aria enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-weak-ssl-ciphers enable-zlib-dynamic enable-tls1_3 enable-tls13downgrademake depend && make clean && make -j 4 all && make test . . . . . ../test/recipes/99-test_fuzz.t ..................... ok Test Summary Report ------------------- ../test/recipes/70-test_tls13messages.t (Wstat: 13 Tests: 13 Failed: 0) Non-zero wait status: 13 Parse errors: Bad plan. You planned 16 tests but ran 13. Files=130, Tests=1257, 392 wallclock secs ( 2.60 usr 0.50 sys + 190.86 cusr 109.06 csys = 303.02 CPU) Result: FAIL make[1]: *** [_tests] Error 1 ? Regards, Uri -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfnsonfsduifb at gmx.de Sat Jul 22 18:26:56 2017 From: dfnsonfsduifb at gmx.de (Johannes Bauer) Date: Sat, 22 Jul 2017 20:26:56 +0200 Subject: [openssl-dev] scrypt as a PKEY KDF Message-ID: Hi list, I've been trying for a while to get scrypt and PBKDF2 exposed via the command line interface. My original attempt was rejected and I thought I wouldn't care anymore. But then I picked it up and implemented the route that Stephen suggested (https://github.com/openssl/openssl/pull/1533). Surprisingly, it wasn't too difficult and I have a first shot that somwhat works with scrypt. Much of the work was figuring out how/where to properly register NIDs and such. So now I do have two questions. First, could someone please provide feedback if this is generally the correct way I'm going at it? Secondly, I'm having a concrete and really bad issue: failing tests. I haven't actually *added* tests for the scrypt PKEY yet and am seeing failing tests in the PKEY facility at places that I haven't touched -- therefore, I'm completely clueless why this is happening. Concretely, this is what I'm seeing: $ TESTS=30 HARNESS_VERBOSE=1 make test [...] # INFO: @ test/evp_test.c:2263 # recipes/30-test_evp_data/evpmac.txt:20: Source of above error; unexpected error MAC_PKEY_CTX_ERROR # 140208181980992:error:0609D09C:digital envelope routines:int_ctx_new:unsupported algorithm:crypto/evp/pmeth_lib.c:130: # ERROR: (ptr) 'genctx = EVP_PKEY_CTX_new_id(expected->type, NULL) != NULL' failed @ test/evp_test.c:900 # 0x0 [... # INFO: @ test/evp_test.c:2263 # recipes/30-test_evp_data/evppkey.txt:17379: Source of above error; unexpected error DIGESTSIGNINIT_ERROR # 139826426584896:error:0609D09C:digital envelope routines:int_ctx_new:unsupported algorithm:crypto/evp/pmeth_lib.c:130: # INFO: @ test/evp_test.c:2263 # recipes/30-test_evp_data/evppkey.txt:17386: Source of above error; unexpected error DIGESTSIGNINIT_ERROR # 139826426584896:error:0609D09C:digital envelope routines:int_ctx_new:unsupported algorithm:crypto/evp/pmeth_lib.c:130: They point to test source data of SipHash and somewhere in Ed25519 code. Nothing I've touched in a mile. Yet, clearly, my branch is the source of the error. So any pointers on what I messed up would be very much appreciated. You can view my code at https://github.com/openssl/openssl/compare/master...johndoe31415:new_kdfs Thanks for your time, Cheers, Johannes From rsalz at akamai.com Sat Jul 22 18:40:44 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 22 Jul 2017 18:40:44 +0000 Subject: [openssl-dev] Master: test fails In-Reply-To: <09E62240-8961-4ECF-8EB4-2B300E4A1282@ll.mit.edu> References: <09E62240-8961-4ECF-8EB4-2B300E4A1282@ll.mit.edu> Message-ID: Wow that green is hard to read ? So your config options change the tests for 70-test-tls13messages, but the plan isn?t updated, right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Sun Jul 23 02:22:51 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Sun, 23 Jul 2017 02:22:51 +0000 Subject: [openssl-dev] Master: test fails In-Reply-To: References: <09E62240-8961-4ECF-8EB4-2B300E4A1282@ll.mit.edu> Message-ID: <1437DEE5-D77A-4E58-8A15-4ED8317B97AE@ll.mit.edu> Sure looks like that... Regards, Uri Sent from my iPhone > On Jul 22, 2017, at 14:41, Salz, Rich via openssl-dev wrote: > > Wow that green is hard to read J > > So your config options change the tests for 70-test-tls13messages, but the plan isn?t updated, right? > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4223 bytes Desc: not available URL: From rsalz at akamai.com Sun Jul 23 13:17:09 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 23 Jul 2017 13:17:09 +0000 Subject: [openssl-dev] Master: test fails In-Reply-To: <1437DEE5-D77A-4E58-8A15-4ED8317B97AE@ll.mit.edu> References: <09E62240-8961-4ECF-8EB4-2B300E4A1282@ll.mit.edu> <1437DEE5-D77A-4E58-8A15-4ED8317B97AE@ll.mit.edu> Message-ID: <1dcd239d5cf04217aea7a232de2af791@usma1ex-dag1mb1.msg.corp.akamai.com> So what are your exact config options? Just the ?./config? line. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz From: Blumenthal, Uri - 0553 - MITLL [mailto:uri at ll.mit.edu] Sent: Saturday, July 22, 2017 10:23 PM To: Salz, Rich ; openssl-dev at openssl.org Subject: Re: [openssl-dev] Master: test fails Sure looks like that... Regards, Uri Sent from my iPhone On Jul 22, 2017, at 14:41, Salz, Rich via openssl-dev > wrote: Wow that green is hard to read ? So your config options change the tests for 70-test-tls13messages, but the plan isn?t updated, right? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Mon Jul 24 01:06:17 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Sun, 23 Jul 2017 21:06:17 -0400 Subject: [openssl-dev] Master: test fails In-Reply-To: <1dcd239d5cf04217aea7a232de2af791@usma1ex-dag1mb1.msg.corp.akamai.com> References: <09E62240-8961-4ECF-8EB4-2B300E4A1282@ll.mit.edu> <1437DEE5-D77A-4E58-8A15-4ED8317B97AE@ll.mit.edu> <1dcd239d5cf04217aea7a232de2af791@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <1096C723-BF5F-49D2-BF9C-06D1FD0FA046@ll.mit.edu> On Jul 23, 2017, at 09:17, Salz, Rich wrote: > > So what are your exact config options? Just the ?./config? line. Simple: ./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc enable-aria enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-weak-ssl-ciphers enable-zlib-dynamic enable-tls1_3 enable-tls13downgrade -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Tue Jul 25 00:33:53 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 25 Jul 2017 00:33:53 +0000 Subject: [openssl-dev] Master: test fails In-Reply-To: <1096C723-BF5F-49D2-BF9C-06D1FD0FA046@ll.mit.edu> References: <09E62240-8961-4ECF-8EB4-2B300E4A1282@ll.mit.edu> <1437DEE5-D77A-4E58-8A15-4ED8317B97AE@ll.mit.edu> <1dcd239d5cf04217aea7a232de2af791@usma1ex-dag1mb1.msg.corp.akamai.com> <1096C723-BF5F-49D2-BF9C-06D1FD0FA046@ll.mit.edu> Message-ID: <1EE4A95E-073A-47B0-8C21-FE7240D11CF5@ll.mit.edu> CI does not seem to flag/manifest this error any more. -- Regards, Uri From: openssl-dev on behalf of Uri Blumenthal Reply-To: openssl-dev Date: Sunday, July 23, 201730 at 21:06 To: Rich Salz Cc: openssl-dev Subject: Re: [openssl-dev] Master: test fails On Jul 23, 2017, at 09:17, Salz, Rich wrote: So what are your exact config options? Just the ?./config? line. Simple: ./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc enable-aria enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-weak-ssl-ciphers enable-zlib-dynamic enable-tls1_3 enable-tls13downgrade -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From mtstickney at gmail.com Tue Jul 25 18:52:50 2017 From: mtstickney at gmail.com (Matthew Stickney) Date: Tue, 25 Jul 2017 14:52:50 -0400 Subject: [openssl-dev] Build issue Message-ID: I've been trying to build OpenSSL to work on a new feature, but I've had problems with the build hanging. I'm building on Windows 10 with mingw-w64 under msys2; perl is v5.24, and I installed the Text::Template module from CPAN. I'm not sure what's relevant, but the hang is definitely in a perl script of some sort, because there's a perl.exe process uses a constant chunk of CPU (I suspect this might be a busy-wait, but I don't know for sure). There are some odd errors before the hang; I've pasted the log below. Any ideas? I'm happy to provide more information if that's needed. -Matt Stickney make[2]: Entering directory '/c/Users/mts/Desktop/openssl' File include/openssl/ssl.h: cannot parse: ()())) #INFO::; File include/openssl/ssl.h: cannot parse: ()())) #INFO::DEPRECATEDIN_1_1_0; File include/openssl/ssl.h: cannot parse: () #INFO::; File include/openssl/ssl.h: cannot parse: () enum; File include/openssl/tls1.h: cannot parse: () #INFO::; File include/openssl/tls1.h: cannot parse: () #INFO::; File include/openssl/asn1.h: cannot parse: () #INFO::; File include/openssl/asn1.h: cannot parse: () #INFO::; File include/openssl/asn1.h: cannot parse: () #INFO::; File include/openssl/asn1.h: cannot parse: () #INFO::; File include/openssl/asn1.h: cannot parse: () #INFO::; File include/openssl/asn1.h: cannot parse: () #INFO::; File include/openssl/asn1.h: cannot parse: () #INFO::; File include/openssl/asn1.h: cannot parse: () #INFO::; File include/openssl/asn1.h: cannot parse: () #INFO::; File include/openssl/bio.h: cannot parse: ()()) #INFO::; File include/openssl/bio.h: cannot parse: ()()) #INFO::; File include/openssl/bio.h: cannot parse: ()()) #INFO::; File include/openssl/bio.h: cannot parse: ()()) #INFO::; File include/openssl/bio.h: cannot parse: ()()) #INFO::; File include/openssl/bio.h: cannot parse: ()()) #INFO::; File include/openssl/bio.h: cannot parse: BIO_CLOSE|BIO_FP_READ,()()) #INFO::; File include/openssl/bio.h: cannot parse: ()()) #INFO::; File include/openssl/cms.h: cannot parse: () #INFO::; <-- hang happens here --> make[2]: *** [Makefile.shared:260: link_shlib.mingw] Interrupt make[1]: *** [Makefile:655: libcrypto.dll.a] Interrupt make: *** [Makefile:136: all] Interrupt From bkaduk at akamai.com Tue Jul 25 18:56:19 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 25 Jul 2017 13:56:19 -0500 Subject: [openssl-dev] Build issue In-Reply-To: References: Message-ID: <4c29bc5c-46e5-5e23-b996-4be21f708486@akamai.com> On 07/25/2017 01:52 PM, Matthew Stickney wrote: > I've been trying to build OpenSSL to work on a new feature, but I've > had problems with the build hanging. I'm building on Windows 10 with > mingw-w64 under msys2; perl is v5.24, and I installed the > Text::Template module from CPAN. > You did not show the config line used, which is perhaps relevant. Also, presumably the perl is the msys perl, but please confirm -- it must be "matching" in order for things to work. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue Jul 25 18:59:01 2017 From: levitte at openssl.org (Richard Levitte) Date: Tue, 25 Jul 2017 20:59:01 +0200 (CEST) Subject: [openssl-dev] Build issue In-Reply-To: References: Message-ID: <20170725.205901.2091843445588818197.levitte@openssl.org> In message on Tue, 25 Jul 2017 14:52:50 -0400, Matthew Stickney said: mtstickney> I've been trying to build OpenSSL to work on a new feature, but I've mtstickney> had problems with the build hanging. I'm building on Windows 10 with mtstickney> mingw-w64 under msys2; perl is v5.24, and I installed the mtstickney> Text::Template module from CPAN. mtstickney> mtstickney> I'm not sure what's relevant, but the hang is definitely in a perl mtstickney> script of some sort, because there's a perl.exe process uses a mtstickney> constant chunk of CPU (I suspect this might be a busy-wait, but I mtstickney> don't know for sure). There are some odd errors before the hang; I've mtstickney> pasted the log below. mtstickney> mtstickney> Any ideas? I'm happy to provide more information if that's needed. mtstickney> mtstickney> -Matt Stickney mtstickney> mtstickney> make[2]: Entering directory '/c/Users/mts/Desktop/openssl' mtstickney> File include/openssl/ssl.h: cannot parse: ()())) mtstickney> #INFO::; This is an issue with util/mkdef.pl. Can you state what OpenSSL version this is, or if it's a git checkout and if it is, the ID of the top commit (take the output of 'git show HEAD --oneline | head -1')? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From mtstickney at gmail.com Tue Jul 25 19:18:35 2017 From: mtstickney at gmail.com (Matthew Stickney) Date: Tue, 25 Jul 2017 15:18:35 -0400 Subject: [openssl-dev] Build issue In-Reply-To: <20170725.205901.2091843445588818197.levitte@openssl.org> References: <20170725.205901.2091843445588818197.levitte@openssl.org> Message-ID: I'm away from the machine in question right now, but: > Also, presumably the perl is the msys perl, but please confirm -- it must be "matching" in order for things to work. It's definitely the msys perl. I'll check the config line tonight, but I'm virtually certain that it was "./config" in it's entirety. > Can you state what OpenSSL version this is I'll get the commit hash tonight, but this was the tip of master as of about 9pm EDT last night, so I'd imagine that util/mkdef.pl in master still has whatever the issue is. -Matt Stickney On Tue, Jul 25, 2017 at 2:59 PM, Richard Levitte wrote: > In message on Tue, 25 Jul 2017 14:52:50 -0400, Matthew Stickney said: > > mtstickney> I've been trying to build OpenSSL to work on a new feature, but I've > mtstickney> had problems with the build hanging. I'm building on Windows 10 with > mtstickney> mingw-w64 under msys2; perl is v5.24, and I installed the > mtstickney> Text::Template module from CPAN. > mtstickney> > mtstickney> I'm not sure what's relevant, but the hang is definitely in a perl > mtstickney> script of some sort, because there's a perl.exe process uses a > mtstickney> constant chunk of CPU (I suspect this might be a busy-wait, but I > mtstickney> don't know for sure). There are some odd errors before the hang; I've > mtstickney> pasted the log below. > mtstickney> > mtstickney> Any ideas? I'm happy to provide more information if that's needed. > mtstickney> > mtstickney> -Matt Stickney > mtstickney> > mtstickney> make[2]: Entering directory '/c/Users/mts/Desktop/openssl' > mtstickney> File include/openssl/ssl.h: cannot parse: ()())) > mtstickney> #INFO::; > > This is an issue with util/mkdef.pl. > > Can you state what OpenSSL version this is, or if it's a git checkout > and if it is, the ID of the top commit (take the output of > 'git show HEAD --oneline | head -1')? > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From levitte at openssl.org Tue Jul 25 22:12:10 2017 From: levitte at openssl.org (Richard Levitte) Date: Wed, 26 Jul 2017 00:12:10 +0200 (CEST) Subject: [openssl-dev] Build issue In-Reply-To: References: <20170725.205901.2091843445588818197.levitte@openssl.org> Message-ID: <20170726.001210.2062515907518977857.levitte@openssl.org> Could it be that this patch fixes the issue? diff --git a/util/mkdef.pl b/util/mkdef.pl index b3eb6b3d9d..1f214dbb8b 100755 --- a/util/mkdef.pl +++ b/util/mkdef.pl @@ -876,7 +876,7 @@ sub do_defs # Reduce argument lists to empty () # fold round brackets recursively: (t(*v)(t),t) -> (t{}{},t) -> {} while(/\(.*\)/s) { - s/\([^\(\)]+\)/\{\}/gs; + s/\([^\(\)]*\)/\{\}/gs; s/\(\s*\*\s*(\w+)\s*\{\}\s*\)/$1/gs; #(*f{}) -> f } # pretend as we didn't use curly braces: {} -> () In message on Tue, 25 Jul 2017 15:18:35 -0400, Matthew Stickney said: mtstickney> I'm away from the machine in question right now, but: mtstickney> mtstickney> > Also, presumably the perl is the msys perl, but please confirm -- it must be "matching" in order for things to work. mtstickney> mtstickney> It's definitely the msys perl. I'll check the config line tonight, but mtstickney> I'm virtually certain that it was "./config" in it's entirety. mtstickney> mtstickney> > Can you state what OpenSSL version this is mtstickney> mtstickney> I'll get the commit hash tonight, but this was the tip of master as of mtstickney> about 9pm EDT last night, so I'd imagine that util/mkdef.pl in master mtstickney> still has whatever the issue is. mtstickney> mtstickney> -Matt Stickney mtstickney> mtstickney> On Tue, Jul 25, 2017 at 2:59 PM, Richard Levitte wrote: mtstickney> > In message on Tue, 25 Jul 2017 14:52:50 -0400, Matthew Stickney said: mtstickney> > mtstickney> > mtstickney> I've been trying to build OpenSSL to work on a new feature, but I've mtstickney> > mtstickney> had problems with the build hanging. I'm building on Windows 10 with mtstickney> > mtstickney> mingw-w64 under msys2; perl is v5.24, and I installed the mtstickney> > mtstickney> Text::Template module from CPAN. mtstickney> > mtstickney> mtstickney> > mtstickney> I'm not sure what's relevant, but the hang is definitely in a perl mtstickney> > mtstickney> script of some sort, because there's a perl.exe process uses a mtstickney> > mtstickney> constant chunk of CPU (I suspect this might be a busy-wait, but I mtstickney> > mtstickney> don't know for sure). There are some odd errors before the hang; I've mtstickney> > mtstickney> pasted the log below. mtstickney> > mtstickney> mtstickney> > mtstickney> Any ideas? I'm happy to provide more information if that's needed. mtstickney> > mtstickney> mtstickney> > mtstickney> -Matt Stickney mtstickney> > mtstickney> mtstickney> > mtstickney> make[2]: Entering directory '/c/Users/mts/Desktop/openssl' mtstickney> > mtstickney> File include/openssl/ssl.h: cannot parse: ()())) mtstickney> > mtstickney> #INFO::; mtstickney> > mtstickney> > This is an issue with util/mkdef.pl. mtstickney> > mtstickney> > Can you state what OpenSSL version this is, or if it's a git checkout mtstickney> > and if it is, the ID of the top commit (take the output of mtstickney> > 'git show HEAD --oneline | head -1')? mtstickney> > mtstickney> > Cheers, mtstickney> > Richard mtstickney> > mtstickney> > -- mtstickney> > Richard Levitte levitte at openssl.org mtstickney> > OpenSSL Project http://www.openssl.org/~levitte/ mtstickney> > -- mtstickney> > openssl-dev mailing list mtstickney> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev mtstickney> -- mtstickney> openssl-dev mailing list mtstickney> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev mtstickney> From mtstickney at gmail.com Wed Jul 26 00:49:14 2017 From: mtstickney at gmail.com (Matthew Stickney) Date: Tue, 25 Jul 2017 20:49:14 -0400 Subject: [openssl-dev] Build issue In-Reply-To: <20170726.001210.2062515907518977857.levitte@openssl.org> References: <20170725.205901.2091843445588818197.levitte@openssl.org> <20170726.001210.2062515907518977857.levitte@openssl.org> Message-ID: Possibly. The original errors and hanging perl process have been replaced with an enormous number of "undefined reference" errors. For example: libssl.a(tls_srp.o):tls_srp.c:(.text+0xc4c): undefined reference to `BN_ucmp' libssl.a(tls_srp.o):tls_srp.c:(.text+0xd45): undefined reference to `OPENSSL_cleanse' libssl.a(tls_srp.o):tls_srp.c:(.text+0xd5f): undefined reference to `SRP_Calc_A' collect2.exe: error: ld returned 1 exit status I don't know enough about the build system to know whether the mkdef.pl change might be responsible for this, or whether this is a separate issue. To follow up on my previous post, the configure line was indeed "./config", and this is commit 1843787173. Any other data that I should collect? -Matt Stickney From ebrun at haproxy.com Wed Jul 26 13:15:46 2017 From: ebrun at haproxy.com (Emeric Brun) Date: Wed, 26 Jul 2017 15:15:46 +0200 Subject: [openssl-dev] Fix a dead lock of async engine. Message-ID: <8d933b4c-c9eb-1028-9437-fd021e47bebc@haproxy.com> Hi All, This bug also affects the 1.1.0 R, Emeric -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-async-engine-dead-lock-in-error-case-in-ossl_ran.patch Type: text/x-patch Size: 761 bytes Desc: not available URL: From bkaduk at akamai.com Wed Jul 26 13:45:35 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 26 Jul 2017 08:45:35 -0500 Subject: [openssl-dev] Fix a dead lock of async engine. In-Reply-To: <8d933b4c-c9eb-1028-9437-fd021e47bebc@haproxy.com> References: <8d933b4c-c9eb-1028-9437-fd021e47bebc@haproxy.com> Message-ID: On 07/26/2017 08:15 AM, Emeric Brun wrote: > Hi All, > > This bug also affects the 1.1.0 > Are you able to submit the patch as a github pull request? That would be the preferred form, as it enables some automation that we have for CLA checks and CI. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebrun at haproxy.com Wed Jul 26 13:47:19 2017 From: ebrun at haproxy.com (Emeric Brun) Date: Wed, 26 Jul 2017 15:47:19 +0200 Subject: [openssl-dev] Fix a dead lock of async engine. In-Reply-To: References: <8d933b4c-c9eb-1028-9437-fd021e47bebc@haproxy.com> Message-ID: Hi, On 07/26/2017 03:45 PM, Benjamin Kaduk wrote: > On 07/26/2017 08:15 AM, Emeric Brun wrote: >> Hi All, >> >> This bug also affects the 1.1.0 >> > > Are you able to submit the patch as a github pull request? That would be the preferred form, as it enables some automation that we have for CLA checks and CI. > I will try to remember my gh account password :) > -Ben R, Emeric From bkaduk at akamai.com Thu Jul 27 19:24:10 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 27 Jul 2017 14:24:10 -0500 Subject: [openssl-dev] Build issue In-Reply-To: References: <20170725.205901.2091843445588818197.levitte@openssl.org> <20170726.001210.2062515907518977857.levitte@openssl.org> Message-ID: On 07/25/2017 07:49 PM, Matthew Stickney wrote: > Possibly. The original errors and hanging perl process have been > replaced with an enormous number of "undefined reference" errors. For > example: > libssl.a(tls_srp.o):tls_srp.c:(.text+0xc4c): undefined reference to `BN_ucmp' > libssl.a(tls_srp.o):tls_srp.c:(.text+0xd45): undefined reference to > `OPENSSL_cleanse' > libssl.a(tls_srp.o):tls_srp.c:(.text+0xd5f): undefined reference to `SRP_Calc_A' > collect2.exe: error: ld returned 1 exit status > > I don't know enough about the build system to know whether the > mkdef.pl change might be responsible for this, or whether this is a > separate issue. To follow up on my previous post, the configure line > was indeed "./config", and this is commit 1843787173. Any other data > that I should collect? > Hmm, all of the listed examples are for things in libssl failing to find symbols from libcrypto, which perhaps suggests a link line ordering issue. Can you paste the actual linker invocation that is failing? -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu Jul 27 19:29:04 2017 From: levitte at openssl.org (Richard Levitte) Date: Thu, 27 Jul 2017 21:29:04 +0200 (CEST) Subject: [openssl-dev] Build issue In-Reply-To: References: <20170726.001210.2062515907518977857.levitte@openssl.org> Message-ID: <20170727.212904.883340979776768366.levitte@openssl.org> In message on Tue, 25 Jul 2017 20:49:14 -0400, Matthew Stickney said: mtstickney> Possibly. The original errors and hanging perl process have been mtstickney> replaced with an enormous number of "undefined reference" errors. For mtstickney> example: mtstickney> libssl.a(tls_srp.o):tls_srp.c:(.text+0xc4c): undefined reference to `BN_ucmp' mtstickney> libssl.a(tls_srp.o):tls_srp.c:(.text+0xd45): undefined reference to mtstickney> `OPENSSL_cleanse' mtstickney> libssl.a(tls_srp.o):tls_srp.c:(.text+0xd5f): undefined reference to `SRP_Calc_A' mtstickney> collect2.exe: error: ld returned 1 exit status mtstickney> mtstickney> I don't know enough about the build system to know whether the mtstickney> mkdef.pl change might be responsible for this, or whether this is a mtstickney> separate issue. To follow up on my previous post, the configure line mtstickney> was indeed "./config", and this is commit 1843787173. Any other data mtstickney> that I should collect? Have you tried a 'make clean' and then rebuild? If the previous run gave incorrect results, you may have ended up with an incomplete libcrypto.so, but with timestamps that make it look lite it's already built. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From mtstickney at gmail.com Fri Jul 28 03:23:47 2017 From: mtstickney at gmail.com (Matthew Stickney) Date: Thu, 27 Jul 2017 23:23:47 -0400 Subject: [openssl-dev] Build issue In-Reply-To: <20170727.212904.883340979776768366.levitte@openssl.org> References: <20170726.001210.2062515907518977857.levitte@openssl.org> <20170727.212904.883340979776768366.levitte@openssl.org> Message-ID: On Thu, Jul 27, 2017 at 3:29 PM, Richard Levitte wrote: > Have you tried a 'make clean' and then rebuild? Yep, and building from the 1.1.0 stable branch (failed with different errors), and from a new master. On Thu, Jul 27, 2017 at 3:24 PM, Benjamin Kaduk wrote: > Can you paste the actual linker invocation that is failing? I can certainly try. 'make 2>&1 1>build.log' doesn't seem to work quite correctly under MSYS2, so I have a build log, and errors, separately. This looks like the relevant part of the build log: make -f ./Makefile.shared -e \ ECHO=echo \ PLATFORM=mingw64 \ PERL="/usr/bin/perl" SRCDIR='.' DSTDIR="." \ INSTALLTOP='/usr/local' LIBDIR='lib' \ LIBDEPS=' '""' -lws2_32 -lgdi32 -lcrypt32 ' \ LIBNAME=crypto SHLIBVERSION=1.1 \ STLIBNAME=libcrypto.a \ SHLIBNAME=libcrypto.dll.a SHLIBNAME_FULL=libcrypto-1_1-x64.dll \ CC='gcc' CFLAGS='-DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1_1\"" -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT -D_WINDLL' \ LDFLAGS='' SHARED_LDFLAGS='-static-libgcc ' \ RC='windres' SHARED_RCFLAGS='--target=pe-x86-64' \ link_shlib.mingw-shared make[2]: Entering directory '/c/Users/mts/Desktop/openssl' /usr/bin/perl ./util/mkrc.pl libcrypto-1_1-x64.dll | windres --target=pe-x86-64 -o rc.o LD_LIBRARY_PATH=: gcc -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/engines-1_1" -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT -D_WINDLL -static-libgcc -shared -Wl,-Bsymbolic -Wl,--out-implib,libcrypto.dll.a crypto.def rc.o -o libcrypto-1_1-x64.dll -Wl,--whole-archive libcrypto.a -Wl,--no-whole-archive -lws2_32 -lgdi32 -lcrypt32 The error messages also contain these, which seem interesting: Error: _num does not have a number assigned Cannot export MD2: symbol not defined Cannot export MD2_Final: symbol not defined Cannot export MD2_Init: symbol not defined Cannot export MD2_Update: symbol not defined Cannot export MD2_options: symbol not defined Cannot export RC5_32_cbc_encrypt: symbol not defined Cannot export RC5_32_cfb64_encrypt: symbol not defined Cannot export RC5_32_decrypt: symbol not defined Cannot export RC5_32_ecb_encrypt: symbol not defined Cannot export RC5_32_encrypt: symbol not defined Cannot export RC5_32_ofb64_encrypt: symbol not defined Cannot export RC5_32_set_key: symbol not defined collect2.exe: error: ld returned 1 exit status make[2]: *** [Makefile.shared:260: link_shlib.mingw] Error 1 make[1]: *** [Makefile:658: libcrypto.dll.a] Error 2 make: *** [Makefile:139: all] Error 2 -Matt Stickney From uri at ll.mit.edu Fri Jul 28 03:54:54 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 28 Jul 2017 03:54:54 +0000 Subject: [openssl-dev] Build issue In-Reply-To: References: <20170726.001210.2062515907518977857.levitte@openssl.org> <20170727.212904.883340979776768366.levitte@openssl.org> Message-ID: Instead of "make clean" try "make distclean", then reconfigure and rebuild (don't forget "make depend"). Regards, Uri Sent from my iPhone > On Jul 27, 2017, at 23:24, Matthew Stickney wrote: > >> On Thu, Jul 27, 2017 at 3:29 PM, Richard Levitte wrote: >> Have you tried a 'make clean' and then rebuild? > > Yep, and building from the 1.1.0 stable branch (failed with different > errors), and from a new master. > >> On Thu, Jul 27, 2017 at 3:24 PM, Benjamin Kaduk wrote: >> Can you paste the actual linker invocation that is failing? > > I can certainly try. 'make 2>&1 1>build.log' doesn't seem to work > quite correctly under MSYS2, so I have a build log, and errors, > separately. This looks like the relevant part of the build log: > make -f ./Makefile.shared -e \ > ECHO=echo \ > PLATFORM=mingw64 \ > PERL="/usr/bin/perl" SRCDIR='.' DSTDIR="." \ > INSTALLTOP='/usr/local' LIBDIR='lib' \ > LIBDEPS=' '""' -lws2_32 -lgdi32 -lcrypt32 ' \ > LIBNAME=crypto SHLIBVERSION=1.1 \ > STLIBNAME=libcrypto.a \ > SHLIBNAME=libcrypto.dll.a SHLIBNAME_FULL=libcrypto-1_1-x64.dll \ > CC='gcc' CFLAGS='-DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS > -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM > -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM > -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" > -DENGINESDIR="\"/usr/local/lib/engines-1_1\"" -DL_ENDIAN > -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT > -D_WINDLL' \ > LDFLAGS='' SHARED_LDFLAGS='-static-libgcc ' \ > RC='windres' SHARED_RCFLAGS='--target=pe-x86-64' \ > link_shlib.mingw-shared > make[2]: Entering directory '/c/Users/mts/Desktop/openssl' > /usr/bin/perl ./util/mkrc.pl libcrypto-1_1-x64.dll | windres > --target=pe-x86-64 -o rc.o > LD_LIBRARY_PATH=: gcc -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS > -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM > -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM > -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" > -DENGINESDIR="/usr/local/lib/engines-1_1" -DL_ENDIAN > -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT > -D_WINDLL -static-libgcc -shared -Wl,-Bsymbolic > -Wl,--out-implib,libcrypto.dll.a crypto.def rc.o -o > libcrypto-1_1-x64.dll -Wl,--whole-archive libcrypto.a > -Wl,--no-whole-archive -lws2_32 -lgdi32 -lcrypt32 > > The error messages also contain these, which seem interesting: > Error: _num does not have a number assigned > Cannot export MD2: symbol not defined > Cannot export MD2_Final: symbol not defined > Cannot export MD2_Init: symbol not defined > Cannot export MD2_Update: symbol not defined > Cannot export MD2_options: symbol not defined > Cannot export RC5_32_cbc_encrypt: symbol not defined > Cannot export RC5_32_cfb64_encrypt: symbol not defined > Cannot export RC5_32_decrypt: symbol not defined > Cannot export RC5_32_ecb_encrypt: symbol not defined > Cannot export RC5_32_encrypt: symbol not defined > Cannot export RC5_32_ofb64_encrypt: symbol not defined > Cannot export RC5_32_set_key: symbol not defined > collect2.exe: error: ld returned 1 exit status > make[2]: *** [Makefile.shared:260: link_shlib.mingw] Error 1 > make[1]: *** [Makefile:658: libcrypto.dll.a] Error 2 > make: *** [Makefile:139: all] Error 2 > > -Matt Stickney > -- > 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: 4223 bytes Desc: not available URL: From mtstickney at gmail.com Fri Jul 28 06:22:02 2017 From: mtstickney at gmail.com (Matthew Stickney) Date: Fri, 28 Jul 2017 02:22:02 -0400 Subject: [openssl-dev] Build issue In-Reply-To: References: <20170726.001210.2062515907518977857.levitte@openssl.org> <20170727.212904.883340979776768366.levitte@openssl.org> Message-ID: With a make distclean, ./config, make depend (didn't appear to do anything), and a make, I'm getting the essentially the same thing: Error: _num does not have a number assigned /usr/bin/perl ./util/mkrc.pl libcrypto-1_1-x64.dll | windres --target=pe-x86-64 -o rc.o LD_LIBRARY_PATH=: gcc -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC _ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM _MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD 5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK _ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/e ngines-1_1" -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT -D_WINDLL -static-libgcc -shared -Wl,-Bsymbolic -Wl,--out-implib,libcrypt o.dll.a crypto.def rc.o -o libcrypto-1_1-x64.dll -Wl,--whole-archive libcrypto.a -Wl,--no-whole-archive -lws2_32 -lgdi32 -lcrypt32 Cannot export MD2: symbol not defined Cannot export MD2_Final: symbol not defined Cannot export MD2_Init: symbol not defined Cannot export MD2_Update: symbol not defined Cannot export MD2_options: symbol not defined Cannot export RC5_32_cbc_encrypt: symbol not defined Cannot export RC5_32_cfb64_encrypt: symbol not defined Cannot export RC5_32_decrypt: symbol not defined Cannot export RC5_32_ecb_encrypt: symbol not defined Cannot export RC5_32_encrypt: symbol not defined Cannot export RC5_32_ofb64_encrypt: symbol not defined Cannot export RC5_32_set_key: symbol not defined collect2.exe: error: ld returned 1 exit status On Thu, Jul 27, 2017 at 11:54 PM, Blumenthal, Uri - 0553 - MITLL wrote: > Instead of "make clean" try "make distclean", then reconfigure and rebuild (don't forget "make depend"). > > Regards, > Uri > > Sent from my iPhone > >> On Jul 27, 2017, at 23:24, Matthew Stickney wrote: >> >>> On Thu, Jul 27, 2017 at 3:29 PM, Richard Levitte wrote: >>> Have you tried a 'make clean' and then rebuild? >> >> Yep, and building from the 1.1.0 stable branch (failed with different >> errors), and from a new master. >> >>> On Thu, Jul 27, 2017 at 3:24 PM, Benjamin Kaduk wrote: >>> Can you paste the actual linker invocation that is failing? >> >> I can certainly try. 'make 2>&1 1>build.log' doesn't seem to work >> quite correctly under MSYS2, so I have a build log, and errors, >> separately. This looks like the relevant part of the build log: >> make -f ./Makefile.shared -e \ >> ECHO=echo \ >> PLATFORM=mingw64 \ >> PERL="/usr/bin/perl" SRCDIR='.' DSTDIR="." \ >> INSTALLTOP='/usr/local' LIBDIR='lib' \ >> LIBDEPS=' '""' -lws2_32 -lgdi32 -lcrypt32 ' \ >> LIBNAME=crypto SHLIBVERSION=1.1 \ >> STLIBNAME=libcrypto.a \ >> SHLIBNAME=libcrypto.dll.a SHLIBNAME_FULL=libcrypto-1_1-x64.dll \ >> CC='gcc' CFLAGS='-DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS >> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 >> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m >> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM >> -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM >> -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" >> -DENGINESDIR="\"/usr/local/lib/engines-1_1\"" -DL_ENDIAN >> -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT >> -D_WINDLL' \ >> LDFLAGS='' SHARED_LDFLAGS='-static-libgcc ' \ >> RC='windres' SHARED_RCFLAGS='--target=pe-x86-64' \ >> link_shlib.mingw-shared >> make[2]: Entering directory '/c/Users/mts/Desktop/openssl' >> /usr/bin/perl ./util/mkrc.pl libcrypto-1_1-x64.dll | windres >> --target=pe-x86-64 -o rc.o >> LD_LIBRARY_PATH=: gcc -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS >> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 >> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m >> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM >> -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM >> -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" >> -DENGINESDIR="/usr/local/lib/engines-1_1" -DL_ENDIAN >> -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT >> -D_WINDLL -static-libgcc -shared -Wl,-Bsymbolic >> -Wl,--out-implib,libcrypto.dll.a crypto.def rc.o -o >> libcrypto-1_1-x64.dll -Wl,--whole-archive libcrypto.a >> -Wl,--no-whole-archive -lws2_32 -lgdi32 -lcrypt32 >> >> The error messages also contain these, which seem interesting: >> Error: _num does not have a number assigned >> Cannot export MD2: symbol not defined >> Cannot export MD2_Final: symbol not defined >> Cannot export MD2_Init: symbol not defined >> Cannot export MD2_Update: symbol not defined >> Cannot export MD2_options: symbol not defined >> Cannot export RC5_32_cbc_encrypt: symbol not defined >> Cannot export RC5_32_cfb64_encrypt: symbol not defined >> Cannot export RC5_32_decrypt: symbol not defined >> Cannot export RC5_32_ecb_encrypt: symbol not defined >> Cannot export RC5_32_encrypt: symbol not defined >> Cannot export RC5_32_ofb64_encrypt: symbol not defined >> Cannot export RC5_32_set_key: symbol not defined >> collect2.exe: error: ld returned 1 exit status >> make[2]: *** [Makefile.shared:260: link_shlib.mingw] Error 1 >> make[1]: *** [Makefile:658: libcrypto.dll.a] Error 2 >> make: *** [Makefile:139: all] Error 2 >> >> -Matt Stickney >> -- >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From bkaduk at akamai.com Fri Jul 28 12:29:04 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 28 Jul 2017 07:29:04 -0500 Subject: [openssl-dev] Build issue In-Reply-To: References: <20170726.001210.2062515907518977857.levitte@openssl.org> <20170727.212904.883340979776768366.levitte@openssl.org> Message-ID: On 07/28/2017 01:22 AM, Matthew Stickney wrote: > With a make distclean, ./config, make depend (didn't appear to do > anything), and a make, I'm getting the essentially the same thing: > > Error: _num does not have a number assigned > /usr/bin/perl ./util/mkrc.pl libcrypto-1_1-x64.dll | windres --target=pe-x86-64 > -o rc.o > LD_LIBRARY_PATH=: gcc -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC > _ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM > _MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD > 5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK > _ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/e > ngines-1_1" -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 > -D_MT -D_WINDLL -static-libgcc -shared -Wl,-Bsymbolic -Wl,--out-implib,libcrypt > o.dll.a crypto.def rc.o -o libcrypto-1_1-x64.dll -Wl,--whole-archive libcrypto.a > -Wl,--no-whole-archive -lws2_32 -lgdi32 -lcrypt32 > Cannot export MD2: symbol not defined > Cannot export MD2_Final: symbol not defined > Cannot export MD2_Init: symbol not defined > Cannot export MD2_Update: symbol not defined > Cannot export MD2_options: symbol not defined > Cannot export RC5_32_cbc_encrypt: symbol not defined > Cannot export RC5_32_cfb64_encrypt: symbol not defined > Cannot export RC5_32_decrypt: symbol not defined > Cannot export RC5_32_ecb_encrypt: symbol not defined > Cannot export RC5_32_encrypt: symbol not defined > Cannot export RC5_32_ofb64_encrypt: symbol not defined > Cannot export RC5_32_set_key: symbol not defined > collect2.exe: error: ld returned 1 exit status > MD2 and RC5 are disabled by default, so it is expected that they will not be defined. It is hard to say whether those messages are the source of the error exit status or just warnings, though. It's certainly plausible that there are further mkdef.pl issues responsible, though. Since mkdef.pl generates the crypto.def file referenced on your link line, maybe you could post that somewhere and link to it? (mkdef.pl can also be used to generate .map files, but it seems like the .def file is the relevant one at the moment.) But I may have to defer to Richard for the workings of mkdef.pl itself... -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: