From levitte at openssl.org Fri Jun 1 10:16:19 2018 From: levitte at openssl.org (Richard Levitte) Date: Fri, 01 Jun 2018 12:16:19 +0200 (CEST) Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) Message-ID: <20180601.121619.1988036059031972518.levitte@openssl.org> Hi, PR #6341 (https://github.com/openssl/openssl/pull/6341) is stuck in a battle of opinions that doesn't seem to get anywhere, so for all practical purposes, it's currently blocked. I think that the gist of the difference of opinion is whether it's OK to use locale dependent functions such as mbstowcs in libcrypto or not. The main arguments against allowing such functions in libcrypto is that we should push applications to run with an UTF-8 input method (whether that's provided by the terminal driver, or the process holding the terminal, or the application itself...) rather than have them call setlocale() with appropriate arguments (which is needed for mbstowcs to work right). The main argument for allowing such functions, in this case, is to make it easy for applications to load what PKCS#12 objects there are in the wild, no matter what program generated them, rather than force them to do all the conversion work (locale->UTF-8) and force the users to regenerate non-compliant PKCS#12 objects (i.e. PKCS#12 objects previously generated by libcrypto with passphrases encoded in anything other than ISO-8859-1 or UTF-8). (to be precise, mbstowcs is needed to convert the passphrase from a non-UTF-8 encoding to UTF-8, to allow reading of compliant PKCS#12 when run with a non-UTF-8 input method... running with a UTF-8 input method is the easy answer, except that this may make some PKCS#12 objects generated with libcrypto unreadable) Please help settle this (it's possible that this will become implicit policy) Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From appro at openssl.org Fri Jun 1 11:04:08 2018 From: appro at openssl.org (Andy Polyakov) Date: Fri, 1 Jun 2018 13:04:08 +0200 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <20180601.121619.1988036059031972518.levitte@openssl.org> References: <20180601.121619.1988036059031972518.levitte@openssl.org> Message-ID: <192828cf-8462-c62e-3ab7-a1d5597e9a55@openssl.org> > I think that the gist of the difference of opinion is whether it's OK > to use locale dependent functions such as mbstowcs in libcrypto or > not. > > The main arguments against allowing such functions in libcrypto is > that we should push applications to run with an UTF-8 input method > (whether that's provided by the terminal driver, or the process > holding the terminal, or the application itself...) rather than have > them call setlocale() with appropriate arguments (which is needed for > mbstowcs to work right). Assertion is rather that we can't/shouldn't rely on application to call setlocale and with argument suitable for specific purpose [of accessing PKCS#12 in this case]. And since we can't do that, we would be better off not calling mbstowcs. Because it adds a variable we have no control over. Given some specific input it would be more honest/appropriate to return error to application than to make outcome conditional on whether or not application called setlocale and with which argument. One can also view it as following: all applications get exactly same treatment. Pushing applications and users toward UTF-8 input method is merely a consequence of the suggestion to give all applications same treatment, it's not alternative by itself. From rsalz at akamai.com Fri Jun 1 12:23:39 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 1 Jun 2018 12:23:39 +0000 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <20180601.121619.1988036059031972518.levitte@openssl.org> References: <20180601.121619.1988036059031972518.levitte@openssl.org> Message-ID: <72139BE1-CD68-4C03-A439-81BD03D6F7D0@akamai.com> > I think that the gist of the difference of opinion is whether it's OK to use locale dependent functions such as mbstowcs in libcrypto or not. Thanks for the summary. I am against use locale-dependent functions in libcrypto. From kaduk at mit.edu Fri Jun 1 18:20:17 2018 From: kaduk at mit.edu (Benjamin Kaduk) Date: Fri, 1 Jun 2018 13:20:17 -0500 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <72139BE1-CD68-4C03-A439-81BD03D6F7D0@akamai.com> References: <20180601.121619.1988036059031972518.levitte@openssl.org> <72139BE1-CD68-4C03-A439-81BD03D6F7D0@akamai.com> Message-ID: <20180601182016.GO27985@kduck.kaduk.org> On Fri, Jun 01, 2018 at 12:23:39PM +0000, Salz, Rich wrote: > > I think that the gist of the difference of opinion is whether it's OK > to use locale dependent functions such as mbstowcs in libcrypto or > not. > > > Thanks for the summary. > > I am against use locale-dependent functions in libcrypto. I think it's pretty clear (at least to me), that such functions do not belong in the normal path. I'd be open to considering them as a fallback attempt to read existing data (as opposed to generating new encrypted data), but find Andy's argument about nonpredictability (combined with David Woodhouse's enumeration of the various cases and the minimal utility of such conversions) to be fairly compelling. That is, I am also against the use of functions that depend on the current process's locale in libcrypto. (I phrase this slightly differently, in that functions which take an explicit locale to use might still be okay, but are not really portable enough for us to use, AIUI.) -Ben From rsalz at akamai.com Fri Jun 1 18:52:21 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 1 Jun 2018 18:52:21 +0000 Subject: [openssl-project] Is Mac a supported platform? Message-ID: <0F6F6671-BE25-4112-B55E-CA044682FD05@akamai.com> Our INSTALL doesn?t mention it. We have config?s for it. I think we should say we support it and update the various docs. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaduk at mit.edu Fri Jun 1 19:10:43 2018 From: kaduk at mit.edu (Benjamin Kaduk) Date: Fri, 1 Jun 2018 14:10:43 -0500 Subject: [openssl-project] Is Mac a supported platform? In-Reply-To: <0F6F6671-BE25-4112-B55E-CA044682FD05@akamai.com> References: <0F6F6671-BE25-4112-B55E-CA044682FD05@akamai.com> Message-ID: <20180601191042.GR27985@kduck.kaduk.org> On Fri, Jun 01, 2018 at 06:52:21PM +0000, Salz, Rich wrote: > Our INSTALL doesn?t mention it. We have config?s for it. I think we should say we support it and update the various docs. Thoughts? The PR associated with the thread around https://mta.openssl.org/pipermail/openssl-project/2018-January/000068.html seems likely to be relevant, though I don't think I have a link handy. -Ben From levitte at openssl.org Fri Jun 1 19:46:41 2018 From: levitte at openssl.org (Richard Levitte) Date: Fri, 01 Jun 2018 21:46:41 +0200 (CEST) Subject: [openssl-project] Is Mac a supported platform? In-Reply-To: <20180601191042.GR27985@kduck.kaduk.org> References: <0F6F6671-BE25-4112-B55E-CA044682FD05@akamai.com> <20180601191042.GR27985@kduck.kaduk.org> Message-ID: <20180601.214641.275741915011230550.levitte@openssl.org> In message <20180601191042.GR27985 at kduck.kaduk.org> on Fri, 1 Jun 2018 14:10:43 -0500, Benjamin Kaduk said: kaduk> On Fri, Jun 01, 2018 at 06:52:21PM +0000, Salz, Rich wrote: kaduk> > Our INSTALL doesn?t mention it. We have config?s for it. I think we should say we support it and update the various docs. Thoughts? kaduk> kaduk> The PR associated with the thread around kaduk> https://mta.openssl.org/pipermail/openssl-project/2018-January/000068.html kaduk> seems likely to be relevant, though I don't think I have a link kaduk> handy. Right, thanks for the reminder... I have a smaller project to have a web page that show different support levels and who has "claimed" each. Regarding the original question, it's "supported" insofar that we have osx among the Travis builds (at least usually... there have been times when the osx backlog has been so great that we've temporarly disabled it). Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Fri Jun 1 21:26:12 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 1 Jun 2018 21:26:12 +0000 Subject: [openssl-project] Is Mac a supported platform? In-Reply-To: <20180601.214641.275741915011230550.levitte@openssl.org> References: <0F6F6671-BE25-4112-B55E-CA044682FD05@akamai.com> <20180601191042.GR27985@kduck.kaduk.org> <20180601.214641.275741915011230550.levitte@openssl.org> Message-ID: <1BD96940-3B3B-4758-938A-01E57630619A@akamai.com> > Regarding the original question, it's "supported" insofar that we have osx among the Travis builds (at least usually... there have been times when the osx backlog has been so great that we've temporarly disabled it). So maybe I should just create a PR to update INSTALL with the Mac recipe? From levitte at openssl.org Fri Jun 1 21:32:57 2018 From: levitte at openssl.org (Richard Levitte) Date: Fri, 01 Jun 2018 23:32:57 +0200 (CEST) Subject: [openssl-project] Is Mac a supported platform? In-Reply-To: <1BD96940-3B3B-4758-938A-01E57630619A@akamai.com> References: <20180601191042.GR27985@kduck.kaduk.org> <20180601.214641.275741915011230550.levitte@openssl.org> <1BD96940-3B3B-4758-938A-01E57630619A@akamai.com> Message-ID: <20180601.233257.53864319625854879.levitte@openssl.org> In message <1BD96940-3B3B-4758-938A-01E57630619A at akamai.com> on Fri, 1 Jun 2018 21:26:12 +0000, "Salz, Rich" said: rsalz> > Regarding the original question, it's "supported" insofar that we have rsalz> osx among the Travis builds (at least usually... there have been rsalz> times when the osx backlog has been so great that we've temporarly rsalz> disabled it). rsalz> rsalz> So maybe I should just create a PR to update INSTALL with the Mac recipe? I don't understand why. In this regard, OS X is Unix. In other words, the quick recipe is what you already see in INSTALL: $ ./config $ make $ make test $ make install Are you telling me that this isn't understood? The only reason why VMS and Windows are mentioned specially, is that the commands on those platforms are syntactically different. Not so for OS X. But hey, if that helps, we can always do this: diff --git a/INSTALL b/INSTALL index 52e3f2ae6c..851093ec01 100644 --- a/INSTALL +++ b/INSTALL @@ -76,7 +76,7 @@ If you want to just get on with it, do: - on Unix: + on Unix (including Mac OS/X): $ ./config $ make Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Fri Jun 1 21:38:41 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 1 Jun 2018 17:38:41 -0400 Subject: [openssl-project] Is Mac a supported platform? In-Reply-To: <1BD96940-3B3B-4758-938A-01E57630619A@akamai.com> References: <0F6F6671-BE25-4112-B55E-CA044682FD05@akamai.com> <20180601191042.GR27985@kduck.kaduk.org> <20180601.214641.275741915011230550.levitte@openssl.org> <1BD96940-3B3B-4758-938A-01E57630619A@akamai.com> Message-ID: > On Jun 1, 2018, at 5:26 PM, Salz, Rich wrote: > > So maybe I should just create a PR to update INSTALL with the Mac recipe? I just use: ./Configure --prefix=/some/where [options] shared darwin64-x86_64-cc -- Viktor. From kurt at roeckx.be Fri Jun 1 21:51:22 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 1 Jun 2018 23:51:22 +0200 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <20180601182016.GO27985@kduck.kaduk.org> References: <20180601.121619.1988036059031972518.levitte@openssl.org> <72139BE1-CD68-4C03-A439-81BD03D6F7D0@akamai.com> <20180601182016.GO27985@kduck.kaduk.org> Message-ID: <20180601215122.GA28517@roeckx.be> On Fri, Jun 01, 2018 at 01:20:17PM -0500, Benjamin Kaduk wrote: > On Fri, Jun 01, 2018 at 12:23:39PM +0000, Salz, Rich wrote: > > > I think that the gist of the difference of opinion is whether it's OK > > to use locale dependent functions such as mbstowcs in libcrypto or > > not. > > > > > > Thanks for the summary. > > > > I am against use locale-dependent functions in libcrypto. > > I think it's pretty clear (at least to me), that such functions do > not belong in the normal path. I'd be open to considering them as a > fallback attempt to read existing data (as opposed to generating new > encrypted data), but find Andy's argument about nonpredictability > (combined with David Woodhouse's enumeration of the various cases > and the minimal utility of such conversions) to be fairly > compelling. That is, I am also against the use of functions that > depend on the current process's locale in libcrypto. (I phrase this > slightly differently, in that functions which take an explicit > locale to use might still be okay, but are not really portable > enough for us to use, AIUI.) So it's my understanding that the library functionw will always work in UTF-8 then, that's just fine for me. That would then just mean that the apps need to do the correct thing and convert it to UTF-8. Kurt From openssl-users at dukhovni.org Fri Jun 1 21:57:46 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 1 Jun 2018 17:57:46 -0400 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <20180601215122.GA28517@roeckx.be> References: <20180601.121619.1988036059031972518.levitte@openssl.org> <72139BE1-CD68-4C03-A439-81BD03D6F7D0@akamai.com> <20180601182016.GO27985@kduck.kaduk.org> <20180601215122.GA28517@roeckx.be> Message-ID: <14B35465-B944-492F-9C09-4A243D1AAB0E@dukhovni.org> > On Jun 1, 2018, at 5:51 PM, Kurt Roeckx wrote: > > That would then just mean that the apps need to do the correct > thing and convert it to UTF-8. Module legacy files, with a passphrase in some other encoding. For those the applications will have to provide the right non-UTF8 octet string, and I assume we'll just use that verbatim. -- -- Viktor. From levitte at openssl.org Fri Jun 1 22:16:17 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 02 Jun 2018 00:16:17 +0200 (CEST) Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <14B35465-B944-492F-9C09-4A243D1AAB0E@dukhovni.org> References: <20180601182016.GO27985@kduck.kaduk.org> <20180601215122.GA28517@roeckx.be> <14B35465-B944-492F-9C09-4A243D1AAB0E@dukhovni.org> Message-ID: <20180602.001617.603160081771587593.levitte@openssl.org> In message <14B35465-B944-492F-9C09-4A243D1AAB0E at dukhovni.org> on Fri, 1 Jun 2018 17:57:46 -0400, Viktor Dukhovni said: openssl-users> openssl-users> openssl-users> > On Jun 1, 2018, at 5:51 PM, Kurt Roeckx wrote: openssl-users> > openssl-users> > That would then just mean that the apps need to do the correct openssl-users> > thing and convert it to UTF-8. openssl-users> openssl-users> Module legacy files, with a passphrase in some other encoding. openssl-users> For those the applications will have to provide the right openssl-users> non-UTF8 octet string, and I assume we'll just use that openssl-users> verbatim. Trouble is that OSSL_STORE is designed so the application doesn't have to know what type of object the URI represents. "provide the right string" requires that knowledge. (I'm currently looking into alternatives where a UI_METHOD can present several variants of the same pass phrase, thus making it possible for the application to virtually say "hey, try one of these" instead of "hey, try this one"... that would be a way to have the application provide the variants rather than libcrypto, and still only have to know the bare minimum of what the URI represents (preferably nothing at all)) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Fri Jun 1 22:23:48 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 1 Jun 2018 18:23:48 -0400 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <20180602.001617.603160081771587593.levitte@openssl.org> References: <20180601182016.GO27985@kduck.kaduk.org> <20180601215122.GA28517@roeckx.be> <14B35465-B944-492F-9C09-4A243D1AAB0E@dukhovni.org> <20180602.001617.603160081771587593.levitte@openssl.org> Message-ID: <7C04EDBC-9D70-42EA-9EC9-6E6C4FBB8322@dukhovni.org> > On Jun 1, 2018, at 6:16 PM, Richard Levitte wrote: > > (I'm currently looking into alternatives where a UI_METHOD can present > several variants of the same pass phrase, thus making it possible for > the application to virtually say "hey, try one of these" instead of > "hey, try this one"... that would be a way to have the application > provide the variants rather than libcrypto, and still only have to > know the bare minimum of what the URI represents (preferably nothing > at all)) If they're using a new API with a new store abstraction, I rather think it'd be better for the PKCS#12 data to be re-built with a UTF-8 password before it is exposed as a store URI. They should be able to decode the old file using legacy tooling, but the new tools should simply require canonical data. Please DO NOT implement password variants. -- Viktor. From levitte at openssl.org Fri Jun 1 22:43:50 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 02 Jun 2018 00:43:50 +0200 (CEST) Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <7C04EDBC-9D70-42EA-9EC9-6E6C4FBB8322@dukhovni.org> References: <14B35465-B944-492F-9C09-4A243D1AAB0E@dukhovni.org> <20180602.001617.603160081771587593.levitte@openssl.org> <7C04EDBC-9D70-42EA-9EC9-6E6C4FBB8322@dukhovni.org> Message-ID: <20180602.004350.1602483119932820478.levitte@openssl.org> In message <7C04EDBC-9D70-42EA-9EC9-6E6C4FBB8322 at dukhovni.org> on Fri, 1 Jun 2018 18:23:48 -0400, Viktor Dukhovni said: openssl-users> openssl-users> openssl-users> > On Jun 1, 2018, at 6:16 PM, Richard Levitte wrote: openssl-users> > openssl-users> > (I'm currently looking into alternatives where a UI_METHOD can present openssl-users> > several variants of the same pass phrase, thus making it possible for openssl-users> > the application to virtually say "hey, try one of these" instead of openssl-users> > "hey, try this one"... that would be a way to have the application openssl-users> > provide the variants rather than libcrypto, and still only have to openssl-users> > know the bare minimum of what the URI represents (preferably nothing openssl-users> > at all)) openssl-users> openssl-users> If they're using a new API with a new store abstraction, I rather openssl-users> think it'd be better for the PKCS#12 data to be re-built with openssl-users> a UTF-8 password before it is exposed as a store URI. openssl-users> openssl-users> They should be able to decode the old file using legacy tooling, openssl-users> but the new tools should simply require canonical data. Ok, yeah, I can deal with that. In that case, though, it might make sense to extend the UI API with wchar_t capable functionality and require that functionality in the 'file' scheme loader, would it not? The application will then be forced to provide something that can be used directly or is easy to convert to UTF-8, as needed. openssl-users> Please DO NOT implement password variants. Frankly, I'm rather glad not to have to... Cheers, Richard ( g'night ) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Fri Jun 1 22:47:00 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 02 Jun 2018 00:47:00 +0200 (CEST) Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <20180602.004350.1602483119932820478.levitte@openssl.org> References: <20180602.001617.603160081771587593.levitte@openssl.org> <7C04EDBC-9D70-42EA-9EC9-6E6C4FBB8322@dukhovni.org> <20180602.004350.1602483119932820478.levitte@openssl.org> Message-ID: <20180602.004700.636682686971483457.levitte@openssl.org> In message <20180602.004350.1602483119932820478.levitte at openssl.org> on Sat, 02 Jun 2018 00:43:50 +0200 (CEST), Richard Levitte said: levitte> In message <7C04EDBC-9D70-42EA-9EC9-6E6C4FBB8322 at dukhovni.org> on Fri, 1 Jun 2018 18:23:48 -0400, Viktor Dukhovni said: levitte> levitte> openssl-users> levitte> openssl-users> levitte> openssl-users> > On Jun 1, 2018, at 6:16 PM, Richard Levitte wrote: levitte> openssl-users> > levitte> openssl-users> > (I'm currently looking into alternatives where a UI_METHOD can present levitte> openssl-users> > several variants of the same pass phrase, thus making it possible for levitte> openssl-users> > the application to virtually say "hey, try one of these" instead of levitte> openssl-users> > "hey, try this one"... that would be a way to have the application levitte> openssl-users> > provide the variants rather than libcrypto, and still only have to levitte> openssl-users> > know the bare minimum of what the URI represents (preferably nothing levitte> openssl-users> > at all)) levitte> openssl-users> levitte> openssl-users> If they're using a new API with a new store abstraction, I rather levitte> openssl-users> think it'd be better for the PKCS#12 data to be re-built with levitte> openssl-users> a UTF-8 password before it is exposed as a store URI. levitte> openssl-users> levitte> openssl-users> They should be able to decode the old file using legacy tooling, levitte> openssl-users> but the new tools should simply require canonical data. levitte> levitte> Ok, yeah, I can deal with that. In that case, though, it might make levitte> sense to extend the UI API with wchar_t capable functionality and levitte> require that functionality in the 'file' scheme loader, would it not? levitte> The application will then be forced to provide something that can be levitte> used directly or is easy to convert to UTF-8, as needed. Ah, forgot one important detail: it is well understood that *all* file based objects will get the same requirements, right? That goes for anything protected through PKCS#5 as well (good ol' PEM encryption, PKCS#8 objects and whatever else I forget...) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Fri Jun 1 23:08:04 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 1 Jun 2018 19:08:04 -0400 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <20180602.004700.636682686971483457.levitte@openssl.org> References: <20180602.001617.603160081771587593.levitte@openssl.org> <7C04EDBC-9D70-42EA-9EC9-6E6C4FBB8322@dukhovni.org> <20180602.004350.1602483119932820478.levitte@openssl.org> <20180602.004700.636682686971483457.levitte@openssl.org> Message-ID: > On Jun 1, 2018, at 6:47 PM, Richard Levitte wrote: > > Ah, forgot one important detail: it is well understood that *all* > file based objects will get the same requirements, right? That goes > for anything protected through PKCS#5 as well (good ol' PEM > encryption, PKCS#8 objects and whatever else I forget...) Canonicalize when importing for use with the store API. Not sure whether wchar_t though, just octet string in UTF-8 seems saner. That is the password is an opaque byte string, not a character string in the platform's encoding of i18n strings. -- Viktor. From paul.dale at oracle.com Sat Jun 2 05:08:45 2018 From: paul.dale at oracle.com (Dr Paul Dale) Date: Sat, 2 Jun 2018 15:08:45 +1000 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: References: <20180602.001617.603160081771587593.levitte@openssl.org> <7C04EDBC-9D70-42EA-9EC9-6E6C4FBB8322@dukhovni.org> <20180602.004350.1602483119932820478.levitte@openssl.org> <20180602.004700.636682686971483457.levitte@openssl.org> Message-ID: <0B63D86D-E76A-40EC-B6F2-1470893D7829@oracle.com> I also believe that we shouldn?t be relying on locale, it is a Pandora?s box we don?t want to open. Even claiming that OpenSSL is UTF-8 compliant is probably a stretch (e.g. the isXXX functions aren?t). Saying we accept unsigned eight bit byte inputs and process them unmodified is as far as I?d like to commit to. Pauli > On 2 Jun 2018, at 9:08 am, Viktor Dukhovni wrote: > > > >> On Jun 1, 2018, at 6:47 PM, Richard Levitte wrote: >> >> Ah, forgot one important detail: it is well understood that *all* >> file based objects will get the same requirements, right? That goes >> for anything protected through PKCS#5 as well (good ol' PEM >> encryption, PKCS#8 objects and whatever else I forget...) > > Canonicalize when importing for use with the store API. Not sure > whether wchar_t though, just octet string in UTF-8 seems saner. > That is the password is an opaque byte string, not a character > string in the platform's encoding of i18n strings. > > -- > Viktor. > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project From levitte at openssl.org Sat Jun 2 06:36:09 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 02 Jun 2018 08:36:09 +0200 (CEST) Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: References: <20180602.004350.1602483119932820478.levitte@openssl.org> <20180602.004700.636682686971483457.levitte@openssl.org> Message-ID: <20180602.083609.1587100912761973109.levitte@openssl.org> In message on Fri, 1 Jun 2018 19:08:04 -0400, Viktor Dukhovni said: openssl-users> openssl-users> openssl-users> > On Jun 1, 2018, at 6:47 PM, Richard Levitte wrote: openssl-users> > openssl-users> > Ah, forgot one important detail: it is well understood that *all* openssl-users> > file based objects will get the same requirements, right? That goes openssl-users> > for anything protected through PKCS#5 as well (good ol' PEM openssl-users> > encryption, PKCS#8 objects and whatever else I forget...) openssl-users> openssl-users> Canonicalize when importing for use with the store API. Yup. openssl-users> Not sure whether wchar_t though, just octet string in UTF-8 seems saner. Dunno about that, really. The aim, to quote David W, is to make it *hard* for applications to get it wrong, and we all know that an octet string is merely an octet string... we cannot know with absolute certainty that it's UTF-8 encoded. The way I saw it is that UTF-8 really means Unicode, and a way to codify that is wchar_t. openssl-users> That is the password is an opaque byte string, not a character openssl-users> string in the platform's encoding of i18n strings. Here is, unfortunately, where standards differ. PKCS#12 has a requirement that makes the pass phrase anything but opaque. With that, the characters have meaning and need to be interpreted correctly to form a standard compliant BMPString. (it would have been smarter to have the PKCS12 routines take wchar_t strings rather than char strings... hindsight is what it is...) Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Sat Jun 2 13:23:10 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 2 Jun 2018 13:23:10 +0000 Subject: [openssl-project] Is Mac a supported platform? In-Reply-To: <20180601.233257.53864319625854879.levitte@openssl.org> References: <20180601191042.GR27985@kduck.kaduk.org> <20180601.214641.275741915011230550.levitte@openssl.org> <1BD96940-3B3B-4758-938A-01E57630619A@akamai.com> <20180601.233257.53864319625854879.levitte@openssl.org> Message-ID: https://github.com/openssl/openssl/pull/6404 ?On 6/1/18, 5:33 PM, "Richard Levitte" wrote: In message <1BD96940-3B3B-4758-938A-01E57630619A at akamai.com> on Fri, 1 Jun 2018 21:26:12 +0000, "Salz, Rich" said: rsalz> > Regarding the original question, it's "supported" insofar that we have rsalz> osx among the Travis builds (at least usually... there have been rsalz> times when the osx backlog has been so great that we've temporarly rsalz> disabled it). rsalz> rsalz> So maybe I should just create a PR to update INSTALL with the Mac recipe? I don't understand why. In this regard, OS X is Unix. In other words, the quick recipe is what you already see in INSTALL: $ ./config $ make $ make test $ make install Are you telling me that this isn't understood? The only reason why VMS and Windows are mentioned specially, is that the commands on those platforms are syntactically different. Not so for OS X. But hey, if that helps, we can always do this: diff --git a/INSTALL b/INSTALL index 52e3f2ae6c..851093ec01 100644 --- a/INSTALL +++ b/INSTALL @@ -76,7 +76,7 @@ If you want to just get on with it, do: - on Unix: + on Unix (including Mac OS/X): $ ./config $ make Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project From kurt at roeckx.be Sat Jun 2 18:07:58 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 2 Jun 2018 20:07:58 +0200 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: References: <20180602.001617.603160081771587593.levitte@openssl.org> <7C04EDBC-9D70-42EA-9EC9-6E6C4FBB8322@dukhovni.org> <20180602.004350.1602483119932820478.levitte@openssl.org> <20180602.004700.636682686971483457.levitte@openssl.org> Message-ID: <20180602180757.GA15977@roeckx.be> On Fri, Jun 01, 2018 at 07:08:04PM -0400, Viktor Dukhovni wrote: > > > > On Jun 1, 2018, at 6:47 PM, Richard Levitte wrote: > > > > Ah, forgot one important detail: it is well understood that *all* > > file based objects will get the same requirements, right? That goes > > for anything protected through PKCS#5 as well (good ol' PEM > > encryption, PKCS#8 objects and whatever else I forget...) > > Canonicalize when importing for use with the store API. Not sure > whether wchar_t though, just octet string in UTF-8 seems saner. > That is the password is an opaque byte string, not a character > string in the platform's encoding of i18n strings. Whatever we do, it should be clear that we expect the application to give us the password in a standardized way, so that we can do with it what is needed. If it's something the user types, a password really contains characters, and so whar_t is really a natural way to pass this. It would at least be very clear to the application what it needs to do. whar_t is part of C89, which is still what we target, so it should be supported. But then we actually have targets that will most likely not support this and never will. So the other solution is that this gets passed in a fixed charset like UTF-8 or UTF-16. Kurt From openssl-users at dukhovni.org Sat Jun 2 18:27:42 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 2 Jun 2018 14:27:42 -0400 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <20180602.083609.1587100912761973109.levitte@openssl.org> References: <20180602.004350.1602483119932820478.levitte@openssl.org> <20180602.004700.636682686971483457.levitte@openssl.org> <20180602.083609.1587100912761973109.levitte@openssl.org> Message-ID: <04337360-C1DB-4F02-AB85-CB1D679FCE85@dukhovni.org> > On Jun 2, 2018, at 2:36 AM, Richard Levitte wrote: > >> Canonicalize when importing for use with the store API. > > Yup. > >> Not sure whether wchar_t though, just octet string in UTF-8 seems saner. > > Dunno about that, really. The aim, to quote David W, is to make it > *hard* for applications to get it wrong, and we all know that an octet > string is merely an octet string... Octet strings are by *defintion* not wide characters, they are an opaque string of *octets* (an array of uint8). The purpose of whchar_t and friends is to process non-ascii *character strings*, with the wide versions of strlen(), strchr(), ... We do none of this. We pass the opaque input to a key-derivation function that treats it as a opaque octet-string. > We cannot know with absolute certainty that it's UTF-8 encoded. Indeed someone could pass us an octet string that is not derived from the UTF-8 encoding of some actual character string entered by a user. That does not matter. What matters is that all user input is canonically encoded, in a *platform-independent* way. And for that the application is responsible for converting user input to UTF-8. If the application does not do it right, it will get incorrect (fail to decrypt) or non-portable (fail to decrypt in the future on other platforms) behaviour. > The way I saw it is that UTF-8 > really means Unicode, and a way to codify that is wchar_t. NO. That's not the point. UTF-8 yields a canonical encoding of what the user typed to an opaque octet string. That encoding is the application's responsibility. We must not treat the password as a character string, that's not portable. > openssl-users> That is the password is an opaque byte string, not a character > openssl-users> string in the platform's encoding of i18n strings. > > Here is, unfortunately, where standards differ. PKCS#12 has a > requirement that makes the pass phrase anything but opaque. OK, looking at: https://tools.ietf.org/html/rfc7292#appendix-B.1 we see that PKCS#5 v2.1 sensibly defines passwords as opaque strings in some unspecified standard encoding (ASCII or UTF-8 for example). PKCS#12 however, is sadly requiring a 16-bit BMPString encoding (instead of UTF-8), presumably for backwards compatibility. > With that, the characters have meaning and need to be interpreted > correctly to form a standard compliant BMPString. Well, in that case for PKCS#12 we must require a well-formed UTF-8 input, which we can convert to BMPString without any need for locale-specific information. The ASN.1 library presumably can convert from UTF-8 to BMP, or code can be added to do that if missing. > (it would have been smarter to have the PKCS12 routines take wchar_t > strings rather than char strings... hindsight is what it is...) No, wchar_t is not defined to be a 16-bit BMPString compatible encoding. It is AFAIK a platform-specific string representation that is not canonical. -- Viktor. From levitte at openssl.org Sun Jun 3 08:45:59 2018 From: levitte at openssl.org (Richard Levitte) Date: Sun, 03 Jun 2018 10:45:59 +0200 (CEST) Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <04337360-C1DB-4F02-AB85-CB1D679FCE85@dukhovni.org> References: <20180602.083609.1587100912761973109.levitte@openssl.org> <04337360-C1DB-4F02-AB85-CB1D679FCE85@dukhovni.org> Message-ID: <20180603.104559.1157803504943295821.levitte@openssl.org> In message <04337360-C1DB-4F02-AB85-CB1D679FCE85 at dukhovni.org> on Sat, 2 Jun 2018 14:27:42 -0400, Viktor Dukhovni said: openssl-users> > (it would have been smarter to have the PKCS12 routines take wchar_t openssl-users> > strings rather than char strings... hindsight is what it is...) openssl-users> openssl-users> No, wchar_t is not defined to be a 16-bit BMPString compatible openssl-users> encoding. It is AFAIK a platform-specific string representation openssl-users> that is not canonical. Yeah, I just learned that myself. Somehow, I thought wchar_t would be Unicode characters. So ok, with this information, UTF-8 makes sense... Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Mon Jun 4 13:47:04 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 4 Jun 2018 14:47:04 +0100 Subject: [openssl-project] Github to be acquired by Microsoft Message-ID: See: https://blog.github.com/2018-06-04-github-microsoft/ Matt From matt at openssl.org Mon Jun 4 16:32:27 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 4 Jun 2018 17:32:27 +0100 Subject: [openssl-project] Monthly Status Report (May) Message-ID: As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Fixed a mem leak in CMS_RecipientInfo_set0_pkey() and added some CMS tests - Added a note around performance and Nagle's algorithm on the SSL_connect() man page - Performend the 1.1.1 pre6 release - Fixed some errors and missing info in the CMS docs - Add getter for X509_VERIFY_PARAM_get_hostflags - Fixed SSL_get_shared_ciphers() to actually return the shared ciphers rather than the client ciphers - Fixed SSL_has_pending() in DTLS - Attended the OMC f2f in Ottawa - Fixed a failure in the event of an out-of-order CCS in DTLS - Fixed s_server/s_client to correctly use the DTLS timer - Ensure we resend the last DTLS flight if we don't get any app data from the peer - Fixed the ticket callbacks in TLSv1.3 and added associated tests - Fixed various "no" config options (multiple times in the month!) - Implemented a preference for SHA-256 when using "old style" PSKs to aid backwards compatibility - Fixed a DTLS problem where we did a memcpy of a NULL pointer of zero length, which is undefined behaviour - Implemented configurable number of TLSv1.3 session tickets - Implemented support for TLSv1.3 drafts 26/27/28 all at the same time - Made BN_GF2m_mod_arr more constant time as a defence against side channel attacks - Reverted an earlier change to pkeyutl to avoid EVP_PKEY_sign() for EdDSA. Also fixed a number of other issues with this application. - Fixed "ca" so that it can use EdDSA - Fixed some undefined behaviour in X509_NAME_cmp() - Modified TLSv1.3 stateless tickets so that they are not cached unnecessarily - Fixed a bug where post-handshake auth Finished messages used the wrong key - Added some sanity checks for a point to check it is defined for the right curve before we perform operations on it - Updated the "Connected Commands" section of the s_server/s_client docs - Create a PR (ongoing) for doing auto-retry in shutdown to fix test issues reported in CPython - Fixed mathematics error in calculating "a ^ 0 mod -1" - Performed the 1.1.1 pre7 release - Fixed most of the outstanding Coverity defects - Major tidy up of the SM2 code Matt From openssl-users at dukhovni.org Tue Jun 5 22:37:21 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 5 Jun 2018 18:37:21 -0400 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <20180603.104559.1157803504943295821.levitte@openssl.org> References: <20180602.083609.1587100912761973109.levitte@openssl.org> <04337360-C1DB-4F02-AB85-CB1D679FCE85@dukhovni.org> <20180603.104559.1157803504943295821.levitte@openssl.org> Message-ID: <4DCA9A91-1487-4BFC-8A4E-B79FAD473AF3@dukhovni.org> > On Jun 3, 2018, at 4:45 AM, Richard Levitte wrote: > > Yeah, I just learned that myself. Somehow, I thought wchar_t would be > Unicode characters. So ok, with this information, UTF-8 makes > sense... Nico has convinced me that the mapping from UTF-8 to BMPString should be UTF-16, which is agrees with the BMP representation on the code points in the Basic Multinational Plane, but also supports surrogate pairs for code points outside the plane, so that if someone wanted to use "emoji" (or more traditional glyph outside the BMP) for their password, they could. This is a strict superset of UCS-2 and avoids having to reject some UTF-8 codepoints. -- Viktor. From levitte at openssl.org Wed Jun 6 07:45:10 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 06 Jun 2018 09:45:10 +0200 (CEST) Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <4DCA9A91-1487-4BFC-8A4E-B79FAD473AF3@dukhovni.org> References: <04337360-C1DB-4F02-AB85-CB1D679FCE85@dukhovni.org> <20180603.104559.1157803504943295821.levitte@openssl.org> <4DCA9A91-1487-4BFC-8A4E-B79FAD473AF3@dukhovni.org> Message-ID: <20180606.094510.1961580216340351361.levitte@openssl.org> In message <4DCA9A91-1487-4BFC-8A4E-B79FAD473AF3 at dukhovni.org> on Tue, 5 Jun 2018 18:37:21 -0400, Viktor Dukhovni said: openssl-users> openssl-users> openssl-users> > On Jun 3, 2018, at 4:45 AM, Richard Levitte wrote: openssl-users> > openssl-users> > Yeah, I just learned that myself. Somehow, I thought wchar_t would be openssl-users> > Unicode characters. So ok, with this information, UTF-8 makes openssl-users> > sense... openssl-users> openssl-users> Nico has convinced me that the mapping from UTF-8 to BMPString should openssl-users> be UTF-16, which is agrees with the BMP representation on the code openssl-users> points in the Basic Multinational Plane, but also supports surrogate openssl-users> pairs for code points outside the plane, so that if someone wanted openssl-users> to use "emoji" (or more traditional glyph outside the BMP) for their openssl-users> password, they could. This is a strict superset of UCS-2 and avoids openssl-users> having to reject some UTF-8 codepoints. Yup. It seems that BMPString evolved from UCS-2 into UTF-16 at some point, and that evolution affected PKCS#12 objects... Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From davidben at google.com Wed Jun 6 15:23:55 2018 From: davidben at google.com (David Benjamin) Date: Wed, 6 Jun 2018 11:23:55 -0400 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <20180606.094510.1961580216340351361.levitte@openssl.org> References: <04337360-C1DB-4F02-AB85-CB1D679FCE85@dukhovni.org> <20180603.104559.1157803504943295821.levitte@openssl.org> <4DCA9A91-1487-4BFC-8A4E-B79FAD473AF3@dukhovni.org> <20180606.094510.1961580216340351361.levitte@openssl.org> Message-ID: On Wed, Jun 6, 2018 at 3:45 AM Richard Levitte wrote: > In message <4DCA9A91-1487-4BFC-8A4E-B79FAD473AF3 at dukhovni.org> on Tue, 5 > Jun 2018 18:37:21 -0400, Viktor Dukhovni > said: > > openssl-users> > openssl-users> > openssl-users> > On Jun 3, 2018, at 4:45 AM, Richard Levitte < > levitte at openssl.org> wrote: > openssl-users> > > openssl-users> > Yeah, I just learned that myself. Somehow, I thought > wchar_t would be > openssl-users> > Unicode characters. So ok, with this information, UTF-8 > makes > openssl-users> > sense... > openssl-users> > openssl-users> Nico has convinced me that the mapping from UTF-8 to > BMPString should > openssl-users> be UTF-16, which is agrees with the BMP representation on > the code > openssl-users> points in the Basic Multinational Plane, but also supports > surrogate > openssl-users> pairs for code points outside the plane, so that if someone > wanted > openssl-users> to use "emoji" (or more traditional glyph outside the BMP) > for their > openssl-users> password, they could. This is a strict superset of UCS-2 > and avoids > openssl-users> having to reject some UTF-8 codepoints. > > Yup. It seems that BMPString evolved from UCS-2 into UTF-16 at some > point, and that evolution affected PKCS#12 objects... > Is there a spec citation for this, or some documented experiments against other implementations' behavior? (What do Microsoft and NSS do here?) I was pondering something similar recently, but things do seem to point at UCS-2 right now. UCS-2 is indeed an unfortunate historical wart, but X.680 says: > BMPString is a subtype of UniversalString that has its own unique tag and contains only the characters in the Basic Multilingual Plane (those corresponding to the first 64K-2 cells, less cells whose encoding is used to address characters outside the Basic Multilingual Plane) of ISO/IEC 10646. RFC 7292 just says to use a BMPString. That doesn't suggest anyone has actually updated it for UTF-16. This is fine for X.509 where BMPString is one of many possible string types and folks can use UTF8String for this anyway. For PKCS#12, yeah, this introduces limitations that may be worth resolving, UTF-16 being the obvious fix. But if it's not in a spec, we should get it into one and also be clear on if this is OpenSSL inventing a behavior or following de facto behavior established elsewhere. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jun 6 15:35:49 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 6 Jun 2018 11:35:49 -0400 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: References: <04337360-C1DB-4F02-AB85-CB1D679FCE85@dukhovni.org> <20180603.104559.1157803504943295821.levitte@openssl.org> <4DCA9A91-1487-4BFC-8A4E-B79FAD473AF3@dukhovni.org> <20180606.094510.1961580216340351361.levitte@openssl.org> Message-ID: <88268D98-7ABE-44FC-8EFC-98ECE3F83F23@dukhovni.org> https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs5-passwords-02#section-4 https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs5-passwords-02#section-5.2 > On Jun 6, 2018, at 11:23 AM, David Benjamin wrote: > > Is there a spec citation for this, or some documented experiments against other implementations' behavior? (What do Microsoft and NSS do here?) I was pondering something similar recently, but things do seem to point at UCS-2 right now. UCS-2 is indeed an unfortunate historical wart, but X.680 says: > > > BMPString is a subtype of UniversalString that has its own unique tag and contains only the characters in the Basic Multilingual Plane (those corresponding to the first 64K-2 cells, less cells whose encoding is used to address characters outside the Basic Multilingual Plane) of ISO/IEC 10646. > > RFC 7292 just says to use a BMPString. That doesn't suggest anyone has actually updated it for UTF-16. This is fine for X.509 where BMPString is one of many possible string types and folks can use UTF8String for this anyway. For PKCS#12, yeah, this introduces limitations that may be worth resolving, UTF-16 being the obvious fix. But if it's not in a spec, we should get it into one and also be clear on if this is OpenSSL inventing a behavior or following de facto behavior established elsewhere. -- Viktor. From davidben at google.com Wed Jun 6 16:52:34 2018 From: davidben at google.com (David Benjamin) Date: Wed, 6 Jun 2018 12:52:34 -0400 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <88268D98-7ABE-44FC-8EFC-98ECE3F83F23@dukhovni.org> References: <04337360-C1DB-4F02-AB85-CB1D679FCE85@dukhovni.org> <20180603.104559.1157803504943295821.levitte@openssl.org> <4DCA9A91-1487-4BFC-8A4E-B79FAD473AF3@dukhovni.org> <20180606.094510.1961580216340351361.levitte@openssl.org> <88268D98-7ABE-44FC-8EFC-98ECE3F83F23@dukhovni.org> Message-ID: Oh, I didn't realize that document existed. Although it doesn't say that it is overriding the BMPString restrictions. It says it "does not add any *further* restrictions to the input passwords of these methods, however it is RECOMMENDED to use (big-endian) UTF-16 NFC form". That reads to me as saying you should use UTF-16 NFC form, but only the subset that still satisfies the existing BMPString restrictions. It even recommends that "applications which restricted the MacData password to BMPString set" fail in some cases. If the intent was otherwise, probably worth some rewording. On Wed, Jun 6, 2018 at 11:36 AM Viktor Dukhovni wrote: > > https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs5-passwords-02#section-4 > > https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs5-passwords-02#section-5.2 > > > On Jun 6, 2018, at 11:23 AM, David Benjamin wrote: > > > > Is there a spec citation for this, or some documented experiments > against other implementations' behavior? (What do Microsoft and NSS do > here?) I was pondering something similar recently, but things do seem to > point at UCS-2 right now. UCS-2 is indeed an unfortunate historical wart, > but X.680 says: > > > > > BMPString is a subtype of UniversalString that has its own unique tag > and contains only the characters in the Basic Multilingual Plane (those > corresponding to the first 64K-2 cells, less cells whose encoding is used > to address characters outside the Basic Multilingual Plane) of ISO/IEC > 10646. > > > > RFC 7292 just says to use a BMPString. That doesn't suggest anyone has > actually updated it for UTF-16. This is fine for X.509 where BMPString is > one of many possible string types and folks can use UTF8String for this > anyway. For PKCS#12, yeah, this introduces limitations that may be worth > resolving, UTF-16 being the obvious fix. But if it's not in a spec, we > should get it into one and also be clear on if this is OpenSSL inventing a > behavior or following de facto behavior established elsewhere. > > -- > Viktor. > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jun 6 17:26:23 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 6 Jun 2018 13:26:23 -0400 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: References: <04337360-C1DB-4F02-AB85-CB1D679FCE85@dukhovni.org> <20180603.104559.1157803504943295821.levitte@openssl.org> <4DCA9A91-1487-4BFC-8A4E-B79FAD473AF3@dukhovni.org> <20180606.094510.1961580216340351361.levitte@openssl.org> <88268D98-7ABE-44FC-8EFC-98ECE3F83F23@dukhovni.org> Message-ID: <445F2780-9542-4F54-80E3-C801FAE5EFB1@dukhovni.org> > On Jun 6, 2018, at 12:52 PM, David Benjamin wrote: > > Oh, I didn't realize that document existed. Although it doesn't say that it is overriding the BMPString restrictions. It says it "does not add any further restrictions to the input passwords of these methods, however it is RECOMMENDED to use (big-endian) UTF-16 NFC form". That reads to me as saying you should use UTF-16 NFC form, but only the subset that still satisfies the existing BMPString restrictions. It even recommends that "applications which restricted the MacData password to BMPString set" fail in some cases. > > If the intent was otherwise, probably worth some rewording. The point is that instead of failing we should use UTF-16 for non-BMP code points. Worst case we'll still fail. We can document a warning that passwords outside the BMP are non-portable. The responsibility for ensuring NFC form will be placed on the application feeding us the UTF-8 data. We should just convert from UTF-8 to UTF-16. I don't read the draft as forbidding non-BMP UTF-16. The two agree on the UCS-2 subset of UTF-16 (i.e. the BMP code points). If the intent is to forbind non-BMP passwords, we should ask the authors to change that, with a portability warning. Such passwords might not work everywhere, but forbidding them is unwise. -- Viktor. From kurt at roeckx.be Wed Jun 6 20:45:59 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 6 Jun 2018 22:45:59 +0200 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: References: <04337360-C1DB-4F02-AB85-CB1D679FCE85@dukhovni.org> <20180603.104559.1157803504943295821.levitte@openssl.org> <4DCA9A91-1487-4BFC-8A4E-B79FAD473AF3@dukhovni.org> <20180606.094510.1961580216340351361.levitte@openssl.org> Message-ID: <20180606204558.GA28581@roeckx.be> On Wed, Jun 06, 2018 at 11:23:55AM -0400, David Benjamin wrote: > > Is there a spec citation for this, or some documented experiments against > other implementations' behavior? (What do Microsoft and NSS do here?) I was > pondering something similar recently, but things do seem to point at UCS-2 > right now. UCS-2 is indeed an unfortunate historical wart, but X.680 says: I'm not sure which code I was looking at recently, probably NNS or gnutls, but it really restricted it to UCS-2. Kurt From kurt at roeckx.be Wed Jun 6 20:53:04 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 6 Jun 2018 22:53:04 +0200 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <20180606.094510.1961580216340351361.levitte@openssl.org> References: <04337360-C1DB-4F02-AB85-CB1D679FCE85@dukhovni.org> <20180603.104559.1157803504943295821.levitte@openssl.org> <4DCA9A91-1487-4BFC-8A4E-B79FAD473AF3@dukhovni.org> <20180606.094510.1961580216340351361.levitte@openssl.org> Message-ID: <20180606205304.GB28581@roeckx.be> On Wed, Jun 06, 2018 at 09:45:10AM +0200, Richard Levitte wrote: > Yup. It seems that BMPString evolved from UCS-2 into UTF-16 at some > point The only thing that evolved from UCS-2 to UTF-16 that I know of is Microsoft Windows. NT used UCS-2, 2000 changed that to UTF-16. Kurt From levitte at openssl.org Thu Jun 7 11:54:11 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 07 Jun 2018 13:54:11 +0200 (CEST) Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries Message-ID: <20180607.135411.1872521132998223104.levitte@openssl.org> Hi, This PR has been blocked, forcing a vote: https://github.com/openssl/openssl/pull/6392 Background: we have been sloppy when producing PKCS#12 files, creating objects that aren't interoperable. This can only happen with non-UTF8 input methods, so this PR adds a higher level of control in the openssl application, so that it will do the best it can to make sure a pass phrase encoded with something other than UTF-8 gets correctly re-encoded, and failing that, try and make the user aware that they are about to create a non-interoperable object. This triggered the use of the iconv API, and in the case of Mac OS/X, the use of the separate libiconv library. I'm going to make this into two votes, as both topics have come out because of this. 1. A vote about general use of other libraries, limited to standard system libraries, which may be platform dependent (I expect libiconv on Mac OS/X to be such a library) 2. A vote about the use of the iconv API Please discuss here, no in the vote threads. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Thu Jun 7 12:38:16 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 07 Jun 2018 14:38:16 +0200 (CEST) Subject: [openssl-project] Votes on the use of other libraries in general and iconv in particular Message-ID: <20180607.143816.2110842945849973759.levitte@openssl.org> Hi, as promised, I've create two votes: ---------- topic: We can use other standard / system libraries, per config target A current example is using libiconv on Mac OS/X. We will be cautious in doing so in the libraries, and are more free to do so in applications. Proposed by Richard Levitte Public: yes opened: 2018-06-07 closed: 2018-06-21 ---------- topic: We can use the iconv API in our applications Proposed by Richard Levitte Public: yes opened: 2018-06-07 closed: 2018-06-21 ---------- The vote tallies will be presented here when the votes are closed. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Thu Jun 7 14:50:57 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 7 Jun 2018 14:50:57 +0000 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <20180607.135411.1872521132998223104.levitte@openssl.org> References: <20180607.135411.1872521132998223104.levitte@openssl.org> Message-ID: <466A062C-5CD7-4D45-A5AB-509A34ECEA3A@akamai.com> I see you already started the votes. No time for discussion? I think OpenSSL should be a "fundamental" system library. Perhaps the apps are different, but it should not require new libraries but could use them if available -- either at run-time or via config/build. I think iconv in particular is a bad thing to require at this time, in a 1.1.1 release. It's not clear to me that it meets our API/ABI compatibility guarantee. I also dislike iconv because of its size, the fact that it is a gross collection of hacks -- not its fault, it's the nature of charsets -- and that it is not universal. This means that apps that "do the right thing" on some platforms, will FAIL to do so on opthers. It is very very late in the release process to be adding a new dependency. Finally, I believe that for this particular issue, we can add an API that enables applications to do the right thing, and we can add flags and warnings to the command-line that make it more clear when a user isn't doing the right thing (such as because they have existing files they need to read). VOTE NO. ?On 6/7/18, 8:04 AM, "Richard Levitte" wrote: Hi, This PR has been blocked, forcing a vote: https://github.com/openssl/openssl/pull/6392 Background: we have been sloppy when producing PKCS#12 files, creating objects that aren't interoperable. This can only happen with non-UTF8 input methods, so this PR adds a higher level of control in the openssl application, so that it will do the best it can to make sure a pass phrase encoded with something other than UTF-8 gets correctly re-encoded, and failing that, try and make the user aware that they are about to create a non-interoperable object. This triggered the use of the iconv API, and in the case of Mac OS/X, the use of the separate libiconv library. I'm going to make this into two votes, as both topics have come out because of this. 1. A vote about general use of other libraries, limited to standard system libraries, which may be platform dependent (I expect libiconv on Mac OS/X to be such a library) 2. A vote about the use of the iconv API Please discuss here, no in the vote threads. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project From rsalz at akamai.com Thu Jun 7 14:51:30 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 7 Jun 2018 14:51:30 +0000 Subject: [openssl-project] Votes on the use of other libraries in general and iconv in particular In-Reply-To: <20180607.143816.2110842945849973759.levitte@openssl.org> References: <20180607.143816.2110842945849973759.levitte@openssl.org> Message-ID: I am disappointed that no time was allowed for discussion. ?On 6/7/18, 8:38 AM, "Richard Levitte" wrote: Hi, as promised, I've create two votes: ---------- topic: We can use other standard / system libraries, per config target A current example is using libiconv on Mac OS/X. We will be cautious in doing so in the libraries, and are more free to do so in applications. Proposed by Richard Levitte Public: yes opened: 2018-06-07 closed: 2018-06-21 ---------- topic: We can use the iconv API in our applications Proposed by Richard Levitte Public: yes opened: 2018-06-07 closed: 2018-06-21 ---------- The vote tallies will be presented here when the votes are closed. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project From appro at openssl.org Thu Jun 7 14:58:20 2018 From: appro at openssl.org (Andy Polyakov) Date: Thu, 7 Jun 2018 16:58:20 +0200 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <20180607.135411.1872521132998223104.levitte@openssl.org> References: <20180607.135411.1872521132998223104.levitte@openssl.org> Message-ID: > This PR has been blocked, forcing a vote: > > https://github.com/openssl/openssl/pull/6392 > > Background: we have been sloppy when producing PKCS#12 files, creating > objects that aren't interoperable. This can only happen with non-UTF8 > input methods, so this PR adds a higher level of control in the > openssl application, so that it will do the best it can to make sure a > pass phrase encoded with something other than UTF-8 gets correctly > re-encoded, and failing that, try and make the user aware that they > are about to create a non-interoperable object. This triggered the > use of the iconv API, and in the case of Mac OS/X, the use of the > separate libiconv library. I find the reference to Mac OS X a bit misleading, because it suggests that assessment was made on limited amount of data points. Basically on how does it look on *contemporary* Linux/Unix platforms and Mac OS X. But question runs deeper than that and should cover all platform that we consider supporting. Which covers even ranges of older versions, in sense that judging on latest version alone is hardly sufficient. For example do we know *when* was libiconv introduced to Mac OS X? One can naturally say that we are not obliged to care about *that* old versions, but this is no excuse for not making thorougher assessment? I mean it's only appropriate if we can answer the question how old does system have to be for us to say "we don't care". And same question applies even to other platforms, OpenBSD, FreeBSD, Android, Cygwin, Solaris, AIX, HP-UX, DJGPP, Tru64, IRIX, ... One can argue that iconv was actually standardized, and in such case it would be appropriate to make it conditional on _POSIX_VERSION. [Though it doesn't seem to be part of pull request in question. Why not?] But as far as _POSIX_VERSION goes, we kind of know that some systems by *default* offer lower version, presumably in order to facilitate backward portability. So that it would mean that we would have to explicitly rise the bar in some cases. Which ones? And how high? This brings us to following question. Is *this* actually right moment to introduce that kind of *multi-variable* problem? In other words the problem kind of has two sides: a) principal, to do or not to do; b) *when* would it be appropriate to start, is minor release right moment? Is b) part of the vote? From levitte at openssl.org Thu Jun 7 15:09:52 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 07 Jun 2018 17:09:52 +0200 Subject: [openssl-project] Votes on the use of other libraries in general and iconv in particular In-Reply-To: References: <20180607.143816.2110842945849973759.levitte@openssl.org> Message-ID: Mm, I was thinking about it, but then, we have already discussed this in circles on github. Besides, those are two week votes, and I now realised I did a procedural error when settling a closed date (what the hell was I thinking?). But still, that gives two weeks before the vote has to be concluded, does that not allow discussion? Has that ever stopped us from discussing before? Cheers Richard "Salz, Rich" skrev: (7 juni 2018 16:51:30 CEST) >I am disappointed that no time was allowed for discussion. > >?On 6/7/18, 8:38 AM, "Richard Levitte" wrote: > > Hi, > > as promised, I've create two votes: > > ---------- > topic: We can use other standard / system libraries, per config target > A current example is using libiconv on Mac OS/X. We will be > cautious in doing so in the libraries, and are more free to do > so in applications. > Proposed by Richard Levitte > Public: yes > opened: 2018-06-07 > closed: 2018-06-21 > ---------- > topic: We can use the iconv API in our applications > Proposed by Richard Levitte > Public: yes > opened: 2018-06-07 > closed: 2018-06-21 > ---------- > > The vote tallies will be presented here when the votes are closed. > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > > >_______________________________________________ >openssl-project mailing list >openssl-project at openssl.org >https://mta.openssl.org/mailman/listinfo/openssl-project -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From levitte at openssl.org Thu Jun 7 15:19:48 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 07 Jun 2018 17:19:48 +0200 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <20180607.135411.1872521132998223104.levitte@openssl.org> References: <20180607.135411.1872521132998223104.levitte@openssl.org> Message-ID: <7B0424BB-7A55-4B59-87D6-B3AE5EC165AE@openssl.org> Regarding general use of other libraries, please think carefully before voting, 'cause this *is* tricky. If you have a look, you will see that we *currently* depend on certain standard libraries, such as, for example, libdl. And perhaps we should also mention the pile of libraries used with windows. In my mind, this makes that more general vote ridiculous, but the matter was brought up to me, and I wasn't going to ignore it, no matter what my personal feelings are. Cheers Richard Richard Levitte skrev: (7 juni 2018 13:54:11 CEST) >Hi, > >This PR has been blocked, forcing a vote: > > https://github.com/openssl/openssl/pull/6392 > >Background: we have been sloppy when producing PKCS#12 files, creating >objects that aren't interoperable. This can only happen with non-UTF8 >input methods, so this PR adds a higher level of control in the >openssl application, so that it will do the best it can to make sure a >pass phrase encoded with something other than UTF-8 gets correctly >re-encoded, and failing that, try and make the user aware that they >are about to create a non-interoperable object. This triggered the >use of the iconv API, and in the case of Mac OS/X, the use of the >separate libiconv library. > >I'm going to make this into two votes, as both topics have come out >because of this. > >1. A vote about general use of other libraries, limited to standard > system libraries, which may be platform dependent (I expect > libiconv on Mac OS/X to be such a library) > >2. A vote about the use of the iconv API > >Please discuss here, no in the vote threads. > >Cheers, >Richard -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From appro at openssl.org Thu Jun 7 15:55:27 2018 From: appro at openssl.org (Andy Polyakov) Date: Thu, 7 Jun 2018 17:55:27 +0200 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <7B0424BB-7A55-4B59-87D6-B3AE5EC165AE@openssl.org> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <7B0424BB-7A55-4B59-87D6-B3AE5EC165AE@openssl.org> Message-ID: > Regarding general use of other libraries, please think carefully before voting, 'cause this *is* tricky. If you have a look, you will see that we *currently* depend on certain standard libraries, such as, for example, libdl. One has to recognize that each dependency has to be justified. Sometimes you don't have a choice. For example if you want to talk network on Solaris, you have to link with -lsocket -lnsl. It's just part of the game. But in cases one has a choice, well, one has a choice to *make*. And key question is how do you anchor it. It's only natural to have as little dependencies as possible, so question is what would justify extra dependency. > And perhaps we should also mention the pile of libraries used with windows. It's not about amount, but ubiquity and stability. Windows is bad example in the context, because it's rather "mono-cultural" environment. But *otherwise* thing is that we already *know* that those extra libraries work. Or at least know what to expect and how to deal with them on different platforms. They were effectively proven to work by lasting through several releases and years-long bug ironing. This *is* factor too. And that's what made me pose "is b) part of vote" in my last post. From openssl-users at dukhovni.org Thu Jun 7 15:56:00 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 7 Jun 2018 11:56:00 -0400 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <7B0424BB-7A55-4B59-87D6-B3AE5EC165AE@openssl.org> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <7B0424BB-7A55-4B59-87D6-B3AE5EC165AE@openssl.org> Message-ID: > On Jun 7, 2018, at 11:19 AM, Richard Levitte wrote: > > Regarding general use of other libraries, please think carefully before voting, 'cause this *is* tricky. If you have a look, you will see that we *currently* depend on certain standard libraries, such as, for example, libdl. And perhaps we should also mention the pile of libraries used with windows. > > In my mind, this makes that more general vote ridiculous, but the matter was brought up to me, and I wasn't going to ignore it, no matter what my personal feelings are. My concern is not so much whether a dependency on libiconv in libcrypto should be allowed, but rather wether we actually need it. I rather think that all codepage conversions should be the application's job. Thus, it is OK for *apps* where we prompt for passwords to support conversion to UTF-8, perhaps via libiconv. So I see /usr/bin/openssl linked against the iconv API (which is, for example, in libc on NetBSD and FreeBSD, and does not require a separate library). We probably require libiconv for "openssl pkcs12" to work correctly, but the dependency should IMHO be in apps not libcrypto. -- Viktor. From kurt at roeckx.be Thu Jun 7 16:49:58 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 7 Jun 2018 18:49:58 +0200 Subject: [openssl-project] Votes on the use of other libraries in general and iconv in particular In-Reply-To: References: <20180607.143816.2110842945849973759.levitte@openssl.org> Message-ID: <20180607164957.GA20164@roeckx.be> On Thu, Jun 07, 2018 at 05:09:52PM +0200, Richard Levitte wrote: > Mm, I was thinking about it, but then, we have already discussed this in circles on github. I do not follow everything on github, I had no idea that this was being discussed. Someone might have convinced you that it's not the right vote, or that the wording could be improved. Kurt From kaduk at mit.edu Thu Jun 7 17:07:34 2018 From: kaduk at mit.edu (Benjamin Kaduk) Date: Thu, 7 Jun 2018 12:07:34 -0500 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: References: <20180607.135411.1872521132998223104.levitte@openssl.org> <7B0424BB-7A55-4B59-87D6-B3AE5EC165AE@openssl.org> Message-ID: <20180607170733.GR72167@kduck.kaduk.org> On Thu, Jun 07, 2018 at 05:55:27PM +0200, Andy Polyakov wrote: > > Regarding general use of other libraries, please think carefully before voting, 'cause this *is* tricky. If you have a look, you will see that we *currently* depend on certain standard libraries, such as, for example, libdl. > > One has to recognize that each dependency has to be justified. Sometimes > you don't have a choice. For example if you want to talk network on > Solaris, you have to link with -lsocket -lnsl. It's just part of the > game. But in cases one has a choice, well, one has a choice to *make*. > And key question is how do you anchor it. It's only natural to have as > little dependencies as possible, so question is what would justify extra > dependency. Taking off on a bit of a tangent, how much justification did we go through when adding pthreads as a dependency. I have not been following very much (Kurt would know more), but apparently in Debian there are some issues regarding (statically linked?) applications and libraries that use libcrypto but do not explicitly link with -pthread. "Issues" here being, IIRC, crashes at runtime. -Ben From rsalz at akamai.com Thu Jun 7 17:09:51 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 7 Jun 2018 17:09:51 +0000 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <20180607170733.GR72167@kduck.kaduk.org> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <7B0424BB-7A55-4B59-87D6-B3AE5EC165AE@openssl.org> <20180607170733.GR72167@kduck.kaduk.org> Message-ID: <2ED40A55-B067-4C4A-8E7D-B6453D34151E@akamai.com> > Taking off on a bit of a tangent, how much justification did we go through when adding pthreads as a dependency. It's an optional, but enabled by default, dependency which is different. We had a lot of discussion within what was then openssl-team. From levitte at openssl.org Thu Jun 7 18:36:07 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 07 Jun 2018 20:36:07 +0200 (CEST) Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: References: <20180607.135411.1872521132998223104.levitte@openssl.org> <7B0424BB-7A55-4B59-87D6-B3AE5EC165AE@openssl.org> Message-ID: <20180607.203607.924023698162066302.levitte@openssl.org> In message on Thu, 7 Jun 2018 17:55:27 +0200, Andy Polyakov said: appro> > Regarding general use of other libraries, please think carefully before voting, 'cause this *is* tricky. If you have a look, you will see that we *currently* depend on certain standard libraries, such as, for example, libdl. appro> appro> One has to recognize that each dependency has to be justified. Yes, of course. Caution is advisable, always. appro> > And perhaps we should also mention the pile of libraries used with windows. appro> appro> It's not about amount, but ubiquity and stability. Windows is bad appro> example in the context, because it's rather "mono-cultural" environment. Yes, you're right, and I didn't really mean to make a serious argument about the amount, just pointing out that we already rely on standard / system libraries. appro> But *otherwise* thing is that we already *know* that those extra appro> libraries work. Or at least know what to expect and how to deal with appro> them on different platforms. They were effectively proven to work by appro> lasting through several releases and years-long bug ironing. This *is* appro> factor too. And that's what made me pose "is b) part of vote" in my last appro> post. I'll have you note that the PR that I'm pointing at still has an open question about how to deal with the problem of some systems not reliably support iconv. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Thu Jun 7 18:39:09 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 07 Jun 2018 20:39:09 +0200 (CEST) Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: References: <20180607.135411.1872521132998223104.levitte@openssl.org> <7B0424BB-7A55-4B59-87D6-B3AE5EC165AE@openssl.org> Message-ID: <20180607.203909.2226537812695433938.levitte@openssl.org> In message on Thu, 7 Jun 2018 11:56:00 -0400, Viktor Dukhovni said: openssl-users> openssl-users> openssl-users> > On Jun 7, 2018, at 11:19 AM, Richard Levitte wrote: openssl-users> > openssl-users> > Regarding general use of other libraries, please openssl-users> > think carefully before voting, 'cause this *is* openssl-users> > tricky. If you have a look, you will see that we openssl-users> > *currently* depend on certain standard libraries, openssl-users> > such as, for example, libdl. And perhaps we should openssl-users> > also mention the pile of libraries used with openssl-users> > windows. openssl-users> > openssl-users> > In my mind, this makes that more general vote openssl-users> > ridiculous, but the matter was brought up to me, and openssl-users> > I wasn't going to ignore it, no matter what my openssl-users> > personal feelings are. openssl-users> openssl-users> My concern is not so much whether a dependency on libiconv in libcrypto openssl-users> should be allowed, but rather wether we actually need it. I rather openssl-users> think that all codepage conversions should be the application's job. openssl-users> openssl-users> Thus, it is OK for *apps* where we prompt for passwords to support openssl-users> conversion to UTF-8, perhaps via libiconv. So I see /usr/bin/openssl openssl-users> linked against the iconv API (which is, for example, in libc on NetBSD openssl-users> and FreeBSD, and does not require a separate library). We probably openssl-users> require libiconv for "openssl pkcs12" to work correctly, but the openssl-users> dependency should IMHO be in apps not libcrypto. Yup, and I did hear you in that other thread. Your argument about having OSSL_STORE be at liberty to *expect* UTF-8 without having to check for it made sense to me, and I did move the check and possible conversion to the application (i.e. 'openssl pkcs12'). That's what the PR I pointed at is all about. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Thu Jun 7 19:01:15 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 07 Jun 2018 21:01:15 +0200 (CEST) Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: References: <20180607.135411.1872521132998223104.levitte@openssl.org> Message-ID: <20180607.210115.379638366064366181.levitte@openssl.org> In message on Thu, 7 Jun 2018 16:58:20 +0200, Andy Polyakov said: appro> One can argue that iconv was actually standardized, and in such appro> case it would be appropriate to make it conditional on appro> _POSIX_VERSION. [Though it doesn't seem to be part of pull appro> request in question. Why not?] But as far as _POSIX_VERSION appro> goes, we kind of know that some systems by *default* offer appro> lower version, presumably in order to facilitate backward appro> portability. [about why not: because I was unsure how _POSIX_SOURCE is defined... having seen too many places where the user (i.e. us) gets to define that macro to get desired features. I've read up since, so expect a change that uses this macro] appro> So that it would mean that we would have to explicitly rise the appro> bar in some cases. Which ones? And how high? This brings us to appro> following question. Is *this* actually right moment to appro> introduce that kind of *multi-variable* problem? In other words appro> the problem kind of has two sides: a) principal, to do or not appro> to do; b) *when* would it be appropriate to start, is minor appro> release right moment? Is b) part of the vote? We don't have to answer the question "how high" now. I'm fully prepared to have the use of iconv limited to platforms where we know it's available (for example, we - or well, *I* - know that VMS has the iconv API in the C RTL, not even any need to link with any extra library... and we *know* it's available in glibc since version 2.something). I'm fully prepared to have to deal with people saying "hey, we have that too!" and having to edit config targets as we go. I do not expect any support of iconv to cover more than what we can test or get patches for, as with anything else. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Thu Jun 7 19:09:55 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 7 Jun 2018 19:09:55 +0000 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <20180607.210115.379638366064366181.levitte@openssl.org> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <20180607.210115.379638366064366181.levitte@openssl.org> Message-ID: <2ABFDBF7-BC73-4CCC-841D-D36DC06B674C@akamai.com> > We don't have to answer the question "how high" now. I'm fully prepared to have the use of iconv limited to platforms where we know it's available That then means that the pkcs12 program is not compatible in behavior across platforms. This would be a first, for us. From openssl-users at dukhovni.org Thu Jun 7 19:16:53 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 7 Jun 2018 19:16:53 +0000 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <20180607.210115.379638366064366181.levitte@openssl.org> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <20180607.210115.379638366064366181.levitte@openssl.org> Message-ID: <20180607191653.GE3322@mournblade.imrryr.org> On Thu, Jun 07, 2018 at 09:01:15PM +0200, Richard Levitte wrote: > We don't have to answer the question "how high" now. I'm fully > prepared to have the use of iconv limited to platforms where we know > it's available (for example, we - or well, *I* - know that VMS has the > iconv API in the C RTL, not even any need to link with any extra > library... and we *know* it's available in glibc since version > 2.something). I'm fully prepared to have to deal with people saying > "hey, we have that too!" and having to edit config targets as we go. > I do not expect any support of iconv to cover more than what we can > test or get patches for, as with anything else. There's also apparently some variation in the iconv API function prototypes (possibly "const char **" vs. "char **"). So some platform-dependent casting may be required... My peers suggest that this late in the release cycle, we leave the responsibility of ensuring UTF-8 input to the user. We could describe work-arounds in documentation. Personally, if this is off by default, and requires a new option to enable, and is just in openssl(1) and not libcrypto, I'm disinclined to say "no" until I see a PR (with documentation) that we can decide to leave for post 1.1.1 or adopt. -- Viktor. From levitte at openssl.org Thu Jun 7 19:23:08 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 07 Jun 2018 21:23:08 +0200 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <2ABFDBF7-BC73-4CCC-841D-D36DC06B674C@akamai.com> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <20180607.210115.379638366064366181.levitte@openssl.org> <2ABFDBF7-BC73-4CCC-841D-D36DC06B674C@akamai.com> Message-ID: <6671CF74-D8AC-410F-B24C-12EA069F9548@openssl.org> "Salz, Rich" skrev: (7 juni 2018 21:09:55 CEST) >> We don't have to answer the question "how high" now. I'm fully > prepared to have the use of iconv limited to platforms where we know > it's available > >That then means that the pkcs12 program is not compatible in behavior >across platforms. This would be a first, for us. It already isn't. Depending on your regional settings, a passphrase isn't always encoded the same way. So no, not a first. -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. From rsalz at akamai.com Thu Jun 7 19:25:01 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 7 Jun 2018 19:25:01 +0000 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <6671CF74-D8AC-410F-B24C-12EA069F9548@openssl.org> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <20180607.210115.379638366064366181.levitte@openssl.org> <2ABFDBF7-BC73-4CCC-841D-D36DC06B674C@akamai.com> <6671CF74-D8AC-410F-B24C-12EA069F9548@openssl.org> Message-ID: <6C5C1F1F-93FD-4BB0-8606-E2DDDBA3CE65@akamai.com> > It already isn't. Depending on your regional settings, a passphrase isn't always encoded the same way. So no, not a first. That is *different.* That is a user setting changing behavior. This would be the exact same executable, and even user settings, doing different things. From levitte at openssl.org Thu Jun 7 19:27:08 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 07 Jun 2018 21:27:08 +0200 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <20180607191653.GE3322@mournblade.imrryr.org> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <20180607.210115.379638366064366181.levitte@openssl.org> <20180607191653.GE3322@mournblade.imrryr.org> Message-ID: <404F1397-1398-4BD5-93A1-B2BA7A157EF3@openssl.org> Viktor Dukhovni skrev: (7 juni 2018 21:16:53 CEST) >On Thu, Jun 07, 2018 at 09:01:15PM +0200, Richard Levitte wrote: > >> We don't have to answer the question "how high" now. I'm fully >> prepared to have the use of iconv limited to platforms where we know >> it's available (for example, we - or well, *I* - know that VMS has >the >> iconv API in the C RTL, not even any need to link with any extra >> library... and we *know* it's available in glibc since version >> 2.something). I'm fully prepared to have to deal with people saying >> "hey, we have that too!" and having to edit config targets as we go. >> I do not expect any support of iconv to cover more than what we can >> test or get patches for, as with anything else. > >There's also apparently some variation in the iconv API function >prototypes (possibly "const char **" vs. "char **"). So some >platform-dependent casting may be required... > >My peers suggest that this late in the release cycle, we leave the >responsibility of ensuring UTF-8 input to the user. We could >describe work-arounds in documentation. Personally, if this is >off by default, and requires a new option to enable, and is just >in openssl(1) and not libcrypto, I'm disinclined to say "no" until >I see a PR (with documentation) that we can decide to leave for >post 1.1.1 or adopt. Please review doc/man7/passphrase-encoding.pod My main concern is that currently, openssl pkcs12 may create broken pkcs12 files (because it misinterprets the pass phrase when constructing a BMPString), and doesn't notify the user at all (doesn't even check). Cheers Richard -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. From davidben at google.com Thu Jun 7 19:29:12 2018 From: davidben at google.com (David Benjamin) Date: Thu, 7 Jun 2018 15:29:12 -0400 Subject: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE) In-Reply-To: <445F2780-9542-4F54-80E3-C801FAE5EFB1@dukhovni.org> References: <04337360-C1DB-4F02-AB85-CB1D679FCE85@dukhovni.org> <20180603.104559.1157803504943295821.levitte@openssl.org> <4DCA9A91-1487-4BFC-8A4E-B79FAD473AF3@dukhovni.org> <20180606.094510.1961580216340351361.levitte@openssl.org> <88268D98-7ABE-44FC-8EFC-98ECE3F83F23@dukhovni.org> <445F2780-9542-4F54-80E3-C801FAE5EFB1@dukhovni.org> Message-ID: On Wed, Jun 6, 2018 at 1:26 PM Viktor Dukhovni wrote: > > > > On Jun 6, 2018, at 12:52 PM, David Benjamin wrote: > > > > Oh, I didn't realize that document existed. Although it doesn't say that > it is overriding the BMPString restrictions. It says it "does not add any > further restrictions to the input passwords of these methods, however it is > RECOMMENDED to use (big-endian) UTF-16 NFC form". That reads to me as > saying you should use UTF-16 NFC form, but only the subset that still > satisfies the existing BMPString restrictions. It even recommends that > "applications which restricted the MacData password to BMPString set" fail > in some cases. > > > > If the intent was otherwise, probably worth some rewording. > > The point is that instead of failing we should use UTF-16 for non-BMP code > points. > Worst case we'll still fail. We can document a warning that passwords > outside > the BMP are non-portable. The responsibility for ensuring NFC form will > be placed > on the application feeding us the UTF-8 data. We should just convert from > UTF-8 to > UTF-16. > > I don't read the draft as forbidding non-BMP UTF-16. The two agree on the > UCS-2 > subset of UTF-16 (i.e. the BMP code points). If the intent is to forbind > non-BMP > passwords, we should ask the authors to change that, with a portability > warning. > Such passwords might not work everywhere, but forbidding them is unwise. > Whether or not it is the intent, the status quo (X.680 + RFC 7292) unambiguously forbids non-BMP passwords by way of the definition of BMPString. Not saying anything in the new document implies carrying over that restriction. I think extending UCS-2 to UTF-16 in the context of PKCS#12 passwords is a fine idea. Likewise with other BMPStrings in PKCS#12 like the friendlyName attribute. (Though, there, changing BMPString to CHOICE { BMPString, UTF8String} may be better as it keeps things working with a standard ASN.1 implementation. I'm fine with either.) But this should be explicitly specified somewhere, rather than implementations making up behavior. See also https://tools.ietf.org/html/draft-thomson-postel-was-wrong-03. As there appears to already be a draft in progress to update things, this should be pretty straightforward to do. Have it say something like: "The definition of BMPString in X.680 restricts the input to code points in the BMP, encoded in big-endian UCS-2. This document generalizes it for these fields to carry any code point, encoded in big-endian UTF-16. This is backwards-compatible with existing PKCS#12 decoders, but note that new files using code points outside the BMP may not interoperate with older decoders." David -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Jun 7 19:29:40 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 7 Jun 2018 19:29:40 +0000 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <404F1397-1398-4BD5-93A1-B2BA7A157EF3@openssl.org> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <20180607.210115.379638366064366181.levitte@openssl.org> <20180607191653.GE3322@mournblade.imrryr.org> <404F1397-1398-4BD5-93A1-B2BA7A157EF3@openssl.org> Message-ID: <15BEE3C8-5CFF-4374-95B9-0BF91D0E1B25@akamai.com> > My main concern is that currently, openssl pkcs12 may create broken pkcs12 files (because it misinterprets the pass phrase when constructing a BMPString), and doesn't notify the user at all (doesn't even check). For those who haven't reada the PR and all its comments, I propose that we reject non-ASCII input unless one of two flags is set. This prevents us from unknowingly making the situation worse, and does not break interop with our installed base. From levitte at openssl.org Thu Jun 7 19:35:01 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 07 Jun 2018 21:35:01 +0200 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <15BEE3C8-5CFF-4374-95B9-0BF91D0E1B25@akamai.com> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <20180607.210115.379638366064366181.levitte@openssl.org> <20180607191653.GE3322@mournblade.imrryr.org> <404F1397-1398-4BD5-93A1-B2BA7A157EF3@openssl.org> <15BEE3C8-5CFF-4374-95B9-0BF91D0E1B25@akamai.com> Message-ID: <4B57B495-4985-463D-B494-3AAC2B1942DE@openssl.org> "Salz, Rich" skrev: (7 juni 2018 21:29:40 CEST) >> My main concern is that currently, openssl pkcs12 may create >broken pkcs12 files (because it misinterprets the pass phrase when >constructing a BMPString), and doesn't notify the user at all (doesn't >even check). > > >For those who haven't reada the PR and all its comments, I propose that >we reject non-ASCII input unless one of two flags is set. This >prevents us from unknowingly making the situation worse, and does not >break interop with our installed base. So even rejecting correctly encoded utf-8? -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. From rsalz at akamai.com Thu Jun 7 19:40:02 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 7 Jun 2018 19:40:02 +0000 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <4B57B495-4985-463D-B494-3AAC2B1942DE@openssl.org> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <20180607.210115.379638366064366181.levitte@openssl.org> <20180607191653.GE3322@mournblade.imrryr.org> <404F1397-1398-4BD5-93A1-B2BA7A157EF3@openssl.org> <15BEE3C8-5CFF-4374-95B9-0BF91D0E1B25@akamai.com> <4B57B495-4985-463D-B494-3AAC2B1942DE@openssl.org> Message-ID: <82A7C165-E14D-4130-8443-800228E74E21@akamai.com> > So even rejecting correctly encoded utf-8? I think you forgot that this is not what I suggested. One flag indicates it's utf-8 encoded, don't touch it. The other flag indicates it might have high-bit chars, don't touch it. From rsalz at akamai.com Thu Jun 7 19:59:44 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 7 Jun 2018 19:59:44 +0000 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <82A7C165-E14D-4130-8443-800228E74E21@akamai.com> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <20180607.210115.379638366064366181.levitte@openssl.org> <20180607191653.GE3322@mournblade.imrryr.org> <404F1397-1398-4BD5-93A1-B2BA7A157EF3@openssl.org> <15BEE3C8-5CFF-4374-95B9-0BF91D0E1B25@akamai.com> <4B57B495-4985-463D-B494-3AAC2B1942DE@openssl.org> <82A7C165-E14D-4130-8443-800228E74E21@akamai.com> Message-ID: <7FB2D6B5-3175-4341-9F07-F59080DDC754@akamai.com> Here is proposed documentation for what I am suggesting. =item B<-passutf8>, B<-pass8bit> These flags indicate the character set encoding on the password value. By default, non-ASCII characters are rejected. This is new to OpenSSL 1.1.1, and is used to enforce complains with the PKCS#12 standard. If B<-passutf8> is given, then the password is taken to be valid UTF-8 encoding, and will be used directly. If B<-pass8bit> is given, the password is taken to be encoded in the current locale, but is still used directly. A future release might automatically convert the password to valid UTF-8 encoding if this flag is given. ?On 6/7/18, 3:42 PM, "Salz, Rich" wrote: > So even rejecting correctly encoded utf-8? I think you forgot that this is not what I suggested. One flag indicates it's utf-8 encoded, don't touch it. The other flag indicates it might have high-bit chars, don't touch it. _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project From openssl-users at dukhovni.org Thu Jun 7 20:14:20 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 7 Jun 2018 16:14:20 -0400 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <7FB2D6B5-3175-4341-9F07-F59080DDC754@akamai.com> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <20180607.210115.379638366064366181.levitte@openssl.org> <20180607191653.GE3322@mournblade.imrryr.org> <404F1397-1398-4BD5-93A1-B2BA7A157EF3@openssl.org> <15BEE3C8-5CFF-4374-95B9-0BF91D0E1B25@akamai.com> <4B57B495-4985-463D-B494-3AAC2B1942DE@openssl.org> <82A7C165-E14D-4130-8443-800228E74E21@akamai.com> <7FB2D6B5-3175-4341-9F07-F59080DDC754@akamai.com> Message-ID: <2785D505-B8A0-48CE-A406-9F43E7BC5077@dukhovni.org> > On Jun 7, 2018, at 3:59 PM, Salz, Rich wrote: > > If B<-pass8bit> is given, the password is taken to be encoded in the current > locale, but is still used directly. > A future release might automatically convert the password to valid UTF-8 > encoding if this flag is given. I would propose that "-pass8bit" means that each byte of the input is a unicode code point value (i.e. ASCII or LATIN1 supplement) and we'll convert to UCS-2 by prepending 0x00 to each one. If so, I would expect this flag to NOT ever change its meaning. We may internally convert to UTF-8 and then to UTF-16 largely undoing the first conversion, but that just internal API gymnastics, not user- observable. -- Viktor. From kurt at roeckx.be Thu Jun 7 20:59:12 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 7 Jun 2018 22:59:12 +0200 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <7B0424BB-7A55-4B59-87D6-B3AE5EC165AE@openssl.org> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <7B0424BB-7A55-4B59-87D6-B3AE5EC165AE@openssl.org> Message-ID: <20180607205911.GA24948@roeckx.be> On Thu, Jun 07, 2018 at 05:19:48PM +0200, Richard Levitte wrote: > Regarding general use of other libraries, please think carefully before voting, 'cause this *is* tricky. If you have a look, you will see that we *currently* depend on certain standard libraries, such as, for example, libdl. And perhaps we should also mention the pile of libraries used with windows. We also started depending on pthread in 1.1.0 ... Kurt From kurt at roeckx.be Thu Jun 7 21:06:15 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 7 Jun 2018 23:06:15 +0200 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <20180607170733.GR72167@kduck.kaduk.org> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <7B0424BB-7A55-4B59-87D6-B3AE5EC165AE@openssl.org> <20180607170733.GR72167@kduck.kaduk.org> Message-ID: <20180607210615.GB24948@roeckx.be> On Thu, Jun 07, 2018 at 12:07:34PM -0500, Benjamin Kaduk wrote: > On Thu, Jun 07, 2018 at 05:55:27PM +0200, Andy Polyakov wrote: > > > Regarding general use of other libraries, please think carefully before voting, 'cause this *is* tricky. If you have a look, you will see that we *currently* depend on certain standard libraries, such as, for example, libdl. > > > > One has to recognize that each dependency has to be justified. Sometimes > > you don't have a choice. For example if you want to talk network on > > Solaris, you have to link with -lsocket -lnsl. It's just part of the > > game. But in cases one has a choice, well, one has a choice to *make*. > > And key question is how do you anchor it. It's only natural to have as > > little dependencies as possible, so question is what would justify extra > > dependency. > > Taking off on a bit of a tangent, how much justification did we go > through when adding pthreads as a dependency. I have not been > following very much (Kurt would know more), but apparently in Debian > there are some issues regarding (statically linked?) applications > and libraries that use libcrypto but do not explicitly link with > -pthread. "Issues" here being, IIRC, crashes at runtime. I haven't really followed it, I just saw some mentionng of it on IRC. At least static linkig glibc itself is complicated. I guess it's also complicated because libc itself contains stubs for the pthread functions, so at least the order of the libraries will be important when linking staticly. But I didn't read anything about crashes, I might have missed things. Kurt From emilia at openssl.org Fri Jun 8 19:56:42 2018 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Fri, 8 Jun 2018 21:56:42 +0200 Subject: [openssl-project] stepping down from OMC Message-ID: Hi all, I'm leaving the project. This should come as no surprise. I've had little to no time to work on OpenSSL lately, and I firmly believe that OpenSSL should be driven by engineers that are actively engaged in the project and writing code for it. But also, I feel that OpenSSL has achieved the goals I set out to contribute to when I joined the team: a healthy open-source community and a transparent technical process. I'm happy to have contributed towards open code review, and I'll remember drafting the first Committer Guidelines as a special moment. And while I can't exactly say that I'm proud of the times when we were putting out security fires on a monthly basis, a day in the office is remarkably more boring now that it's been over a year since the last high severity OpenSSL vulnerability =) Good luck and good bye! Emilia -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Jun 8 21:11:27 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 8 Jun 2018 22:11:27 +0100 Subject: [openssl-project] stepping down from OMC In-Reply-To: References: Message-ID: <65fd3989-835c-d2ec-6676-16eb3139b1ea@openssl.org> On 08/06/18 20:56, Emilia K?sper wrote: > Hi all, > > I'm leaving the project. This should come as no surprise. I've had > little to no time to work on OpenSSL lately, and I firmly believe that > OpenSSL should be driven by engineers that are actively engaged in the > project and writing code for it. > > But also, I feel that OpenSSL has achieved the goals I set out to > contribute to when I joined the team: a healthy open-source community > and a transparent technical process. I'm happy to have contributed > towards open code review, and I'll remember drafting the first Committer > Guidelines as a special moment. And while I can't exactly say that I'm > proud of the times when we were putting out security fires on a monthly > basis, a day in the office is remarkably more boring now that it's been > over a year since the last high severity OpenSSL vulnerability =) Emilia, Thank you for all your contributions and work that you put into OpenSSL. It has been a pleasure working with you. I hope you won't be a complete stranger to the project! Matt From appro at openssl.org Sun Jun 10 18:37:39 2018 From: appro at openssl.org (Andy Polyakov) Date: Sun, 10 Jun 2018 20:37:39 +0200 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <7B0424BB-7A55-4B59-87D6-B3AE5EC165AE@openssl.org> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <7B0424BB-7A55-4B59-87D6-B3AE5EC165AE@openssl.org> Message-ID: <610544da-2c9c-64ef-cf03-60d94dd7d7ff@openssl.org> > Regarding general use of other libraries, please think carefully before voting, 'cause this *is* tricky. If you have a look, you will see that we *currently* depend on certain standard libraries, such as, for example, libdl. And perhaps we should also mention the pile of libraries used with windows. > > In my mind, this makes that more general vote ridiculous, It certainly is, the vote should not be about such general principle. It's way too general and most importantly *too natural* to vote about. In sense that there are things that can't be voting matter. For example "humans need air to breath" is not, and so is assertion that OpenSSL needs libraries. And it's all but utterly natural to *minimize* dependencies and make *minimum* assumptions. This means that one can only vote on specifics, i.e. do we want specific dependency (at specific level) or make specific assumption (at specific level). That's why ballot should not be formulated "such as iconv", but *be* about iconv. As for iconv per se. One has to recognize that it was standardized by POSIX and one can expect it to be available on compliant system. Trick is to reliably identify the said systems, and possibly by version, not just by being X. So it's as important to have a fall-back to handle the exclusions. As there will be exclusions. I can even name one already, Android. And once again, I argue that there is even timing issue. It's not right moment to make too broad assumptions about iconv availability arguing that one is prepared to deal with issues. One can only argue that it might be appropriate to enable it in cases one can actually verify and confirm. From rsalz at akamai.com Mon Jun 11 11:58:45 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 11 Jun 2018 11:58:45 +0000 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <610544da-2c9c-64ef-cf03-60d94dd7d7ff@openssl.org> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <7B0424BB-7A55-4B59-87D6-B3AE5EC165AE@openssl.org> <610544da-2c9c-64ef-cf03-60d94dd7d7ff@openssl.org> Message-ID: <3915E784-C385-48DE-B982-48087FCF881B@akamai.com> And also: having *runtime* dependencies means that a pkcs12 password file generated on one system could not be used on another. I am strongly opposed to introducing that variance, especially in a "compatible" release. From rsalz at akamai.com Mon Jun 11 15:06:01 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 11 Jun 2018 15:06:01 +0000 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <2785D505-B8A0-48CE-A406-9F43E7BC5077@dukhovni.org> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <20180607.210115.379638366064366181.levitte@openssl.org> <20180607191653.GE3322@mournblade.imrryr.org> <404F1397-1398-4BD5-93A1-B2BA7A157EF3@openssl.org> <15BEE3C8-5CFF-4374-95B9-0BF91D0E1B25@akamai.com> <4B57B495-4985-463D-B494-3AAC2B1942DE@openssl.org> <82A7C165-E14D-4130-8443-800228E74E21@akamai.com> <7FB2D6B5-3175-4341-9F07-F59080DDC754@akamai.com> <2785D505-B8A0-48CE-A406-9F43E7BC5077@dukhovni.org> Message-ID: > If B<-pass8bit> is given, the password is taken to be encoded in the current > locale, but is still used directly. > A future release might automatically convert the password to valid UTF-8 > encoding if this flag is given. I would propose that "-pass8bit" means that each byte of the input is a unicode code point value (i.e. ASCII or LATIN1 supplement) and we'll convert to UCS-2 by prepending 0x00 to each one. If so, I would expect this flag to NOT ever change its meaning. I don't see the point of this. My goal, with the two flags, was to allow users to make explicit what they want, and to warn them that *one* of the cases might/will change in the future. From rsalz at akamai.com Mon Jun 11 15:10:11 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 11 Jun 2018 15:10:11 +0000 Subject: [openssl-project] [openssl-omc] stepping down from OMC In-Reply-To: References: Message-ID: * I'm leaving the project. https://www.youtube.com/watch?v=YtsZoIe3Czk You have a great deal to be proud of, and OpenSSL is much better for the time you spent here. We will miss you. I will miss you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Jun 11 15:21:14 2018 From: levitte at openssl.org (Richard Levitte) Date: Mon, 11 Jun 2018 17:21:14 +0200 (CEST) Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: References: <7FB2D6B5-3175-4341-9F07-F59080DDC754@akamai.com> <2785D505-B8A0-48CE-A406-9F43E7BC5077@dukhovni.org> Message-ID: <20180611.172114.2224129771235795007.levitte@openssl.org> In message on Mon, 11 Jun 2018 15:06:01 +0000, "Salz, Rich" said: rsalz> > If B<-pass8bit> is given, the password is taken to be encoded in the current rsalz> > locale, but is still used directly. rsalz> > A future release might automatically convert the password to valid UTF-8 rsalz> > encoding if this flag is given. rsalz> rsalz> I would propose that "-pass8bit" means that each byte of the input is rsalz> a unicode code point value (i.e. ASCII or LATIN1 supplement) and we'll rsalz> convert to UCS-2 by prepending 0x00 to each one. If so, I would expect rsalz> this flag to NOT ever change its meaning. rsalz> rsalz> I don't see the point of this. rsalz> rsalz> My goal, with the two flags, was to allow users to make explicit what they want, and to warn them that *one* of the cases might/will change in the future. Well, that is what's done in PKCS12_generate_mac(), so this isn't something that should be done by the application. What the appication *must* do when getting '-pass8bit' is to do a na?ve UTF-8 encode of the input pass phrase string. PKCS12_generate_mac() will then decode it and zero extend every resulting byte to 16 bits. If you *don't* do this, you risk having any byte sequence that looks like UTF-8 in the original input to be decoded and made into something other than what the user intended. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Mon Jun 11 15:25:23 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 11 Jun 2018 15:25:23 +0000 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <20180611.172114.2224129771235795007.levitte@openssl.org> References: <7FB2D6B5-3175-4341-9F07-F59080DDC754@akamai.com> <2785D505-B8A0-48CE-A406-9F43E7BC5077@dukhovni.org> <20180611.172114.2224129771235795007.levitte@openssl.org> Message-ID: <8EE45344-9BFC-44F9-9DB2-C384F7645CD6@akamai.com> > *must* do when getting '-pass8bit' is to do a na?ve UTF-8 encode of the input pass phrase string. PKCS12_generate_mac() will then decode I disagree. There are two reasons why users enter "illegal" passwords now, and by now requiring them to make it explicit we can (a) check only for ASCII on current inputs; (b) make them thing about what they're doing and require them to specify; (c) set the expectation that something will change in the future. From levitte at openssl.org Mon Jun 11 15:40:17 2018 From: levitte at openssl.org (Richard Levitte) Date: Mon, 11 Jun 2018 17:40:17 +0200 (CEST) Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <8EE45344-9BFC-44F9-9DB2-C384F7645CD6@akamai.com> References: <20180611.172114.2224129771235795007.levitte@openssl.org> <8EE45344-9BFC-44F9-9DB2-C384F7645CD6@akamai.com> Message-ID: <20180611.174017.983859058924160655.levitte@openssl.org> In message <8EE45344-9BFC-44F9-9DB2-C384F7645CD6 at akamai.com> on Mon, 11 Jun 2018 15:25:23 +0000, "Salz, Rich" said: rsalz> > *must* do when getting '-pass8bit' is to do a na?ve UTF-8 encode of rsalz> the input pass phrase string. PKCS12_generate_mac() will then decode rsalz> rsalz> I disagree. rsalz> rsalz> There are two reasons why users enter "illegal" passwords now, rsalz> and by now requiring them to make it explicit we can (a) check rsalz> only for ASCII on current inputs; (b) make them thing about rsalz> what they're doing and require them to specify; (c) set the rsalz> expectation that something will change in the future. [btw, PKCS12_gen_mac(), not PKCS12_generate_mac()] So wait, if the user enters this: openssl pkcs12 -export -in foo.pem -out foo.p12 \ -pass8bit -password pass:`echo 72c3a46b61 | xxd -r -p` ... then it seems "natural" that the user would expect the resulting BMPString to become this set of bytes, right? 0x00, 0x72, 0x00, 0xc3, 0x00, 0xa4, 0x00, 0x6b, 0x00, 0x61, 0x00, 0x00 However, what's going to happen is that PKCS12_gen_mac() will generate this for a BMPString: 0x00, 0x72, 0x00, 0xe4, 0x00, 0x6b, 0x00, 0x61, 0x00, 0x00 Why? Because the input pass phrase can be interpreted as a UTF-8 encoded string, and PKCS12_gen_mac() will decode it thusly. >From a user interface point of view, I would fine such behavior very surprising, and not at all what I'd expect for a flag named '-pass8bit' Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Mon Jun 11 15:46:38 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 11 Jun 2018 15:46:38 +0000 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <20180611.174017.983859058924160655.levitte@openssl.org> References: <20180611.172114.2224129771235795007.levitte@openssl.org> <8EE45344-9BFC-44F9-9DB2-C384F7645CD6@akamai.com> <20180611.174017.983859058924160655.levitte@openssl.org> Message-ID: <80D24B14-F73B-4258-B9EE-BB96F95BD064@akamai.com> > However, what's going to happen is that PKCS12_gen_mac() will generate this for a BMPString: Which is what we do now, right? And the docs for this *new flag* explain that the behavior could change in the future. To be "pass8bit" means "pass 8bit bytes through to lower layer" But if we want to bikeshed about the name of the flag, fine. From levitte at openssl.org Mon Jun 11 15:46:58 2018 From: levitte at openssl.org (Richard Levitte) Date: Mon, 11 Jun 2018 17:46:58 +0200 (CEST) Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <8EE45344-9BFC-44F9-9DB2-C384F7645CD6@akamai.com> References: <20180611.172114.2224129771235795007.levitte@openssl.org> <8EE45344-9BFC-44F9-9DB2-C384F7645CD6@akamai.com> Message-ID: <20180611.174658.889950056271240296.levitte@openssl.org> In message <8EE45344-9BFC-44F9-9DB2-C384F7645CD6 at akamai.com> on Mon, 11 Jun 2018 15:25:23 +0000, "Salz, Rich" said: rsalz> > *must* do when getting '-pass8bit' is to do a na?ve UTF-8 encode of rsalz> the input pass phrase string. PKCS12_generate_mac() will then decode rsalz> rsalz> I disagree. rsalz> rsalz> There are two reasons why users enter "illegal" passwords now, and by now requiring them to make it explicit we can (a) check only for ASCII on current inputs; (b) make them thing about what they're doing and require them to specify; (c) set the expectation that something will change in the future. A variant is to check if the 8bit string can be decoded as a UTF-8 string and warn the user that such string is going to get screwed. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Mon Jun 11 15:48:03 2018 From: levitte at openssl.org (Richard Levitte) Date: Mon, 11 Jun 2018 17:48:03 +0200 (CEST) Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <80D24B14-F73B-4258-B9EE-BB96F95BD064@akamai.com> References: <8EE45344-9BFC-44F9-9DB2-C384F7645CD6@akamai.com> <20180611.174017.983859058924160655.levitte@openssl.org> <80D24B14-F73B-4258-B9EE-BB96F95BD064@akamai.com> Message-ID: <20180611.174803.558818446511595769.levitte@openssl.org> In message <80D24B14-F73B-4258-B9EE-BB96F95BD064 at akamai.com> on Mon, 11 Jun 2018 15:46:38 +0000, "Salz, Rich" said: rsalz> And the docs for this *new flag* explain that the behavior could change in the future. I have zero idea what the doc says, because I haven't seen the docs yet. Did I miss the PR? -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Mon Jun 11 16:03:48 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 11 Jun 2018 16:03:48 +0000 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <20180611.174803.558818446511595769.levitte@openssl.org> References: <8EE45344-9BFC-44F9-9DB2-C384F7645CD6@akamai.com> <20180611.174017.983859058924160655.levitte@openssl.org> <80D24B14-F73B-4258-B9EE-BB96F95BD064@akamai.com> <20180611.174803.558818446511595769.levitte@openssl.org> Message-ID: <5BA62036-BD2E-41B7-ADF9-25C6C116EF2A@akamai.com> > I have zero idea what the doc says, because I haven't seen the docs yet. Did I miss the PR? No. It's posted here on the mailing list for discussion and reposted here: +=item B<-passutf8>, B<-pass8bit> + +These flags indicate the character set encoding on the password value. +By default, non-ASCII characters are rejected. This is new behavior +with OpenSSL 1.1.1, +and is used to enforce compliance with the PKCS#12 standard. +If B<-passutf8> is given, then the password is taken to be valid UTF-8 encoding, +and will be used directly. +If B<-pass8bit> is given, the password is taken to be encoded in the current +locale, but is still used directly; note that +a future release might automatically convert the password to valid UTF-8 +encoding if this flag is given. + From bernd.edlinger at hotmail.de Mon Jun 11 16:17:33 2018 From: bernd.edlinger at hotmail.de (Bernd Edlinger) Date: Mon, 11 Jun 2018 16:17:33 +0000 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <20180611.174017.983859058924160655.levitte@openssl.org> References: <20180611.172114.2224129771235795007.levitte@openssl.org> <8EE45344-9BFC-44F9-9DB2-C384F7645CD6@akamai.com> <20180611.174017.983859058924160655.levitte@openssl.org> Message-ID: On 06/11/18 17:40, Richard Levitte wrote: > In message <8EE45344-9BFC-44F9-9DB2-C384F7645CD6 at akamai.com> on Mon, 11 Jun 2018 15:25:23 +0000, "Salz, Rich" said: > > rsalz> > *must* do when getting '-pass8bit' is to do a na?ve UTF-8 encode of > rsalz> the input pass phrase string. PKCS12_generate_mac() will then decode > rsalz> > rsalz> I disagree. > rsalz> > rsalz> There are two reasons why users enter "illegal" passwords now, > rsalz> and by now requiring them to make it explicit we can (a) check > rsalz> only for ASCII on current inputs; (b) make them thing about > rsalz> what they're doing and require them to specify; (c) set the > rsalz> expectation that something will change in the future. > > [btw, PKCS12_gen_mac(), not PKCS12_generate_mac()] > > So wait, if the user enters this: > > openssl pkcs12 -export -in foo.pem -out foo.p12 \ > -pass8bit -password pass:`echo 72c3a46b61 | xxd -r -p` > > ... then it seems "natural" that the user would expect the resulting > BMPString to become this set of bytes, right? > > 0x00, 0x72, 0x00, 0xc3, 0x00, 0xa4, 0x00, 0x6b, 0x00, 0x61, 0x00, 0x00 > > However, what's going to happen is that PKCS12_gen_mac() will generate > this for a BMPString: > > 0x00, 0x72, 0x00, 0xe4, 0x00, 0x6b, 0x00, 0x61, 0x00, 0x00 > > Why? Because the input pass phrase can be interpreted as a UTF-8 > encoded string, and PKCS12_gen_mac() will decode it thusly. > > From a user interface point of view, I would fine such behavior very > surprising, and not at all what I'd expect for a flag named '-pass8bit' > I think there are many ways for the user to shoot into his own knee with entering unicode glyphs accidentally, with are even invisible when printed to the console, just think of the EM DASH U+2014: "?" Or unicode non break space U+00A0 which looks like an ordinary space but is something different As a user, I would not be happy if one of these slipped into a password, that's certainly sure. So in my opinion when entering new passwords it should be restricted to 7bit ASCII printable characters, except if advised otherwise by an option like -pass8bit. Bernd. From levitte at openssl.org Mon Jun 11 16:32:38 2018 From: levitte at openssl.org (Richard Levitte) Date: Mon, 11 Jun 2018 18:32:38 +0200 (CEST) Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <5BA62036-BD2E-41B7-ADF9-25C6C116EF2A@akamai.com> References: <80D24B14-F73B-4258-B9EE-BB96F95BD064@akamai.com> <20180611.174803.558818446511595769.levitte@openssl.org> <5BA62036-BD2E-41B7-ADF9-25C6C116EF2A@akamai.com> Message-ID: <20180611.183238.1488272518276817866.levitte@openssl.org> In message <5BA62036-BD2E-41B7-ADF9-25C6C116EF2A at akamai.com> on Mon, 11 Jun 2018 16:03:48 +0000, "Salz, Rich" said: rsalz> > I have zero idea what the doc says, because I haven't seen the docs rsalz> yet. Did I miss the PR? rsalz> rsalz> No. It's posted here on the mailing list for discussion and reposted here: Ah, found it in the archive... I somehow glossed over it before, sorry. rsalz> +If B<-pass8bit> is given, the password is taken to be encoded in the current rsalz> +locale, but is still used directly; note that rsalz> +a future release might automatically convert the password to valid UTF-8 rsalz> +encoding if this flag is given. Except that, because of the way PKCS12_gen_mac() works, this isn't true. If the input pass phrase looks like a UTF-8 encoded string (because there are valid characters in other encodings that will like like UTF-8 byte sequences), it will be used as if -passutf8 was given instead. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Mon Jun 11 16:34:32 2018 From: levitte at openssl.org (Richard Levitte) Date: Mon, 11 Jun 2018 18:34:32 +0200 (CEST) Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: References: <8EE45344-9BFC-44F9-9DB2-C384F7645CD6@akamai.com> <20180611.174017.983859058924160655.levitte@openssl.org> Message-ID: <20180611.183432.988992010214698465.levitte@openssl.org> In message on Mon, 11 Jun 2018 16:17:33 +0000, Bernd Edlinger said: bernd.edlinger> So in my opinion when entering new passwords it should be restricted to bernd.edlinger> 7bit ASCII printable characters, except if advised otherwise by an bernd.edlinger> option like -pass8bit. That's Rich's intent, and I'm fine with that. It's the fine print of what message we tell with -pass8bit that's being disputed. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Mon Jun 11 16:54:37 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 11 Jun 2018 16:54:37 +0000 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <20180611.183238.1488272518276817866.levitte@openssl.org> References: <80D24B14-F73B-4258-B9EE-BB96F95BD064@akamai.com> <20180611.174803.558818446511595769.levitte@openssl.org> <5BA62036-BD2E-41B7-ADF9-25C6C116EF2A@akamai.com> <20180611.183238.1488272518276817866.levitte@openssl.org> Message-ID: <22DB1499-DFD9-4C3E-AF5A-AE21EE4AAEAC@akamai.com> > Except that, because of the way PKCS12_gen_mac() works, this isn't true. If the input pass phrase looks like a UTF-8 encoded string (because there are valid characters in other encodings that will like like UTF-8 byte sequences), it will be used as if -passutf8 was given instead. Well, at least I started down the path. I wonder if one of those flags should set the keygen to asc? From levitte at openssl.org Mon Jun 11 17:29:09 2018 From: levitte at openssl.org (Richard Levitte) Date: Mon, 11 Jun 2018 19:29:09 +0200 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <22DB1499-DFD9-4C3E-AF5A-AE21EE4AAEAC@akamai.com> References: <80D24B14-F73B-4258-B9EE-BB96F95BD064@akamai.com> <20180611.174803.558818446511595769.levitte@openssl.org> <5BA62036-BD2E-41B7-ADF9-25C6C116EF2A@akamai.com> <20180611.183238.1488272518276817866.levitte@openssl.org> <22DB1499-DFD9-4C3E-AF5A-AE21EE4AAEAC@akamai.com> Message-ID: <2418FE0A-8A61-47AD-9E60-F40BD0C79582@openssl.org> "Salz, Rich" skrev: (11 juni 2018 18:54:37 CEST) >> Except that, because of the way PKCS12_gen_mac() works, this isn't > true. If the input pass phrase looks like a UTF-8 encoded string > (because there are valid characters in other encodings that will like > like UTF-8 byte sequences), it will be used as if -passutf8 was given > instead. > >Well, at least I started down the path. I wonder if one of those flags >should set the keygen to asc? That could be an idea, except that's not an easy change. Effectively, that's exactly equivalent to doing a na?ve utf-8 encode in the application. Cheers Richard -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From levitte at openssl.org Tue Jun 12 07:08:11 2018 From: levitte at openssl.org (Richard Levitte) Date: Tue, 12 Jun 2018 09:08:11 +0200 (CEST) Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <2418FE0A-8A61-47AD-9E60-F40BD0C79582@openssl.org> References: <20180611.183238.1488272518276817866.levitte@openssl.org> <22DB1499-DFD9-4C3E-AF5A-AE21EE4AAEAC@akamai.com> <2418FE0A-8A61-47AD-9E60-F40BD0C79582@openssl.org> Message-ID: <20180612.090811.2224872165879837725.levitte@openssl.org> In message <2418FE0A-8A61-47AD-9E60-F40BD0C79582 at openssl.org> on Mon, 11 Jun 2018 19:29:09 +0200, Richard Levitte said: levitte> levitte> levitte> "Salz, Rich" skrev: (11 juni 2018 18:54:37 CEST) levitte> >> Except that, because of the way PKCS12_gen_mac() works, this isn't levitte> > true. If the input pass phrase looks like a UTF-8 encoded string levitte> > (because there are valid characters in other encodings that will like levitte> > like UTF-8 byte sequences), it will be used as if -passutf8 was given levitte> > instead. levitte> > levitte> >Well, at least I started down the path. I wonder if one of those flags levitte> >should set the keygen to asc? levitte> levitte> That could be an idea, except that's not an easy change. Effectively, that's exactly equivalent to doing a na?ve utf-8 encode in the application. BTW, this subthread is a development discussion... shouldn't that be happening on github, along with a WIP PR? -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Tue Jun 12 09:16:34 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 12 Jun 2018 10:16:34 +0100 Subject: [openssl-project] Please approve 6457 for backport Message-ID: This is the PR for the CVE. I forgot to add the branches to the PR...this is for 1.1.0 and 1.0.2. Please can someone approve the backport asap? Thanks Matt From matt at openssl.org Tue Jun 12 09:59:18 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 12 Jun 2018 10:59:18 +0100 Subject: [openssl-project] Please approve 6457 for backport In-Reply-To: References: Message-ID: <98070898-cbe1-b234-e563-6490f5a33110@openssl.org> On 12/06/18 10:16, Matt Caswell wrote: > This is the PR for the CVE. I forgot to add the branches to the > PR...this is for 1.1.0 and 1.0.2. Please can someone approve the > backport asap? This is now done (thanks Tim). Now looking for an approval for the web updates: https://github.com/openssl/web/pull/58 Matt From openssl at openssl.org Tue Jun 12 10:18:03 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 12 Jun 2018 10:18:03 +0000 Subject: [openssl-project] OpenSSL Security Advisory Message-ID: <20180612101803.GA31999@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL Security Advisory [12 June 2018] ======================================== Client DoS due to large DH parameter (CVE-2018-0732) ==================================================== Severity: Low During key agreement in a TLS handshake using a DH(E) based ciphersuite a malicious server can send a very large prime value to the client. This will cause the client to spend an unreasonably long period of time generating a key for this prime resulting in a hang until the client has finished. This could be exploited in a Denial Of Service attack. Due to the low severity of this issue we are not issuing a new release of OpenSSL 1.1.0 or 1.0.2 at this time. The fix will be included in OpenSSL 1.1.0i and OpenSSL 1.0.2p when they become available. The fix is also available in commit ea7abeeab (for 1.1.0) and commit 3984ef0b7 (for 1.0.2) in the OpenSSL git repository. This issue was reported to OpenSSL on 5th June 2018 by Guido Vranken who also developed the fix. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20180612.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlsfnTgACgkQ2cTSbQ5g RJE9Twf/VSgXaFPlW+JyA2BAiwGREMr/oMQe8mhmka3WQgNb7oMQRxk4ZqwRvLi2 ggPVOQilJ+tkXgeifEQ3SDRxDnnmcUvxbWB8Lt+7tjhM6O+GYGbGbzupnkBs2IIY 72vll4l7ySMQ8/fcdU/uuNyObfigLC9XndH3tEewxffs6uvDxMyGhZmNQpq1aZNj rGj3dETUuO/Ln8siAD7nkv9xodRINViMP76fSKAtdaikvZa3uhLBMhX5tOzpR/ta tc2+6uthdU9JjSRZZpfDlzzhsOFqMrLfOLrJQIIXshxUNeOZyJCkmT9ED8XZRDMB twb1kOxCKz8Ky+Xm/Rki9uRVoZFjBg== =kKic -----END PGP SIGNATURE----- From openssl-users at dukhovni.org Tue Jun 12 14:03:28 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 12 Jun 2018 10:03:28 -0400 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <80D24B14-F73B-4258-B9EE-BB96F95BD064@akamai.com> References: <20180611.172114.2224129771235795007.levitte@openssl.org> <8EE45344-9BFC-44F9-9DB2-C384F7645CD6@akamai.com> <20180611.174017.983859058924160655.levitte@openssl.org> <80D24B14-F73B-4258-B9EE-BB96F95BD064@akamai.com> Message-ID: <37B332CE-D034-45E1-92CC-695CB0B6A802@dukhovni.org> > On Jun 11, 2018, at 11:46 AM, Salz, Rich wrote: > > And the docs for this *new flag* explain that the behavior could change in the future. There must be no "change in the future". Whatever flags we add now, must implement a stable interface. A flag that changes behaviour is useless. -- Viktor. From openssl-users at dukhovni.org Tue Jun 12 15:06:40 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 12 Jun 2018 11:06:40 -0400 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <82A7C165-E14D-4130-8443-800228E74E21@akamai.com> References: <20180607.135411.1872521132998223104.levitte@openssl.org> <20180607.210115.379638366064366181.levitte@openssl.org> <20180607191653.GE3322@mournblade.imrryr.org> <404F1397-1398-4BD5-93A1-B2BA7A157EF3@openssl.org> <15BEE3C8-5CFF-4374-95B9-0BF91D0E1B25@akamai.com> <4B57B495-4985-463D-B494-3AAC2B1942DE@openssl.org> <82A7C165-E14D-4130-8443-800228E74E21@akamai.com> Message-ID: > On Jun 7, 2018, at 3:40 PM, Salz, Rich wrote: > > I think you forgot that this is not what I suggested. One flag indicates it's utf-8 encoded, don't touch it. The other flag indicates it might have high-bit chars, don't touch it. The flags I'd like to see are: -latin1: Passphrase is a stream of octets, each of which is a single unicode character in the range 0-255. -utf8: Passphrase is already utf-8 encoded -ascii: Passphrase must be ASCII, reject inadvertent 8-bit input. And as available: -toutf8: Convert passphrase from the input encoding to UTF-8. Either using the locale-specific encoding, or yet another flag: -encoding: A platform-specific name for the input encoding understood by the system's encoding conversion library (iconv on Unix). None of these flags change semantics after introduction. -- -- Viktor. From levitte at openssl.org Tue Jun 12 19:39:02 2018 From: levitte at openssl.org (Richard Levitte) Date: Tue, 12 Jun 2018 21:39:02 +0200 (CEST) Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: References: <4B57B495-4985-463D-B494-3AAC2B1942DE@openssl.org> <82A7C165-E14D-4130-8443-800228E74E21@akamai.com> Message-ID: <20180612.213902.1015453641492421977.levitte@openssl.org> In message on Tue, 12 Jun 2018 11:06:40 -0400, Viktor Dukhovni said: openssl-users> openssl-users> openssl-users> > On Jun 7, 2018, at 3:40 PM, Salz, Rich wrote: openssl-users> > openssl-users> > I think you forgot that this is not what I suggested. One flag indicates it's utf-8 encoded, don't touch it. The other flag indicates it might have high-bit chars, don't touch it. openssl-users> openssl-users> The flags I'd like to see are: openssl-users> openssl-users> -latin1: Passphrase is a stream of octets, each of which is a single unicode openssl-users> character in the range 0-255. I would prefer to call it -binary or something like that... it certainly comes down to the same thing in practice, and should translate exactly to the pre-1.1.0 behaviour. openssl-users> -utf8: Passphrase is already utf-8 encoded openssl-users> openssl-users> -ascii: Passphrase must be ASCII, reject inadvertent 8-bit input. ... and if none of these are given? openssl-users> And as available: openssl-users> openssl-users> -toutf8: Convert passphrase from the input encoding to UTF-8. openssl-users> Either using the locale-specific encoding, or yet openssl-users> another flag: openssl-users> openssl-users> -encoding: A platform-specific name for the input encoding understood openssl-users> by the system's encoding conversion library (iconv on Unix). If the availability of -toutf8 depends on the presumed presence of iconv(), then we can assume that nl_langinfo() is present as well. That renders -encoding unnecessary, unless you want to use it to override the locale-specific encoding. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Tue Jun 12 20:02:16 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 12 Jun 2018 16:02:16 -0400 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <20180612.213902.1015453641492421977.levitte@openssl.org> References: <4B57B495-4985-463D-B494-3AAC2B1942DE@openssl.org> <82A7C165-E14D-4130-8443-800228E74E21@akamai.com> <20180612.213902.1015453641492421977.levitte@openssl.org> Message-ID: <333784C8-4870-4DDB-A892-13D552724222@dukhovni.org> > On Jun 12, 2018, at 3:39 PM, Richard Levitte wrote: > >> The flags I'd like to see are: >> >> -latin1: Passphrase is a stream of octets, each of which is a single unicode >> character in the range 0-255. > > I would prefer to call it -binary or something like that... it > certainly comes down to the same thing in practice, and should > translate exactly to the pre-1.1.0 behaviour. I won't quibble over the name. > >> -utf8: Passphrase is already utf-8 encoded >> >> -ascii: Passphrase must be ASCII, reject inadvertent 8-bit input. > > ... and if none of these are given? Not sure. We could opt for "-binary" by default, which is backwards compatible, but it produces non-standard outputs, which is a disfavour to new users. We could go with "-ascii" as a default, forcing failure for non-ascii passwords without an explicit indication of encoding. The second seems more appealing to me. >> And as available: >> >> -toutf8: Convert passphrase from the input encoding to UTF-8. >> Either using the locale-specific encoding, or yet >> another flag: >> >> -encoding: A platform-specific name for the input encoding understood >> by the system's encoding conversion library (iconv on Unix). > > If the availability of -toutf8 depends on the presumed presence of > iconv(), then we can assume that nl_langinfo() is present as well. > That renders -encoding unnecessary, unless you want to use it to > override the locale-specific encoding. The purpose is specifically to override the encoding when it is wrong for some reason. The iconv library takes the empty string as the locale-specific encoding, so we should not need nl_langinfo(), unless that's known to produce better results. -- Viktor. From levitte at openssl.org Tue Jun 12 22:56:50 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 13 Jun 2018 00:56:50 +0200 (CEST) Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <333784C8-4870-4DDB-A892-13D552724222@dukhovni.org> References: <20180612.213902.1015453641492421977.levitte@openssl.org> <333784C8-4870-4DDB-A892-13D552724222@dukhovni.org> Message-ID: <20180613.005650.972270183259818739.levitte@openssl.org> In message <333784C8-4870-4DDB-A892-13D552724222 at dukhovni.org> on Tue, 12 Jun 2018 16:02:16 -0400, Viktor Dukhovni said: openssl-users> openssl-users> openssl-users> > On Jun 12, 2018, at 3:39 PM, Richard Levitte wrote: openssl-users> > openssl-users> >> The flags I'd like to see are: openssl-users> >> openssl-users> >> -latin1: Passphrase is a stream of octets, each of which is a single unicode openssl-users> >> character in the range 0-255. openssl-users> > openssl-users> > I would prefer to call it -binary or something like that... it openssl-users> > certainly comes down to the same thing in practice, and should openssl-users> > translate exactly to the pre-1.1.0 behaviour. openssl-users> openssl-users> I won't quibble over the name. openssl-users> openssl-users> > openssl-users> >> -utf8: Passphrase is already utf-8 encoded openssl-users> >> openssl-users> >> -ascii: Passphrase must be ASCII, reject inadvertent 8-bit input. openssl-users> > openssl-users> > ... and if none of these are given? openssl-users> openssl-users> Not sure. We could opt for "-binary" by default, which is backwards openssl-users> compatible, but it produces non-standard outputs, which is a disfavour openssl-users> to new users. We could go with "-ascii" as a default, forcing failure openssl-users> for non-ascii passwords without an explicit indication of encoding. openssl-users> The second seems more appealing to me. Same here. openssl-users> >> And as available: openssl-users> >> openssl-users> >> -toutf8: Convert passphrase from the input encoding to UTF-8. openssl-users> >> Either using the locale-specific encoding, or yet openssl-users> >> another flag: openssl-users> >> openssl-users> >> -encoding: A platform-specific name for the input encoding understood openssl-users> >> by the system's encoding conversion library (iconv on Unix). openssl-users> > openssl-users> > If the availability of -toutf8 depends on the presumed presence of openssl-users> > iconv(), then we can assume that nl_langinfo() is present as well. openssl-users> > That renders -encoding unnecessary, unless you want to use it to openssl-users> > override the locale-specific encoding. openssl-users> openssl-users> The purpose is specifically to override the encoding when it is wrong openssl-users> for some reason. The iconv library takes the empty string as the openssl-users> locale-specific encoding, so we should not need nl_langinfo(), unless openssl-users> that's known to produce better results. Some implementations of the iconv library take the empty string as the locale-specific encoding, but that is in no way universal, and isn't specified in the standard: http://pubs.opengroup.org/onlinepubs/009695399/functions/iconv_open.html Using nl_langinfo() to get the locale-specific encoding will, as far as I know, always get you what you expect. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Wed Jun 13 02:39:05 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 12 Jun 2018 22:39:05 -0400 Subject: [openssl-project] To use or not use the iconv API, and to use or not use other libraries In-Reply-To: <20180613.005650.972270183259818739.levitte@openssl.org> References: <20180612.213902.1015453641492421977.levitte@openssl.org> <333784C8-4870-4DDB-A892-13D552724222@dukhovni.org> <20180613.005650.972270183259818739.levitte@openssl.org> Message-ID: > On Jun 12, 2018, at 6:56 PM, Richard Levitte wrote: > > Some implementations of the iconv library take the empty string as > the locale-specific encoding, but that is in no way universal, and > isn't specified in the standard: > > http://pubs.opengroup.org/onlinepubs/009695399/functions/iconv_open.html > > Using nl_langinfo() to get the locale-specific encoding will, as far > as I know, always get you what you expect. On FreeBSD, after (required) calling: setlocale(LC_CTYPE, ""); The nl_langinfo(CODESET) returns the correct charset for by UTF-8 terminal emulator for which my environment has: LC_CTYPE=en_US.UTF-8 With that, iconv_open() and iconv() behave correctly converting to from ISO-8859-1 and UTF-8 (minimal tests). Without the setlocale() call, my encoding is always US-ASCII, and iconv is naturally crippled. -- Viktor. From levitte at openssl.org Wed Jun 13 14:52:46 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 13 Jun 2018 16:52:46 +0200 (CEST) Subject: [openssl-project] Monthly Status Report (May) Message-ID: <20180613.165246.1519756224119855526.levitte@openssl.org> [appologies for the delay] Apart from normal business, such as normal reviews, OMC business, normal system administration tasks, etc., key activities this month: Development: - Attended the OMC f2f in Ottawa (remotely) - Started as contact with legal advisor - Adapted VMS random seeding to the new DRBG methods - Documented our current handling of passphrase encoding and proposed a few ways to deal with it (still ongoing) - Proposed building docs as part of the build instead of during installation (PR pending) - Supported the 1.1.1-pre7 release - Small refinements in preparation for the final release Others: - Worked on platform support database (yet unpublished) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Wed Jun 13 15:35:33 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 13 Jun 2018 16:35:33 +0100 Subject: [openssl-project] ECDSA blinding Message-ID: FYI see commit a3e9d5aa98 (and equivalent commits in 1.1.0 and 1.0.2). These fixes were reviewed in private due to an embargo from the reporter. In spite of that we have chosen not to issue a CVE for these fixes since they are localhost side channels only. Matt From matt at openssl.org Tue Jun 19 15:16:43 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 19 Jun 2018 16:16:43 +0100 Subject: [openssl-project] Beta release today Message-ID: Oops, there is supposed to be a beta release today... If someone is available to review it (any volunteers), I'll do it this evening. Starting around 17.30 UTC (although it looks like we might have to fix travis first). In the meantime please could someone freeze the repo? Matt From rsalz at akamai.com Tue Jun 19 15:29:22 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 19 Jun 2018 15:29:22 +0000 Subject: [openssl-project] Beta release today In-Reply-To: References: Message-ID: <9FEEFD6D-A85B-4A4C-A44B-DFAAA55AE1A3@akamai.com> I can review, if you still want to do it. IM or email me. ?On 6/19/18, 11:16 AM, "Matt Caswell" wrote: Oops, there is supposed to be a beta release today... If someone is available to review it (any volunteers), I'll do it this evening. Starting around 17.30 UTC (although it looks like we might have to fix travis first). In the meantime please could someone freeze the repo? Matt _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project From matt at openssl.org Tue Jun 19 16:14:56 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 19 Jun 2018 17:14:56 +0100 Subject: [openssl-project] Beta release today In-Reply-To: <9FEEFD6D-A85B-4A4C-A44B-DFAAA55AE1A3@akamai.com> References: <9FEEFD6D-A85B-4A4C-A44B-DFAAA55AE1A3@akamai.com> Message-ID: <0f1649d0-c46b-84cf-0733-b24920a9d1a5@openssl.org> Actually, it feels a bit rushed, so I think I'm going to do it tomorrow instead. It would still be good if someone can freeze the repo though please: ssh openssl-git at git.openssl.org freeze openssl matt Matt On 19/06/18 16:29, Salz, Rich wrote: > I can review, if you still want to do it. IM or email me. > > ?On 6/19/18, 11:16 AM, "Matt Caswell" wrote: > > Oops, there is supposed to be a beta release today... > > > If someone is available to review it (any volunteers), I'll do it this > evening. Starting around 17.30 UTC (although it looks like we might have > to fix travis first). > > In the meantime please could someone freeze the repo? > > Matt > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > From rsalz at akamai.com Tue Jun 19 16:47:14 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 19 Jun 2018 16:47:14 +0000 Subject: [openssl-project] Beta release today In-Reply-To: <0f1649d0-c46b-84cf-0733-b24920a9d1a5@openssl.org> References: <9FEEFD6D-A85B-4A4C-A44B-DFAAA55AE1A3@akamai.com> <0f1649d0-c46b-84cf-0733-b24920a9d1a5@openssl.org> Message-ID: <95FD279A-9947-4C4B-89AC-4525680432CA@akamai.com> > It would still be good if someone can freeze the repo though please: ssh openssl-git at git.openssl.org freeze openssl matt I will do this tonight, eastern time. From mark at awe.com Tue Jun 19 17:01:19 2018 From: mark at awe.com (Mark J Cox) Date: Tue, 19 Jun 2018 18:01:19 +0100 Subject: [openssl-project] Open Source Summit Europe Message-ID: Just as a FYI in case anyone is interested in an OpenSSL-related submission (if you want to do something joint with me, I'm interested and local lol). > Conference: Open Source Summit Europe > Location: Edinburgh > Dates: October 22 ? 24 > > Deadline for speaking submissions: July 1 https://events.linuxfoundation.org/events/open-source-summit-europe-2018/ Mark From matt at openssl.org Tue Jun 19 17:10:38 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 19 Jun 2018 18:10:38 +0100 Subject: [openssl-project] Beta release today In-Reply-To: <0f1649d0-c46b-84cf-0733-b24920a9d1a5@openssl.org> References: <9FEEFD6D-A85B-4A4C-A44B-DFAAA55AE1A3@akamai.com> <0f1649d0-c46b-84cf-0733-b24920a9d1a5@openssl.org> Message-ID: On 19/06/18 17:14, Matt Caswell wrote: > Actually, it feels a bit rushed, so I think I'm going to do it tomorrow > instead. > > It would still be good if someone can freeze the repo though please: > > ssh openssl-git at git.openssl.org freeze openssl matt The repo is now frozen! Thanks Bernd. Matt > > Matt > > > On 19/06/18 16:29, Salz, Rich wrote: >> I can review, if you still want to do it. IM or email me. >> >> ?On 6/19/18, 11:16 AM, "Matt Caswell" wrote: >> >> Oops, there is supposed to be a beta release today... >> >> >> If someone is available to review it (any volunteers), I'll do it this >> evening. Starting around 17.30 UTC (although it looks like we might have >> to fix travis first). >> >> In the meantime please could someone freeze the repo? >> >> Matt >> _______________________________________________ >> openssl-project mailing list >> openssl-project at openssl.org >> https://mta.openssl.org/mailman/listinfo/openssl-project >> >> >> _______________________________________________ >> openssl-project mailing list >> openssl-project at openssl.org >> https://mta.openssl.org/mailman/listinfo/openssl-project >> > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > From kurt at roeckx.be Tue Jun 19 17:21:12 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 19 Jun 2018 19:21:12 +0200 Subject: [openssl-project] Open Source Summit Europe In-Reply-To: References: Message-ID: <20180619172111.GA26806@roeckx.be> On Tue, Jun 19, 2018 at 06:01:19PM +0100, Mark J Cox wrote: > Just as a FYI in case anyone is interested in an OpenSSL-related > submission (if you want to do something joint with me, I'm interested > and local lol). > > > Conference: Open Source Summit Europe > > Location: Edinburgh > > Dates: October 22 ? 24 > > > > Deadline for speaking submissions: July 1 > > https://events.linuxfoundation.org/events/open-source-summit-europe-2018/ You've suggested to do an OMC meeting there before. Kurt From matt at openssl.org Wed Jun 20 10:32:42 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 20 Jun 2018 11:32:42 +0100 Subject: [openssl-project] Beta release today Message-ID: <63c1be8b-02ac-a8d7-10a1-4ee0935677f8@openssl.org> The build is currently not stable. We have a number of outstanding issues: - external pyca tests are failing - no-sm2 fails (see PR#6531)...I'm doing some more investigation on that at the moment - failures in test_internal_sm2. Bernd has been working on that and we now have a fix that I just need to merge - run-checker reported a failure in no-ec. This turns out to the be the same problem as the no-sm2 failure - run-checker reported a failure with asan. I think this is the same issue as the test_internal_sm2 one above The biggest blocker is the pyca one. We don't currently understand that issue. I think we understand the resolution for the others. With the above issues I don't think we're ready to release yet. Possibly later today. Watch this space. Matt From matt at openssl.org Wed Jun 20 14:11:16 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 20 Jun 2018 15:11:16 +0100 Subject: [openssl-project] Beta release today In-Reply-To: <63c1be8b-02ac-a8d7-10a1-4ee0935677f8@openssl.org> References: <63c1be8b-02ac-a8d7-10a1-4ee0935677f8@openssl.org> Message-ID: <5118a14a-1172-2694-47df-31b5db3200db@openssl.org> The last few commits seem to have stabilised the build: https://travis-ci.org/openssl/openssl/builds/394565396 There is one red cross from travis. That is due to one failure in the pyca external tests. However, we know what that is and believe it to be a bug in pyca itself (a latent bug that we inadvertently triggered recently): https://travis-ci.org/openssl/openssl/builds/394565396 Therefore we are going to press ahead with the release. Matt On 20/06/18 11:32, Matt Caswell wrote: > The build is currently not stable. We have a number of outstanding issues: > > - external pyca tests are failing > - no-sm2 fails (see PR#6531)...I'm doing some more investigation on that > at the moment > - failures in test_internal_sm2. Bernd has been working on that and we > now have a fix that I just need to merge > - run-checker reported a failure in no-ec. This turns out to the be the > same problem as the no-sm2 failure > - run-checker reported a failure with asan. I think this is the same > issue as the test_internal_sm2 one above > > The biggest blocker is the pyca one. We don't currently understand that > issue. I think we understand the resolution for the others. > > With the above issues I don't think we're ready to release yet. Possibly > later today. Watch this space. > > > Matt > From openssl at openssl.org Wed Jun 20 15:06:20 2018 From: openssl at openssl.org (OpenSSL) Date: Wed, 20 Jun 2018 15:06:20 +0000 Subject: [openssl-project] OpenSSL version 1.1.1 pre release 8 published Message-ID: <20180620150620.GA32273@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.1.1 pre release 8 (beta) =========================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 8 has now been made available. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. The beta release is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1-pre8.tar.gz Size: 8334954 SHA1 checksum: 6bca29b8b9b6cf399ad9ee585ff72c314406a757 SHA256 checksum: 1205cd763dd92c910cc590658a5b0774599e8587d89d6debd948f242b949321e The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1-pre8.tar.gz openssl sha256 openssl-1.1.1-pre8.tar.gz Please download and check this beta release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlsqaTYACgkQ2cTSbQ5g RJEDPgf+MNjzRojgEzlu1IQmBthLgE2u9FL1IzTqeDGLBHolCws136AP0C8meHMi kJUS616C5Xe8P4NYJKHQhrRoJoB8iY92aJRJTjWLEic/KWR/SmTfLLuUCQ35iArP sT95NOhtHiYhc5iHAk0cDt42kf8ukgpLi1DcobNwzoFUma9M5y973V6fMg7OpIWu gdSFFRjajmGJnWWmlW6+25XPBW+2otu07yRTIM+O08CEl2EcYf0TxDmncCoHS1Zu vHt8HmRVTTzZ27hFndeD2HLeiVUe/teUfHAWe5VyqRhLcNoa20zGX2F/cvzZH8Zb 7qmwRpfVFJX0llNccuhCQVKnah1kjw== =6mX8 -----END PGP SIGNATURE----- From matt at openssl.org Wed Jun 20 15:11:16 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 20 Jun 2018 16:11:16 +0100 Subject: [openssl-project] Beta release today In-Reply-To: <5118a14a-1172-2694-47df-31b5db3200db@openssl.org> References: <63c1be8b-02ac-a8d7-10a1-4ee0935677f8@openssl.org> <5118a14a-1172-2694-47df-31b5db3200db@openssl.org> Message-ID: <71664dbb-edfb-a317-e959-3181d3d38190@openssl.org> Release is done - repo is unfrozen! Thanks to Richard once again for helping out. Matt On 20/06/18 15:11, Matt Caswell wrote: > The last few commits seem to have stabilised the build: > > https://travis-ci.org/openssl/openssl/builds/394565396 > > There is one red cross from travis. That is due to one failure in the > pyca external tests. However, we know what that is and believe it to be > a bug in pyca itself (a latent bug that we inadvertently triggered > recently): > > https://travis-ci.org/openssl/openssl/builds/394565396 > > Therefore we are going to press ahead with the release. > > Matt > > > On 20/06/18 11:32, Matt Caswell wrote: >> The build is currently not stable. We have a number of outstanding issues: >> >> - external pyca tests are failing >> - no-sm2 fails (see PR#6531)...I'm doing some more investigation on that >> at the moment >> - failures in test_internal_sm2. Bernd has been working on that and we >> now have a fix that I just need to merge >> - run-checker reported a failure in no-ec. This turns out to the be the >> same problem as the no-sm2 failure >> - run-checker reported a failure with asan. I think this is the same >> issue as the test_internal_sm2 one above >> >> The biggest blocker is the pyca one. We don't currently understand that >> issue. I think we understand the resolution for the others. >> >> With the above issues I don't think we're ready to release yet. Possibly >> later today. Watch this space. >> >> >> Matt >> From rsalz at akamai.com Wed Jun 20 16:41:57 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 20 Jun 2018 16:41:57 +0000 Subject: [openssl-project] GitHub labels Message-ID: <4647F5F5-A2F4-4DFE-8B03-D43BFB4465E3@akamai.com> I think it?s a good idea that we periodically review the labels we?re using. Please look at https://github.com/openssl/openssl/labels and maybe suggest changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Wed Jun 20 19:59:02 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 20 Jun 2018 19:59:02 +0000 Subject: [openssl-project] GitHub labels In-Reply-To: <4647F5F5-A2F4-4DFE-8B03-D43BFB4465E3@akamai.com> References: <4647F5F5-A2F4-4DFE-8B03-D43BFB4465E3@akamai.com> Message-ID: There are a lot of things that come to my mind when I see all those labels: IMHO there are too many of them and for some of them the precise meaning is not clear. So maybe we should reduce their number a bit and document the meaning and semantics of the other. I) NAMING CONVENTIONS First of all: Labels should be short and lowercase. Personally, I like these lisp-style identifiers like 'need-cla' and 'technical-debt'. So I would rename ???????????? 'pending 2nd review'? ->? 'review-required' ???????????? 'Issue resolved - WONTFIX'?? -> 'wont-fix' A propos: it might be useful to split the 'pending 2nd review' into two different labels (of the same color): ???????????? 'pending 2nd review'? ->? 'review-required'? and 'omc-review-required' II) UNUSED LABELS 'wont-fix' and 'technical-debt' are currently unused. Do we really need them? For example, if an issue is closed without fixing it, does it really require a ?wont-fix? label? III) VERSION NUMBER LABELS It seems like the version number labels '1.0.2', '1.1.0', '1.1.1', 'after 1.1.1' currently serve two differente purposes: 1. Indicate the intention to which branches a pull request will be backported ?? Approval holds for all labeled branches. ?? 2. As surrogate milestones ad 1): Using the version number labels as indication of merge intention makes sense. But then the 'master' label and (currently) the '1.1.1' label are superfluous. If the pull request targets the 'master' branch, why does it need a 'master' label? The github search index allows to search for 'base:' which is a much more reliable way of determining the target branch: ???????????? Open pull requests targeting 'master': ???????????? https://github.com/openssl/openssl/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+base%3Amaster ???????????? Open pull requests targeting 'OpenSSL_1_1_0-stable': ???????????? https://github.com/openssl/openssl/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+base%3AOpenSSL_1_1_0-stable If you follow the second link, you will immediately find #5260 which targets OpenSSL_1_1_0-stable but is erroneously labeled with 'post 1.1.1'. So IMHO it only makes sense to set labels for stable branches to which one intents to backport. This means that 'master' and (currently) '1.1.1' are superfluous. ad 2): The label 'after 1.1.1' is a surrogate milestone and IMHO it would be better to use the 'Post 1.1.1' milestone instead of the label. One could go even further and ask what sense does it make to have such an unspecific milestone as 'Post 1.1.1'? Wouldn't it be better to leave such pull requests unassigned? Maybe one reason for having the 'after 1.1.1' label is that these pull requests can't be merged yet, since 1.1.1 has not been split off as a separate branch yet. But isn't the 'hold' label intended for precisely this case? Or will it be set only if an omc member places a veto and requests a vote? The latter could be named 'vote-requested'. IMHO it would make sense to use the version labels only to indicate merge intention and otherwise use milestones. ???????????? https://github.com/openssl/openssl/labels??????? ???????????? https://github.com/openssl/openssl/milestones Regards, Matthias From levitte at openssl.org Wed Jun 20 20:29:37 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 20 Jun 2018 22:29:37 +0200 (CEST) Subject: [openssl-project] GitHub labels In-Reply-To: References: <4647F5F5-A2F4-4DFE-8B03-D43BFB4465E3@akamai.com> Message-ID: <20180620.222937.2058428337069560654.levitte@openssl.org> In message on Wed, 20 Jun 2018 19:59:02 +0000, "Dr. Matthias St. Pierre" said: Matthias.St.Pierre> There are a lot of things that come to my mind when I see all those labels: Matthias.St.Pierre> Matthias.St.Pierre> IMHO there are too many of them and for some of them the precise meaning is Matthias.St.Pierre> not clear. So maybe we should reduce their number a bit and document the Matthias.St.Pierre> meaning and semantics of the other. Matthias.St.Pierre> Matthias.St.Pierre> Matthias.St.Pierre> I) NAMING CONVENTIONS Matthias.St.Pierre> Matthias.St.Pierre> First of all: Labels should be short and lowercase. Personally, I like these Matthias.St.Pierre> lisp-style identifiers like 'need-cla' and 'technical-debt'. So I would rename Matthias.St.Pierre> Matthias.St.Pierre> ???????????? 'pending 2nd review'? ->? 'review-required' Matthias.St.Pierre> ???????????? 'Issue resolved - WONTFIX'?? -> 'wont-fix' There should be a consistent coloring scheme too. Matthias.St.Pierre> A propos: it might be useful to split the 'pending Matthias.St.Pierre> 2nd review' into two different labels (of the same color): Matthias.St.Pierre> Matthias.St.Pierre> ???????????? 'pending 2nd review'? ->? 'review-required'? and 'omc-review-required' I'm frankly unsure... it's not like there's such a massive amount of 'pending 2nd review' at one time to warrant such a split... Matthias.St.Pierre> II) UNUSED LABELS Matthias.St.Pierre> Matthias.St.Pierre> 'wont-fix' and 'technical-debt' are currently Matthias.St.Pierre> unused. Do we really need them? For example, if Matthias.St.Pierre> an issue is closed without fixing it, does it Matthias.St.Pierre> really require a ?wont-fix? label? That depends on how keen you are, when someone asks two weeks later why an issue was closed, to dig through lots of commentary (for an issue that did, in fact, contain a lot of commentary) to find that one comment that says "Wont fix" (remember that people can keep commenting after an issue is closed, so scrolling to the end isn't necessarely the easy answer). Matthias.St.Pierre> III) VERSION NUMBER LABELS Matthias.St.Pierre> Matthias.St.Pierre> It seems like the version number labels '1.0.2', Matthias.St.Pierre> '1.1.0', '1.1.1', 'after 1.1.1' currently serve Matthias.St.Pierre> two differente purposes: Matthias.St.Pierre> Matthias.St.Pierre> 1. Indicate the intention to which branches a pull Matthias.St.Pierre> request will be backported Matthias.St.Pierre> ?? Approval holds for all labeled branches. Matthias.St.Pierre> ?? Matthias.St.Pierre> 2. As surrogate milestones ... and the other way around, it seems silly to use a "1.0.2" milestone, since 1.0.2 was released a long time ago. I'd argue that all old milestones should really be removed, and only future versions should have milestones. Matthias.St.Pierre> ad 1): Matthias.St.Pierre> Using the version number labels as indication of merge intention makes sense. Matthias.St.Pierre> But then the 'master' label and (currently) the '1.1.1' label are superfluous. I'd suggest keeping the 1.1.1 label, as we will have use for it. Matthias.St.Pierre> If the pull request targets the 'master' branch, why does it need a 'master' label? Matthias.St.Pierre> The github search index allows to search for 'base:' which is a much Matthias.St.Pierre> more reliable way of determining the target branch: I'm learning something new, I had no clue of the 'base:' feature. However, it sometimes happens that I do a PR based on, for example, OpenSSL_1_1_0-stable, simply because that's where the issue was found, but with the intent to cherry pick into newer lines of development (master, and OpenSSL_1_1_1-stable soon). That gives those labels their potential for showing intent. Matthias.St.Pierre> ad 2): Matthias.St.Pierre> The label 'after 1.1.1' is a surrogate milestone Matthias.St.Pierre> and IMHO it would be better to use the 'Post Matthias.St.Pierre> 1.1.1' milestone instead of the label. I agree with you, but this was debated during the last F2F, and ideas differ. I don't quite remember if we came to a real decision, though. Matthias.St.Pierre> One could go even further and ask what sense does Matthias.St.Pierre> it make to have such an unspecific milestone as Matthias.St.Pierre> 'Post 1.1.1'? Wouldn't it be better to leave such Matthias.St.Pierre> pull requests unassigned? No, because we need to differentiate between PRs and issues we haven't looked at yet and those where we have made a decision where they should go. And perhaps that's an argument to keep using the label, as it's more visible in the pull request summary. Matthias.St.Pierre> IMHO it would make sense to use the version labels Matthias.St.Pierre> only to indicate merge intention and otherwise use Matthias.St.Pierre> milestones. I personally agree. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From Matthias.St.Pierre at ncp-e.com Wed Jun 20 21:09:18 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 20 Jun 2018 21:09:18 +0000 Subject: [openssl-project] GitHub labels In-Reply-To: <20180620.222937.2058428337069560654.levitte@openssl.org> References: <4647F5F5-A2F4-4DFE-8B03-D43BFB4465E3@akamai.com> <20180620.222937.2058428337069560654.levitte@openssl.org> Message-ID: <3a78fc0b3f5445db83fcc19bb6c777eb@Ex13.ncp.local> > Matthias.St.Pierre> A propos: it might be useful to split the 'pending > Matthias.St.Pierre> 2nd review' into two different labels (of the same color): > Matthias.St.Pierre> > Matthias.St.Pierre> ???????????? 'pending 2nd review'? ->? 'review-required'? and > 'omc-review-required' > > I'm frankly unsure... it's not like there's such a massive amount of 'pending 2nd > review' at one time to warrant such a split... You are probably right. It was just a quick idea that came to my mind. > Matthias.St.Pierre> 'wont-fix' and 'technical-debt' are currently > Matthias.St.Pierre> unused. Do we really need them? For example, if > Matthias.St.Pierre> an issue is closed without fixing it, does it > Matthias.St.Pierre> really require a ?wont-fix? label? > > That depends on how keen you are, when someone asks two weeks later why > an issue was closed, to dig through lots of commentary (for an issue that did, in > fact, contain a lot of commentary) to find that one comment that says "Wont > fix" (remember that people can keep commenting after an issue is closed, so > scrolling to the end isn't necessarely the easy answer). Makes sense, in theory. In practice, there is not a single issue marked 'wontfix', neither open nor closed: https://github.com/openssl/openssl/issues?utf8=%E2%9C%93&q=label%3A%22Issue+resolved+-+WONTFIX%22+ > However, it sometimes happens that I do a PR based on, for example, > OpenSSL_1_1_0-stable, simply because that's where the issue was found, but > with the intent to cherry pick into newer lines of development (master, and > OpenSSL_1_1_1-stable soon). That gives those labels their potential for > showing intent. You're right, having labels for all relevant branches ('master', '1.1.1', '1.1.0', '1.0.2') makes sense for consistency and there is nothing wrong if people prefer to label a pull request with the target branch, too. > Matthias.St.Pierre> One could go even further and ask what sense does > Matthias.St.Pierre> it make to have such an unspecific milestone as > Matthias.St.Pierre> 'Post 1.1.1'? Wouldn't it be better to leave such > Matthias.St.Pierre> pull requests unassigned? > > No, because we need to differentiate between PRs and issues we haven't > looked at yet and those where we have made a decision where they should go. > And perhaps that's an argument to keep using the label, as it's more visible in > the pull request summary. The milestones are listed to on the right hand side, too, see https://github.com/openssl/openssl/pull/6509. Under 'Labels' there is an entry 'Projects' followed by 'Milestones' Matthias From Matthias.St.Pierre at ncp-e.com Wed Jun 20 21:22:48 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 20 Jun 2018 21:22:48 +0000 Subject: [openssl-project] GitHub labels In-Reply-To: <20180620.222937.2058428337069560654.levitte@openssl.org> References: <4647F5F5-A2F4-4DFE-8B03-D43BFB4465E3@akamai.com> <20180620.222937.2058428337069560654.levitte@openssl.org> Message-ID: <6b56bce517284c26bcd702e50e9176be@Ex13.ncp.local> > Matthias.St.Pierre> The github search index allows to search for > 'base:' which is a much Matthias.St.Pierre> more reliable way of > determining the target branch: > > I'm learning something new, I had no clue of the 'base:' feature. Me neither, until today ;-). I looked it up on a useful page called 'Searching issues and pull requests': https://help.github.com/articles/searching-issues-and-pull-requests/#search-by-branch-name Matthias From kaduk at mit.edu Fri Jun 22 01:08:13 2018 From: kaduk at mit.edu (Benjamin Kaduk) Date: Thu, 21 Jun 2018 20:08:13 -0500 Subject: [openssl-project] GitHub labels In-Reply-To: <20180620.222937.2058428337069560654.levitte@openssl.org> References: <4647F5F5-A2F4-4DFE-8B03-D43BFB4465E3@akamai.com> <20180620.222937.2058428337069560654.levitte@openssl.org> Message-ID: <20180622010813.GY4946@kduck.kaduk.org> On Wed, Jun 20, 2018 at 10:29:37PM +0200, Richard Levitte wrote: > In message on Wed, 20 Jun 2018 19:59:02 +0000, "Dr. Matthias St. Pierre" said: > > Matthias.St.Pierre> III) VERSION NUMBER LABELS > Matthias.St.Pierre> > Matthias.St.Pierre> It seems like the version number labels '1.0.2', > Matthias.St.Pierre> '1.1.0', '1.1.1', 'after 1.1.1' currently serve > Matthias.St.Pierre> two differente purposes: > Matthias.St.Pierre> > Matthias.St.Pierre> 1. Indicate the intention to which branches a pull > Matthias.St.Pierre> request will be backported > Matthias.St.Pierre> ?? Approval holds for all labeled branches. > Matthias.St.Pierre> ?? > Matthias.St.Pierre> 2. As surrogate milestones > > ... and the other way around, it seems silly to use a "1.0.2" > milestone, since 1.0.2 was released a long time ago. I'd argue that > all old milestones should really be removed, and only future versions > should have milestones. I would argue that old milestones should *not* be removed! There seems to be some archival value in being able to see the contents of the milestone even after it is completed. > Matthias.St.Pierre> ad 1): > Matthias.St.Pierre> Using the version number labels as indication of merge intention makes sense. > Matthias.St.Pierre> But then the 'master' label and (currently) the '1.1.1' label are superfluous. > > I'd suggest keeping the 1.1.1 label, as we will have use for it. > > Matthias.St.Pierre> If the pull request targets the 'master' branch, why does it need a 'master' label? > Matthias.St.Pierre> The github search index allows to search for 'base:' which is a much > Matthias.St.Pierre> more reliable way of determining the target branch: > > I'm learning something new, I had no clue of the 'base:' feature. > > However, it sometimes happens that I do a PR based on, for example, > OpenSSL_1_1_0-stable, simply because that's where the issue was found, > but with the intent to cherry pick into newer lines of development > (master, and OpenSSL_1_1_1-stable soon). That gives those labels > their potential for showing intent. > > Matthias.St.Pierre> ad 2): > Matthias.St.Pierre> The label 'after 1.1.1' is a surrogate milestone > Matthias.St.Pierre> and IMHO it would be better to use the 'Post > Matthias.St.Pierre> 1.1.1' milestone instead of the label. > > I agree with you, but this was debated during the last F2F, and ideas > differ. I don't quite remember if we came to a real decision, though. > > Matthias.St.Pierre> One could go even further and ask what sense does > Matthias.St.Pierre> it make to have such an unspecific milestone as > Matthias.St.Pierre> 'Post 1.1.1'? Wouldn't it be better to leave such > Matthias.St.Pierre> pull requests unassigned? > > No, because we need to differentiate between PRs and issues we haven't > looked at yet and those where we have made a decision where they > should go. And perhaps that's an argument to keep using the label, as > it's more visible in the pull request summary. > > Matthias.St.Pierre> IMHO it would make sense to use the version labels > Matthias.St.Pierre> only to indicate merge intention and otherwise use > Matthias.St.Pierre> milestones. > > I personally agree. I think that could work. What's still unclear to me in the current scheme is how I'm supposed to indicate something that is (intentionally) API/ABI-breaking and must be postponed to the next major release. Bear in mind that we still don't know of the release after 1.1.1 will be such a thing or not... -Ben From levitte at openssl.org Fri Jun 22 08:26:09 2018 From: levitte at openssl.org (Richard Levitte) Date: Fri, 22 Jun 2018 10:26:09 +0200 (CEST) Subject: [openssl-project] GitHub labels In-Reply-To: <20180622010813.GY4946@kduck.kaduk.org> References: <20180620.222937.2058428337069560654.levitte@openssl.org> <20180622010813.GY4946@kduck.kaduk.org> Message-ID: <20180622.102609.409894780578016397.levitte@openssl.org> In message <20180622010813.GY4946 at kduck.kaduk.org> on Thu, 21 Jun 2018 20:08:13 -0500, Benjamin Kaduk said: kaduk> What's still unclear to me in the current scheme is how I'm supposed to kaduk> indicate something that is (intentionally) API/ABI-breaking and must be kaduk> postponed to the next major release. Bear in mind that we still don't know kaduk> of the release after 1.1.1 will be such a thing or not... Argh! I'm pretty sure I added a label '1.2.0' to do *exactly* that. Apparently, not everyone agrees with such indication... -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Fri Jun 22 09:25:15 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 22 Jun 2018 10:25:15 +0100 Subject: [openssl-project] GitHub labels In-Reply-To: <20180622.102609.409894780578016397.levitte@openssl.org> References: <20180620.222937.2058428337069560654.levitte@openssl.org> <20180622010813.GY4946@kduck.kaduk.org> <20180622.102609.409894780578016397.levitte@openssl.org> Message-ID: <8e20b090-2db5-730c-3e2b-e6796079f189@openssl.org> On 22/06/18 09:26, Richard Levitte wrote: > In message <20180622010813.GY4946 at kduck.kaduk.org> on Thu, 21 Jun 2018 20:08:13 -0500, Benjamin Kaduk said: > > kaduk> What's still unclear to me in the current scheme is how I'm supposed to > kaduk> indicate something that is (intentionally) API/ABI-breaking and must be > kaduk> postponed to the next major release. Bear in mind that we still don't know > kaduk> of the release after 1.1.1 will be such a thing or not... > > Argh! > > I'm pretty sure I added a label '1.2.0' to do *exactly* that. > Apparently, not everyone agrees with such indication... > We did. I think we lost information when we got rid of it, and I think it should be restored. There was a discussion about this recently here: https://github.com/openssl/openssl/issues/6464 Matt From Matthias.St.Pierre at ncp-e.com Sat Jun 23 17:28:25 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 23 Jun 2018 17:28:25 +0000 Subject: [openssl-project] Creating the OpenSSL_1_1_1-stable branch Message-ID: <97b79a0726d8447fbacdf60cd513da55@Ex13.ncp.local> Hi, just a reminder: our release strategy still states that the OpenSSL_1_1_1-stable branch will be created together with the first beta release. 20th March 2018, beta release 1 (pre3) o OpenSSL_1_1_1-stable created (feature freeze) o master becomes basis for 1.1.2 or 1.2.0 (TBD) The branching has been postponed a while ago in order to concentrate on stabilizing the beta and fixing errors. I assume there is a silent agreement that the branching will take place together with the final release? Does this decision require an official OMC vote and shouldn't the release strategy be updated accordingly? Regards, Matthias From levitte at openssl.org Sat Jun 23 17:51:26 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 23 Jun 2018 19:51:26 +0200 (CEST) Subject: [openssl-project] Creating the OpenSSL_1_1_1-stable branch In-Reply-To: <97b79a0726d8447fbacdf60cd513da55@Ex13.ncp.local> References: <97b79a0726d8447fbacdf60cd513da55@Ex13.ncp.local> Message-ID: <20180623.195126.1878584452239778695.levitte@openssl.org> In message <97b79a0726d8447fbacdf60cd513da55 at Ex13.ncp.local> on Sat, 23 Jun 2018 17:28:25 +0000, "Dr. Matthias St. Pierre" said: Matthias.St.Pierre> Hi, Matthias.St.Pierre> Matthias.St.Pierre> just a reminder: our release strategy still states that the OpenSSL_1_1_1-stable Matthias.St.Pierre> branch will be created together with the first beta release. Matthias.St.Pierre> Matthias.St.Pierre> 20th March 2018, beta release 1 (pre3) Matthias.St.Pierre> o OpenSSL_1_1_1-stable created (feature freeze) Matthias.St.Pierre> o master becomes basis for 1.1.2 or 1.2.0 (TBD) Matthias.St.Pierre> Matthias.St.Pierre> The branching has been postponed a while ago in Matthias.St.Pierre> order to concentrate on stabilizing the beta and Matthias.St.Pierre> fixing errors. I assume there is a silent Matthias.St.Pierre> agreement that the branching will take place Matthias.St.Pierre> together with the final release? Does this Matthias.St.Pierre> decision require an official OMC vote and Matthias.St.Pierre> shouldn't the release strategy be updated Matthias.St.Pierre> accordingly? We the OMC figured that all work will go towards making as good a release as possible, everything else will be left in feature branches anyway. This means that effectively, OpenSSL_1_1_1-stable and master remain the same, i.e. won't start diverging before the final release. That makes if pointless to create a branch just to fast-forward it a little now and then. At some point, the above will become true, but you're right, we should probably update that detail. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From Matthias.St.Pierre at ncp-e.com Sat Jun 23 20:43:32 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 23 Jun 2018 20:43:32 +0000 Subject: [openssl-project] Creating the OpenSSL_1_1_1-stable branch In-Reply-To: <20180623.195126.1878584452239778695.levitte@openssl.org> References: <97b79a0726d8447fbacdf60cd513da55@Ex13.ncp.local> <20180623.195126.1878584452239778695.levitte@openssl.org> Message-ID: > We the OMC figured that all work will go towards making as good a release as > possible, everything else will be left in feature branches anyway. This means > that effectively, OpenSSL_1_1_1-stable and master remain the same, i.e. won't > start diverging before the final release. > That makes if pointless to create a branch just to fast-forward it a little now > and then. I completely agree with you and I'm not arguing for preponing the branching before the final release. I just meant to say that it's currently a silent agreement and not written down on the policy page that the branching will occur together with the final release. The upcoming vote for the "Release readiness check following pre8 release" would be a good opportunity to update the policy accordingly. Matthias From matt at openssl.org Tue Jun 26 15:56:26 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 26 Jun 2018 16:56:26 +0100 Subject: [openssl-project] Milestones and the 1.1.1 release Message-ID: <6a460a10-face-5780-7c6f-885a7e0e3ecb@openssl.org> I'm thinking that we should maybe re-asses the current milestones in github. We currently use the following milestones: Assessed - Anything against this milestone isn't relevant to the 1.1.1 release (e.g. 1.0.2 specific issue) 1.1.1 - This is relevant to the 1.1.1 release but may not be specific to it (e.g. an issue that affects both 1.1.1 and 1.1.0) Post 1.1.1 - Feature request to be looked at once 1.1.1 is released I think we should re-asses everything currently against the 1.1.1 milestone so that anything which isn't specific to that release gets moved to the "Assessed" milestone. At the moment its difficult to see the "wood for the trees" between issues which are newly introduced and those that are long standing. In terms of getting the 1.1.1 release out the door we should focus on the former. Thoughts? Matt From kaduk at mit.edu Tue Jun 26 16:05:43 2018 From: kaduk at mit.edu (Benjamin Kaduk) Date: Tue, 26 Jun 2018 11:05:43 -0500 Subject: [openssl-project] Milestones and the 1.1.1 release In-Reply-To: <6a460a10-face-5780-7c6f-885a7e0e3ecb@openssl.org> References: <6a460a10-face-5780-7c6f-885a7e0e3ecb@openssl.org> Message-ID: <20180626160542.GH79565@kduck.kaduk.org> On Tue, Jun 26, 2018 at 04:56:26PM +0100, Matt Caswell wrote: > I'm thinking that we should maybe re-asses the current milestones in github. > > We currently use the following milestones: > > Assessed - Anything against this milestone isn't relevant to the 1.1.1 > release (e.g. 1.0.2 specific issue) > > 1.1.1 - This is relevant to the 1.1.1 release but may not be specific to > it (e.g. an issue that affects both 1.1.1 and 1.1.0) > > Post 1.1.1 - Feature request to be looked at once 1.1.1 is released > > > I think we should re-asses everything currently against the 1.1.1 > milestone so that anything which isn't specific to that release gets > moved to the "Assessed" milestone. > > At the moment its difficult to see the "wood for the trees" between > issues which are newly introduced and those that are long standing. In > terms of getting the 1.1.1 release out the door we should focus on the > former. > > Thoughts? If the choice is between your proposal and the current state, your proposal seems better. I don't want to start a bikeshed, so I'll try to leave the discussion on the immediate topic which relates to getting 1.1.1 out the door and not add in other things I'd like to see changed (but do not really seem to be blocking 1.1.1). -Ben From rsalz at akamai.com Tue Jun 26 17:18:35 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 26 Jun 2018 17:18:35 +0000 Subject: [openssl-project] Milestones and the 1.1.1 release In-Reply-To: <6a460a10-face-5780-7c6f-885a7e0e3ecb@openssl.org> References: <6a460a10-face-5780-7c6f-885a7e0e3ecb@openssl.org> Message-ID: So are you saying look at the 73 open issues at https://github.com/openssl/openssl/milestone/9 and re-evaluate them? ?On 6/26/18, 11:56 AM, "Matt Caswell" wrote: I'm thinking that we should maybe re-asses the current milestones in github. We currently use the following milestones: Assessed - Anything against this milestone isn't relevant to the 1.1.1 release (e.g. 1.0.2 specific issue) 1.1.1 - This is relevant to the 1.1.1 release but may not be specific to it (e.g. an issue that affects both 1.1.1 and 1.1.0) Post 1.1.1 - Feature request to be looked at once 1.1.1 is released I think we should re-asses everything currently against the 1.1.1 milestone so that anything which isn't specific to that release gets moved to the "Assessed" milestone. At the moment its difficult to see the "wood for the trees" between issues which are newly introduced and those that are long standing. In terms of getting the 1.1.1 release out the door we should focus on the former. Thoughts? Matt _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project From rsalz at akamai.com Tue Jun 26 18:46:00 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 26 Jun 2018 18:46:00 +0000 Subject: [openssl-project] FW: [openssl-commits] Build failed in Jenkins: master_noec #574 Message-ID: <75958832-65A3-4306-A761-C427743FAB8F@akamai.com> FYI ?On 6/26/18, 2:45 PM, "Barry Fussell (bfussell)" wrote: The evp_test is failing intermittently because there is an attempt to malloc zero bytes when running the new test that came in with this commit. https://bitbucket-eng-rtp1.cisco.com/bitbucket/projects/TS/repos/ciscossl/commits/7b3e775a6a78650bbd3e8e19a5aa12981880402b#test/evptests.txt static int pderive_test_run(struct evp_test *t) { struct pkey_data *kdata = t->data; unsigned char *out = NULL; size_t out_len; const char *err = "INTERNAL_ERROR"; out_len = kdata->output_len; out = OPENSSL_malloc(out_len); <----- out is zero because there is no SharedSecret if (!out) { -----Original Message----- From: osslsanity at gmail.com [mailto:osslsanity at gmail.com] Sent: Tuesday, June 19, 2018 11:28 AM To: Barry Fussell (bfussell) ; openssl-commits at openssl.org Subject: Build failed in Jenkins: master_noec #574 See Changes: [Matthias.St.Pierre] Fix & update documentation about RAND_priv_bytes() [Matthias.St.Pierre] Improve the output of `make doc-nits` ------------------------------------------ [...truncated 505.72 KB...] rm -f test/v3ext ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ -o test/v3ext test/v3ext.o \ test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/v3nametest.d.tmp -MT test/v3nametest.o -c -o test/v3nametest.o test/v3nametest.c rm -f test/v3nametest ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ -o test/v3nametest test/v3nametest.o \ test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/verify_extra_test.d.tmp -MT test/verify_extra_test.o -c -o test/verify_extra_test.o test/verify_extra_test.c rm -f test/verify_extra_test ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ -o test/verify_extra_test test/verify_extra_test.o \ test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/versions.d.tmp -MT test/versions.o -c -o test/versions.o test/versions.c rm -f test/versions ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ -o test/versions test/versions.o \ -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/wpackettest.d.tmp -MT test/wpackettest.o -c -o test/wpackettest.o test/wpackettest.c rm -f test/wpackettest ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ -o test/wpackettest test/wpackettest.o \ libssl.a test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/x509_check_cert_pkey_test.d.tmp -MT test/x509_check_cert_pkey_test.o -c -o test/x509_check_cert_pkey_test.o test/x509_check_cert_pkey_test.c rm -f test/x509_check_cert_pkey_test ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ -o test/x509_check_cert_pkey_test test/x509_check_cert_pkey_test.o \ test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/x509_dup_cert_test.d.tmp -MT test/x509_dup_cert_test.o -c -o test/x509_dup_cert_test.o test/x509_dup_cert_test.c rm -f test/x509_dup_cert_test ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ -o test/x509_dup_cert_test test/x509_dup_cert_test.o \ test/libtestutil.a -lcrypto -ldl -pthread gcc -I. -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/x509_internal_test.d.tmp -MT test/x509_internal_test.o -c -o test/x509_internal_test.o test/x509_internal_test.c rm -f test/x509_internal_test ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ -o test/x509_internal_test test/x509_internal_test.o \ test/libtestutil.a libcrypto.a -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/x509_time_test.d.tmp -MT test/x509_time_test.o -c -o test/x509_time_test.o test/x509_time_test.c rm -f test/x509_time_test ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ -o test/x509_time_test test/x509_time_test.o \ test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/x509aux.d.tmp -MT test/x509aux.o -c -o test/x509aux.o test/x509aux.c rm -f test/x509aux ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ -o test/x509aux test/x509aux.o \ test/libtestutil.a -lcrypto -ldl -pthread /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \ "-oMakefile" apps/CA.pl.in > "apps/CA.pl" chmod a+x apps/CA.pl /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \ "-oMakefile" apps/tsget.in > "apps/tsget" chmod a+x apps/tsget /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \ "-oMakefile" tools/c_rehash.in > "tools/c_rehash" chmod a+x tools/c_rehash /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \ "-oMakefile" util/shlib_wrap.sh.in > "util/shlib_wrap.sh" chmod a+x util/shlib_wrap.sh make[1]: Leaving directory ` + apps/openssl version -a OpenSSL 1.1.1-pre8-dev xx XXX xxxx built on: Tue Jun 19 15:22:11 2018 UTC platform: linux-x86_64 options: bn(64,64) rc4(16x,int) des(int) idea(int) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DNDEBUG OPENSSLDIR: "/usr/local/ssl" ENGINESDIR: "/usr/local/lib/engines-1.1" Seeding source: os-specific + make test make depend && make _tests make[1]: Entering directory ` make[1]: Leaving directory ` make[1]: Entering directory ` ( cd test; \ mkdir -p test-runs; \ SRCTOP=../. \ BLDTOP=../. \ RESULT_D=test-runs \ PERL="/usr/bin/perl" \ EXE_EXT= \ OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ OPENSSL_DEBUG_MEMORY=on \ /usr/bin/perl .././test/run_tests.pl ) ../test/recipes/01-test_abort.t .................... ok ../test/recipes/01-test_sanity.t ................... ok ../test/recipes/01-test_symbol_presence.t .......... skipped: Only useful when building shared libraries ../test/recipes/01-test_test.t ..................... ok ../test/recipes/02-test_internal_ctype.t ........... ok ../test/recipes/02-test_lhash.t .................... ok ../test/recipes/02-test_ordinals.t ................. ok ../test/recipes/02-test_stack.t .................... ok ../test/recipes/03-test_exdata.t ................... ok ../test/recipes/03-test_internal_asn1.t ............ ok ../test/recipes/03-test_internal_chacha.t .......... ok ../test/recipes/03-test_internal_curve448.t ........ skipped: This test is unsupported in a no-ec build ../test/recipes/03-test_internal_mdc2.t ............ ok ../test/recipes/03-test_internal_modes.t ........... ok ../test/recipes/03-test_internal_poly1305.t ........ ok ../test/recipes/ 03-test_internal_siphash.t ......... ok ../test/recipes/03-test_internal_sm2.t ............. skipped: sm2 is not supported by this OpenSSL build ../test/recipes/03-test_internal_sm4.t ............. ok ../test/recipes/03-test_internal_ssl_cert_table.t .. ok ../test/recipes/03-test_internal_x509.t ............ ok ../test/recipes/03-test_ui.t ....................... ok ../test/recipes/04-test_asn1_encode.t .............. ok ../test/recipes/04-test_asn1_string_table.t ........ ok ../test/recipes/04-test_bio_callback.t ............. ok ../test/recipes/04-test_bioprint.t ................. ok ../test/recipes/04-test_err.t ...................... ok ../test/recipes/04-test_pem.t ...................... ok ../test/recipes/05-test_bf.t ....................... ok ../test/recipes/05-test_cast.t ..................... ok ../test/recipes/05-test_des.t ...................... ok ../test/recipes/05-test_hmac.t ..................... ok ../test/recipes/05-test_idea.t ..................... ok ../test/reci pes/05-test_md2.t ...................... skipped: md2 is not supported by this OpenSSL build ../test/recipes/05-test_mdc2.t ..................... ok ../test/recipes/05-test_rand.t ..................... ok ../test/recipes/05-test_rc2.t ...................... ok ../test/recipes/05-test_rc4.t ...................... ok ../test/recipes/05-test_rc5.t ...................... skipped: rc5 is not supported by this OpenSSL build ../test/recipes/06-test-rdrand.t ................... ok ../test/recipes/10-test_bn.t ....................... ok ../test/recipes/10-test_exp.t ...................... ok ../test/recipes/15-test_dh.t ....................... ok ../test/recipes/15-test_dsa.t ...................... ok ../test/recipes/15-test_ec.t ....................... ok ../test/recipes/15-test_ecdsa.t .................... skipped: ec is not supported by this OpenSSL build ../test/recipes/15-test_ecparam.t .................. skipped: EC isn't supported in this build ../test/recipes/15-test_genrsa.t ....... ............ ok ../test/recipes/15-test_mp_rsa.t ................... ok ../test/recipes/15-test_out_option.t ............... ok ../test/recipes/15-test_rsa.t ...................... ok ../test/recipes/15-test_rsapss.t ................... ok ../test/recipes/20-test_enc.t ...................... ok ../test/recipes/20-test_enc_more.t ................. ok ../test/recipes/20-test_passwd.t ................... ok ../test/recipes/25-test_crl.t ...................... ok ../test/recipes/25-test_d2i.t ...................... ok ../test/recipes/25-test_pkcs7.t .................... ok ../test/recipes/25-test_req.t ...................... ok ../test/recipes/25-test_sid.t ...................... skipped: test_sid needs EC to run ../test/recipes/25-test_verify.t ................... ok ../test/recipes/25-test_x509.t ..................... ok ../test/recipes/30-test_afalg.t .................... skipped: test_afalg not supported for this build ../test/recipes/30-test_engine.t ................... ok ../test/ recipes/30-test_evp.t ...................... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/7 subtests ../test/recipes/30-test_evp_extra.t ................ ok ../test/recipes/30-test_pbelu.t .................... ok ../test/recipes/30-test_pkey_meth.t ................ ok ../test/recipes/30-test_pkey_meth_kdf.t ............ ok ../test/recipes/40-test_rehash.t ................... ok ../test/recipes/60-test_x509_check_cert_pkey.t ..... ok ../test/recipes/60-test_x509_dup_cert.t ............ ok ../test/recipes/60-test_x509_store.t ............... ok ../test/recipes/60-test_x509_time.t ................ ok ../test/recipes/70-test_asyncio.t .................. ok ../test/recipes/70-test_bad_dtls.t ................. ok ../test/recipes/70-test_clienthello.t .............. ok ../test/recipes/70-test_comp.t ..................... skipped: test_comp needs the dynamic engine feature enabled ../test/recipes/70-test_key_share.t ................ skipped: test_key_share needs the dynamic engine feature enabled ../test/recipes/70-test_packet. t ................... ok ../test/recipes/70-test_recordlen.t ................ ok ../test/recipes/70-test_renegotiation.t ............ skipped: test_renegotiation needs the dynamic engine feature enabled ../test/recipes/70-test_servername.t ............... ok ../test/recipes/70-test_sslcbcpadding.t ............ skipped: test_sslcbcpadding needs the dynamic engine feature enabled ../test/recipes/70-test_sslcertstatus.t ............ skipped: test_sslcertstatus needs the dynamic engine feature enabled ../test/recipes/70-test_sslextension.t ............. skipped: test_sslextension needs the dynamic engine feature enabled ../test/recipes/70-test_sslmessages.t .............. skipped: test_sslmessages needs the dynamic engine feature enabled ../test/recipes/70-test_sslrecords.t ............... skipped: test_sslrecords needs the dynamic engine feature enabled ../test/recipes/70-test_sslsessiontick.t ........... skipped: test_sslsessiontick needs the dynamic engine feature enabled ../test/rec ipes/70-test_sslsigalgs.t ............... skipped: test_sslsigalgs needs the dynamic engine feature enabled ../test/recipes/70-test_sslsignature.t ............. skipped: test_sslsignature needs the dynamic engine feature enabled ../test/recipes/70-test_sslskewith0p.t ............. skipped: test_sslskewith0p needs the dynamic engine feature enabled ../test/recipes/70-test_sslversions.t .............. skipped: test_sslversions needs the dynamic engine feature enabled ../test/recipes/70-test_sslvertol.t ................ skipped: test_sslextension needs the dynamic engine feature enabled ../test/recipes/70-test_tls13cookie.t .............. skipped: test_tls13cookie needs the dynamic engine feature enabled ../test/recipes/70-test_tls13downgrade.t ........... skipped: test_tls13downgrade needs the dynamic engine feature enabled ../test/recipes/70-test_tls13hrr.t ................. skipped: test_tls13hrr needs the dynamic engine feature enabled ../test/recipes/70-test_tls13kexmodes.t ...... ...... skipped: test_tls13kexmodes needs the dynamic engine feature enabled ../test/recipes/70-test_tls13messages.t ............ skipped: test_tls13messages needs the dynamic engine feature enabled ../test/recipes/70-test_tls13psk.t ................. skipped: test_tls13psk needs the dynamic engine feature enabled ../test/recipes/70-test_tlsextms.t ................. skipped: test_tlsextms needs the dynamic engine feature enabled ../test/recipes/70-test_verify_extra.t ............. ok ../test/recipes/70-test_wpacket.t .................. ok ../test/recipes/80-test_ca.t ....................... ok ../test/recipes/80-test_cipherbytes.t .............. ok ../test/recipes/80-test_cipherlist.t ............... ok ../test/recipes/80-test_ciphername.t ............... ok ../test/recipes/80-test_cms.t ...................... ok ../test/recipes/80-test_cmsapi.t ................... ok ../test/recipes/80-test_ct.t ....................... skipped: ct and ec are not supported by this OpenSSL build ../te st/recipes/80-test_dane.t ..................... skipped: test_dane uses ec which is not supported by this OpenSSL build ../test/recipes/80-test_dtls.t ..................... ok ../test/recipes/80-test_dtls_mtu.t ................. ok ../test/recipes/80-test_dtlsv1listen.t ............. ok ../test/recipes/80-test_ocsp.t ..................... ok ../test/recipes/80-test_pkcs12.t ................... ok ../test/recipes/80-test_ssl_new.t .................. ok ../test/recipes/80-test_ssl_old.t .................. ok ../test/recipes/80-test_ssl_test_ctx.t ............. ok ../test/recipes/80-test_sslcorrupt.t ............... ok ../test/recipes/80-test_tsa.t ...................... ok ../test/recipes/80-test_x509aux.t .................. skipped: test_dane uses ec which is not supported by this OpenSSL build ../test/recipes/90-test_asn1_time.t ................ ok ../test/recipes/90-test_async.t .................... ok ../test/recipes/90-test_bio_enc.t .................. ok ../test/recipes/90-test_ constant_time.t ............ ok ../test/recipes/90-test_fatalerr.t ................. ok ../test/recipes/90-test_gmdiff.t ................... ok ../test/recipes/90-test_ige.t ...................... ok ../test/recipes/90-test_includes.t ................. ok ../test/recipes/90-test_memleak.t .................. ok ../test/recipes/90-test_overhead.t ................. ok ../test/recipes/90-test_secmem.t ................... ok ../test/recipes/90-test_shlibload.t ................ skipped: Test only supported in a shared build ../test/recipes/90-test_srp.t ...................... ok ../test/recipes/90-test_sslapi.t ................... ok ../test/recipes/90-test_sslbuffers.t ............... ok ../test/recipes/90-test_store.t .................... ok ../test/recipes/90-test_sysdefault.t ............... ok ../test/recipes/90-test_threads.t .................. ok ../test/recipes/90-test_time_offset.t .............. ok ../test/recipes/90-test_tls13ccs.t ................. skipped: test_tls13ccs is no t supported in this build ../test/recipes/90-test_tls13encryption.t .......... skipped: tls13encryption is not supported in this build ../test/recipes/90-test_tls13secrets.t ............. skipped: tls13secrets is not supported in this build ../test/recipes/90-test_v3name.t ................... ok ../test/recipes/95-test_external_boringssl.t ....... skipped: No external tests in this configuration ../test/recipes/95-test_external_krb5.t ............ skipped: No external tests in this configuration ../test/recipes/95-test_external_pyca.t ............ skipped: No external tests in this configuration ../test/recipes/99-test_ecstress.t ................. ok ../test/recipes/99-test_fuzz.t ..................... ok Test Summary Report ------------------- ../test/recipes/30-test_evp.t (Wstat: 256 Tests: 7 Failed: 1) Failed test: 7 Non-zero exit status: 1 Files=149, Tests=1016, 111 wallclock secs ( 0.43 usr 0.11 sys + 40.62 cusr 8.81 csys = 49.97 CPU) Result: FAIL make[1]: *** [_tests] Error 1 make[1]: Leaving directory ` make: *** [tests] Error 2 Build step 'Execute shell' marked build as failure _____ openssl-commits mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-commits From matt at openssl.org Tue Jun 26 19:32:47 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 26 Jun 2018 20:32:47 +0100 Subject: [openssl-project] Milestones and the 1.1.1 release In-Reply-To: References: <6a460a10-face-5780-7c6f-885a7e0e3ecb@openssl.org> Message-ID: On 26/06/18 18:18, Salz, Rich wrote: > So are you saying look at the 73 open issues at https://github.com/openssl/openssl/milestone/9 and re-evaluate them? Exactly. My guess is that a significant proportion of them also apply to 1.1.0 and therefore should not hold up the 1.1.1 release. At the moment though it is impossible to tell which are the high priority issues we should be focussing on. Matt > > > > ?On 6/26/18, 11:56 AM, "Matt Caswell" wrote: > > I'm thinking that we should maybe re-asses the current milestones in github. > > We currently use the following milestones: > > Assessed - Anything against this milestone isn't relevant to the 1.1.1 > release (e.g. 1.0.2 specific issue) > > 1.1.1 - This is relevant to the 1.1.1 release but may not be specific to > it (e.g. an issue that affects both 1.1.1 and 1.1.0) > > Post 1.1.1 - Feature request to be looked at once 1.1.1 is released > > > I think we should re-asses everything currently against the 1.1.1 > milestone so that anything which isn't specific to that release gets > moved to the "Assessed" milestone. > > At the moment its difficult to see the "wood for the trees" between > issues which are newly introduced and those that are long standing. In > terms of getting the 1.1.1 release out the door we should focus on the > former. > > Thoughts? > > Matt > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > From rsalz at akamai.com Tue Jun 26 19:43:45 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 26 Jun 2018 19:43:45 +0000 Subject: [openssl-project] Milestones and the 1.1.1 release In-Reply-To: References: <6a460a10-face-5780-7c6f-885a7e0e3ecb@openssl.org> Message-ID: <98E3F9EB-D27D-4307-945F-A921E3FF3E29@akamai.com> That's interesting. Would we put a bugfix in 1.1.0, not put the fix in 1.1.1 until our first "a" release? Or are you saying that if it's in 1.1.0, then we don't have to fix it until after 1.1.1 comes out? That seems justifiable to me. ?On 6/26/18, 3:32 PM, "Matt Caswell" wrote: On 26/06/18 18:18, Salz, Rich wrote: > So are you saying look at the 73 open issues at https://github.com/openssl/openssl/milestone/9 and re-evaluate them? Exactly. My guess is that a significant proportion of them also apply to 1.1.0 and therefore should not hold up the 1.1.1 release. At the moment though it is impossible to tell which are the high priority issues we should be focussing on. Matt > > > > On 6/26/18, 11:56 AM, "Matt Caswell" wrote: > > I'm thinking that we should maybe re-asses the current milestones in github. > > We currently use the following milestones: > > Assessed - Anything against this milestone isn't relevant to the 1.1.1 > release (e.g. 1.0.2 specific issue) > > 1.1.1 - This is relevant to the 1.1.1 release but may not be specific to > it (e.g. an issue that affects both 1.1.1 and 1.1.0) > > Post 1.1.1 - Feature request to be looked at once 1.1.1 is released > > > I think we should re-asses everything currently against the 1.1.1 > milestone so that anything which isn't specific to that release gets > moved to the "Assessed" milestone. > > At the moment its difficult to see the "wood for the trees" between > issues which are newly introduced and those that are long standing. In > terms of getting the 1.1.1 release out the door we should focus on the > former. > > Thoughts? > > Matt > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project From kaduk at mit.edu Tue Jun 26 19:51:23 2018 From: kaduk at mit.edu (Benjamin Kaduk) Date: Tue, 26 Jun 2018 14:51:23 -0500 Subject: [openssl-project] Milestones and the 1.1.1 release In-Reply-To: <98E3F9EB-D27D-4307-945F-A921E3FF3E29@akamai.com> References: <6a460a10-face-5780-7c6f-885a7e0e3ecb@openssl.org> <98E3F9EB-D27D-4307-945F-A921E3FF3E29@akamai.com> Message-ID: <20180626195123.GL79565@kduck.kaduk.org> On Tue, Jun 26, 2018 at 07:43:45PM +0000, Salz, Rich wrote: > That's interesting. Would we put a bugfix in 1.1.0, not put the fix in 1.1.1 until our first "a" release? > > Or are you saying that if it's in 1.1.0, then we don't have to fix it until after 1.1.1 comes out? That seems justifiable to me. I assume the latter -- we feel obligated to fix regressions from 1.1.0 to 1.1.1 before finalizing 1.1.1, but bugs that are present in 1.1.0 can be present in the 1.1.1 initial release (to be fixed in 1.1.1a and 1.1.0next). (This is what I do for OpenAFS.) -Ben From matt at openssl.org Tue Jun 26 20:15:48 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 26 Jun 2018 21:15:48 +0100 Subject: [openssl-project] Milestones and the 1.1.1 release In-Reply-To: <98E3F9EB-D27D-4307-945F-A921E3FF3E29@akamai.com> References: <6a460a10-face-5780-7c6f-885a7e0e3ecb@openssl.org> <98E3F9EB-D27D-4307-945F-A921E3FF3E29@akamai.com> Message-ID: On 26/06/18 20:43, Salz, Rich wrote: > That's interesting. Would we put a bugfix in 1.1.0, not put the fix in 1.1.1 until our first "a" release? > > Or are you saying that if it's in 1.1.0, then we don't have to fix it until after 1.1.1 comes out? That seems justifiable to me. The latter. I mean it doesn't *prevent* us from fixing something that's in both 1.1.0 and 1.1.1 - but our focus should be on fixing issues that are newly introduced in 1.1.1. Matt > > ?On 6/26/18, 3:32 PM, "Matt Caswell" wrote: > > > > On 26/06/18 18:18, Salz, Rich wrote: > > So are you saying look at the 73 open issues at https://github.com/openssl/openssl/milestone/9 and re-evaluate them? > > Exactly. My guess is that a significant proportion of them also apply to > 1.1.0 and therefore should not hold up the 1.1.1 release. At the moment > though it is impossible to tell which are the high priority issues we > should be focussing on. > > Matt > > > > > > > > > > On 6/26/18, 11:56 AM, "Matt Caswell" wrote: > > > > I'm thinking that we should maybe re-asses the current milestones in github. > > > > We currently use the following milestones: > > > > Assessed - Anything against this milestone isn't relevant to the 1.1.1 > > release (e.g. 1.0.2 specific issue) > > > > 1.1.1 - This is relevant to the 1.1.1 release but may not be specific to > > it (e.g. an issue that affects both 1.1.1 and 1.1.0) > > > > Post 1.1.1 - Feature request to be looked at once 1.1.1 is released > > > > > > I think we should re-asses everything currently against the 1.1.1 > > milestone so that anything which isn't specific to that release gets > > moved to the "Assessed" milestone. > > > > At the moment its difficult to see the "wood for the trees" between > > issues which are newly introduced and those that are long standing. In > > terms of getting the 1.1.1 release out the door we should focus on the > > former. > > > > Thoughts? > > > > Matt > > > > _______________________________________________ > > openssl-project mailing list > > openssl-project at openssl.org > > https://mta.openssl.org/mailman/listinfo/openssl-project > > > > > > _______________________________________________ > > openssl-project mailing list > > openssl-project at openssl.org > > https://mta.openssl.org/mailman/listinfo/openssl-project > > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > From matt at openssl.org Wed Jun 27 08:56:45 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 27 Jun 2018 09:56:45 +0100 Subject: [openssl-project] Forthcoming holidays Message-ID: FYI, I have a few days off coming up which will mean I am less responsive than normal. I will have very limited/no access to email during these periods: Thursday 28th - Friday 29th June and Sunday 8th - Thursday 12th July Matt From matt at openssl.org Wed Jun 27 09:32:05 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 27 Jun 2018 10:32:05 +0100 Subject: [openssl-project] [openssl-commits] Build failed in Jenkins: master_noec #574 In-Reply-To: <932ef019d3644767a9b17effafcc19f8@XCH-ALN-004.cisco.com> References: <1825497302.459.1529407642729.JavaMail.jenkins@ip-172-31-34-99> <2047571367.460.1529422051316.JavaMail.jenkins@ip-172-31-34-99> <932ef019d3644767a9b17effafcc19f8@XCH-ALN-004.cisco.com> Message-ID: <72a8f0a4-5e06-6312-6bc3-87aec4dde94e@openssl.org> I am slightly confused because the code sample below and the commit id you gave is for 1.1.0, but the original email seems to be about master. Is the same issue affecting both? Note: the pderive_test_run() function looks quite different between 1.1.0 and master. Matt On 26/06/18 19:32, Barry Fussell (bfussell) wrote: > The evp_test is failing intermittently because there is an attempt to > malloc zero bytes when running the new test that came in with > this commit. > > https://bitbucket-eng-rtp1.cisco.com/bitbucket/projects/TS/repos/ciscossl/commits/7b3e775a6a78650bbd3e8e19a5aa12981880402b#test/evptests.txt > > > static int pderive_test_run(struct evp_test *t) > { > struct pkey_data *kdata = t->data; > unsigned char *out = NULL; > size_t out_len; > const char *err = "INTERNAL_ERROR"; > > out_len = kdata->output_len; > out = OPENSSL_malloc(out_len); <----- out is zero because there is no SharedSecret > if (!out) { > > -----Original Message----- > From: osslsanity at gmail.com [mailto:osslsanity at gmail.com] > Sent: Tuesday, June 19, 2018 11:28 AM > To: Barry Fussell (bfussell) ; openssl-commits at openssl.org > Subject: Build failed in Jenkins: master_noec #574 > > See > > Changes: > > [Matthias.St.Pierre] Fix & update documentation about RAND_priv_bytes() > > [Matthias.St.Pierre] Improve the output of `make doc-nits` > > ------------------------------------------ > [...truncated 505.72 KB...] > rm -f test/v3ext > ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ > -o test/v3ext test/v3ext.o \ > test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/v3nametest.d.tmp -MT test/v3nametest.o -c -o test/v3nametest.o test/v3nametest.c rm -f test/v3nametest > ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ > -o test/v3nametest test/v3nametest.o \ > test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/verify_extra_test.d.tmp -MT test/verify_extra_test.o -c -o test/verify_extra_test.o test/verify_extra_test.c rm -f test/verify_extra_test > ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ > -o test/verify_extra_test test/verify_extra_test.o \ > test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/versions.d.tmp -MT test/versions.o -c -o test/versions.o test/versions.c rm -f test/versions > ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ > -o test/versions test/versions.o \ > -lcrypto -ldl -pthread > gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/wpackettest.d.tmp -MT test/wpackettest.o -c -o test/wpackettest.o test/wpackettest.c rm -f test/wpackettest > ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ > -o test/wpackettest test/wpackettest.o \ > libssl.a test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/x509_check_cert_pkey_test.d.tmp -MT test/x509_check_cert_pkey_test.o -c -o test/x509_check_cert_pkey_test.o test/x509_check_cert_pkey_test.c rm -f test/x509_check_cert_pkey_test > ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ > -o test/x509_check_cert_pkey_test test/x509_check_cert_pkey_test.o \ > test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/x509_dup_cert_test.d.tmp -MT test/x509_dup_cert_test.o -c -o test/x509_dup_cert_test.o test/x509_dup_cert_test.c rm -f test/x509_dup_cert_test > ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ > -o test/x509_dup_cert_test test/x509_dup_cert_test.o \ > test/libtestutil.a -lcrypto -ldl -pthread gcc -I. -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/x509_internal_test.d.tmp -MT test/x509_internal_test.o -c -o test/x509_internal_test.o test/x509_internal_test.c rm -f test/x509_internal_test > ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ > -o test/x509_internal_test test/x509_internal_test.o \ > test/libtestutil.a libcrypto.a -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/x509_time_test.d.tmp -MT test/x509_time_test.o -c -o test/x509_time_test.o test/x509_time_test.c rm -f test/x509_time_test > ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ > -o test/x509_time_test test/x509_time_test.o \ > test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/x509aux.d.tmp -MT test/x509aux.o -c -o test/x509aux.o test/x509aux.c rm -f test/x509aux > ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ > -o test/x509aux test/x509aux.o \ > test/libtestutil.a -lcrypto -ldl -pthread /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \ > "-oMakefile" apps/CA.pl.in > "apps/CA.pl" > chmod a+x apps/CA.pl > /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \ > "-oMakefile" apps/tsget.in > "apps/tsget" > chmod a+x apps/tsget > /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \ > "-oMakefile" tools/c_rehash.in > "tools/c_rehash" > chmod a+x tools/c_rehash > /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \ > "-oMakefile" util/shlib_wrap.sh.in > "util/shlib_wrap.sh" > chmod a+x util/shlib_wrap.sh > make[1]: Leaving directory ` > + apps/openssl version -a > OpenSSL 1.1.1-pre8-dev xx XXX xxxx > built on: Tue Jun 19 15:22:11 2018 UTC > platform: linux-x86_64 > options: bn(64,64) rc4(16x,int) des(int) idea(int) blowfish(ptr) > compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DNDEBUG > OPENSSLDIR: "/usr/local/ssl" > ENGINESDIR: "/usr/local/lib/engines-1.1" > Seeding source: os-specific > + make test > make depend && make _tests > make[1]: Entering directory ` > make[1]: Leaving directory ` > make[1]: Entering directory ` > ( cd test; \ > mkdir -p test-runs; \ > SRCTOP=../. \ > BLDTOP=../. \ > RESULT_D=test-runs \ > PERL="/usr/bin/perl" \ > EXE_EXT= \ > OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ > OPENSSL_DEBUG_MEMORY=on \ > /usr/bin/perl .././test/run_tests.pl ) ../test/recipes/01-test_abort.t .................... ok ../test/recipes/01-test_sanity.t ................... ok ../test/recipes/01-test_symbol_presence.t .......... skipped: Only useful when building shared libraries ../test/recipes/01-test_test.t ..................... ok ../test/recipes/02-test_internal_ctype.t ........... ok ../test/recipes/02-test_lhash.t .................... ok ../test/recipes/02-test_ordinals.t ................. ok ../test/recipes/02-test_stack.t .................... ok ../test/recipes/03-test_exdata.t ................... ok ../test/recipes/03-test_internal_asn1.t ............ ok ../test/recipes/03-test_internal_chacha.t .......... ok ../test/recipes/03-test_internal_curve448.t ........ skipped: This test is unsupported in a no-ec build ../test/recipes/03-test_internal_mdc2.t ............ ok ../test/recipes/03-test_internal_modes.t ........... ok ../test/recipes/03-test_internal_poly1305.t ........ ok ../test/recipes/03-test_internal_siphash.t ......... ok ../test/recipes/03-test_internal_sm2.t ............. skipped: sm2 is not supported by this OpenSSL build ../test/recipes/03-test_internal_sm4.t ............. ok ../test/recipes/03-test_internal_ssl_cert_table.t .. ok ../test/recipes/03-test_internal_x509.t ............ ok ../test/recipes/03-test_ui.t ....................... ok ../test/recipes/04-test_asn1_encode.t .............. ok ../test/recipes/04-test_asn1_string_table.t ........ ok ../test/recipes/04-test_bio_callback.t ............. ok ../test/recipes/04-test_bioprint.t ................. ok ../test/recipes/04-test_err.t ...................... ok ../test/recipes/04-test_pem.t ...................... ok ../test/recipes/05-test_bf.t ....................... ok ../test/recipes/05-test_cast.t ..................... ok ../test/recipes/05-test_des.t ...................... ok ../test/recipes/05-test_hmac.t ..................... ok ../test/recipes/05-test_idea.t ..................... ok ../test/recipes/05-test_md2.t ...................... skipped: md2 is not supported by this OpenSSL build ../test/recipes/05-test_mdc2.t ..................... ok ../test/recipes/05-test_rand.t ..................... ok ../test/recipes/05-test_rc2.t ...................... ok ../test/recipes/05-test_rc4.t ...................... ok ../test/recipes/05-test_rc5.t ...................... skipped: rc5 is not supported by this OpenSSL build ../test/recipes/06-test-rdrand.t ................... ok ../test/recipes/10-test_bn.t ....................... ok ../test/recipes/10-test_exp.t ...................... ok ../test/recipes/15-test_dh.t ....................... ok ../test/recipes/15-test_dsa.t ...................... ok ../test/recipes/15-test_ec.t ....................... ok ../test/recipes/15-test_ecdsa.t .................... skipped: ec is not supported by this OpenSSL build ../test/recipes/15-test_ecparam.t .................. skipped: EC isn't supported in this build ../test/recipes/15-test_genrsa.t ................... ok ../test/recipes/15-test_mp_rsa.t ................... ok ../test/recipes/15-test_out_option.t ............... ok ../test/recipes/15-test_rsa.t ...................... ok ../test/recipes/15-test_rsapss.t ................... ok ../test/recipes/20-test_enc.t ...................... ok ../test/recipes/20-test_enc_more.t ................. ok ../test/recipes/20-test_passwd.t ................... ok ../test/recipes/25-test_crl.t ...................... ok ../test/recipes/25-test_d2i.t ...................... ok ../test/recipes/25-test_pkcs7.t .................... ok ../test/recipes/25-test_req.t ...................... ok ../test/recipes/25-test_sid.t ...................... skipped: test_sid needs EC to run ../test/recipes/25-test_verify.t ................... ok ../test/recipes/25-test_x509.t ..................... ok ../test/recipes/30-test_afalg.t .................... skipped: test_afalg not supported for this build ../test/recipes/30-test_engine.t ................... ok ../test/recipes/30-test_evp.t ...................... > Dubious, test returned 1 (wstat 256, 0x100) Failed 1/7 subtests ../test/recipes/30-test_evp_extra.t ................ ok ../test/recipes/30-test_pbelu.t .................... ok ../test/recipes/30-test_pkey_meth.t ................ ok ../test/recipes/30-test_pkey_meth_kdf.t ............ ok ../test/recipes/40-test_rehash.t ................... ok ../test/recipes/60-test_x509_check_cert_pkey.t ..... ok ../test/recipes/60-test_x509_dup_cert.t ............ ok ../test/recipes/60-test_x509_store.t ............... ok ../test/recipes/60-test_x509_time.t ................ ok ../test/recipes/70-test_asyncio.t .................. ok ../test/recipes/70-test_bad_dtls.t ................. ok ../test/recipes/70-test_clienthello.t .............. ok ../test/recipes/70-test_comp.t ..................... skipped: test_comp needs the dynamic engine feature enabled ../test/recipes/70-test_key_share.t ................ skipped: test_key_share needs the dynamic engine feature enabled ../test/recipes/70-test_packet.t ................... ok ../test/recipes/70-test_recordlen.t ................ ok ../test/recipes/70-test_renegotiation.t ............ skipped: test_renegotiation needs the dynamic engine feature enabled ../test/recipes/70-test_servername.t ............... ok ../test/recipes/70-test_sslcbcpadding.t ............ skipped: test_sslcbcpadding needs the dynamic engine feature enabled ../test/recipes/70-test_sslcertstatus.t ............ skipped: test_sslcertstatus needs the dynamic engine feature enabled ../test/recipes/70-test_sslextension.t ............. skipped: test_sslextension needs the dynamic engine feature enabled ../test/recipes/70-test_sslmessages.t .............. skipped: test_sslmessages needs the dynamic engine feature enabled ../test/recipes/70-test_sslrecords.t ............... skipped: test_sslrecords needs the dynamic engine feature enabled ../test/recipes/70-test_sslsessiontick.t ........... skipped: test_sslsessiontick needs the dynamic engine feature enabled ../test/recipes/70-test_sslsigalgs.t ............... skipped: test_sslsigalgs needs the dynamic engine feature enabled ../test/recipes/70-test_sslsignature.t ............. skipped: test_sslsignature needs the dynamic engine feature enabled ../test/recipes/70-test_sslskewith0p.t ............. skipped: test_sslskewith0p needs the dynamic engine feature enabled ../test/recipes/70-test_sslversions.t .............. skipped: test_sslversions needs the dynamic engine feature enabled ../test/recipes/70-test_sslvertol.t ................ skipped: test_sslextension needs the dynamic engine feature enabled ../test/recipes/70-test_tls13cookie.t .............. skipped: test_tls13cookie needs the dynamic engine feature enabled ../test/recipes/70-test_tls13downgrade.t ........... skipped: test_tls13downgrade needs the dynamic engine feature enabled ../test/recipes/70-test_tls13hrr.t ................. skipped: test_tls13hrr needs the dynamic engine feature enabled ../test/recipes/70-test_tls13kexmodes.t ............ skipped: test_tls13kexmodes needs the dynamic engine feature enabled ../test/recipes/70-test_tls13messages.t ............ skipped: test_tls13messages needs the dynamic engine feature enabled ../test/recipes/70-test_tls13psk.t ................. skipped: test_tls13psk needs the dynamic engine feature enabled ../test/recipes/70-test_tlsextms.t ................. skipped: test_tlsextms needs the dynamic engine feature enabled ../test/recipes/70-test_verify_extra.t ............. ok ../test/recipes/70-test_wpacket.t .................. ok ../test/recipes/80-test_ca.t ....................... ok ../test/recipes/80-test_cipherbytes.t .............. ok ../test/recipes/80-test_cipherlist.t ............... ok ../test/recipes/80-test_ciphername.t ............... ok ../test/recipes/80-test_cms.t ...................... ok ../test/recipes/80-test_cmsapi.t ................... ok ../test/recipes/80-test_ct.t ....................... skipped: ct and ec are not supported by this OpenSSL build ../test/recipes/80-test_dane.t ..................... skipped: test_dane uses ec which is not supported by this OpenSSL build ../test/recipes/80-test_dtls.t ..................... ok ../test/recipes/80-test_dtls_mtu.t ................. ok ../test/recipes/80-test_dtlsv1listen.t ............. ok ../test/recipes/80-test_ocsp.t ..................... ok ../test/recipes/80-test_pkcs12.t ................... ok ../test/recipes/80-test_ssl_new.t .................. ok ../test/recipes/80-test_ssl_old.t .................. ok ../test/recipes/80-test_ssl_test_ctx.t ............. ok ../test/recipes/80-test_sslcorrupt.t ............... ok ../test/recipes/80-test_tsa.t ...................... ok ../test/recipes/80-test_x509aux.t .................. skipped: test_dane uses ec which is not supported by this OpenSSL build ../test/recipes/90-test_asn1_time.t ................ ok ../test/recipes/90-test_async.t .................... ok ../test/recipes/90-test_bio_enc.t .................. ok ../test/recipes/90-test_constant_time.t ............ ok ../test/recipes/90-test_fatalerr.t ................. ok ../test/recipes/90-test_gmdiff.t ................... ok ../test/recipes/90-test_ige.t ...................... ok ../test/recipes/90-test_includes.t ................. ok ../test/recipes/90-test_memleak.t .................. ok ../test/recipes/90-test_overhead.t ................. ok ../test/recipes/90-test_secmem.t ................... ok ../test/recipes/90-test_shlibload.t ................ skipped: Test only supported in a shared build ../test/recipes/90-test_srp.t ...................... ok ../test/recipes/90-test_sslapi.t ................... ok ../test/recipes/90-test_sslbuffers.t ............... ok ../test/recipes/90-test_store.t .................... ok ../test/recipes/90-test_sysdefault.t ............... ok ../test/recipes/90-test_threads.t .................. ok ../test/recipes/90-test_time_offset.t .............. ok ../test/recipes/90-test_tls13ccs.t ................. skipped: test_tls13ccs is not supported in this build ../test/recipes/90-test_tls13encryption.t .......... skipped: tls13encryption is not supported in this build ../test/recipes/90-test_tls13secrets.t ............. skipped: tls13secrets is not supported in this build ../test/recipes/90-test_v3name.t ................... ok ../test/recipes/95-test_external_boringssl.t ....... skipped: No external tests in this configuration ../test/recipes/95-test_external_krb5.t ............ skipped: No external tests in this configuration ../test/recipes/95-test_external_pyca.t ............ skipped: No external tests in this configuration ../test/recipes/99-test_ecstress.t ................. ok ../test/recipes/99-test_fuzz.t ..................... ok > > Test Summary Report > ------------------- > ../test/recipes/30-test_evp.t (Wstat: 256 Tests: 7 Failed: 1) > Failed test: 7 > Non-zero exit status: 1 > Files=149, Tests=1016, 111 wallclock secs ( 0.43 usr 0.11 sys + 40.62 cusr 8.81 csys = 49.97 CPU) > Result: FAIL > make[1]: *** [_tests] Error 1 > make[1]: Leaving directory ` > make: *** [tests] Error 2 > Build step 'Execute shell' marked build as failure > _____ > openssl-commits mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-commits > From matt at openssl.org Wed Jun 27 10:06:14 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 27 Jun 2018 11:06:14 +0100 Subject: [openssl-project] [openssl-commits] Build failed in Jenkins: master_noec #574 In-Reply-To: <72a8f0a4-5e06-6312-6bc3-87aec4dde94e@openssl.org> References: <1825497302.459.1529407642729.JavaMail.jenkins@ip-172-31-34-99> <2047571367.460.1529422051316.JavaMail.jenkins@ip-172-31-34-99> <932ef019d3644767a9b17effafcc19f8@XCH-ALN-004.cisco.com> <72a8f0a4-5e06-6312-6bc3-87aec4dde94e@openssl.org> Message-ID: <94d410b5-13fe-5bbe-bf81-0d49825797d3@openssl.org> Also - does this only happen with no-ec? Matt On 27/06/18 10:32, Matt Caswell wrote: > I am slightly confused because the code sample below and the commit id > you gave is for 1.1.0, but the original email seems to be about master. > > Is the same issue affecting both? Note: the pderive_test_run() function > looks quite different between 1.1.0 and master. > > Matt > > > On 26/06/18 19:32, Barry Fussell (bfussell) wrote: >> The evp_test is failing intermittently because there is an attempt to >> malloc zero bytes when running the new test that came in with >> this commit. >> >> https://bitbucket-eng-rtp1.cisco.com/bitbucket/projects/TS/repos/ciscossl/commits/7b3e775a6a78650bbd3e8e19a5aa12981880402b#test/evptests.txt >> >> >> static int pderive_test_run(struct evp_test *t) >> { >> struct pkey_data *kdata = t->data; >> unsigned char *out = NULL; >> size_t out_len; >> const char *err = "INTERNAL_ERROR"; >> >> out_len = kdata->output_len; >> out = OPENSSL_malloc(out_len); <----- out is zero because there is no SharedSecret >> if (!out) { >> >> -----Original Message----- >> From: osslsanity at gmail.com [mailto:osslsanity at gmail.com] >> Sent: Tuesday, June 19, 2018 11:28 AM >> To: Barry Fussell (bfussell) ; openssl-commits at openssl.org >> Subject: Build failed in Jenkins: master_noec #574 >> >> See >> >> Changes: >> >> [Matthias.St.Pierre] Fix & update documentation about RAND_priv_bytes() >> >> [Matthias.St.Pierre] Improve the output of `make doc-nits` >> >> ------------------------------------------ >> [...truncated 505.72 KB...] >> rm -f test/v3ext >> ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ >> -o test/v3ext test/v3ext.o \ >> test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/v3nametest.d.tmp -MT test/v3nametest.o -c -o test/v3nametest.o test/v3nametest.c rm -f test/v3nametest >> ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ >> -o test/v3nametest test/v3nametest.o \ >> test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/verify_extra_test.d.tmp -MT test/verify_extra_test.o -c -o test/verify_extra_test.o test/verify_extra_test.c rm -f test/verify_extra_test >> ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ >> -o test/verify_extra_test test/verify_extra_test.o \ >> test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/versions.d.tmp -MT test/versions.o -c -o test/versions.o test/versions.c rm -f test/versions >> ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ >> -o test/versions test/versions.o \ >> -lcrypto -ldl -pthread >> gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/wpackettest.d.tmp -MT test/wpackettest.o -c -o test/wpackettest.o test/wpackettest.c rm -f test/wpackettest >> ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ >> -o test/wpackettest test/wpackettest.o \ >> libssl.a test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/x509_check_cert_pkey_test.d.tmp -MT test/x509_check_cert_pkey_test.o -c -o test/x509_check_cert_pkey_test.o test/x509_check_cert_pkey_test.c rm -f test/x509_check_cert_pkey_test >> ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ >> -o test/x509_check_cert_pkey_test test/x509_check_cert_pkey_test.o \ >> test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/x509_dup_cert_test.d.tmp -MT test/x509_dup_cert_test.o -c -o test/x509_dup_cert_test.o test/x509_dup_cert_test.c rm -f test/x509_dup_cert_test >> ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ >> -o test/x509_dup_cert_test test/x509_dup_cert_test.o \ >> test/libtestutil.a -lcrypto -ldl -pthread gcc -I. -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/x509_internal_test.d.tmp -MT test/x509_internal_test.o -c -o test/x509_internal_test.o test/x509_internal_test.c rm -f test/x509_internal_test >> ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ >> -o test/x509_internal_test test/x509_internal_test.o \ >> test/libtestutil.a libcrypto.a -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/x509_time_test.d.tmp -MT test/x509_time_test.o -c -o test/x509_time_test.o test/x509_time_test.c rm -f test/x509_time_test >> ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ >> -o test/x509_time_test test/x509_time_test.o \ >> test/libtestutil.a -lcrypto -ldl -pthread gcc -Iinclude -pthread -m64 -Wa,--noexecstack -Wall -O3 -DNDEBUG -MMD -MF test/x509aux.d.tmp -MT test/x509aux.o -c -o test/x509aux.o test/x509aux.c rm -f test/x509aux >> ${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L. \ >> -o test/x509aux test/x509aux.o \ >> test/libtestutil.a -lcrypto -ldl -pthread /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \ >> "-oMakefile" apps/CA.pl.in > "apps/CA.pl" >> chmod a+x apps/CA.pl >> /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \ >> "-oMakefile" apps/tsget.in > "apps/tsget" >> chmod a+x apps/tsget >> /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \ >> "-oMakefile" tools/c_rehash.in > "tools/c_rehash" >> chmod a+x tools/c_rehash >> /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \ >> "-oMakefile" util/shlib_wrap.sh.in > "util/shlib_wrap.sh" >> chmod a+x util/shlib_wrap.sh >> make[1]: Leaving directory ` >> + apps/openssl version -a >> OpenSSL 1.1.1-pre8-dev xx XXX xxxx >> built on: Tue Jun 19 15:22:11 2018 UTC >> platform: linux-x86_64 >> options: bn(64,64) rc4(16x,int) des(int) idea(int) blowfish(ptr) >> compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DNDEBUG >> OPENSSLDIR: "/usr/local/ssl" >> ENGINESDIR: "/usr/local/lib/engines-1.1" >> Seeding source: os-specific >> + make test >> make depend && make _tests >> make[1]: Entering directory ` >> make[1]: Leaving directory ` >> make[1]: Entering directory ` >> ( cd test; \ >> mkdir -p test-runs; \ >> SRCTOP=../. \ >> BLDTOP=../. \ >> RESULT_D=test-runs \ >> PERL="/usr/bin/perl" \ >> EXE_EXT= \ >> OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \ >> OPENSSL_DEBUG_MEMORY=on \ >> /usr/bin/perl .././test/run_tests.pl ) ../test/recipes/01-test_abort.t .................... ok ../test/recipes/01-test_sanity.t ................... ok ../test/recipes/01-test_symbol_presence.t .......... skipped: Only useful when building shared libraries ../test/recipes/01-test_test.t ..................... ok ../test/recipes/02-test_internal_ctype.t ........... ok ../test/recipes/02-test_lhash.t .................... ok ../test/recipes/02-test_ordinals.t ................. ok ../test/recipes/02-test_stack.t .................... ok ../test/recipes/03-test_exdata.t ................... ok ../test/recipes/03-test_internal_asn1.t ............ ok ../test/recipes/03-test_internal_chacha.t .......... ok ../test/recipes/03-test_internal_curve448.t ........ skipped: This test is unsupported in a no-ec build ../test/recipes/03-test_internal_mdc2.t ............ ok ../test/recipes/03-test_internal_modes.t ........... ok ../test/recipes/03-test_internal_poly1305.t ........ ok ../test/recipes/03-test_internal_siphash.t ......... ok ../test/recipes/03-test_internal_sm2.t ............. skipped: sm2 is not supported by this OpenSSL build ../test/recipes/03-test_internal_sm4.t ............. ok ../test/recipes/03-test_internal_ssl_cert_table.t .. ok ../test/recipes/03-test_internal_x509.t ............ ok ../test/recipes/03-test_ui.t ....................... ok ../test/recipes/04-test_asn1_encode.t .............. ok ../test/recipes/04-test_asn1_string_table.t ........ ok ../test/recipes/04-test_bio_callback.t ............. ok ../test/recipes/04-test_bioprint.t ................. ok ../test/recipes/04-test_err.t ...................... ok ../test/recipes/04-test_pem.t ...................... ok ../test/recipes/05-test_bf.t ....................... ok ../test/recipes/05-test_cast.t ..................... ok ../test/recipes/05-test_des.t ...................... ok ../test/recipes/05-test_hmac.t ..................... ok ../test/recipes/05-test_idea.t ..................... ok ../test/recipes/05-test_md2.t ...................... skipped: md2 is not supported by this OpenSSL build ../test/recipes/05-test_mdc2.t ..................... ok ../test/recipes/05-test_rand.t ..................... ok ../test/recipes/05-test_rc2.t ...................... ok ../test/recipes/05-test_rc4.t ...................... ok ../test/recipes/05-test_rc5.t ...................... skipped: rc5 is not supported by this OpenSSL build ../test/recipes/06-test-rdrand.t ................... ok ../test/recipes/10-test_bn.t ....................... ok ../test/recipes/10-test_exp.t ...................... ok ../test/recipes/15-test_dh.t ....................... ok ../test/recipes/15-test_dsa.t ...................... ok ../test/recipes/15-test_ec.t ....................... ok ../test/recipes/15-test_ecdsa.t .................... skipped: ec is not supported by this OpenSSL build ../test/recipes/15-test_ecparam.t .................. skipped: EC isn't supported in this build ../test/recipes/15-test_genrsa.t ................... ok ../test/recipes/15-test_mp_rsa.t ................... ok ../test/recipes/15-test_out_option.t ............... ok ../test/recipes/15-test_rsa.t ...................... ok ../test/recipes/15-test_rsapss.t ................... ok ../test/recipes/20-test_enc.t ...................... ok ../test/recipes/20-test_enc_more.t ................. ok ../test/recipes/20-test_passwd.t ................... ok ../test/recipes/25-test_crl.t ...................... ok ../test/recipes/25-test_d2i.t ...................... ok ../test/recipes/25-test_pkcs7.t .................... ok ../test/recipes/25-test_req.t ...................... ok ../test/recipes/25-test_sid.t ...................... skipped: test_sid needs EC to run ../test/recipes/25-test_verify.t ................... ok ../test/recipes/25-test_x509.t ..................... ok ../test/recipes/30-test_afalg.t .................... skipped: test_afalg not supported for this build ../test/recipes/30-test_engine.t ................... ok ../test/recipes/30-test_evp.t ...................... >> Dubious, test returned 1 (wstat 256, 0x100) Failed 1/7 subtests ../test/recipes/30-test_evp_extra.t ................ ok ../test/recipes/30-test_pbelu.t .................... ok ../test/recipes/30-test_pkey_meth.t ................ ok ../test/recipes/30-test_pkey_meth_kdf.t ............ ok ../test/recipes/40-test_rehash.t ................... ok ../test/recipes/60-test_x509_check_cert_pkey.t ..... ok ../test/recipes/60-test_x509_dup_cert.t ............ ok ../test/recipes/60-test_x509_store.t ............... ok ../test/recipes/60-test_x509_time.t ................ ok ../test/recipes/70-test_asyncio.t .................. ok ../test/recipes/70-test_bad_dtls.t ................. ok ../test/recipes/70-test_clienthello.t .............. ok ../test/recipes/70-test_comp.t ..................... skipped: test_comp needs the dynamic engine feature enabled ../test/recipes/70-test_key_share.t ................ skipped: test_key_share needs the dynamic engine feature enabled ../test/recipes/70-test_packet.t ................... ok ../test/recipes/70-test_recordlen.t ................ ok ../test/recipes/70-test_renegotiation.t ............ skipped: test_renegotiation needs the dynamic engine feature enabled ../test/recipes/70-test_servername.t ............... ok ../test/recipes/70-test_sslcbcpadding.t ............ skipped: test_sslcbcpadding needs the dynamic engine feature enabled ../test/recipes/70-test_sslcertstatus.t ............ skipped: test_sslcertstatus needs the dynamic engine feature enabled ../test/recipes/70-test_sslextension.t ............. skipped: test_sslextension needs the dynamic engine feature enabled ../test/recipes/70-test_sslmessages.t .............. skipped: test_sslmessages needs the dynamic engine feature enabled ../test/recipes/70-test_sslrecords.t ............... skipped: test_sslrecords needs the dynamic engine feature enabled ../test/recipes/70-test_sslsessiontick.t ........... skipped: test_sslsessiontick needs the dynamic engine feature enabled ../test/recipes/70-test_sslsigalgs.t ............... skipped: test_sslsigalgs needs the dynamic engine feature enabled ../test/recipes/70-test_sslsignature.t ............. skipped: test_sslsignature needs the dynamic engine feature enabled ../test/recipes/70-test_sslskewith0p.t ............. skipped: test_sslskewith0p needs the dynamic engine feature enabled ../test/recipes/70-test_sslversions.t .............. skipped: test_sslversions needs the dynamic engine feature enabled ../test/recipes/70-test_sslvertol.t ................ skipped: test_sslextension needs the dynamic engine feature enabled ../test/recipes/70-test_tls13cookie.t .............. skipped: test_tls13cookie needs the dynamic engine feature enabled ../test/recipes/70-test_tls13downgrade.t ........... skipped: test_tls13downgrade needs the dynamic engine feature enabled ../test/recipes/70-test_tls13hrr.t ................. skipped: test_tls13hrr needs the dynamic engine feature enabled ../test/recipes/70-test_tls13kexmodes.t ............ skipped: test_tls13kexmodes needs the dynamic engine feature enabled ../test/recipes/70-test_tls13messages.t ............ skipped: test_tls13messages needs the dynamic engine feature enabled ../test/recipes/70-test_tls13psk.t ................. skipped: test_tls13psk needs the dynamic engine feature enabled ../test/recipes/70-test_tlsextms.t ................. skipped: test_tlsextms needs the dynamic engine feature enabled ../test/recipes/70-test_verify_extra.t ............. ok ../test/recipes/70-test_wpacket.t .................. ok ../test/recipes/80-test_ca.t ....................... ok ../test/recipes/80-test_cipherbytes.t .............. ok ../test/recipes/80-test_cipherlist.t ............... ok ../test/recipes/80-test_ciphername.t ............... ok ../test/recipes/80-test_cms.t ...................... ok ../test/recipes/80-test_cmsapi.t ................... ok ../test/recipes/80-test_ct.t ....................... skipped: ct and ec are not supported by this OpenSSL build ../test/recipes/80-test_dane.t ..................... skipped: test_dane uses ec which is not supported by this OpenSSL build ../test/recipes/80-test_dtls.t ..................... ok ../test/recipes/80-test_dtls_mtu.t ................. ok ../test/recipes/80-test_dtlsv1listen.t ............. ok ../test/recipes/80-test_ocsp.t ..................... ok ../test/recipes/80-test_pkcs12.t ................... ok ../test/recipes/80-test_ssl_new.t .................. ok ../test/recipes/80-test_ssl_old.t .................. ok ../test/recipes/80-test_ssl_test_ctx.t ............. ok ../test/recipes/80-test_sslcorrupt.t ............... ok ../test/recipes/80-test_tsa.t ...................... ok ../test/recipes/80-test_x509aux.t .................. skipped: test_dane uses ec which is not supported by this OpenSSL build ../test/recipes/90-test_asn1_time.t ................ ok ../test/recipes/90-test_async.t .................... ok ../test/recipes/90-test_bio_enc.t .................. ok ../test/recipes/90-test_constant_time.t ............ ok ../test/recipes/90-test_fatalerr.t ................. ok ../test/recipes/90-test_gmdiff.t ................... ok ../test/recipes/90-test_ige.t ...................... ok ../test/recipes/90-test_includes.t ................. ok ../test/recipes/90-test_memleak.t .................. ok ../test/recipes/90-test_overhead.t ................. ok ../test/recipes/90-test_secmem.t ................... ok ../test/recipes/90-test_shlibload.t ................ skipped: Test only supported in a shared build ../test/recipes/90-test_srp.t ...................... ok ../test/recipes/90-test_sslapi.t ................... ok ../test/recipes/90-test_sslbuffers.t ............... ok ../test/recipes/90-test_store.t .................... ok ../test/recipes/90-test_sysdefault.t ............... ok ../test/recipes/90-test_threads.t .................. ok ../test/recipes/90-test_time_offset.t .............. ok ../test/recipes/90-test_tls13ccs.t ................. skipped: test_tls13ccs is not supported in this build ../test/recipes/90-test_tls13encryption.t .......... skipped: tls13encryption is not supported in this build ../test/recipes/90-test_tls13secrets.t ............. skipped: tls13secrets is not supported in this build ../test/recipes/90-test_v3name.t ................... ok ../test/recipes/95-test_external_boringssl.t ....... skipped: No external tests in this configuration ../test/recipes/95-test_external_krb5.t ............ skipped: No external tests in this configuration ../test/recipes/95-test_external_pyca.t ............ skipped: No external tests in this configuration ../test/recipes/99-test_ecstress.t ................. ok ../test/recipes/99-test_fuzz.t ..................... ok >> >> Test Summary Report >> ------------------- >> ../test/recipes/30-test_evp.t (Wstat: 256 Tests: 7 Failed: 1) >> Failed test: 7 >> Non-zero exit status: 1 >> Files=149, Tests=1016, 111 wallclock secs ( 0.43 usr 0.11 sys + 40.62 cusr 8.81 csys = 49.97 CPU) >> Result: FAIL >> make[1]: *** [_tests] Error 1 >> make[1]: Leaving directory ` >> make: *** [tests] Error 2 >> Build step 'Execute shell' marked build as failure >> _____ >> openssl-commits mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-commits >> > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > From matt at openssl.org Wed Jun 27 15:10:02 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 27 Jun 2018 16:10:02 +0100 Subject: [openssl-project] Milestones and the 1.1.1 release In-Reply-To: References: <6a460a10-face-5780-7c6f-885a7e0e3ecb@openssl.org> <98E3F9EB-D27D-4307-945F-A921E3FF3E29@akamai.com> Message-ID: <16cd0d05-e301-9a68-f464-267175e0d21b@openssl.org> Well, no one has objected so far. I'm not around tomorrow and Friday to action this but, unless anyone shouts between now and then, I'll start doing this on Monday. Matt On 26/06/18 21:15, Matt Caswell wrote: > > > On 26/06/18 20:43, Salz, Rich wrote: >> That's interesting. Would we put a bugfix in 1.1.0, not put the fix in 1.1.1 until our first "a" release? >> >> Or are you saying that if it's in 1.1.0, then we don't have to fix it until after 1.1.1 comes out? That seems justifiable to me. > > The latter. > > I mean it doesn't *prevent* us from fixing something that's in both > 1.1.0 and 1.1.1 - but our focus should be on fixing issues that are > newly introduced in 1.1.1. > > Matt > >> >> ?On 6/26/18, 3:32 PM, "Matt Caswell" wrote: >> >> >> >> On 26/06/18 18:18, Salz, Rich wrote: >> > So are you saying look at the 73 open issues at https://github.com/openssl/openssl/milestone/9 and re-evaluate them? >> >> Exactly. My guess is that a significant proportion of them also apply to >> 1.1.0 and therefore should not hold up the 1.1.1 release. At the moment >> though it is impossible to tell which are the high priority issues we >> should be focussing on. >> >> Matt >> >> >> > >> > >> > >> > On 6/26/18, 11:56 AM, "Matt Caswell" wrote: >> > >> > I'm thinking that we should maybe re-asses the current milestones in github. >> > >> > We currently use the following milestones: >> > >> > Assessed - Anything against this milestone isn't relevant to the 1.1.1 >> > release (e.g. 1.0.2 specific issue) >> > >> > 1.1.1 - This is relevant to the 1.1.1 release but may not be specific to >> > it (e.g. an issue that affects both 1.1.1 and 1.1.0) >> > >> > Post 1.1.1 - Feature request to be looked at once 1.1.1 is released >> > >> > >> > I think we should re-asses everything currently against the 1.1.1 >> > milestone so that anything which isn't specific to that release gets >> > moved to the "Assessed" milestone. >> > >> > At the moment its difficult to see the "wood for the trees" between >> > issues which are newly introduced and those that are long standing. In >> > terms of getting the 1.1.1 release out the door we should focus on the >> > former. >> > >> > Thoughts? >> > >> > Matt >> > >> > _______________________________________________ >> > openssl-project mailing list >> > openssl-project at openssl.org >> > https://mta.openssl.org/mailman/listinfo/openssl-project >> > >> > >> > _______________________________________________ >> > openssl-project mailing list >> > openssl-project at openssl.org >> > https://mta.openssl.org/mailman/listinfo/openssl-project >> > >> _______________________________________________ >> openssl-project mailing list >> openssl-project at openssl.org >> https://mta.openssl.org/mailman/listinfo/openssl-project >> >> _______________________________________________ >> openssl-project mailing list >> openssl-project at openssl.org >> https://mta.openssl.org/mailman/listinfo/openssl-project >> > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project >