From matt at openssl.org Thu Feb 1 08:31:17 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 1 Feb 2018 08:31:17 +0000 Subject: [openssl-project] New Committer Message-ID: Please welcome our newest committer David Benjamin! Matt From Matthias.St.Pierre at ncp-e.com Thu Feb 1 09:49:38 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 1 Feb 2018 10:49:38 +0100 Subject: [openssl-project] New Committer In-Reply-To: References: Message-ID: <5A72E2B2.5020204@ncp-e.com> Congratulations and welcome, David! Matthias P.S: Good choice, OMC! Am 01.02.2018 um 09:31 schrieb Matt Caswell: > Please welcome our newest committer David Benjamin! > > Matt > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project From matt at openssl.org Thu Feb 1 16:52:24 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 1 Feb 2018 16:52:24 +0000 Subject: [openssl-project] Monthly Status Report (January) Message-ID: As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Attended Real World Crypto 2018 in Z?rich in order to collect the Levchin prize on behalf of the team - Took part in an interview for RedHat - Reviewed a large number of historic commits wrt the licence change - IETF TLS WG discussions and updates to spec with respect to signature_algorithms_cert extension - Reviewed all outstanding issues and PRs in order to assign them to a milestone as part of 1.1.1 release planning. Closed 134 issues as part of this. - Co-ordinated discussions on the 1.1.1 release timetable and made a proposal that is currently part of an OMC vote - Ongoing work on the OpenSSL book - Ongoing work on the Curve448 primitives implementation - WIP implementation of configurable number of TLSv1.3 session tickets - Fixed a bug in s_client PSK usage in 1.1.1 - Fixed some instances of a wrong alert being sent - Discovered and fixed a bug wrt how renegotiation is handled - Updated and pushed the SSL_stateless implementation - Fixed a bug in speed which was attempting to use X25519 for ECDSA - Fixed a crash in ca - Fixed a timeout problem in TLSProxy - Fixed a problem with BN_FLG_CONSTTIME and BN_copy() - Fixed a problem in DTLS so that we now tolerate alerts with the wrong version number - Fixed a minor issue in the SSL_trace() code Matt From rsalz at akamai.com Thu Feb 1 17:00:57 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 1 Feb 2018 17:00:57 +0000 Subject: [openssl-project] chatty make output Message-ID: <65DA0575-DCFB-49AF-9F8F-CF97371563A2@akamai.com> I think this belongs in CHANGES or NEWS, not with every single reconfigure build Creating Makefile NOTE: Starting with OpenSSL 1.1.1, 'Configure' doesn't display all the disabled options or the "make variables" with their values. Instead, you must use 'configdata.pm' as a script to get a display of the configuration data. For help, please do this: perl configdata.pm --help -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu Feb 1 17:50:38 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 01 Feb 2018 18:50:38 +0100 Subject: [openssl-project] chatty make output In-Reply-To: <65DA0575-DCFB-49AF-9F8F-CF97371563A2@akamai.com> References: <65DA0575-DCFB-49AF-9F8F-CF97371563A2@akamai.com> Message-ID: <2299301F-29E7-49E0-BCA1-8170346C7E6C@openssl.org> Me, I've noticed that quite a lot of people don't read CHANGES, so this is to avoid getting a ton of reports about Configure not displaying all the stuff it used to do. Also, the message is geared to disappear with 1.1.1a or above. Cheers Richard "Salz, Rich" skrev: (1 februari 2018 18:00:57 CET) >I think this belongs in CHANGES or NEWS, not with every single >reconfigure build > >Creating Makefile > >NOTE: Starting with OpenSSL 1.1.1, 'Configure' doesn't display all the >disabled >options or the "make variables" with their values. Instead, you must >use >'configdata.pm' as a script to get a display of the configuration data. > For >help, please do this: > > perl configdata.pm --help -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Feb 1 17:52:26 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 1 Feb 2018 17:52:26 +0000 Subject: [openssl-project] chatty make output In-Reply-To: <2299301F-29E7-49E0-BCA1-8170346C7E6C@openssl.org> References: <65DA0575-DCFB-49AF-9F8F-CF97371563A2@akamai.com> <2299301F-29E7-49E0-BCA1-8170346C7E6C@openssl.org> Message-ID: <3146A6F1-2631-4E65-A0EB-C41DE65BDED0@akamai.com> Fine. How about this change? iff --git a/Configure b/Configure index cad25bb..a994876 100755 --- a/Configure +++ b/Configure @@ -939,7 +939,7 @@ if ($target eq "HASH") { exit 0; } -print "Configuring OpenSSL version $config{version} ($config{version_num})\n"; +print "Configuring OpenSSL version $config{version} ($config{version_num}) "; print "for $target\n"; From: "levitte at openssl.org" Reply-To: "openssl-project at openssl.org" Date: Thursday, February 1, 2018 at 12:50 PM To: "openssl-project at openssl.org" Subject: Re: [openssl-project] chatty make output Me, I've noticed that quite a lot of people don't read CHANGES, so this is to avoid getting a ton of reports about Configure not displaying all the stuff it used to do. Also, the message is geared to disappear with 1.1.1a or above. Cheers Richard "Salz, Rich" skrev: (1 februari 2018 18:00:57 CET) I think this belongs in CHANGES or NEWS, not with every single reconfigure build Creating Makefile NOTE: Starting with OpenSSL 1.1.1, 'Configure' doesn't display all the disabled options or the "make variables" with their values. Instead, you must use 'configdata.pm' as a script to get a display of the configuration data. For help, please do this: perl configdata.pm --help -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu Feb 1 17:58:03 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 01 Feb 2018 18:58:03 +0100 Subject: [openssl-project] chatty make output In-Reply-To: <3146A6F1-2631-4E65-A0EB-C41DE65BDED0@akamai.com> References: <65DA0575-DCFB-49AF-9F8F-CF97371563A2@akamai.com> <2299301F-29E7-49E0-BCA1-8170346C7E6C@openssl.org> <3146A6F1-2631-4E65-A0EB-C41DE65BDED0@akamai.com> Message-ID: <382ADE17-0F08-4883-9202-02F252EB0990@openssl.org> I want to approve the PR that you're gonna submit any time now ? (I would like to see that in just one statement if possible) Cheers Richard "Salz, Rich" skrev: (1 februari 2018 18:52:26 CET) >Fine. > >How about this change? >iff --git a/Configure b/Configure >index cad25bb..a994876 100755 >--- a/Configure >+++ b/Configure >@@ -939,7 +939,7 @@ if ($target eq "HASH") { > exit 0; > } > >-print "Configuring OpenSSL version $config{version} >($config{version_num})\n"; >+print "Configuring OpenSSL version $config{version} >($config{version_num}) "; > print "for $target\n"; > > >From: "levitte at openssl.org" >Reply-To: "openssl-project at openssl.org" >Date: Thursday, February 1, 2018 at 12:50 PM >To: "openssl-project at openssl.org" >Subject: Re: [openssl-project] chatty make output > >Me, I've noticed that quite a lot of people don't read CHANGES, so this >is to avoid getting a ton of reports about Configure not displaying all >the stuff it used to do. > >Also, the message is geared to disappear with 1.1.1a or above. > >Cheers >Richard > >"Salz, Rich" skrev: (1 februari 2018 18:00:57 CET) >I think this belongs in CHANGES or NEWS, not with every single >reconfigure build > >Creating Makefile > >NOTE: Starting with OpenSSL 1.1.1, 'Configure' doesn't display all the >disabled >options or the "make variables" with their values. Instead, you must >use >'configdata.pm' as a script to get a display of the configuration data. > For >help, please do this: > > perl configdata.pm --help > > > >-- >Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Feb 1 19:16:11 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 1 Feb 2018 19:16:11 +0000 Subject: [openssl-project] FW: [Dcrup] WGLC final issues draft-ietf-dcrup-dkim-crypto In-Reply-To: <20180201191420.D41ED1A2A6E5@ary.qy> References: <3569AEBA-5089-4827-8C18-EC13246BC201@akamai.com> <20180201191420.D41ED1A2A6E5@ary.qy> Message-ID: Can anyone lend John a hand with ed25519 signatures via command-line? This is important for the next version of domain-key email signing (spam avoidance) On 2/1/18, 2:14 PM, "John Levine" wrote: In article <3569AEBA-5089-4827-8C18-EC13246BC201 at akamai.com> you write: >Scott has asked that his WGLC call issues from December be addressed. I believe this is the message he >means is this: > https://www.ietf.org/mail-archive/web/dcrup/current/msg00619.html >and that only the first two points remain. They seem like editorial clarifications to me; John can you make >those changes or something similar? Done, an updated draft is sitting here waiting for ... >There has also been discussion about including samples in the document. Where are we with that? I think a lot of us are twiddling our thumbs waiting for the OpenSSL version it is that will include ed25519 signatures since we'd rather not rewrite our RSA code to call some library that already has ed25519 and we don't want to call two different crypto libraries from our DKIM code. I see 1.1.0g in the freebsd packages which looks like it's got ed25519, so now I just have to figure out how to use the fricking thing. R's, John From paul.dale at oracle.com Thu Feb 1 21:24:01 2018 From: paul.dale at oracle.com (Paul Dale) Date: Thu, 1 Feb 2018 13:24:01 -0800 (PST) Subject: [openssl-project] New Committer In-Reply-To: References: Message-ID: <8228ab07-9889-41c5-af11-6ef304d190f7@default> Congratulations David! Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -----Original Message----- From: Matt Caswell [mailto:matt at openssl.org] Sent: Thursday, 1 February 2018 6:31 PM To: openssl-project at openssl.org Subject: [openssl-project] New Committer Please welcome our newest committer David Benjamin! Matt _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project From appro at openssl.org Thu Feb 1 22:12:47 2018 From: appro at openssl.org (Andy Polyakov) Date: Thu, 1 Feb 2018 23:12:47 +0100 Subject: [openssl-project] chatty make output In-Reply-To: <65DA0575-DCFB-49AF-9F8F-CF97371563A2@akamai.com> References: <65DA0575-DCFB-49AF-9F8F-CF97371563A2@akamai.com> Message-ID: <21e9cf89-dbcf-1b0e-5269-fb508e85e355@openssl.org> > I think this belongs in CHANGES or NEWS, not with every single > reconfigure build > > > Creating Makefile > > > NOTE: Starting with OpenSSL 1.1.1, 'Configure' doesn't display all the > disabled > options or the "make variables" with their values.? Instead, you must use > 'configdata.pm' as a script to get a display of the configuration data.? For > help, please do this: > > > ? ? ? ? perl configdata.pm --help BTW, I didn't appreciate this change. Thing about original output was that it was telling things about user's environment. Idea was that one didn't have to ask for additional information when user reported "ran config, it printed this, help"... I would even say that new message is meaningless to user. "Instead, you mist use 'configdata.pm'"? User will simply wonder "instead of what"? Then execute --help and wonder what is it that needs to be included into problem report... In other words if config doesn't produce output that appears worthy to include into problem report, then it should tell how to produce information that we would appreciate in problem report. From levitte at openssl.org Thu Feb 1 23:31:28 2018 From: levitte at openssl.org (Richard Levitte) Date: Fri, 02 Feb 2018 00:31:28 +0100 (CET) Subject: [openssl-project] chatty make output In-Reply-To: <21e9cf89-dbcf-1b0e-5269-fb508e85e355@openssl.org> References: <65DA0575-DCFB-49AF-9F8F-CF97371563A2@akamai.com> <21e9cf89-dbcf-1b0e-5269-fb508e85e355@openssl.org> Message-ID: <20180202.003128.416216254073166740.levitte@openssl.org> In message <21e9cf89-dbcf-1b0e-5269-fb508e85e355 at openssl.org> on Thu, 1 Feb 2018 23:12:47 +0100, Andy Polyakov said: appro> > I think this belongs in CHANGES or NEWS, not with every single appro> > reconfigure build appro> > appro> > appro> > Creating Makefile appro> > appro> > appro> > NOTE: Starting with OpenSSL 1.1.1, 'Configure' doesn't display all the appro> > disabled appro> > options or the "make variables" with their values.? Instead, you must use appro> > 'configdata.pm' as a script to get a display of the configuration data.? For appro> > help, please do this: appro> > appro> > appro> > ? ? ? ? perl configdata.pm --help appro> appro> BTW, I didn't appreciate this change. Thing about original appro> output was that it was telling things about user's environment. Yeahwell, there were other voices who didn't quite appreciate that dump, or that it was kinda sorta half baked, and not always on par with what actually ended up in the build file. Still doesn't *entirely*, but closer. appro> Idea was that one didn't have to ask for additional information appro> when user reported "ran config, it printed this, help"... I appro> would even say that new message is meaningless to user. appro> "Instead, you must use 'configdata.pm'"? User will simply appro> wonder "instead of what"? Then execute --help and wonder what appro> is it that needs to be included into problem report... In other appro> words if config doesn't produce output that appears worthy to appro> include into problem report, then it should tell how to produce appro> information that we would appreciate in problem report. Now this is a good point. There is a flag --dump that dumps quite a bit chunk of info... One thing I didn't think of was that the final config target attributes could be a useful addition, that could be added in the dump as well... -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kaduk at mit.edu Fri Feb 2 02:09:59 2018 From: kaduk at mit.edu (Benjamin Kaduk) Date: Thu, 1 Feb 2018 20:09:59 -0600 Subject: [openssl-project] New Committer In-Reply-To: <8228ab07-9889-41c5-af11-6ef304d190f7@default> References: <8228ab07-9889-41c5-af11-6ef304d190f7@default> Message-ID: <20180202020959.GX12363@mit.edu> Yes, congratulations! I will confess I was wondering when this was going to happen... -Ben On Thu, Feb 01, 2018 at 01:24:01PM -0800, Paul Dale wrote: > Congratulations David! > > Pauli > -- > Oracle > Dr Paul Dale | Cryptographer | Network Security & Encryption > Phone +61 7 3031 7217 > Oracle Australia > > > -----Original Message----- > From: Matt Caswell [mailto:matt at openssl.org] > Sent: Thursday, 1 February 2018 6:31 PM > To: openssl-project at openssl.org > Subject: [openssl-project] New Committer > > Please welcome our newest committer David Benjamin! > > 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 Sat Feb 3 23:40:42 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 3 Feb 2018 23:40:42 +0000 Subject: [openssl-project] release tools now in the 'tools' repository Message-ID: <722B1CE5-F9CC-4EC1-9622-AF1593731F78@akamai.com> We have cleaned up and posted the release tools as part of the tools repository. Thanks to Richard Levitte for a great deal of feedback and review. I had thought someone opened an issue for this, but I can?t find it; anyone else remember? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaduk at mit.edu Sat Feb 3 23:48:47 2018 From: kaduk at mit.edu (Benjamin Kaduk) Date: Sat, 3 Feb 2018 17:48:47 -0600 Subject: [openssl-project] release tools now in the 'tools' repository In-Reply-To: <722B1CE5-F9CC-4EC1-9622-AF1593731F78@akamai.com> References: <722B1CE5-F9CC-4EC1-9622-AF1593731F78@akamai.com> Message-ID: <20180203234847.GP12363@mit.edu> On Sat, Feb 03, 2018 at 11:40:42PM +0000, Salz, Rich wrote: > We have cleaned up and posted the release tools as part of the tools repository. Thanks to Richard Levitte for a great deal of feedback and review. > > I had thought someone opened an issue for this, but I can?t find it; anyone else remember? Someone was asking for xz compressed releases and the non-visibility of the tools came up there: https://github.com/openssl/openssl/issues/3786 -Ben From rsalz at akamai.com Sun Feb 4 00:33:30 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 4 Feb 2018 00:33:30 +0000 Subject: [openssl-project] release tools now in the 'tools' repository In-Reply-To: <20180203234847.GP12363@mit.edu> References: <722B1CE5-F9CC-4EC1-9622-AF1593731F78@akamai.com> <20180203234847.GP12363@mit.edu> Message-ID: <945E038B-58FA-4C73-AE2F-2D510CA8469B@akamai.com> > https://github.com/openssl/openssl/issues/3786 ah, thanks. From rsalz at akamai.com Mon Feb 5 18:13:09 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 5 Feb 2018 18:13:09 +0000 Subject: [openssl-project] Style guide update -- summary so far Message-ID: A summary of the discussion thread so far. Not surprisingly, it?s all about the whitespace. :) The descriptions here were written to be understandable stand-alone. Once we come to a conclusion, we?ll wordsmith them into the coding style. Do not put a size after sizeof; do use parens. When breaking long lines, if there are Boolean conditionals, put them at the start of the line. Consider doing this consistently, and don?t merge even if they fit. For example: some_long_condition() && short1() && short2() should be three lines. Related conditions should be on one line if they fit, else given an extra level of indent some_long_condition() && (short1() || short2()) && some_other_flag != 0 If the expression for an if statement does not fit, indent the continuation lines an extra level if (this_is_true() && !that_is_false()) { code(); ?. Try not to break long lines across a function call, but if you have to, indent the rest of the parameter list to be after the function?s opening paren. Remember a blank line after variable declarations (even local ones). Treat a single-statement with comment as if it were multi-line and use curly braces if (test()) { /* already alerted */ close(); } Note that this could end up having ?cascading curly? effects. Arguments inside macro expansions should be parenthesized. #define foo(a, b) ((a) + (b)) Free routines should properly handle null; don?t check for null before calling a free routine. When possible, use size_t for sizes of things (including array indicies) [ Matt said ?initialize in the declaration if appropriate; can someone provide wording? ] This is controversial, so maybe drop it. Don?t use else after return or goto unless it makes the flow more clear. Argument names in function definition should match the declaration, but you can use ?unused_? as a prefix in the definition for unused arguments. Use ossl_assert, not assert. Do not forget to handle the error condition as asserts are not compiled into production code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Feb 5 18:34:20 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 5 Feb 2018 18:34:20 +0000 Subject: [openssl-project] FW: CT Order Confirmation - OPENSSL SOFTWARE SERVICES INC. In-Reply-To: References: Message-ID: I filed the annual registration for OpenSSL Software Services and paid with the OpenSSL credit card. From: CT Corporation Reply-To: "[DO NOT REPLY] CT Corporation" Date: Monday, February 5, 2018 at 1:32 PM To: "rsalz at openssl.org" Subject: CT Order Confirmation - OPENSSL SOFTWARE SERVICES INC. Your order details are enclosed View Online [olters Kluwer] Order Confirmation CT Corporation Thank you for your order We?ve received your request and our experts are already on top of it. You may check your order status and view your invoice by logging into your account. Order Summary CONFIRMATION #: 10813302 AMOUNT: $225.00 COMPANY: OPENSSL SOFTWARE SERVICES INC. Ordered By Rich Salz 44 West St Reading, Massachusetts 018673712 View or Manage Order Next steps: * Your Annual Report will now be submitted to the state of Delaware * In the unlikely event that your report is not accepted by the state, we will contact you to reconcile the discrepancies. * We will notify you by email upon acceptance of the filing by Delaware. Questions? We're available to assist you at (844) 216-1680 Monday through Friday, 9:00 AM to 5:00 PM ET. Thank you again for your order, Your Team at CT CONNECT: [http://images.ctmail.wolterskluwer.com/EloquaImages/clients/CTCorporation/%7b3c6558af-61f6-4f5d-997b-a9787d2a37c6%7d_fb_24x24_white.png] [http://images.ctmail.wolterskluwer.com/EloquaImages/clients/CTCorporation/%7b19213369-075d-4f5a-98d5-ba058e15dcc2%7d_twitter_24x24_white.png] [http://images.ctmail.wolterskluwer.com/EloquaImages/clients/CTCorporation/%7b41819dbf-8702-48dc-9694-4c4369726225%7d_linkedIn_24x24_white.png] [http://images.ctmail.wolterskluwer.com/EloquaImages/clients/CTCorporation/%7b944e3016-0704-4573-9748-f4d4b00cd809%7d_google_24x24_white.png] You are receiving this email at rsalz at openssl.org as a customer of CT Corporation. Please do not reply to this e-mail. This mailbox is not monitored and you will not receive a response. CT Corporation | 111 Eighth Avenue, 13th Floor | New York, NY 10011 | (844) 216-1680 Manage My Subscription | Privacy Policy [olters Kluwer] -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Feb 5 19:05:57 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 5 Feb 2018 19:05:57 +0000 Subject: [openssl-project] Style guide update -- summary so far In-Reply-To: References: Message-ID: <6f36b748-dd3d-d0af-e769-b488e3da79a3@openssl.org> On 05/02/18 18:13, Salz, Rich wrote: > Use ossl_assert, not assert.? Do not forget to handle the error > condition as asserts are not compiled into production code. It's slightly more nuanced than that. There are occasions where assert is ok, e.g. switch(my_expression) { case 1: /* do something */ break; case 2: /* do something else */ break; default: assert("Shouldn't get here" == NULL); return -1; } In general we should prefer ossl_assert over assert. Never use OPENSSL_assert() in libcrypto or libssl. Matt From rsalz at akamai.com Mon Feb 5 19:18:52 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 5 Feb 2018 19:18:52 +0000 Subject: [openssl-project] Style guide update -- summary so far In-Reply-To: <6f36b748-dd3d-d0af-e769-b488e3da79a3@openssl.org> References: <6f36b748-dd3d-d0af-e769-b488e3da79a3@openssl.org> Message-ID: ? In general we should prefer ossl_assert over assert. Never use OPENSSL_assert() in libcrypto or libssl. Maybe that?s all to put into the guide, then. From Matthias.St.Pierre at ncp-e.com Mon Feb 5 19:43:04 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 5 Feb 2018 20:43:04 +0100 Subject: [openssl-project] Style guide update -- summary so far In-Reply-To: References: Message-ID: <1235a92a-d82b-c0f9-1b04-9e1cb8c94ef1@ncp-e.com> Am 05.02.2018 um 19:13 schrieb Salz, Rich: > > > Do not put a size after sizeof; do use parens. > nit: Do not put a /space /after sizeof. > > > Treat a single-statement with comment as if it were multi-line and use > curly braces > > > > if (test()) { > > /* already alerted */ > > close(); > > } > > > Wasn't there also the suggestion by someone that if one part of an if-else statements needs braces that the other part should get some, too? if (foo) do_this(); else do_that(); vs. if (foo) { /* some statements */ ... } else { ... } Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Feb 5 19:45:12 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 5 Feb 2018 19:45:12 +0000 Subject: [openssl-project] Style guide update -- summary so far In-Reply-To: <1235a92a-d82b-c0f9-1b04-9e1cb8c94ef1@ncp-e.com> References: <1235a92a-d82b-c0f9-1b04-9e1cb8c94ef1@ncp-e.com> Message-ID: <45a12566-8181-8a7d-cd4f-65538247b9eb@openssl.org> On 05/02/18 19:43, Dr. Matthias St. Pierre wrote: > > Wasn't there also the suggestion by someone that if one part of an > if-else statements needs braces that the other part should get some, too? That's already in the style guide: Do not unnecessarily use braces around a single statement: if (condition) action(); and if (condition) do_this(); else do_that(); If one of the branches is a compound statement, then use braces on both parts: if (condition) { do_this(); do_that(); } else { otherwise(); } Matt From rsalz at akamai.com Mon Feb 5 19:47:52 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 5 Feb 2018 19:47:52 +0000 Subject: [openssl-project] Style guide update -- summary so far In-Reply-To: <1235a92a-d82b-c0f9-1b04-9e1cb8c94ef1@ncp-e.com> References: <1235a92a-d82b-c0f9-1b04-9e1cb8c94ef1@ncp-e.com> Message-ID: <73E783A0-ECFB-4A90-A922-FA1369C1FDA9@akamai.com> * nit: Do not put a space after sizeof. fixed. * Wasn't there also the suggestion by someone that if one part of an if-else statements needs braces that the other part should get some, too? It already says that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Mon Feb 5 20:59:25 2018 From: paul.dale at oracle.com (Paul Dale) Date: Mon, 5 Feb 2018 12:59:25 -0800 (PST) Subject: [openssl-project] Style guide update -- summary so far In-Reply-To: References: Message-ID: > Arguments inside macro expansions should be parenthesized. > ??????????????? #define foo(a, b)? ((a) + (b)) Except when token concatenating a ## b and stringifying # a. As an aside, should there be spaces on either size of the ## concatenator? The current code mostly doesn't -- which means it sometimes does. My feeling is use whichever is clearer but we might want to codify this as yes, no or submitter decides. Likewise, should there be a space after the # stringifier? Existing code doesn't, apparently without exception. I'm pressed to think of a case where having a space increases clarity but I'm sure some exist. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From kurt at roeckx.be Mon Feb 5 22:48:15 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Mon, 5 Feb 2018 23:48:15 +0100 Subject: [openssl-project] Style guide update -- summary so far In-Reply-To: <1235a92a-d82b-c0f9-1b04-9e1cb8c94ef1@ncp-e.com> References: <1235a92a-d82b-c0f9-1b04-9e1cb8c94ef1@ncp-e.com> Message-ID: <20180205224814.GA19088@roeckx.be> On Mon, Feb 05, 2018 at 08:43:04PM +0100, Dr. Matthias St. Pierre wrote: > > > Am 05.02.2018 um 19:13 schrieb Salz, Rich: > > > > > > Do not put a size after sizeof; do use parens. > > > > nit: Do not put a /space /after sizeof. > > > > > > > Treat a single-statement with comment as if it were multi-line and use > > curly braces > > > > > > > > if (test()) { > > > > /* already alerted */ > > > > close(); > > > > } > > > > > > > > Wasn't there also the suggestion by someone that if one part of an > if-else statements needs braces that the other part should get some, too? > > if (foo) > do_this(); > else > do_that(); > > vs. > > if (foo) { > /* some statements */ > ... > } else { > ... > } As already pointed out by others, it's mostly already in the style guide. What is not in it is the combination with a comment: if (foo) /* some comment */ do_this(); else do_that(); And it's been suggested to use curly braces for that. Kurt From matt at openssl.org Tue Feb 6 10:29:09 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 6 Feb 2018 10:29:09 +0000 Subject: [openssl-project] 1.1.1 Release timetable (again) In-Reply-To: References: <960F4FFA-8EEC-41A2-BD47-CFB119BC99EA@akamai.com> <20180125.083954.321572440752486616.levitte@openssl.org> <5b07b199-edce-0184-99f9-f76f07e84199@openssl.org> <37773e09-ec15-339e-6319-a6f443c4fd7c@openssl.org> Message-ID: On 30/01/18 10:45, Matt Caswell wrote: > No feedback so I started the vote: > > topic: We should update the release strategy as shown in > https://github.com/openssl/web/pull/41, commit id 52d9ea8fb > Proposed by Matt Caswell > Public: yes > opened: 2018-01-30 > closed: yyyy-mm-dd > ONE WEEK VOTE > > I will report back here with the result once the vote is complete. This vote has passed: 8 in favour, 0 against, 0 abstentions, 0 no-vote Matt From matt at openssl.org Tue Feb 6 11:14:42 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 6 Feb 2018 11:14:42 +0000 Subject: [openssl-project] Feature freeze for 1.1.1 Message-ID: <82145be2-9bbb-be69-4c6d-ce3f14c9050a@openssl.org> I have now updated the release strategy page with the agreed plan for the 1.1.1 release: https://www.openssl.org/policies/releasestrat.html I'd like to draw everyone's attention to the key date of 13th March 2018. Which is when we do the feature freeze. In practice we typically freeze the repo 24 hours before a release - so this really means you have until sometime on 12th March to get your features in. From that point on we will create the OpenSSL_1_1_1-stable branch and will only allow bug fixes onto it. I'd also like to point out that our first alpha release will be *next Tuesday*! Matt From matt at openssl.org Tue Feb 6 15:38:55 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 6 Feb 2018 15:38:55 +0000 Subject: [openssl-project] TLSv1.3 Message-ID: Now that the TLSv1.3 implementation is quite stable - should we switch it on by default? Matt From rsalz at akamai.com Tue Feb 6 15:39:59 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 6 Feb 2018 15:39:59 +0000 Subject: [openssl-project] TLSv1.3 In-Reply-To: References: Message-ID: <300904BD-70B2-40B6-B13D-92ACC5B760D9@akamai.com> YES On 2/6/18, 10:39 AM, "Matt Caswell" wrote: Now that the TLSv1.3 implementation is quite stable - should we switch it on by default? Matt _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project From openssl-users at dukhovni.org Tue Feb 6 15:55:49 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 6 Feb 2018 10:55:49 -0500 Subject: [openssl-project] crypto/bn/asm/x86/ gone, but still used by crypto/bn/asm/x86.pl? Message-ID: <6F937438-6A23-462C-B713-89FBDBDED865@dukhovni.org> In master and OpenSSL_1_1_0-stable we have: commit df8c39d52256c2e5327a636928b6d1ed05f695a2 Author: Rich Salz Date: Tue Sep 30 17:30:19 2014 -0400 RT3549: Remove obsolete files in crypto Reviewed-by: Andy Polyakov crypto/bn/asm/x86/add.pl | 76 ------ crypto/bn/asm/x86/comba.pl | 277 -------------------- crypto/bn/asm/x86/div.pl | 15 -- crypto/bn/asm/x86/f | 3 - crypto/bn/asm/x86/mul.pl | 77 ------ crypto/bn/asm/x86/mul_add.pl | 87 ------- crypto/bn/asm/x86/sqr.pl | 60 ----- crypto/bn/asm/x86/sub.pl | 76 ------ 36 files changed, 5815 deletions(-) All the crypto/bn/asm/x86/*.pl are deleted, but they are still required by: $ head -n18 crypto/bn/asm/x86.pl #! /usr/bin/env perl # ... copyright ... push(@INC,"perlasm","../../perlasm"); require "x86asm.pl"; require("x86/mul_add.pl"); require("x86/mul.pl"); require("x86/sqr.pl"); require("x86/div.pl"); require("x86/add.pl"); require("x86/sub.pl"); require("x86/comba.pl"); Is that file obsolete also? Is there no need for asm support for "bn" on x86? -- Viktor. From appro at openssl.org Tue Feb 6 18:36:40 2018 From: appro at openssl.org (Andy Polyakov) Date: Tue, 6 Feb 2018 19:36:40 +0100 Subject: [openssl-project] crypto/bn/asm/x86/ gone, but still used by crypto/bn/asm/x86.pl? In-Reply-To: <6F937438-6A23-462C-B713-89FBDBDED865@dukhovni.org> References: <6F937438-6A23-462C-B713-89FBDBDED865@dukhovni.org> Message-ID: <56d644f0-6c88-bea2-3ab7-de00a56e1d6c@openssl.org> > In master and OpenSSL_1_1_0-stable we have: > > commit df8c39d52256c2e5327a636928b6d1ed05f695a2 > Author: Rich Salz > Date: Tue Sep 30 17:30:19 2014 -0400 > > RT3549: Remove obsolete files in crypto > > Reviewed-by: Andy Polyakov > > crypto/bn/asm/x86/add.pl | 76 ------ > crypto/bn/asm/x86/comba.pl | 277 -------------------- > crypto/bn/asm/x86/div.pl | 15 -- > crypto/bn/asm/x86/f | 3 - > crypto/bn/asm/x86/mul.pl | 77 ------ > crypto/bn/asm/x86/mul_add.pl | 87 ------- > crypto/bn/asm/x86/sqr.pl | 60 ----- > crypto/bn/asm/x86/sub.pl | 76 ------ > 36 files changed, 5815 deletions(-) > > All the crypto/bn/asm/x86/*.pl are deleted, but they are still > required by: > > $ head -n18 crypto/bn/asm/x86.pl > #! /usr/bin/env perl > # ... copyright ... > > push(@INC,"perlasm","../../perlasm"); > require "x86asm.pl"; > > require("x86/mul_add.pl"); > require("x86/mul.pl"); > require("x86/sqr.pl"); > require("x86/div.pl"); > require("x86/add.pl"); > require("x86/sub.pl"); > require("x86/comba.pl"); > > Is that file obsolete also? Looks like it. > Is there no need for asm support for "bn" > on x86? There are bn-586, co-586 and x86-mont modules. Those are currently used. From rsalz at akamai.com Tue Feb 6 18:44:42 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 6 Feb 2018 18:44:42 +0000 Subject: [openssl-project] crypto/bn/asm/x86/ gone, but still used by crypto/bn/asm/x86.pl? In-Reply-To: <56d644f0-6c88-bea2-3ab7-de00a56e1d6c@openssl.org> References: <6F937438-6A23-462C-B713-89FBDBDED865@dukhovni.org> <56d644f0-6c88-bea2-3ab7-de00a56e1d6c@openssl.org> Message-ID: <097481CE-3534-4425-B562-13ABD4DC09A5@akamai.com> https://github.com/openssl/openssl/pull/5267 On 2/6/18, 1:36 PM, "Andy Polyakov" wrote: > In master and OpenSSL_1_1_0-stable we have: > > commit df8c39d52256c2e5327a636928b6d1ed05f695a2 > Author: Rich Salz > Date: Tue Sep 30 17:30:19 2014 -0400 > > RT3549: Remove obsolete files in crypto > > Reviewed-by: Andy Polyakov > > crypto/bn/asm/x86/add.pl | 76 ------ > crypto/bn/asm/x86/comba.pl | 277 -------------------- > crypto/bn/asm/x86/div.pl | 15 -- > crypto/bn/asm/x86/f | 3 - > crypto/bn/asm/x86/mul.pl | 77 ------ > crypto/bn/asm/x86/mul_add.pl | 87 ------- > crypto/bn/asm/x86/sqr.pl | 60 ----- > crypto/bn/asm/x86/sub.pl | 76 ------ > 36 files changed, 5815 deletions(-) > > All the crypto/bn/asm/x86/*.pl are deleted, but they are still > required by: > > $ head -n18 crypto/bn/asm/x86.pl > #! /usr/bin/env perl > # ... copyright ... > > push(@INC,"perlasm","../../perlasm"); > require "x86asm.pl"; > > require("x86/mul_add.pl"); > require("x86/mul.pl"); > require("x86/sqr.pl"); > require("x86/div.pl"); > require("x86/add.pl"); > require("x86/sub.pl"); > require("x86/comba.pl"); > > Is that file obsolete also? Looks like it. > Is there no need for asm support for "bn" > on x86? There are bn-586, co-586 and x86-mont modules. Those are currently used. _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project From rsalz at akamai.com Thu Feb 8 19:27:46 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 8 Feb 2018 19:27:46 +0000 Subject: [openssl-project] FW: [vendor-meetings] Invitation to the 2018 CERT Vendor Meeting [INFO#384036] Message-ID: <4B5BAFEE-B31F-47B5-AC84-70A5E14C7522@akamai.com> IN case anyone is going to be in the area. On 2/8/18, 2:26 PM, "Art Manion" wrote: The CERT Coordination Center invites you to attend the 2018 CERT Vendor Meeting. The meeting will be held on Monday April 16, 2018, at the Westin St. Francis in San Francisco, CA, US. Meeting time will be 9 AM to 5 PM, lunch and snacks will be provided. There is no cost to attend. This year we will be holding a morning-only introductory vulnerability response capability building course. Anyone attending the morning course is welcome to attend the meeting in the afternoon. Both the course and meeting will run concurrently in the morning. This year we are focusing the meeting on two not-unrelated topics: 1. Supply chain transparency and component relationships How to vendors identify and track upstream components, and vulnerabilities in those components? How do vendors inform downstream users? How do defenders maintain accurate inventories of components and vulnerabilities? 2. Radically new ways to do multi-party coordinated vulnerability disclosure How does the hub-and-spoke coordination model perform at increasing scale (both frequency and number of parties)? What alternatives exist? What trade-offs are vendors and other stakeholders willing to make? The CERT/CC plans to introduce and frame both topics. We welcome questions and discussion on this list, and also offers to speak on either topic. We ask that teams initially limit attendance at two people; we'll raise this limit depending on the response and available seating. Seats are first come first served. To register, please visit: Questions and discussion topics can be sent to . Regards, - Art -- Art Manion -- CERT Coordination Center +1 412-268-5800 11CD AEFD A187 0946 BA68 5C01 536D E2E4 D1BB 6ADF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: signature.asc URL: From matt at openssl.org Fri Feb 9 10:15:56 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 9 Feb 2018 10:15:56 +0000 Subject: [openssl-project] OS/X builds failing Message-ID: The new travis OS/X builds are failing with this: -MT apps/enc.o -c -o apps/enc.o apps/enc.c apps/enc.c:567:54: error: format specifies type 'uintmax_t' (aka 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] BIO_printf(bio_err, "bytes read : %8ju\n", BIO_number_read(in)); ~~~~ ^~~~~~~~~~~~~~~~~~~ %8llu apps/enc.c:568:54: error: format specifies type 'uintmax_t' (aka 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] BIO_printf(bio_err, "bytes written: %8ju\n", BIO_number_written(out)); ~~~~ ^~~~~~~~~~~~~~~~~~~~~~~ %8llu 2 errors generated. The thing is though this is *our* BIO_printf, and we do seem to expect a uint64_t for a "%ju". So I'm not sure how to fix that. Matt From appro at openssl.org Fri Feb 9 11:02:48 2018 From: appro at openssl.org (Andy Polyakov) Date: Fri, 9 Feb 2018 12:02:48 +0100 Subject: [openssl-project] OS/X builds failing In-Reply-To: References: Message-ID: <891d1cc1-0635-d303-634e-f674dd9f9a64@openssl.org> > apps/enc.c:568:54: error: format specifies type 'uintmax_t' (aka > 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned > long long') [-Werror,-Wformat] > BIO_printf(bio_err, "bytes written: %8ju\n", > BIO_number_written(out)); > ~~~~ ^~~~~~~~~~~~~~~~~~~~~~~ > %8llu > 2 errors generated. > > > The thing is though this is *our* BIO_printf, and we do seem to expect a > uint64_t for a "%ju". So I'm not sure how to fix that. I'd suggest -Wno-format. With rationale that a) Xcode is arguably somewhat unreasonable, b) we can rely on Linux builds to catch warnings that actually matter. From appro at openssl.org Fri Feb 9 11:24:13 2018 From: appro at openssl.org (Andy Polyakov) Date: Fri, 9 Feb 2018 12:24:13 +0100 Subject: [openssl-project] OS/X builds failing In-Reply-To: <891d1cc1-0635-d303-634e-f674dd9f9a64@openssl.org> References: <891d1cc1-0635-d303-634e-f674dd9f9a64@openssl.org> Message-ID: <219b8f20-c67f-93ec-ca01-9da98d474ca1@openssl.org> >> apps/enc.c:568:54: error: format specifies type 'uintmax_t' (aka >> 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned >> long long') [-Werror,-Wformat] >> BIO_printf(bio_err, "bytes written: %8ju\n", >> BIO_number_written(out)); >> ~~~~ ^~~~~~~~~~~~~~~~~~~~~~~ >> %8llu >> 2 errors generated. >> >> >> The thing is though this is *our* BIO_printf, and we do seem to expect a >> uint64_t for a "%ju". So I'm not sure how to fix that. > > I'd suggest -Wno-format. With rationale that a) Xcode is arguably > somewhat unreasonable, b) we can rely on Linux builds to catch warnings > that actually matter. Another possibility *could* be suppressing corresponding __attribute__ in bio.h, but it's public header, so question would be if change can be justified in minor release. Just in case, suppress specifically for Xcode [which would cover even iOS]. From rsalz at akamai.com Fri Feb 9 13:47:09 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 9 Feb 2018 13:47:09 +0000 Subject: [openssl-project] Draft Travel Reimbursement policy Message-ID: <7D14B585-5A72-4745-94AA-9C39FE360EA9@akamai.com> Any commentary on this? Otherwise I?ll do a (two-week) vote next week. From: Rich Salz Reply-To: "openssl-project at openssl.org" Date: Monday, January 29, 2018 at 11:18 AM To: "openssl-project at openssl.org" Subject: [openssl-project] Draft Travel Reimbursement policy At the London F2F I had the action item to draft a travel reimbursement policy. Here?s a starting point. After discussion dies down I?ll post it to the bureau and vote. The OpenSSL project may pay travel expenses for OMC members when pre-approved by the OMC or when it is an official OMC meeting (as determined by vote). Project members may seek to be reimbursed if their employer is not covering the expense. The requirements for reimbursement are: * An email sent to openssl-omc, including scanned attachments of all receipts over 30 Euro?s. * Barring exceptional circumstances, for an all-day meeting the project will pay for arrival the day before and departure the following morning. * When presenting at a conference, the project will pay the expenses for the entire conference provided the attendee agrees to act as representative of the project during that time. * Reasonable lodging and meal expenses during the travel time will be covered. * Barring exceptional circumstances, room service, minibar, in-room movies, and other similar amenities are not covered. -------------- next part -------------- An HTML attachment was scrubbed... URL: From appro at openssl.org Fri Feb 9 13:54:25 2018 From: appro at openssl.org (Andy Polyakov) Date: Fri, 9 Feb 2018 14:54:25 +0100 Subject: [openssl-project] OS/X builds failing In-Reply-To: <219b8f20-c67f-93ec-ca01-9da98d474ca1@openssl.org> References: <891d1cc1-0635-d303-634e-f674dd9f9a64@openssl.org> <219b8f20-c67f-93ec-ca01-9da98d474ca1@openssl.org> Message-ID: <9f8afe29-c327-fdbf-4690-5afb1aebe5cc@openssl.org> For the record. I don't generally appreciate fast commits, but I feel like 100 times stronger when it comes to public headers [naturally in supported or minor release] and I can't qualify 19 minutes turnaround for merge request as appropriate. From openssl-users at dukhovni.org Fri Feb 9 16:03:40 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 9 Feb 2018 11:03:40 -0500 Subject: [openssl-project] OS/X builds failing In-Reply-To: References: Message-ID: > On Feb 9, 2018, at 5:15 AM, Matt Caswell wrote: > > The new travis OS/X builds are failing with this: > > -MT apps/enc.o -c -o apps/enc.o apps/enc.c > apps/enc.c:567:54: error: format specifies type 'uintmax_t' (aka > 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned > long long') [-Werror,-Wformat] > BIO_printf(bio_err, "bytes read : %8ju\n", BIO_number_read(in)); > ~~~~ ^~~~~~~~~~~~~~~~~~~ > %8llu > apps/enc.c:568:54: error: format specifies type 'uintmax_t' (aka > 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned > long long') [-Werror,-Wformat] > BIO_printf(bio_err, "bytes written: %8ju\n", > BIO_number_written(out)); > ~~~~ ^~~~~~~~~~~~~~~~~~~~~~~ > %8llu > 2 errors generated. > > > The thing is though this is *our* BIO_printf, and we do seem to expect a > uint64_t for a "%ju". So I'm not sure how to fix that. The obvious and correct fix is to cast the output of BIO_number_read() and BIO_number_written() to uintmax_t. And we should expect uintmax_t with %j, even in our BIO_printf(). It happens to be 64-bit on all the platforms we support perhaps (any Crays?), but that's just a coincidence. -- Viktor. From levitte at openssl.org Fri Feb 9 16:23:53 2018 From: levitte at openssl.org (Richard Levitte) Date: Fri, 09 Feb 2018 17:23:53 +0100 (CET) Subject: [openssl-project] OS/X builds failing In-Reply-To: References: Message-ID: <20180209.172353.1978950592850119243.levitte@openssl.org> In message on Fri, 9 Feb 2018 11:03:40 -0500, Viktor Dukhovni said: openssl-users> openssl-users> openssl-users> > On Feb 9, 2018, at 5:15 AM, Matt Caswell wrote: openssl-users> > openssl-users> > The new travis OS/X builds are failing with this: openssl-users> > openssl-users> > -MT apps/enc.o -c -o apps/enc.o apps/enc.c openssl-users> > apps/enc.c:567:54: error: format specifies type 'uintmax_t' (aka openssl-users> > 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned openssl-users> > long long') [-Werror,-Wformat] openssl-users> > BIO_printf(bio_err, "bytes read : %8ju\n", BIO_number_read(in)); openssl-users> > ~~~~ ^~~~~~~~~~~~~~~~~~~ openssl-users> > %8llu openssl-users> > apps/enc.c:568:54: error: format specifies type 'uintmax_t' (aka openssl-users> > 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned openssl-users> > long long') [-Werror,-Wformat] openssl-users> > BIO_printf(bio_err, "bytes written: %8ju\n", openssl-users> > BIO_number_written(out)); openssl-users> > ~~~~ ^~~~~~~~~~~~~~~~~~~~~~~ openssl-users> > %8llu openssl-users> > 2 errors generated. openssl-users> > openssl-users> > openssl-users> > The thing is though this is *our* BIO_printf, and we do seem to expect a openssl-users> > uint64_t for a "%ju". So I'm not sure how to fix that. openssl-users> openssl-users> The obvious and correct fix is to cast the output of BIO_number_read() and openssl-users> BIO_number_written() to uintmax_t. And we should expect uintmax_t with %j, openssl-users> even in our BIO_printf(). It happens to be 64-bit on all the platforms we openssl-users> support perhaps (any Crays?), but that's just a coincidence. >From those errors, it looks to me like uintmax_t isn't 64-bit on that Mac OS/X machine, unless 'unsigned long' and 'unsigned long long' are the same. (that error does surprise me, since uintmax_t is supposed to be the largest integer type possible, and yet, the error suggests that this isn't the case here) Cheers, Richard ( or do I misunderstand something here? ) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Fri Feb 9 16:36:07 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 9 Feb 2018 11:36:07 -0500 Subject: [openssl-project] OS/X builds failing In-Reply-To: <20180209.172353.1978950592850119243.levitte@openssl.org> References: <20180209.172353.1978950592850119243.levitte@openssl.org> Message-ID: <511748BD-B4A4-45DA-A9C1-9D0052D7EEFA@dukhovni.org> > On Feb 9, 2018, at 11:23 AM, Richard Levitte wrote: > > From those errors, it looks to me like uintmax_t isn't 64-bit on that > Mac OS/X machine, unless 'unsigned long' and 'unsigned long long' are > the same. No, the compiler is not telling you they're not actually the same, rather it is telling you that their definitions are independent, and they *could* be different, and so the code is not portable. > (that error does surprise me, since uintmax_t is supposed to be the > largest integer type possible, and yet, the error suggests that this > isn't the case here) See above. Compiling the below on the latest MacOS/X: $ cat size.c #include #include int main(int argc, char **argv) { printf("char = %zu\n", sizeof(unsigned char)); printf("short = %zu\n", sizeof(unsigned short)); printf("int = %zu\n", sizeof(unsigned int)); printf("long = %zu\n", sizeof(unsigned long int)); printf("long long = %zu\n", sizeof(unsigned long long int)); printf("int8_t = %zu\n", sizeof(uint8_t)); printf("int16_t = %zu\n", sizeof(uint16_t)); printf("int32_t = %zu\n", sizeof(uint32_t)); printf("int64_t = %zu\n", sizeof(uint64_t)); printf("intmax_t = %zu\n", sizeof(uintmax_t)); return 0; } shows that long, long long, int64_t and intmax_t are presently all the same: $ ./size char = 1 short = 2 int = 4 long = 8 long long = 8 int8_t = 1 int16_t = 2 int32_t = 4 int64_t = 8 intmax_t = 8 -- Viktor. From openssl-users at dukhovni.org Fri Feb 9 16:52:48 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 9 Feb 2018 11:52:48 -0500 Subject: [openssl-project] OS/X builds failing In-Reply-To: <511748BD-B4A4-45DA-A9C1-9D0052D7EEFA@dukhovni.org> References: <20180209.172353.1978950592850119243.levitte@openssl.org> <511748BD-B4A4-45DA-A9C1-9D0052D7EEFA@dukhovni.org> Message-ID: <63F0F652-E94B-4B43-9CAD-A50C8B39166C@dukhovni.org> > On Feb 9, 2018, at 11:36 AM, Viktor Dukhovni wrote: > > $ cat size.c > #include > #include > > int main(int argc, char **argv) > { > printf("char = %zu\n", sizeof(unsigned char)); > printf("short = %zu\n", sizeof(unsigned short)); > printf("int = %zu\n", sizeof(unsigned int)); > printf("long = %zu\n", sizeof(unsigned long int)); > printf("long long = %zu\n", sizeof(unsigned long long int)); > > printf("int8_t = %zu\n", sizeof(uint8_t)); > printf("int16_t = %zu\n", sizeof(uint16_t)); > printf("int32_t = %zu\n", sizeof(uint32_t)); > printf("int64_t = %zu\n", sizeof(uint64_t)); > printf("intmax_t = %zu\n", sizeof(uintmax_t)); > return 0; > } > > shows that long, long long, int64_t and intmax_t are presently all the same. And throwing an extra line with a cast, yields the expected warning: $ cc -o size size.c size.c:18:36: warning: format specifies type 'uintmax_t' (aka 'unsigned long') but the argument has type 'unsigned long long' [-Wformat] printf("intmax_t = %ju\n", (unsigned long long)sizeof(uintmax_t)); ~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ %llu 1 warning generated. Interestingly casting to "unsigned long" instead of "unsigned long long" does not result in a warning. The warning is about the underlying C type, and expands typedefs. So it is a bit annoying that typedefs that might change are not a problem, but "long long" vs. "long" is even though they are actually the same underlying data type. Still, we're wrong to use int64_t values with "%j" formats. All format arguments to "%j" need to be "intmax_t". -- Viktor. From kurt at roeckx.be Fri Feb 9 17:39:39 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 9 Feb 2018 18:39:39 +0100 Subject: [openssl-project] OS/X builds failing In-Reply-To: <63F0F652-E94B-4B43-9CAD-A50C8B39166C@dukhovni.org> References: <20180209.172353.1978950592850119243.levitte@openssl.org> <511748BD-B4A4-45DA-A9C1-9D0052D7EEFA@dukhovni.org> <63F0F652-E94B-4B43-9CAD-A50C8B39166C@dukhovni.org> Message-ID: <20180209173939.GA31539@roeckx.be> On Fri, Feb 09, 2018 at 11:52:48AM -0500, Viktor Dukhovni wrote: > > Still, we're wrong to use int64_t values with "%j" formats. All format > arguments to "%j" need to be "intmax_t". We document printf to be like the C standard, so it should be intmax_t, not int64_t, or we need to fix the documentation. Kurt From openssl-users at dukhovni.org Fri Feb 9 17:48:49 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 9 Feb 2018 12:48:49 -0500 Subject: [openssl-project] OS/X builds failing In-Reply-To: <20180209173939.GA31539@roeckx.be> References: <20180209.172353.1978950592850119243.levitte@openssl.org> <511748BD-B4A4-45DA-A9C1-9D0052D7EEFA@dukhovni.org> <63F0F652-E94B-4B43-9CAD-A50C8B39166C@dukhovni.org> <20180209173939.GA31539@roeckx.be> Message-ID: > On Feb 9, 2018, at 12:39 PM, Kurt Roeckx wrote: > > We document printf to be like the C standard, so it should be > intmax_t, not int64_t, or we need to fix the documentation. I don't think we get to co?pt "j" for another purpose, if we we want a letter format for int64t, we'll need to use a new one, but that's a bad idea. So I think the "or ..." part is not a good idea. Just cast to (intmax_t) or use OSSL_PRIi64/OSSL_PRIu64 (defined to PRIi64/PRIu64 where available or else to some appropriate letter for the platform in question). BIO_printf should handle the underlying primitive types when, e.g., encountering "%lu", "%llu", "%ju" and "%zu"... -- Viktor. From rsalz at akamai.com Sat Feb 10 21:08:05 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 10 Feb 2018 21:08:05 +0000 Subject: [openssl-project] Removing assembler for outdated algorithms Message-ID: <7DD1C2AC-6EC3-4AD2-A7C5-90192041828D@akamai.com> This is derived from bureau/libcrypto-proposal that Emilila made in November 2015. We should remove the assembler versions of the following Blowfish, cast, des, rc4, rc5, ripemd, whirlpool, md5 The reason is that they are outdated, not in use very much, and optimization is not important, compared to having a single reference source that we can maintain and debug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Sat Feb 10 21:27:42 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 10 Feb 2018 21:27:42 -0000 Subject: [openssl-project] should doc-nits flag long lines? In-Reply-To: <9065A29A-3E28-47CD-B8DD-EC83F761B6B9@akamai.com> References: <9065A29A-3E28-47CD-B8DD-EC83F761B6B9@akamai.com> Message-ID: I would say on the contrary, that long lines in code section should be flagged, because they aren't wrapped in the final output. For the rest, warning on long lines is still nice for the readability of the original file, but to my judgment, that's slightly less important than the code sections. Cheers Richard "Salz, Rich" skrev: (19 januari 2018 16:21:07 CET) >Maybe not within code displays? -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From levitte at openssl.org Sat Feb 10 21:27:44 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 10 Feb 2018 21:27:44 -0000 Subject: [openssl-project] Fwd: [openssl-commits] Broken: openssl/openssl#15676 (master - e44c7d0) In-Reply-To: <8a1f0baf-b0f8-7f5c-23a4-30ab8587b622@openssl.org> References: <5a60acdbd8d1d_43fb99c78e890102778@448662c1-6ee3-42b8-ba9e-5bdcfaab6bc7.mail> <71b90238-cb35-ee19-2b7b-59e1d5983769@openssl.org> <8a1f0baf-b0f8-7f5c-23a4-30ab8587b622@openssl.org> Message-ID: Matt Caswell skrev: (18 januari 2018 15:59:32 CET) > > >On 18/01/18 14:43, Matt Caswell wrote: >> ok/B1h/b96gGE1fnxPUU4dtr31EZGX0L2oHLwLxvjrsh+whkiviIH7aA4G1/7F35 >> >> ^^ >> Is the ok here confusing TAP? > > >A quick test proves to me that it does confuse it. The chances of 2 >characters of base64 at the beginning of a lines are "ok" (assuming >evenly distributed data) is about 1 in 4000. But the store test outputs >100s of lines of base64 so this will increase the odds significantly. > >Richard - any ideas? The TAP way is really to prefix non-TAP with # The interesting part is how to do that in a platform independent manner... > >Matt > >_______________________________________________ >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 Sat Feb 10 21:27:48 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 10 Feb 2018 21:27:48 -0000 Subject: [openssl-project] FW: [openssl-commits] Copyright warnings for refs/heads/master In-Reply-To: <3E3E04F3-2733-4447-BE60-B13C614396B2@akamai.com> References: <1515605053.939960.3500.nullmailer@dev.openssl.org> <3E3E04F3-2733-4447-BE60-B13C614396B2@akamai.com> Message-ID: Yeah. And it's wrong, I will soon correct the script "Salz, Rich" skrev: (10 januari 2018 18:36:23 CET) >This is too too funny. > >On 1/10/18, 12:24 PM, "openssl-git at dev.openssl.org" > wrote: > > The following files seem to need a copyright year update: > util/openssl-update-copyright > > >_______________________________________________ >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 tjh at openssl.org Sat Feb 10 21:29:32 2018 From: tjh at openssl.org (Tim Hudson) Date: Sun, 11 Feb 2018 07:29:32 +1000 Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: <7DD1C2AC-6EC3-4AD2-A7C5-90192041828D@akamai.com> References: <7DD1C2AC-6EC3-4AD2-A7C5-90192041828D@akamai.com> Message-ID: Before we look at removing things like this, I think we should look at whether or not they actually have a significant maintenance cost. Tim. On 11 Feb. 2018 7:08 am, "Salz, Rich" wrote: This is derived from bureau/libcrypto-proposal that Emilila made in November 2015. We should remove the assembler versions of the following Blowfish, cast, des, rc4, rc5, ripemd, whirlpool, md5 The reason is that they are outdated, not in use very much, and optimization is not important, compared to having a single reference source that we can maintain and debug. _______________________________________________ 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 viktor at dukhovni.org Sat Feb 10 21:58:36 2018 From: viktor at dukhovni.org (Viktor Dukhovni) Date: Sat, 10 Feb 2018 16:58:36 -0500 Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: <7DD1C2AC-6EC3-4AD2-A7C5-90192041828D@akamai.com> References: <7DD1C2AC-6EC3-4AD2-A7C5-90192041828D@akamai.com> Message-ID: <3EAC8B7F-EA48-465B-B4BE-3D5AC62D9A4C@dukhovni.org> > On Feb 10, 2018, at 4:08 PM, Salz, Rich wrote: > > This is derived from bureau/libcrypto-proposal that Emilila made in November 2015. > > We should remove the assembler versions of the following > Blowfish, cast, des, rc4, rc5, ripemd, whirlpool, md5 > > The reason is that they are outdated, not in use very much, and optimization is not important, compared to having a single reference source that we can maintain and debug. Is blowfish actually outdated? I thought it had some significant use, and don't recall any major weakness... -- Viktor. From rsalz at akamai.com Sat Feb 10 22:06:10 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 10 Feb 2018 22:06:10 +0000 Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: References: <7DD1C2AC-6EC3-4AD2-A7C5-90192041828D@akamai.com> Message-ID: <85D1F61C-9A8A-4DD1-9B55-A9F6A3BFA78E@akamai.com> There is a maintenance cost. Maybe it is negligible, but there is a cost. * The build rules are more complicated; we have had errors with .S vs .s files * There are more internal config parameters to understand * There are more ifdefs in the code * There?s only one person who really understands the perlasm stuff I think ?significant maintenance cost? is not the question to ask. It?s maintenance and risk versus use. From: "tjh at openssl.org" Reply-To: "openssl-project at openssl.org" Date: Saturday, February 10, 2018 at 4:29 PM To: "openssl-project at openssl.org" Subject: Re: [openssl-project] Removing assembler for outdated algorithms Before we look at removing things like this, I think we should look at whether or not they actually have a significant maintenance cost. Tim. On 11 Feb. 2018 7:08 am, "Salz, Rich" > wrote: This is derived from bureau/libcrypto-proposal that Emilila made in November 2015. We should remove the assembler versions of the following Blowfish, cast, des, rc4, rc5, ripemd, whirlpool, md5 The reason is that they are outdated, not in use very much, and optimization is not important, compared to having a single reference source that we can maintain and debug. _______________________________________________ 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 rsalz at akamai.com Sat Feb 10 22:10:12 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 10 Feb 2018 22:10:12 +0000 Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: <85D1F61C-9A8A-4DD1-9B55-A9F6A3BFA78E@akamai.com> References: <7DD1C2AC-6EC3-4AD2-A7C5-90192041828D@akamai.com> <85D1F61C-9A8A-4DD1-9B55-A9F6A3BFA78E@akamai.com> Message-ID: Look at https://github.com/openssl/openssl/pull/5320 to get an example. It?s about safety and maintainability. From: Rich Salz Reply-To: "openssl-project at openssl.org" Date: Saturday, February 10, 2018 at 5:06 PM To: "openssl-project at openssl.org" Subject: Re: [openssl-project] Removing assembler for outdated algorithms There is a maintenance cost. Maybe it is negligible, but there is a cost. * The build rules are more complicated; we have had errors with .S vs .s files * There are more internal config parameters to understand * There are more ifdefs in the code * There?s only one person who really understands the perlasm stuff I think ?significant maintenance cost? is not the question to ask. It?s maintenance and risk versus use. From: "tjh at openssl.org" Reply-To: "openssl-project at openssl.org" Date: Saturday, February 10, 2018 at 4:29 PM To: "openssl-project at openssl.org" Subject: Re: [openssl-project] Removing assembler for outdated algorithms Before we look at removing things like this, I think we should look at whether or not they actually have a significant maintenance cost. Tim. On 11 Feb. 2018 7:08 am, "Salz, Rich" > wrote: This is derived from bureau/libcrypto-proposal that Emilila made in November 2015. We should remove the assembler versions of the following Blowfish, cast, des, rc4, rc5, ripemd, whirlpool, md5 The reason is that they are outdated, not in use very much, and optimization is not important, compared to having a single reference source that we can maintain and debug. _______________________________________________ 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 viktor at dukhovni.org Sat Feb 10 22:10:42 2018 From: viktor at dukhovni.org (Viktor Dukhovni) Date: Sat, 10 Feb 2018 17:10:42 -0500 Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: <3EAC8B7F-EA48-465B-B4BE-3D5AC62D9A4C@dukhovni.org> References: <7DD1C2AC-6EC3-4AD2-A7C5-90192041828D@akamai.com> <3EAC8B7F-EA48-465B-B4BE-3D5AC62D9A4C@dukhovni.org> Message-ID: <0EA60701-6E1A-4FE0-86F8-33B37D01612E@dukhovni.org> > On Feb 10, 2018, at 4:58 PM, Viktor Dukhovni wrote: > > > Is blowfish actually outdated? I thought it had some significant use, > and don't recall any major weakness... In particular, IIRC OpenSSH uses blowfish, and links to OpenSSL for the underlying cipher... -- Viktor. From rsalz at akamai.com Sat Feb 10 22:19:20 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 10 Feb 2018 22:19:20 +0000 Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: <0EA60701-6E1A-4FE0-86F8-33B37D01612E@dukhovni.org> References: <7DD1C2AC-6EC3-4AD2-A7C5-90192041828D@akamai.com> <3EAC8B7F-EA48-465B-B4BE-3D5AC62D9A4C@dukhovni.org> <0EA60701-6E1A-4FE0-86F8-33B37D01612E@dukhovni.org> Message-ID: <87431112-FE0D-4C50-9FD6-BDF38E502917@akamai.com> > Is blowfish actually outdated? I thought it had some significant use, > and don't recall any major weakness... In particular, IIRC OpenSSH uses blowfish, and links to OpenSSL for the underlying cipher... PGP use to be a heavy user, but now it only decrypts or does key-wrapping for compatibility; it no longer uses blowfish to encrypt data. SSH uses it, but according to https://bbs.archlinux.org/viewtopic.php?id=188613 it has been removed, circa 2014. Schneier recommends not using it, and use its successor(s) instead, which we don't implement. From viktor at dukhovni.org Sat Feb 10 22:32:53 2018 From: viktor at dukhovni.org (Viktor Dukhovni) Date: Sat, 10 Feb 2018 22:32:53 +0000 Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: <87431112-FE0D-4C50-9FD6-BDF38E502917@akamai.com> References: <7DD1C2AC-6EC3-4AD2-A7C5-90192041828D@akamai.com> <3EAC8B7F-EA48-465B-B4BE-3D5AC62D9A4C@dukhovni.org> <0EA60701-6E1A-4FE0-86F8-33B37D01612E@dukhovni.org> <87431112-FE0D-4C50-9FD6-BDF38E502917@akamai.com> Message-ID: <20180210223253.GR3322@mournblade.imrryr.org> On Sat, Feb 10, 2018 at 10:19:20PM +0000, Salz, Rich wrote: > > Is blowfish actually outdated? I thought it had some significant use, > > and don't recall any major weakness... > > In particular, IIRC OpenSSH uses blowfish, and links to OpenSSL for > the underlying cipher... > > PGP use to be a heavy user, but now it only decrypts or does key-wrapping for compatibility; it no longer uses blowfish to encrypt data. > > SSH uses it, but according to https://bbs.archlinux.org/viewtopic.php?id=188613 it has been removed, circa 2014. > Schneier recommends not using it, and use its successor(s) instead, which we don't implement. Removed in 2014 is much too recent, there are still LTS systems with older SSH versions, and modern platforms that may want to interoperate. So I'm very reluctant to support removal of blowfish ASM at this time... -- Viktor. From rsalz at akamai.com Sat Feb 10 22:40:24 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 10 Feb 2018 22:40:24 +0000 Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: <20180210223253.GR3322@mournblade.imrryr.org> References: <7DD1C2AC-6EC3-4AD2-A7C5-90192041828D@akamai.com> <3EAC8B7F-EA48-465B-B4BE-3D5AC62D9A4C@dukhovni.org> <0EA60701-6E1A-4FE0-86F8-33B37D01612E@dukhovni.org> <87431112-FE0D-4C50-9FD6-BDF38E502917@akamai.com> <20180210223253.GR3322@mournblade.imrryr.org> Message-ID: I am not suggesting we remove blowfish or any of those algorithms. I am suggesting we remove the assembler versions of them. ?On 2/10/18, 5:33 PM, "Viktor Dukhovni" wrote: On Sat, Feb 10, 2018 at 10:19:20PM +0000, Salz, Rich wrote: > > Is blowfish actually outdated? I thought it had some significant use, > > and don't recall any major weakness... > > In particular, IIRC OpenSSH uses blowfish, and links to OpenSSL for > the underlying cipher... > > PGP use to be a heavy user, but now it only decrypts or does key-wrapping for compatibility; it no longer uses blowfish to encrypt data. > > SSH uses it, but according to https://bbs.archlinux.org/viewtopic.php?id=188613 it has been removed, circa 2014. > Schneier recommends not using it, and use its successor(s) instead, which we don't implement. Removed in 2014 is much too recent, there are still LTS systems with older SSH versions, and modern platforms that may want to interoperate. So I'm very reluctant to support removal of blowfish ASM at this time... -- Viktor. _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project From levitte at openssl.org Sun Feb 11 06:57:57 2018 From: levitte at openssl.org (Richard Levitte) Date: Sun, 11 Feb 2018 07:57:57 +0100 (CET) Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: <3EAC8B7F-EA48-465B-B4BE-3D5AC62D9A4C@dukhovni.org> References: <7DD1C2AC-6EC3-4AD2-A7C5-90192041828D@akamai.com> <3EAC8B7F-EA48-465B-B4BE-3D5AC62D9A4C@dukhovni.org> Message-ID: <20180211.075757.565172294498023571.levitte@openssl.org> In message <3EAC8B7F-EA48-465B-B4BE-3D5AC62D9A4C at dukhovni.org> on Sat, 10 Feb 2018 16:58:36 -0500, Viktor Dukhovni said: viktor> viktor> viktor> > On Feb 10, 2018, at 4:08 PM, Salz, Rich wrote: viktor> > viktor> > This is derived from bureau/libcrypto-proposal that Emilila made in November 2015. viktor> > viktor> > We should remove the assembler versions of the following viktor> > Blowfish, cast, des, rc4, rc5, ripemd, whirlpool, md5 viktor> > viktor> > The reason is that they are outdated, not in use very much, and optimization is not important, compared to having a single reference source that we can maintain and debug. viktor> viktor> Is blowfish actually outdated? I thought it had some significant use, viktor> and don't recall any major weakness... For what it's worth, https://en.wikipedia.org/wiki/Blowfish_(cipher) mentions some weaknesses, and also that the author recommends moving away from Blowfish (use Twofish instead, but we haven't implemented that) Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sun Feb 11 07:18:15 2018 From: levitte at openssl.org (Richard Levitte) Date: Sun, 11 Feb 2018 08:18:15 +0100 (CET) Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: <0EA60701-6E1A-4FE0-86F8-33B37D01612E@dukhovni.org> References: <7DD1C2AC-6EC3-4AD2-A7C5-90192041828D@akamai.com> <3EAC8B7F-EA48-465B-B4BE-3D5AC62D9A4C@dukhovni.org> <0EA60701-6E1A-4FE0-86F8-33B37D01612E@dukhovni.org> Message-ID: <20180211.081815.1379561613075973737.levitte@openssl.org> In message <0EA60701-6E1A-4FE0-86F8-33B37D01612E at dukhovni.org> on Sat, 10 Feb 2018 17:10:42 -0500, Viktor Dukhovni said: viktor> viktor> viktor> > On Feb 10, 2018, at 4:58 PM, Viktor Dukhovni wrote: viktor> > viktor> > viktor> > Is blowfish actually outdated? I thought it had some significant use, viktor> > and don't recall any major weakness... viktor> viktor> In particular, IIRC OpenSSH uses blowfish, and links to OpenSSL for viktor> the underlying cipher... OpenSSH disabled blowfish-cbc (all cbc ciphers, as a matter of fact) two years ago, and removed it (them) entirely last autumn. So one can say that even in the OpenSSH world, blowfish support has decreased. Ref: http://www.openssh.com/releasenotes.html Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Sun Feb 11 07:20:30 2018 From: levitte at openssl.org (Richard Levitte) Date: Sun, 11 Feb 2018 08:20:30 +0100 (CET) Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: <20180210223253.GR3322@mournblade.imrryr.org> References: <0EA60701-6E1A-4FE0-86F8-33B37D01612E@dukhovni.org> <87431112-FE0D-4C50-9FD6-BDF38E502917@akamai.com> <20180210223253.GR3322@mournblade.imrryr.org> Message-ID: <20180211.082030.1623349319332151243.levitte@openssl.org> In message <20180210223253.GR3322 at mournblade.imrryr.org> on Sat, 10 Feb 2018 22:32:53 +0000, Viktor Dukhovni said: viktor> On Sat, Feb 10, 2018 at 10:19:20PM +0000, Salz, Rich wrote: viktor> viktor> > > Is blowfish actually outdated? I thought it had some significant use, viktor> > > and don't recall any major weakness... viktor> > viktor> > In particular, IIRC OpenSSH uses blowfish, and links to OpenSSL for viktor> > the underlying cipher... viktor> > viktor> > PGP use to be a heavy user, but now it only decrypts or does key-wrapping for compatibility; it no longer uses blowfish to encrypt data. viktor> > viktor> > SSH uses it, but according to https://bbs.archlinux.org/viewtopic.php?id=188613 it has been removed, circa 2014. viktor> > Schneier recommends not using it, and use its successor(s) instead, which we don't implement. viktor> viktor> Removed in 2014 is much too recent, there are still LTS systems viktor> with older SSH versions, and modern platforms that may want to viktor> interoperate. So I'm very reluctant to support removal of blowfish viktor> ASM at this time... Those same systems will probably not have the newest OpenSSL either, and OpenSSH on those machines will certainly not be linked with a newer OpenSSL... Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Sun Feb 11 13:07:13 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 11 Feb 2018 13:07:13 +0000 Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: <20180211.082030.1623349319332151243.levitte@openssl.org> References: <0EA60701-6E1A-4FE0-86F8-33B37D01612E@dukhovni.org> <87431112-FE0D-4C50-9FD6-BDF38E502917@akamai.com> <20180210223253.GR3322@mournblade.imrryr.org> <20180211.082030.1623349319332151243.levitte@openssl.org> Message-ID: > Those same systems will probably not have the newest OpenSSL either, and OpenSSH on those machines will certainly not be linked with a newer OpenSSL... I apologize for not being clear enough. I do not want to remove any of those algorithms. I just want to remove 10,000 lines of assembler version and just have the C code. I want to do that for safety and maintainability and because they do not justify the burden -- ON US -- to keep hand-tuned assembler that only one, maybe two, people understand. From openssl-users at dukhovni.org Sun Feb 11 17:51:02 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 11 Feb 2018 12:51:02 -0500 Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: <20180211.082030.1623349319332151243.levitte@openssl.org> References: <0EA60701-6E1A-4FE0-86F8-33B37D01612E@dukhovni.org> <87431112-FE0D-4C50-9FD6-BDF38E502917@akamai.com> <20180210223253.GR3322@mournblade.imrryr.org> <20180211.082030.1623349319332151243.levitte@openssl.org> Message-ID: <97DD7AD0-6994-48D0-BD92-9799A2991C17@dukhovni.org> > On Feb 11, 2018, at 2:20 AM, Richard Levitte wrote: > > Those same systems will probably not have the newest OpenSSL either, > and OpenSSH on those machines will certainly not be linked with a > newer OpenSSL... It is not those systems, but other systems that need to communicate with them (various "appliances" that may not see an SSH implementation update in years) that may need ongoing blowfish support. So we should tread with some care. Perhaps the software-only Blowfish is fast enough, but my point is that Blowfish is much less of an obvious outdated cipher than the others... -- -- Viktor. From rsalz at akamai.com Sun Feb 11 17:57:49 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 11 Feb 2018 17:57:49 +0000 Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: <97DD7AD0-6994-48D0-BD92-9799A2991C17@dukhovni.org> References: <0EA60701-6E1A-4FE0-86F8-33B37D01612E@dukhovni.org> <87431112-FE0D-4C50-9FD6-BDF38E502917@akamai.com> <20180210223253.GR3322@mournblade.imrryr.org> <20180211.082030.1623349319332151243.levitte@openssl.org> <97DD7AD0-6994-48D0-BD92-9799A2991C17@dukhovni.org> Message-ID: > So we should tread with some care. Perhaps the software-only Blowfish is fast enough, but my point is that Blowfish is much less of an obvious outdated cipher than the others... That's a different point. I still don't agree. The difference between hand-tuned assembler and C for Blowfish... enh. From levitte at openssl.org Sun Feb 11 19:25:10 2018 From: levitte at openssl.org (Richard Levitte) Date: Sun, 11 Feb 2018 20:25:10 +0100 Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: References: <0EA60701-6E1A-4FE0-86F8-33B37D01612E@dukhovni.org> <87431112-FE0D-4C50-9FD6-BDF38E502917@akamai.com> <20180210223253.GR3322@mournblade.imrryr.org> <20180211.082030.1623349319332151243.levitte@openssl.org> Message-ID: "Salz, Rich" skrev: (11 februari 2018 14:07:13 CET) >> Those same systems will probably not have the newest OpenSSL >either, > and OpenSSH on those machines will certainly not be linked with a > newer OpenSSL... > >I apologize for not being clear enough. > >I do not want to remove any of those algorithms. I just want to remove >10,000 lines of assembler version and just have the C code. I want to >do that for safety and maintainability and because they do not justify >the burden -- ON US -- to keep hand-tuned assembler that only one, >maybe two, people understand. I'm worried that the number could go down to zero some day. I do see the benefits with the assembly code and personally find then justifiable enough to try and learn. (side note: I've just started compiling the ia64 code on VMS. It currently bombs for reasons I haven't fathomed yet, but am thinking it's a pointer size thing... It's about the quirkiest assembly I've seen, but I'm hell bent to get through it) Cheers Richard > > >_______________________________________________ >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 rsalz at akamai.com Sun Feb 11 19:34:20 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 11 Feb 2018 19:34:20 +0000 Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: References: <0EA60701-6E1A-4FE0-86F8-33B37D01612E@dukhovni.org> <87431112-FE0D-4C50-9FD6-BDF38E502917@akamai.com> <20180210223253.GR3322@mournblade.imrryr.org> <20180211.082030.1623349319332151243.levitte@openssl.org> Message-ID: <6755A806-81EB-4771-85F3-9925DCC02522@akamai.com> > I'm worried that the number could go down to zero some day. I do see the benefits with the assembly code and personally find then justifiable enough to try and learn. I am not at all worried about that. The best current algorithms will always benefit from assembler. It's just that this is moving window. From appro at openssl.org Sun Feb 11 19:42:49 2018 From: appro at openssl.org (Andy Polyakov) Date: Sun, 11 Feb 2018 20:42:49 +0100 Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: References: <0EA60701-6E1A-4FE0-86F8-33B37D01612E@dukhovni.org> <87431112-FE0D-4C50-9FD6-BDF38E502917@akamai.com> <20180210223253.GR3322@mournblade.imrryr.org> <20180211.082030.1623349319332151243.levitte@openssl.org> Message-ID: > (side note: I've just started compiling the ia64 code on VMS. It currently bombs for reasons I haven't fathomed yet, but am thinking it's a pointer size thing... You ought to generate assembly listing for 'int foo(int *p) {return *p;}' with different flags and send it to me. I told you that long time ago :-) > It's about the quirkiest assembly I've seen, but I'm hell bent to get through it) Well... From levitte at openssl.org Sun Feb 11 21:27:33 2018 From: levitte at openssl.org (Richard Levitte) Date: Sun, 11 Feb 2018 22:27:33 +0100 Subject: [openssl-project] Removing assembler for outdated algorithms In-Reply-To: References: <0EA60701-6E1A-4FE0-86F8-33B37D01612E@dukhovni.org> <87431112-FE0D-4C50-9FD6-BDF38E502917@akamai.com> <20180210223253.GR3322@mournblade.imrryr.org> <20180211.082030.1623349319332151243.levitte@openssl.org> Message-ID: <60919D8A-AAE6-4958-A77C-BC1839919910@openssl.org> Andy Polyakov skrev: (11 februari 2018 20:42:49 CET) >> (side note: I've just started compiling the ia64 code on VMS. It >currently bombs for reasons I haven't fathomed yet, but am thinking >it's a pointer size thing... > >You ought to generate assembly listing for 'int foo(int *p) {return >*p;}' with different flags and send it to me. I told you that long time >ago :-) True, you did. I blame my poor L1 cache ;-) Will do later tonight. Am on my way home as I write... >> It's about the quirkiest assembly I've seen, but I'm hell bent to get >through it) > >Well... >_______________________________________________ >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 mark at openssl.org Mon Feb 12 11:18:57 2018 From: mark at openssl.org (Mark J Cox) Date: Mon, 12 Feb 2018 11:18:57 +0000 Subject: [openssl-project] Mitre GIT CVE pilot, vulnerability JSON files Message-ID: Mostly this is a note for any future release managers but also a FYI to anyone interested. We're participating in the CVE Automation Working Group pilot to provide CVE information via git[1]. This means when we do any future security release of OpenSSL we can send information about each CVE directly to Mitre (via a forked github repo and pull request) rather than filling out their web based form. In order to prepare for the pilot we've also switched from providing CVE information from the Mitre plain text format to JSON[2]. The JSON files do not have to be written by hand, unlike the text versions we had to create, and are instead created using a script[4] from the XML format[3] we use to populate the OpenSSL site. Step by step Instructions for release managers are (temporarily) included in cvepool.txt file in the private repo. Mark J Cox [1] https://github.com/CVEProject/cvelist/ [2] https://github.com/CVEProject/automation-working-group/tree/master/cve_json_schema [3] https://www.openssl.org/news/vulnerabilities.xml [4] https://github.com/openssl/web/blob/master/bin/vulnxml2json.py From matt at openssl.org Mon Feb 12 11:24:24 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 12 Feb 2018 11:24:24 +0000 Subject: [openssl-project] Code freeze later today Message-ID: <0334edc9-5b9c-8fd4-66a8-ea0b277e99b9@openssl.org> Tomorrow we are doing our first alpha release. Therefore I plan to call a code freeze from later today until after the release is complete tomorrow afternoon. If there's anything you wanted to get pushed before alpha1 please do so ASAP! Thanks Matt From levitte at openssl.org Mon Feb 12 11:54:14 2018 From: levitte at openssl.org (Richard Levitte) Date: Mon, 12 Feb 2018 12:54:14 +0100 (CET) Subject: [openssl-project] Code freeze later today In-Reply-To: <0334edc9-5b9c-8fd4-66a8-ea0b277e99b9@openssl.org> References: <0334edc9-5b9c-8fd4-66a8-ea0b277e99b9@openssl.org> Message-ID: <20180212.125414.1536893413382802120.levitte@openssl.org> In message <0334edc9-5b9c-8fd4-66a8-ea0b277e99b9 at openssl.org> on Mon, 12 Feb 2018 11:24:24 +0000, Matt Caswell said: matt> Tomorrow we are doing our first alpha release. Therefore I plan to call matt> a code freeze from later today until after the release is complete matt> tomorrow afternoon. If there's anything you wanted to get pushed before matt> alpha1 please do so ASAP! Hrrrm... nah, no way I'm gonna have time within the few hours that follow. There are a few items I'm gonna push for 'til next Alpha: - complete the OSSL_STORE work. The search functionality PR still needs a review (gonna call for it). - some details on how we build stuff. We introduced GNU-like "make variable" support in configuration, but Andy correctly pointed out that there are some macros and stuff that we don't want to make optional. This requires a bit of a rethink of config attributes and the make variables we do use in the end. - I'm trying to build ia64 assembler stuff on VMS. This also requires a bit of a rethink how we use the make variables (not as hard as it sounds). Just wanted to let you know what I've on my plate. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Mon Feb 12 12:11:48 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 12 Feb 2018 12:11:48 +0000 Subject: [openssl-project] Code freeze later today In-Reply-To: <0334edc9-5b9c-8fd4-66a8-ea0b277e99b9@openssl.org> References: <0334edc9-5b9c-8fd4-66a8-ea0b277e99b9@openssl.org> Message-ID: Please try to walk through and use the release instructions in the tool repo and fix any errors. ?On 2/12/18, 6:24 AM, "Matt Caswell" wrote: Tomorrow we are doing our first alpha release. Therefore I plan to call a code freeze from later today until after the release is complete tomorrow afternoon. If there's anything you wanted to get pushed before alpha1 please do so ASAP! Thanks Matt _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project From matt at openssl.org Mon Feb 12 15:04:36 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 12 Feb 2018 15:04:36 +0000 Subject: [openssl-project] Code Freeze!!! Message-ID: <48d370b8-6fbc-2047-3b02-35049d010e10@openssl.org> Please could someone freeze the repo for me? The tools don't let me do it for my own benefit: ssh openssl-git at git.openssl.org freeze openssl matt Thanks Matt From levitte at openssl.org Mon Feb 12 15:06:48 2018 From: levitte at openssl.org (Richard Levitte) Date: Mon, 12 Feb 2018 16:06:48 +0100 (CET) Subject: [openssl-project] Code Freeze!!! In-Reply-To: <48d370b8-6fbc-2047-3b02-35049d010e10@openssl.org> References: <48d370b8-6fbc-2047-3b02-35049d010e10@openssl.org> Message-ID: <20180212.160648.1141696370681215671.levitte@openssl.org> In message <48d370b8-6fbc-2047-3b02-35049d010e10 at openssl.org> on Mon, 12 Feb 2018 15:04:36 +0000, Matt Caswell said: matt> Please could someone freeze the repo for me? The tools don't let me do matt> it for my own benefit: matt> matt> ssh openssl-git at git.openssl.org freeze openssl matt matt> matt> Thanks Done -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Mon Feb 12 16:02:48 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 12 Feb 2018 16:02:48 +0000 Subject: [openssl-project] Style question Message-ID: <81b883ae-ac3e-1d8b-2096-c62b8d318958@openssl.org> I've been looking at our use of EVP_MD_size() (prompted by Coverity). That function can return a -1 on error: int EVP_MD_size(const EVP_MD *md) { if (!md) { EVPerr(EVP_F_EVP_MD_SIZE, EVP_R_MESSAGE_DIGEST_IS_NULL); return -1; } return md->md_size; } The only (current) possible error is that the passed digest is NULL. Otherwise it returns the size of the digest as you would expect. In some places we do things like this: const EVP_MD *md = ssl_md(s->session->cipher->algorithm2); if (md != NULL) { /* * Add the fixed PSK overhead, the identity length and the binder * length. */ hlen += PSK_PRE_BINDER_OVERHEAD + s->session->ext.ticklen + EVP_MD_size(md); } So we have an explicit NULL check of the md before we call the function. Therefore there is no possible way that EVP_MD_size() can return anything except a success response. Are we entitled to assume that? Or should we always check the return value regardless? My instinct says we should in case we ever wanted to change the function in the future to return an error in some other circumstances. Just to make it more interesting our documentation does not mention the possibility of an error return at all. Matt From matt at openssl.org Mon Feb 12 16:07:38 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 12 Feb 2018 16:07:38 +0000 Subject: [openssl-project] Style question In-Reply-To: <2CD80758-AF80-48D4-B191-0BED3B3F80E3@akamai.com> References: <81b883ae-ac3e-1d8b-2096-c62b8d318958@openssl.org> <2CD80758-AF80-48D4-B191-0BED3B3F80E3@akamai.com> Message-ID: <97fd6a26-da09-17fa-a381-8b65dc50c05e@openssl.org> On 12/02/18 16:05, Short, Todd wrote: > My 2cents (since I can?t reply to the list), is that other functions > (e.g. most SSL and SSL_CTX functions) require a non-NULL object. I?m not > sure this is any different. Good point. Although that then changes the question slightly to be can we assume that this function will never return an error (even though it has in the past)? (BTW you can reply to the list - its just moderated so you have to wait for someone to approve it.) Matt > > -- > -Todd Short > // tshort at akamai.com > // "One if by land, two if by sea, three if by the Internet." > >> On Feb 12, 2018, at 11:02 AM, Matt Caswell > > wrote: >> >> I've been looking at our use of EVP_MD_size() (prompted by Coverity). >> >> That function can return a -1 on error: >> >> int EVP_MD_size(const EVP_MD *md) >> { >> ???if (!md) { >> ???????EVPerr(EVP_F_EVP_MD_SIZE, EVP_R_MESSAGE_DIGEST_IS_NULL); >> ???????return -1; >> ???} >> ???return md->md_size; >> } >> >> >> The only (current) possible error is that the passed digest is NULL. >> Otherwise it returns the size of the digest as you would expect. >> >> In some places we do things like this: >> >> ???????const EVP_MD *md = ssl_md(s->session->cipher->algorithm2); >> >> ???????if (md != NULL) { >> ???????????/* >> ????????????* Add the fixed PSK overhead, the identity length and the >> binder >> ????????????* length. >> ????????????*/ >> ???????????hlen += ?PSK_PRE_BINDER_OVERHEAD + s->session->ext.ticklen >> ????????????????????+ EVP_MD_size(md); >> ???????} >> >> So we have an explicit NULL check of the md before we call the function. >> Therefore there is no possible way that EVP_MD_size() can return >> anything except a success response. >> >> Are we entitled to assume that? Or should we always check the return >> value regardless? My instinct says we should in case we ever wanted to >> change the function in the future to return an error in some other >> circumstances. >> >> Just to make it more interesting our documentation does not mention the >> possibility of an error return at all. >> >> Matt >> _______________________________________________ >> openssl-project mailing list >> openssl-project at openssl.org >> https://mta.openssl.org/mailman/listinfo/openssl-project > From matt at openssl.org Mon Feb 12 16:10:38 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 12 Feb 2018 16:10:38 +0000 Subject: [openssl-project] Style question In-Reply-To: <97fd6a26-da09-17fa-a381-8b65dc50c05e@openssl.org> References: <81b883ae-ac3e-1d8b-2096-c62b8d318958@openssl.org> <2CD80758-AF80-48D4-B191-0BED3B3F80E3@akamai.com> <97fd6a26-da09-17fa-a381-8b65dc50c05e@openssl.org> Message-ID: <03178288-79df-3eeb-e2ae-b5853333cae3@openssl.org> On 12/02/18 16:07, Matt Caswell wrote: > > > On 12/02/18 16:05, Short, Todd wrote: >> My 2cents (since I can?t reply to the list), is that other functions >> (e.g. most SSL and SSL_CTX functions) require a non-NULL object. I?m not >> sure this is any different. > > Good point. Although that then changes the question slightly to be can > we assume that this function will never return an error (even though it > has in the past)? But then thinking about it more - I don't think we can remove this check. Since we are currently checking this, removing it could cause a binary compat issue if some application is relying on that check. Matt > > > (BTW you can reply to the list - its just moderated so you have to wait > for someone to approve it.) > > Matt > >> >> -- >> -Todd Short >> // tshort at akamai.com >> // "One if by land, two if by sea, three if by the Internet." >> >>> On Feb 12, 2018, at 11:02 AM, Matt Caswell >> > wrote: >>> >>> I've been looking at our use of EVP_MD_size() (prompted by Coverity). >>> >>> That function can return a -1 on error: >>> >>> int EVP_MD_size(const EVP_MD *md) >>> { >>> ???if (!md) { >>> ???????EVPerr(EVP_F_EVP_MD_SIZE, EVP_R_MESSAGE_DIGEST_IS_NULL); >>> ???????return -1; >>> ???} >>> ???return md->md_size; >>> } >>> >>> >>> The only (current) possible error is that the passed digest is NULL. >>> Otherwise it returns the size of the digest as you would expect. >>> >>> In some places we do things like this: >>> >>> ???????const EVP_MD *md = ssl_md(s->session->cipher->algorithm2); >>> >>> ???????if (md != NULL) { >>> ???????????/* >>> ????????????* Add the fixed PSK overhead, the identity length and the >>> binder >>> ????????????* length. >>> ????????????*/ >>> ???????????hlen += ?PSK_PRE_BINDER_OVERHEAD + s->session->ext.ticklen >>> ????????????????????+ EVP_MD_size(md); >>> ???????} >>> >>> So we have an explicit NULL check of the md before we call the function. >>> Therefore there is no possible way that EVP_MD_size() can return >>> anything except a success response. >>> >>> Are we entitled to assume that? Or should we always check the return >>> value regardless? My instinct says we should in case we ever wanted to >>> change the function in the future to return an error in some other >>> circumstances. >>> >>> Just to make it more interesting our documentation does not mention the >>> possibility of an error return at all. >>> >>> 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 Mon Feb 12 16:42:38 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 12 Feb 2018 16:42:38 +0000 Subject: [openssl-project] Style question In-Reply-To: <81b883ae-ac3e-1d8b-2096-c62b8d318958@openssl.org> References: <81b883ae-ac3e-1d8b-2096-c62b8d318958@openssl.org> Message-ID: <5CB9139A-CC61-4DCB-B6BB-6AE52520E4CE@akamai.com> The error return is not documented. We are definitely moving to a "don't check params for NULL". I would like to see this changed to be the obvious one-liner. Tim will disagree, but he's on the wrong side of history :) From matt at openssl.org Mon Feb 12 16:47:22 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 12 Feb 2018 16:47:22 +0000 Subject: [openssl-project] Style question In-Reply-To: <5CB9139A-CC61-4DCB-B6BB-6AE52520E4CE@akamai.com> References: <81b883ae-ac3e-1d8b-2096-c62b8d318958@openssl.org> <5CB9139A-CC61-4DCB-B6BB-6AE52520E4CE@akamai.com> Message-ID: On 12/02/18 16:42, Salz, Rich wrote: > The error return is not documented. I don't see why that matters. It is trivial to see that an error is returned in some circumstances, and there are plenty of examples in our own code where we check this. If we removed this check we would have to go through all of our uses to check that we've not introduced a bug (e.g. where we know that we may send a NULL md and rely on the error return to do the right thing). If we have to do that for our own code it's not a big stretch to imagine plenty of other applications would be similarly affected. We really can't remove the check. Matt > > We are definitely moving to a "don't check params for NULL". > > I would like to see this changed to be the obvious one-liner. Tim will disagree, but he's on the wrong side of history :) > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > From openssl at openssl.org Tue Feb 13 14:33:43 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 13 Feb 2018 14:33:43 +0000 Subject: [openssl-project] OpenSSL version 1.1.1 pre release 1 published Message-ID: <20180213143343.GA15047@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.1 pre release 1 (alpha) =========================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 1.1.1 is currently in alpha. OpenSSL 1.1.1 pre release 1 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 alpha 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-pre1.tar.gz Size: 6406872 SHA1 checksum: 83fee0570c8aff4701700f88d193fcf785b595ae SHA256 checksum: dd291d0a81d77219d40b21b9caf4713daaf43416fe8d6eae0b96df39b8b17e6d The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1-pre1.tar.gz openssl sha256 openssl-1.1.1-pre1.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: ttps://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaguyiAAoJENnE0m0OYESRQSoH/03mmxlj3zAcOgiWcQW7Nsfv bDr6TArh2zplEv/KUxrZiy9CCCKh3p9KI2VlUclObj327pkknMrQfx2TvYDztqfn UsbBL2XA+aiTlF0qgzDQMxg4bdfzYMKL5MUxQvsteVyyTrz5Wm1EWnwjn/mtKh6f p+nJPM9slFeV5EYTdNWIsugl55xU3oueFdVKdOqdZIUkKf5yAVe0/7UH/zVHYRt9 Mq7KZP6suRWhOgcK+g16tevO03+KkY/4O8rwE05DG3gjBbpT/hQvMcluV6jpHgIK KhMUurwOwjN81TZhYmkdKf5gBRvJ03zaJE+LeZHIKR6xdzOQBURsM4m+xPAs7i0= =ZT+8 -----END PGP SIGNATURE----- From matt at openssl.org Tue Feb 13 14:36:52 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Feb 2018 14:36:52 +0000 Subject: [openssl-project] Code Freeze!!! In-Reply-To: <20180212.160648.1141696370681215671.levitte@openssl.org> References: <48d370b8-6fbc-2047-3b02-35049d010e10@openssl.org> <20180212.160648.1141696370681215671.levitte@openssl.org> Message-ID: <0f84bff1-a1de-6f75-2aa0-f18cc22f1331@openssl.org> Release is done. The repo is now unfrozen! Thanks to Richard for your help in the release. Matt On 12/02/18 15:06, Richard Levitte wrote: > In message <48d370b8-6fbc-2047-3b02-35049d010e10 at openssl.org> on Mon, 12 Feb 2018 15:04:36 +0000, Matt Caswell said: > > matt> Please could someone freeze the repo for me? The tools don't let me do > matt> it for my own benefit: > matt> > matt> ssh openssl-git at git.openssl.org freeze openssl matt > matt> > matt> Thanks > > Done > From rsalz at akamai.com Wed Feb 14 16:06:44 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 14 Feb 2018 16:06:44 +0000 Subject: [openssl-project] VOTE on travel reimbursement policy Message-ID: <6903CCE3-F275-491C-865B-698360CC6CC4@akamai.com> The policy is in the bureau (not a public repo) so that we have something concrete to vote on. It is exactly the same as I posted to the project list before. +---------------- +topic: Adopt travel recommendation policy in commit e12d59a and format and +post to the web. +Proposed by Rich +Public: yes +opened: 2018-02-14 +closed: yyyy-mm-dd + + Matt [ ] + Mark [ ] + Viktor [ ] + Tim [ ] + Emilia [ ] + Richard [ ] + Kurt [ ] + Rich [+1] -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjh at cryptsoft.com Wed Feb 14 19:53:05 2018 From: tjh at cryptsoft.com (Tim Hudson) Date: Thu, 15 Feb 2018 05:53:05 +1000 Subject: [openssl-project] [openssl-omc] VOTE on travel reimbursement policy In-Reply-To: References: <6903CCE3-F275-491C-865B-698360CC6CC4@akamai.com> Message-ID: +1 On 15 Feb. 2018 2:06 am, "Salz, Rich" wrote: The policy is in the bureau (not a public repo) so that we have something concrete to vote on. It is exactly the same as I posted to the project list before. +---------------- +topic: Adopt travel recommendation policy in commit e12d59a and format and +post to the web. +Proposed by Rich +Public: yes +opened: 2018-02-14 +closed: yyyy-mm-dd + + Matt [ ] + Mark [ ] + Viktor [ ] + Tim [ ] + Emilia [ ] + Richard [ ] + Kurt [ ] + Rich [+1] -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Wed Feb 14 21:24:14 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 14 Feb 2018 22:24:14 +0100 Subject: [openssl-project] VOTE on travel reimbursement policy In-Reply-To: <6903CCE3-F275-491C-865B-698360CC6CC4@akamai.com> References: <6903CCE3-F275-491C-865B-698360CC6CC4@akamai.com> Message-ID: <20180214212414.GA13565@roeckx.be> On Wed, Feb 14, 2018 at 04:06:44PM +0000, Salz, Rich wrote: > The policy is in the bureau (not a public repo) so that we have something concrete to vote on. It is exactly the same as I posted to the project list before. I would like to see all votes contain the full text and not a reference to some commit id. The call for votes should probably also not go to the project list based on that current rules say that we vote on the omc list afaik. Kurt From levitte at openssl.org Wed Feb 14 21:40:29 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 14 Feb 2018 22:40:29 +0100 (CET) Subject: [openssl-project] VOTE on travel reimbursement policy In-Reply-To: <20180214212414.GA13565@roeckx.be> References: <6903CCE3-F275-491C-865B-698360CC6CC4@akamai.com> <20180214212414.GA13565@roeckx.be> Message-ID: <20180214.224029.2264108395512660970.levitte@openssl.org> In message <20180214212414.GA13565 at roeckx.be> on Wed, 14 Feb 2018 22:24:14 +0100, Kurt Roeckx said: kurt> The call for votes should probably also not go to the project list kurt> based on that current rules say that we vote on the omc list kurt> afaik. This is exactly contrary to what we agreed on at the last f2f, apart from *certain* votes (such as invitation of new people). Note that there's a difference between the thing we vote on and our votes. That latter is supposed to happen within the confines of the OMC, but the final tally (numbers only) would be presented on the project list. Now, the initial posting went to both the OMC and the project list, and some chose to vote with a simple "Reply All" without editing the recipients. If that was on purpose or because attention wasn't payed to that detail, I cannot say. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From tjh at cryptsoft.com Wed Feb 14 21:47:15 2018 From: tjh at cryptsoft.com (Tim Hudson) Date: Thu, 15 Feb 2018 07:47:15 +1000 Subject: [openssl-project] VOTE on travel reimbursement policy In-Reply-To: <20180214.224029.2264108395512660970.levitte@openssl.org> References: <6903CCE3-F275-491C-865B-698360CC6CC4@akamai.com> <20180214212414.GA13565@roeckx.be> <20180214.224029.2264108395512660970.levitte@openssl.org> Message-ID: > Now, the initial posting went to both the OMC and the project list, > and some chose to vote with a simple "Reply All" without editing the > recipients. If that was on purpose or because attention wasn't payed > to that detail, I cannot say. For my part, it was just a reply-all - but if I had stopped to look at the details I still would have done a reply-all - as there is nothing in this vote that needs to be kept private in my view. I guess it is a choice for each OMC member as to whether or not they make their actual votes public - the summary results will be - but the actual votes were indeed meant to be on openssl-omc only. It would also have been good for the text to be attached - especially when we are sending vote details to openssl-project. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Wed Feb 14 22:10:28 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 14 Feb 2018 23:10:28 +0100 Subject: [openssl-project] VOTE on travel reimbursement policy In-Reply-To: <20180214.224029.2264108395512660970.levitte@openssl.org> References: <6903CCE3-F275-491C-865B-698360CC6CC4@akamai.com> <20180214212414.GA13565@roeckx.be> <20180214.224029.2264108395512660970.levitte@openssl.org> Message-ID: <20180214221028.GA15293@roeckx.be> On Wed, Feb 14, 2018 at 10:40:29PM +0100, Richard Levitte wrote: > In message <20180214212414.GA13565 at roeckx.be> on Wed, 14 Feb 2018 22:24:14 +0100, Kurt Roeckx said: > > kurt> The call for votes should probably also not go to the project list > kurt> based on that current rules say that we vote on the omc list > kurt> afaik. > > This is exactly contrary to what we agreed on at the last f2f, apart > from *certain* votes (such as invitation of new people). I think that what we agreed to is that the text to vote on should be discussed on the project list before the vote, and that the vote should happen on the omc list. Since the vote happens on the omc list, I see no reason to send the call for votes to the project list, I only see it as confusing. Note that I have no problem with voting in public, but then everybody should vote in public. If some people vote in public and others don't, the summary might give enough information about what the others voted. So I think we should either all vote in public, or nobody should vote in public. Kurt From tjh at cryptsoft.com Wed Feb 14 22:21:31 2018 From: tjh at cryptsoft.com (Tim Hudson) Date: Thu, 15 Feb 2018 08:21:31 +1000 Subject: [openssl-project] VOTE on travel reimbursement policy In-Reply-To: <20180214221028.GA15293@roeckx.be> References: <6903CCE3-F275-491C-865B-698360CC6CC4@akamai.com> <20180214212414.GA13565@roeckx.be> <20180214.224029.2264108395512660970.levitte@openssl.org> <20180214221028.GA15293@roeckx.be> Message-ID: [kurt] > So I think we should either all vote in public, or nobody should vote in public. You make a good point there - I agree. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Feb 14 22:26:56 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 14 Feb 2018 22:26:56 +0000 Subject: [openssl-project] VOTE on travel reimbursement policy In-Reply-To: References: <6903CCE3-F275-491C-865B-698360CC6CC4@akamai.com> <20180214212414.GA13565@roeckx.be> <20180214.224029.2264108395512660970.levitte@openssl.org> <20180214221028.GA15293@roeckx.be> Message-ID: * > So I think we should either all vote in public, or nobody should vote in public. * You make a good point there - I agree. Sure. So what does the public takes in votes.txt mean? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjh at openssl.org Wed Feb 14 22:28:10 2018 From: tjh at openssl.org (Tim Hudson) Date: Thu, 15 Feb 2018 08:28:10 +1000 Subject: [openssl-project] Alpha release coverage on The Register Message-ID: http://www.theregister.co.uk/2018/02/14/openssl_1_1_1_alpha_adds_tls_1_3_support/ Note that the headline "Shambling corpse of ancient, shoddy, buggy, crypto shoved towards the grave" is referring to TLS protocol versions not to OpenSSL (at least that is my reading of the article) but as always The Register does like snappy headlines. It could do with a pointing out the timeline on TLSv1.3 support in OpenSSL ... Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Thu Feb 15 07:01:33 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 15 Feb 2018 08:01:33 +0100 Subject: [openssl-project] Alpha release coverage on The Register In-Reply-To: References: Message-ID: <306a7140-2bf4-5d6a-210c-dd6ce28c9b1f@ncp-e.com> Am 14.02.2018 um 23:28 schrieb Tim Hudson: > http://www.theregister.co.uk/2018/02/14/openssl_1_1_1_alpha_adds_tls_1_3_support/ > > > Note that the headline "Shambling corpse of ancient, shoddy, buggy, > crypto shoved towards the grave" is referring to TLS protocol versions > not to OpenSSL (at least that is my reading of the article) but as > always The Register does like snappy headlines. > > It could do with a pointing out the timeline on TLSv1.3 support in > OpenSSL ... > > Tim. > Thanks for the Link! After all, the article is much more positive than the subtitle suggests. Personally, I very much enjoyed seeing the "grand redesign" in double quotes ;-) Matthias From matt at openssl.org Thu Feb 15 13:58:24 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 15 Feb 2018 13:58:24 +0000 Subject: [openssl-project] Fwd: [TLS] Publication has been requested for draft-ietf-tls-tls13-24 In-Reply-To: <151870287628.7541.593435688547795665.idtracker@ietfa.amsl.com> References: <151870287628.7541.593435688547795665.idtracker@ietfa.amsl.com> Message-ID: FYI -------- Forwarded Message -------- Subject: [TLS] Publication has been requested for draft-ietf-tls-tls13-24 Date: Thu, 15 Feb 2018 05:54:36 -0800 From: Sean Turner To: Kathleen.Moriarty.ietf at gmail.com CC: iesg-secretary at ietf.org, tls-chairs at ietf.org, tls at ietf.org Sean Turner has requested publication of draft-ietf-tls-tls13-24 as Proposed Standard on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ _______________________________________________ TLS mailing list TLS at ietf.org https://www.ietf.org/mailman/listinfo/tls From matt at openssl.org Thu Feb 15 23:43:11 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 15 Feb 2018 23:43:11 +0000 Subject: [openssl-project] tag for 1.1.1pre1? In-Reply-To: <032c72a4-d33d-dc41-cdfd-f0a820a35927@akamai.com> References: <032c72a4-d33d-dc41-cdfd-f0a820a35927@akamai.com> Message-ID: (cc'ing openssl-project) On 15/02/18 22:36, Benjamin Kaduk wrote: > Hi Matt, > > I see git tags for 1.1.0pre[1-6], but not one for the 1.1.1 alpha.? Is > this intentional or an omission? Oops. 'cos we had a few problems during the release I had to run the mkrelease script more than once and back out the changes. Looks like I forgot to delete the tag from one of the earlier runs, so when I reran the script the tag create failed and the old one was left hanging around. That did get pushed to the repo, but pointing at a commit that didn't exist. When you do a git pull it only pulls down tags for commits that exist in your repo. It should be sorted now. Matt From rsalz at akamai.com Fri Feb 16 15:22:37 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 16 Feb 2018 15:22:37 +0000 Subject: [openssl-project] Coding style updates Message-ID: <192496A1-C492-4BB7-A663-3644D079E4B2@akamai.com> I?ve written up everything that seemed to have agreement, and kept the couple of items where it was less clear. Please comment here: https://github.com/openssl/web/pull/43 I want to do a vote by the end of the month. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Feb 21 09:49:04 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 21 Feb 2018 10:49:04 +0100 (CET) Subject: [openssl-project] Sick with the flu Message-ID: <20180221.104904.905297731367684287.levitte@openssl.org> Hey all, just wanted to let you know that I got the flu (started last weekend)... I'm starting to get better, but still don't have enough cycles to do much more than a spurious response to something that catches my eye a little now and then. I hope I'll be back up to speed by this weekend. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From appro at openssl.org Wed Feb 21 12:44:50 2018 From: appro at openssl.org (Andy Polyakov) Date: Wed, 21 Feb 2018 13:44:50 +0100 Subject: [openssl-project] x25519-x86_64 Message-ID: <29f3b800-7782-279b-a0b1-2fab75398bfb@openssl.org> Hi, A word of clarification about recently introduced x25519-x86_64 module. Specifically in the context of an apparently common shift toward auto-generated C such fiat-crypto or hacl64. As far as I'm concerned problem with just mentioned auto-generated C implementations is that while being verified by themselves, they rely on effectively unverified compiler and its [unverifiable] ability to perform advanced optimizations. Or in other words it's problematic on two levels: a) can output from unvalidated compiler count as validated? b) will compilers get performance right across a range of platforms? And as one can imagine I imply that answer to both questions is "not really". As for b). Well, current [x86_64] compilers were observed to generate decent code that performs virtually on-par with assembly on contemporary high-end Intel processors. At least for 2^51 radix customarily chosen for C. Indeed, if you consider the improvement coefficients table in x25519-x86_64.pl, you'll notice as low coefficients as 11%, 13%, 9% in comparison to code generated by gcc-5.4. Normally it's not large enough improvement [to subject yourself to misery of assembly programming], right? But assembly does shine on non-Sandy Bridge and non-Haswell processors, most notably in ADCX/ADOX cases. As for a). Intention is to work with group at Academia Sinica to formally verify the implementation. On related note they did verify amd64-51(*) implementation that x25519-x86_64 refers to, so it wouldn't be unprecedented. Cheers. (*) Just in case for reference. Being hardly readable, amd64-51 is hard to integrate, because it targets specifically Unix ABI and is not position-independent. It also performs sub-optimally on non-"Intel Core family" processors, nor does it solve ADCX/ADOX problem. These are arguments against taking in amd64-51 that is. From kaduk at mit.edu Sat Feb 24 18:57:02 2018 From: kaduk at mit.edu (Benjamin Kaduk) Date: Sat, 24 Feb 2018 12:57:02 -0600 Subject: [openssl-project] Potentially adding TLS record header to TLS 1.3 AAD Message-ID: <20180224185702.GL50954@kduck.kaduk.org> Hi all, There's a pull request open against the TLS 1.3 spec to include the record header in the AAD for record protection (https://github.com/tlswg/tls13-spec/pull/1158). We're somewhat on the fence about this, with the main advantage seeming to be for DTLS and not plain TLS, but it would probably still be useful to have some sense for how hard it would be to implement. Matt, do you have any thoughts off the top of your head? Thanks, Ben From matt at openssl.org Mon Feb 26 12:33:20 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 26 Feb 2018 12:33:20 +0000 Subject: [openssl-project] Potentially adding TLS record header to TLS 1.3 AAD In-Reply-To: <20180224185702.GL50954@kduck.kaduk.org> References: <20180224185702.GL50954@kduck.kaduk.org> Message-ID: <2464a0da-9561-85f4-57cf-164d455381f4@openssl.org> On 24/02/18 18:57, Benjamin Kaduk wrote: > Hi all, > > There's a pull request open against the TLS 1.3 spec to include the > record header in the AAD for record protection > (https://github.com/tlswg/tls13-spec/pull/1158). We're somewhat on > the fence about this, with the main advantage seeming to be for DTLS > and not plain TLS, but it would probably still be useful to have > some sense for how hard it would be to implement. Matt, do you have > any thoughts off the top of your head? I've looked into this. And because I can't put this stuff down I played around to see what it would take to implement it: https://github.com/mattcaswell/openssl/commit/46494d3056fdfb9416b3585c8a5430e53abe0a58 It's quite straight forward really. The above commit still leaves a couple of test failures there - but I went far enough to prove the concept. The test failures just need a bit more time to solve (one is something to do with the way I set up AAD for CCM ciphersuites; and the other is that the TLSv1.3 encryption test vectors need updating). Matt From matt at openssl.org Mon Feb 26 16:26:26 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 26 Feb 2018 16:26:26 +0000 Subject: [openssl-project] Freezing the repo soon Message-ID: <11c792b7-61e5-99a6-e01a-622de2e61f70@openssl.org> Just a reminder to everyone that we are doing the alpha2 release tomorrow, so we will be freezing the repo soon (in about an hour or so). Matt From appro at openssl.org Mon Feb 26 17:23:01 2018 From: appro at openssl.org (Andy Polyakov) Date: Mon, 26 Feb 2018 18:23:01 +0100 Subject: [openssl-project] Freezing the repo soon In-Reply-To: <11c792b7-61e5-99a6-e01a-622de2e61f70@openssl.org> References: <11c792b7-61e5-99a6-e01a-622de2e61f70@openssl.org> Message-ID: <2ce18b42-5145-d7fd-c274-c466e50e5141@openssl.org> > Just a reminder to everyone that we are doing the alpha2 release > tomorrow, so we will be freezing the repo soon (in about an hour or so). master is read at https://travis-ci.org/openssl/openssl/branches since https://github.com/openssl/openssl/commit/b38ede8043439d99a3c6c174f17b91875cce66ac. appears as ubsan failure... From matt at openssl.org Mon Feb 26 17:27:13 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 26 Feb 2018 17:27:13 +0000 Subject: [openssl-project] Freezing the repo soon In-Reply-To: <2ce18b42-5145-d7fd-c274-c466e50e5141@openssl.org> References: <11c792b7-61e5-99a6-e01a-622de2e61f70@openssl.org> <2ce18b42-5145-d7fd-c274-c466e50e5141@openssl.org> Message-ID: <244ffe09-9e3f-0ba5-701a-2961818ddae3@openssl.org> On 26/02/18 17:23, Andy Polyakov wrote: >> Just a reminder to everyone that we are doing the alpha2 release >> tomorrow, so we will be freezing the repo soon (in about an hour or so). > > master is read at https://travis-ci.org/openssl/openssl/branches since > https://github.com/openssl/openssl/commit/b38ede8043439d99a3c6c174f17b91875cce66ac. > appears as ubsan failure... Please could someone freeze the repo for me? $ ssh openssl-git at git.openssl.org freeze openssl matt I will take a look at the ubsan failure (and we should push a fix when we have one regardless of the freeze). Matt From appro at openssl.org Mon Feb 26 17:28:03 2018 From: appro at openssl.org (Andy Polyakov) Date: Mon, 26 Feb 2018 18:28:03 +0100 Subject: [openssl-project] Freezing the repo soon In-Reply-To: <244ffe09-9e3f-0ba5-701a-2961818ddae3@openssl.org> References: <11c792b7-61e5-99a6-e01a-622de2e61f70@openssl.org> <2ce18b42-5145-d7fd-c274-c466e50e5141@openssl.org> <244ffe09-9e3f-0ba5-701a-2961818ddae3@openssl.org> Message-ID: <0ea961fa-1f35-330d-634e-76051cb80e57@openssl.org> > ssh openssl-git at git.openssl.org freeze openssl matt done. From matt at openssl.org Mon Feb 26 19:13:24 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 26 Feb 2018 19:13:24 +0000 Subject: [openssl-project] Freezing the repo soon In-Reply-To: <2ce18b42-5145-d7fd-c274-c466e50e5141@openssl.org> References: <11c792b7-61e5-99a6-e01a-622de2e61f70@openssl.org> <2ce18b42-5145-d7fd-c274-c466e50e5141@openssl.org> Message-ID: <462bc4e7-fa5e-89f2-ccc1-1955d8605e56@openssl.org> On 26/02/18 17:23, Andy Polyakov wrote: >> Just a reminder to everyone that we are doing the alpha2 release >> tomorrow, so we will be freezing the repo soon (in about an hour or so). > > master is read at https://travis-ci.org/openssl/openssl/branches since > https://github.com/openssl/openssl/commit/b38ede8043439d99a3c6c174f17b91875cce66ac. > appears as ubsan failure... Hmmm. I cannot reproduce the problem. Matt From matt at openssl.org Mon Feb 26 19:33:27 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 26 Feb 2018 19:33:27 +0000 Subject: [openssl-project] Freezing the repo soon In-Reply-To: <462bc4e7-fa5e-89f2-ccc1-1955d8605e56@openssl.org> References: <11c792b7-61e5-99a6-e01a-622de2e61f70@openssl.org> <2ce18b42-5145-d7fd-c274-c466e50e5141@openssl.org> <462bc4e7-fa5e-89f2-ccc1-1955d8605e56@openssl.org> Message-ID: On 26/02/18 19:13, Matt Caswell wrote: > > > On 26/02/18 17:23, Andy Polyakov wrote: >>> Just a reminder to everyone that we are doing the alpha2 release >>> tomorrow, so we will be freezing the repo soon (in about an hour or so). >> >> master is read at https://travis-ci.org/openssl/openssl/branches since >> https://github.com/openssl/openssl/commit/b38ede8043439d99a3c6c174f17b91875cce66ac. >> appears as ubsan failure... > > Hmmm. I cannot reproduce the problem. Aha! Setting the environment variable OPENSSL_TEST_RAND_ORDER triggers the problem. I think I know what the issue is. Matt From kaduk at mit.edu Mon Feb 26 21:28:16 2018 From: kaduk at mit.edu (Benjamin Kaduk) Date: Mon, 26 Feb 2018 15:28:16 -0600 Subject: [openssl-project] Potentially adding TLS record header to TLS 1.3 AAD In-Reply-To: <2464a0da-9561-85f4-57cf-164d455381f4@openssl.org> References: <20180224185702.GL50954@kduck.kaduk.org> <2464a0da-9561-85f4-57cf-164d455381f4@openssl.org> Message-ID: <20180226212816.GS50954@kduck.kaduk.org> On Mon, Feb 26, 2018 at 12:33:20PM +0000, Matt Caswell wrote: > > > On 24/02/18 18:57, Benjamin Kaduk wrote: > > Hi all, > > > > There's a pull request open against the TLS 1.3 spec to include the > > record header in the AAD for record protection > > (https://github.com/tlswg/tls13-spec/pull/1158). We're somewhat on > > the fence about this, with the main advantage seeming to be for DTLS > > and not plain TLS, but it would probably still be useful to have > > some sense for how hard it would be to implement. Matt, do you have > > any thoughts off the top of your head? > > I've looked into this. And because I can't put this stuff down I played > around to see what it would take to implement it: Thank you! -Ben > https://github.com/mattcaswell/openssl/commit/46494d3056fdfb9416b3585c8a5430e53abe0a58 > > It's quite straight forward really. The above commit still leaves a > couple of test failures there - but I went far enough to prove the > concept. The test failures just need a bit more time to solve (one is > something to do with the way I set up AAD for CCM ciphersuites; and the > other is that the TLSv1.3 encryption test vectors need updating). > > Matt > From openssl at openssl.org Tue Feb 27 14:29:24 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 27 Feb 2018 14:29:24 +0000 Subject: [openssl-project] OpenSSL version 1.1.1 pre release 2 published Message-ID: <20180227142924.GA9892@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.1 pre release 2 (alpha) =========================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 1.1.1 is currently in alpha. OpenSSL 1.1.1 pre release 2 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 alpha 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-pre2.tar.gz Size: 6485957 SHA1 checksum: 11be9034aa6b84eb8bfff7accc2a1a3f940deef9 SHA256 checksum: 33dbda4a90345d256942fb5316967efd90df4f2373578c7b56c90062fe21fc9c The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1-pre2.tar.gz openssl sha256 openssl-1.1.1-pre2.tar.gz Please download and check this alpha 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----- iQEcBAEBCAAGBQJalV/kAAoJENnE0m0OYESRW3kIAJhmXNT0kBRffoJn4jK5VC/R eDd+Pv25fNBq+LaNKd1m0B0BO+cZcxw6fygxM4rrsU8vchbWmquY4HH8rCaXZ7SE iW2EsnJJR9JZk7dnhNImmct3jYhALHnabC0qrinvIYVJRWaFRmpPPOFkvVaJ3Ouy 24vQ4Np98x33fw+p/0m6r4wHZ6c5zkHMUw5W1bmGPJF6i7YkZcM8ZKpMM2svObuS 2NEZvyfqrZNiBKwtRzl2WFFOMEgk/bbDrpqUPg6Ul2iYyfyz/LGtu5O5xYGxHCbq AptoWRILpkYmpgH+2ULJWuiVb21wIWCLcgKIfmizdMOPqsO6XmgzFJOV730HEW0= =W0yX -----END PGP SIGNATURE----- From matt at openssl.org Tue Feb 27 14:32:36 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 27 Feb 2018 14:32:36 +0000 Subject: [openssl-project] Freezing the repo soon In-Reply-To: <0ea961fa-1f35-330d-634e-76051cb80e57@openssl.org> References: <11c792b7-61e5-99a6-e01a-622de2e61f70@openssl.org> <2ce18b42-5145-d7fd-c274-c466e50e5141@openssl.org> <244ffe09-9e3f-0ba5-701a-2961818ddae3@openssl.org> <0ea961fa-1f35-330d-634e-76051cb80e57@openssl.org> Message-ID: <3f0db4c1-4b06-d021-42e9-940bf1bb117a@openssl.org> On 26/02/18 17:28, Andy Polyakov wrote: >> ssh openssl-git at git.openssl.org freeze openssl matt > > done. Release is complete and repo is now unfrozen. Thanks to Richard for all his help (as usual). Matt From rsalz at akamai.com Tue Feb 27 14:53:20 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 27 Feb 2018 14:53:20 +0000 Subject: [openssl-project] Freezing the repo soon In-Reply-To: <3f0db4c1-4b06-d021-42e9-940bf1bb117a@openssl.org> References: <11c792b7-61e5-99a6-e01a-622de2e61f70@openssl.org> <2ce18b42-5145-d7fd-c274-c466e50e5141@openssl.org> <244ffe09-9e3f-0ba5-701a-2961818ddae3@openssl.org> <0ea961fa-1f35-330d-634e-76051cb80e57@openssl.org> <3f0db4c1-4b06-d021-42e9-940bf1bb117a@openssl.org> Message-ID: <48A62B44-B08F-4245-BED8-2CA617AC5744@akamai.com> > Release is complete and repo is now unfrozen. > Thanks to Richard for all his help (as usual). So Richard and Matt, please update the release instructions in the release-tools part of the tools repo. (I know, for example, that making sure an old/1.1.x release directory is needed) Thanks! From appro at openssl.org Wed Feb 28 10:39:14 2018 From: appro at openssl.org (Andy Polyakov) Date: Wed, 28 Feb 2018 11:39:14 +0100 Subject: [openssl-project] to fully overlap or not to Message-ID: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org> Hi, I'd like to request more opinions on https://github.com/openssl/openssl/pull/5427. Key dispute question is whether or not following fragment should work unsigned char *inp = buf, *out = buf; for (i = 0; i < sizeof(buf); i++) { EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); out += outl; } [Just in case, corresponding corner case is effectively exercised in evp_test.] Bernd argues that this is unreasonable, which I counter with assertion that it doesn't matter how unreasonable this snippet is, because since we support in-place processing, it's reasonable to expect stream-cipher-like semantic as above to work even with block ciphers. As it stands now, suggested modified code would accept in-place calls only on block boundaries. Collateral question also is whether or not it would be appropriate to make this kind of change in minor release. Just in case, to give a bit of more general background. Benrd has shown that current checks are not sufficient to catch all corner cases of partially overlapping buffers. It was discussed that partially overlapping is not same as fully overlapping, a.k.a. in-place processing, with latter being in fact supported. And even though above snippet can be formally viewed as a stretch, it's argued that it does exhibit "legitimate intention" that deserves to be recognized and supported. At least it was so far, in sense that it's not exactly a coincidence that it currently works. [The fact that other corner cases are not recognized as invalid is of course a bug, but there is no contradiction, as fixing the bug doesn't have to mean that specific corner case is no longer recognized.] Thanks in advance. From appro at openssl.org Wed Feb 28 10:57:34 2018 From: appro at openssl.org (Andy Polyakov) Date: Wed, 28 Feb 2018 11:57:34 +0100 Subject: [openssl-project] to fully overlap or not to In-Reply-To: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org> References: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org> Message-ID: <17d4af0f-c626-83af-aea7-4606a43c38d5@openssl.org> > Collateral question also is whether or not it would > be appropriate to make this kind of change in minor release. One can wonder if this is actually more burning question. But keep in mind that ... > ... there is no > contradiction, as fixing the bug doesn't have to mean that specific > corner case is no longer recognized.] In sense that fixing the bug, i.e. passing cases *other* than one in question as valid, doesn't [necessarily] conflict with compatibility goals. From rsalz at akamai.com Wed Feb 28 15:15:38 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 28 Feb 2018 15:15:38 +0000 Subject: [openssl-project] Travel reimbursement policy Message-ID: By a vote of 6-0-2 the OMC adopted the following travel reimbursement policy. On a related matter, the OMC voted to hold a face-to-face meeting May 5-6 in Ottawa, just before the ICMC conference. The travel policy will now be subject to ruthless html?ization and posted to the website. The OpenSSL project may pay travel expenses for OMC members when pre-approved by the OMC or when it is an official OMC meeting (as determined by vote). Project members may seek to be reimbursed if their employer is not covering the expense. The requirements for reimbursement are: - An email sent to openssl-omc, including scanned attachments of all receipts over 30 Euros. - Barring exceptional circumstances, for an all-day meeting the project will pay for arrival the day before and departure the following morning. - When presenting at a conference, the project will pay the expenses for the entire conference provided the attendee agrees to act as representative of the project during that time. - Reasonable lodging and meal expenses during the travel time will be covered. - Barring exceptional circumstances, room service, minibar, in-room movies, and other similar amenities are not covered. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Feb 28 16:16:06 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 28 Feb 2018 16:16:06 +0000 Subject: [openssl-project] Coding style updates Message-ID: <469024E1-5DFD-4D4C-BEA2-8E8FC48FDDE1@akamai.com> Please look at https://github.com/openssl/web/pull/43 I want to have an OMC vote on this soon, like within a week. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Feb 28 16:25:12 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 28 Feb 2018 11:25:12 -0500 Subject: [openssl-project] to fully overlap or not to In-Reply-To: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org> References: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org> Message-ID: <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org> > On Feb 28, 2018, at 5:39 AM, Andy Polyakov wrote: > > I'd like to request more opinions on > https://github.com/openssl/openssl/pull/5427. Key dispute question is > whether or not following fragment should work > > unsigned char *inp = buf, *out = buf; > > for (i = 0; i < sizeof(buf); i++) { > EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); > out += outl; > } This should work. -- Viktor. From openssl-users at dukhovni.org Wed Feb 28 16:32:20 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 28 Feb 2018 11:32:20 -0500 Subject: [openssl-project] to fully overlap or not to In-Reply-To: <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org> References: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org> <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org> Message-ID: <0C04E9B7-7481-4FCD-9EB5-CF9032F5152A@dukhovni.org> > On Feb 28, 2018, at 11:25 AM, Viktor Dukhovni wrote: > >> I'd like to request more opinions on >> https://github.com/openssl/openssl/pull/5427. Key dispute question is >> whether or not following fragment should work >> >> unsigned char *inp = buf, *out = buf; >> >> for (i = 0; i < sizeof(buf); i++) { >> EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); >> out += outl; >> } > > This should work. On second thought, perhaps not. A block cipher cannot provide output synchronously on byte boundaries. -- Viktor. From matt at openssl.org Wed Feb 28 16:37:33 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 28 Feb 2018 16:37:33 +0000 Subject: [openssl-project] to fully overlap or not to In-Reply-To: <0C04E9B7-7481-4FCD-9EB5-CF9032F5152A@dukhovni.org> References: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org> <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org> <0C04E9B7-7481-4FCD-9EB5-CF9032F5152A@dukhovni.org> Message-ID: <70fabd58-7444-9636-09fd-d7187b08c3f9@openssl.org> On 28/02/18 16:32, Viktor Dukhovni wrote: > > >> On Feb 28, 2018, at 11:25 AM, Viktor Dukhovni wrote: >> >>> I'd like to request more opinions on >>> https://github.com/openssl/openssl/pull/5427. Key dispute question is >>> whether or not following fragment should work >>> >>> unsigned char *inp = buf, *out = buf; >>> >>> for (i = 0; i < sizeof(buf); i++) { >>> EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); >>> out += outl; >>> } >> >> This should work. > > On second thought, perhaps not. A block cipher cannot provide output > synchronously on byte boundaries. > It should still work IMO. With a block size of 16 you should get 15 invocations of EVP_EncryptUpdate where outl is set to 0 afterwards, followed by 1 invocation where outl is set to 16 afterwards. This should still be the case for in-place encryption. Matt From openssl-users at dukhovni.org Wed Feb 28 16:37:06 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 28 Feb 2018 11:37:06 -0500 Subject: [openssl-project] to fully overlap or not to In-Reply-To: <0C04E9B7-7481-4FCD-9EB5-CF9032F5152A@dukhovni.org> References: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org> <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org> <0C04E9B7-7481-4FCD-9EB5-CF9032F5152A@dukhovni.org> Message-ID: <114AEABD-6DC9-45D3-B944-96E24F5512DE@dukhovni.org> > On Feb 28, 2018, at 11:32 AM, Viktor Dukhovni wrote: > >>> I'd like to request more opinions on >>> https://github.com/openssl/openssl/pull/5427. Key dispute question is >>> whether or not following fragment should work >>> >>> unsigned char *inp = buf, *out = buf; >>> >>> for (i = 0; i < sizeof(buf); i++) { >>> EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); >>> out += outl; >>> } >> >> This should work. > > On second thought, perhaps not. A block cipher cannot provide output > synchronously on byte boundaries. Time to stop composing email on the train... I see that the code supports 0-length output, so the block cipher can buffer internally, and periodically output a block. So, back to the first message, it should work, with internal input buffering in the block cipher context until a full block is obtained or EVP_EncryptFinal() is called. Unless that has prohibitive performance impact on existing callers. -- Viktor. From appro at openssl.org Wed Feb 28 17:09:38 2018 From: appro at openssl.org (Andy Polyakov) Date: Wed, 28 Feb 2018 18:09:38 +0100 Subject: [openssl-project] to fully overlap or not to In-Reply-To: <0C04E9B7-7481-4FCD-9EB5-CF9032F5152A@dukhovni.org> References: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org> <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org> <0C04E9B7-7481-4FCD-9EB5-CF9032F5152A@dukhovni.org> Message-ID: <39cb0562-d313-c2d7-8d84-58badaaaf327@openssl.org> >>> I'd like to request more opinions on >>> https://github.com/openssl/openssl/pull/5427. Key dispute question is >>> whether or not following fragment should work >>> >>> unsigned char *inp = buf, *out = buf; >>> >>> for (i = 0; i < sizeof(buf); i++) { >>> EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); >>> out += outl; >>> } >> >> This should work. > > On second thought, perhaps not. It seems that double-clarification is appropriate. As it stands now it *does* work. So question is rather if it should keep working [and if not, is it appropriate that stops working in minor release]. From matt at openssl.org Wed Feb 28 17:21:58 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 28 Feb 2018 17:21:58 +0000 Subject: [openssl-project] to fully overlap or not to In-Reply-To: <39cb0562-d313-c2d7-8d84-58badaaaf327@openssl.org> References: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org> <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org> <0C04E9B7-7481-4FCD-9EB5-CF9032F5152A@dukhovni.org> <39cb0562-d313-c2d7-8d84-58badaaaf327@openssl.org> Message-ID: <2fbd2faa-e236-ca68-3108-1b89bc3de11b@openssl.org> On 28/02/18 17:09, Andy Polyakov wrote: >>>> I'd like to request more opinions on >>>> https://github.com/openssl/openssl/pull/5427. Key dispute question is >>>> whether or not following fragment should work >>>> >>>> unsigned char *inp = buf, *out = buf; >>>> >>>> for (i = 0; i < sizeof(buf); i++) { >>>> EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); >>>> out += outl; >>>> } >>> >>> This should work. >> >> On second thought, perhaps not. > > It seems that double-clarification is appropriate. As it stands now it > *does* work. So question is rather if it should keep working [and if > not, is it appropriate that stops working in minor release]. It should continue to work and must not stop in a minor release. Matt From levitte at openssl.org Wed Feb 28 17:37:48 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 28 Feb 2018 18:37:48 +0100 (CET) Subject: [openssl-project] to fully overlap or not to In-Reply-To: <39cb0562-d313-c2d7-8d84-58badaaaf327@openssl.org> References: <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org> <0C04E9B7-7481-4FCD-9EB5-CF9032F5152A@dukhovni.org> <39cb0562-d313-c2d7-8d84-58badaaaf327@openssl.org> Message-ID: <20180228.183748.735717429235160398.levitte@openssl.org> In message <39cb0562-d313-c2d7-8d84-58badaaaf327 at openssl.org> on Wed, 28 Feb 2018 18:09:38 +0100, Andy Polyakov said: appro> >>> I'd like to request more opinions on appro> >>> https://github.com/openssl/openssl/pull/5427. Key dispute question is appro> >>> whether or not following fragment should work appro> >>> appro> >>> unsigned char *inp = buf, *out = buf; appro> >>> appro> >>> for (i = 0; i < sizeof(buf); i++) { appro> >>> EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); appro> >>> out += outl; appro> >>> } appro> >> appro> >> This should work. appro> > appro> > On second thought, perhaps not. appro> appro> It seems that double-clarification is appropriate. As it stands now it appro> *does* work. So question is rather if it should keep working [and if appro> not, is it appropriate that stops working in minor release]. I'll side with that it should continue to work... and most definitely should NOT stop working in a minor release. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From bernd.edlinger at hotmail.de Wed Feb 28 18:48:03 2018 From: bernd.edlinger at hotmail.de (Bernd Edlinger) Date: Wed, 28 Feb 2018 18:48:03 +0000 Subject: [openssl-project] to fully overlap or not to In-Reply-To: <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org> References: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org> <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org> Message-ID: On 02/28/18 17:25, Viktor Dukhovni wrote: > > >> On Feb 28, 2018, at 5:39 AM, Andy Polyakov wrote: >> >> I'd like to request more opinions on >> https://github.com/openssl/openssl/pull/5427. Key dispute question is >> whether or not following fragment should work >> >> unsigned char *inp = buf, *out = buf; >> >> for (i = 0; i < sizeof(buf); i++) { >> EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); >> out += outl; >> } > > This should work. > It does only work, if you know that ctx->buf_len == 0 before the loop is entered. It does not work with CFB1, CCM, XTS and WRAP modes. There is no access function to get the internal state of the cipher context. I the documentation does not cover this at all, and most of all I really wonder how the wording could look like. Bernd. From pdm at box.com Tue Feb 13 20:07:19 2018 From: pdm at box.com (Phillip Moore) Date: Tue, 13 Feb 2018 20:07:19 -0000 Subject: [openssl-project] FIPS support and sponsorship Message-ID: Hi, I would like to talk with some one about my company possibly sponsoring OpenSSL to get 1.1 or newer enabled with FIPS support. I know there have been some other sponsorships and setbacks from sponsors leaving. I'd like to understand the roadmap for FIPS and what support you need to be able to see a newer version of OpenSSL with FIPS support. Thanks, Phillip Moore -- Phillip Moore Staff Site Reliability Engineer / Box pdm at box.com / 571-213-4323 -------------- next part -------------- An HTML attachment was scrubbed... URL: