Re: [openssl-project] Welcome Dr. Matthias St. Pierre

[Richard Levitte]

In message  on Tue, 23 Jan 
2018 16:35:02 +, "Salz, Rich"  said:

rsalz> In a little while, Richard should have his SSH keys integrated
rsalz> into our systems, and will email him some more detailed
rsalz> instructions.

Done and done!  Welcome, Matthias

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Speaking of releases, did we finalize a release plan for 1.1.1?

[Richard Levitte]

I can't seem to remember a final agreement...  last thing I remember
is a disagreement of what "the last alpha" means in practice, and that
I finally got Matt's point with having it being a feature freeze in
practice.  But a final release plan, I can't remember one.

Time to reiterate this, perhaps?

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] 1.1.1 Release timetable (again)

[Richard Levitte]

In message  on Wed, 24 Jan 
2018 20:48:54 +, Matt Caswell  said:

matt> On 24/01/18 19:12, Salz, Rich wrote:
matt> > A monthly release cadence for beta seems too long.  I would prefer two 
weeks.  And we keep doing that until TLS 1.3 is published.
matt> 
matt> That might be ok. As a technical issue though we can only have a maximum
matt> of 14 alpha/beta releases (due to the format of OPENSSL_VERSION_NUMBER
matt> in opensslv.h). If we were to do a release every 2 weeks starting on
matt> 14th Feb, that would mean the last beta we could possibly do would be on
matt> 15th August.  If there is a risk that the TLSv1.3 publication could go
matt> beyond that date then we would be stuck.

This is the first time, as far as I recall, that we've decided to wait
on someone else for our releases, so I'm thinking that we have the
freedom to decide how to act if there's a delay, for example to delay
our own beta cycle.  It shouldn't be too hard to write a kind of
"caveat emptor" where we say that "should the TLSv1.3 publication be
delayed, we till re-evaluate our plans".

(another way to do it is to refuse making a release plan before we
receive a clear signal that publication *will* happen and when it
will...  after all, we *are* putting ourselves in a kind of hostage
situation)

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Style guide updates

[Richard Levitte]

In message <2a47205b-d7f1-406b-b99b-d0139c075...@akamai.com> on Fri, 26 Jan 
2018 13:26:58 +, "Salz, Rich"  said:

rsalz> Some things I think we should add to the style guide.  Let’s discuss 
here.
rsalz> 
rsalz> No space after sizeof, use parens.  (But see 
ssl/record/rec_layer_{d1,s3}.c )

Yes

rsalz> Multiline conditionals, such as in an if, should be broken
rsalz> before the logical connector and indented an extra tabstop.
rsalz> For example:
rsalz> 
rsalz> while (this_is_true
rsalz>   && that_is_not_false) {
rsalz> frobit();
rsalz> more_stuff();
rsalz> }

Please don't call it a tabstop.  extra indentation if you will, and in
that case, it should be 4 spaces inside the parenthesis.

Now, to have indent do that for us is a whole other story...
(side note: I saw an indent program a few days ago that's quite
promising.  I'll dig it up again)

Frankly, I'm not sure I like this, and strictly speaking, it only has
visual value for 'if' conditionals, since the inside of the
conditional parenthesis is exactly 4 spaces in, and because we break
before operators, I don't see the visual problem, but that's a very
personal viewpoint, YMMV...

rsalz> When dealing with long lines, try to avoid breaking across a function 
call. Don’t do this:
rsalz> If (some_long_text && foo(a,
rsalz>  b, c) && bar()) {
rsalz> Instead do this:
rsalz> If (some_long_text
rsalz> && foo(a, b, c,)
rsalz> && bar())

YES!

rsalz> What else needs to be updated?

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Style guide updates

[Richard Levitte]

In message  on Fri, 26 Jan 
2018 14:06:27 +, Matt Caswell  said:

matt> - Use size_t for sizes of things

... and, it seems, as array index.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Fwd: [openssl-commits] Broken: openssl/openssl#15866 (master - cf8e923)

[Richard Levitte]

I think I said it earlier, that prefixing the output with '#' is a TAP
compatible way to fix this.  One way is to pipe the execution of the
program through a "sed -e 's|^|# |'", except that it's not exactly
portable...  Another way *might* be to open("program |") and handle
the output in OpenSSL::Test.  However, both these solutions will mess
with all the test programs that we've made TAP friendly.

H...

Come to think of it, a third option is to have the openssl program
notice the environment variable 'OPENSSL_HARNESS_PREFIX' that contains
a string to prefix all the output with, and in that case, use a custom
BIO filter that gets pushed on bio_out.

Actually, I think that last idea is the one to go for.

Cheers,
Richard

In message  on Fri, 26 Jan 
2018 16:32:10 +, Matt Caswell  said:

matt> This looks like another instance of this:
matt> 
matt> https://mta.openssl.org/pipermail/openssl-project/2018-January/000140.html
matt> 
matt> i.e. the word "ok" appearing at the beginning of a line in test_store
matt> while it is printing base-64 encoded output - which then confuses TAP
matt> 
matt> Richard - any ideas?
matt> 
matt> Matt
matt> 
matt> 
matt>  Forwarded Message 
matt> Subject:  [openssl-commits] Broken: openssl/openssl#15866 (master - 
cf8e923)
matt> Date: Fri, 26 Jan 2018 16:10:35 +
matt> From: Travis CI 
matt> To:   openssl-comm...@openssl.org
matt> 
matt> 
matt> 
matt> *openssl / openssl
matt> 
*
matt> (master )
matt> 
matt>   Build #15866 was broken.
matt> 

matt>   
matt> 28 minutes and 51 seconds
matt>   *Benjamin Kaduk*cf8e923
matt> 

matt> Changeset →
matt> 
matt>   Catch some more old sigalg names in comments
matt> 
matt> Make the sigalg name in comments reflect one that actually exists
matt> in the draft standard.
matt> 
matt> Reviewed-by: Matt Caswell 
matt> (Merged from https://github.com/openssl/openssl/pull/5174)
matt> 
matt> *Want to know about upcoming build environment updates?*
matt> 
matt> Would you like to stay up-to-date with the upcoming Travis CI build
matt> environment updates? We set up a mailing list for you! Sign up here
matt> .
matt> 
matt>   Documentation  about Travis CI
matt> Need help? Mail support !
matt> Choose who receives these build notification emails in your
matt> configuration file .
matt> 
matt> *Would you like to test your private code?*
matt> 
matt> Travis CI for Private Projects
matt> 

matt> could be your new best friend!
matt> 
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] travis builds failing with aligment errors?

[Richard Levitte]

In message  on Tue, 30 Jan 
2018 14:32:33 +, Matt Caswell  said:

matt> 
matt> 
matt> On 30/01/18 14:30, Matt Caswell wrote:
matt> > 
matt> > 
matt> > On 30/01/18 14:27, Benjamin Kaduk wrote:
matt> >> It seems that we've started getting issues with a single build
matt> >> configuration, e.g.,
matt> >> https://travis-ci.org/openssl/openssl/jobs/335110257
matt> >>
matt> >> Lots of complaints about alignment, like:
matt> >>
matt> >> crypto/modes/gcm128.c:1090:36: runtime error: load of misaligned
matt> >> address 0x02350ce5 for type 'const size_t' (aka 'const unsigned
matt> >> long'), which requires 8 byte alignment
matt> >> 0x02350ce5: note: pointer points here
matt> >>  68 1f ea 3b 14 00 00  0c 00 02 00 00 00 00 00  0c a3 35 89 7d a7 5e 
9e  87 fa d7 fd 8b c7 34 8a  8d
matt> >>  ^ 
matt> >> I didn't see anything particularly special about that configuration
matt> >> on a quick once-over; any ideas?
matt> > 
matt> > I raised an issue on this with some of my thoughts and investigation:
matt> > 
matt> > https://github.com/openssl/openssl/issues/5203
matt> > 
matt> > 
matt> > The error message about unsigned int requiring 8 byte alignment seems
matt> > suspicious to me. Shouldn't it be 4?
matt> 
matt> Oh...sorry just realised this is a slightly different but very similar
matt> error. In my issue it is complaining about an unsigned int requiring 8
matt> byte alignment. This issue is for an unsigned long.

So, err, ubsan isn't my forte, so I have to ask, shouldn't the
-fno-sanitize=alignment that's added in both cases have us avoid
this kind of message?  I.e. we know that we break alignment in some
cases, but that happens to be fine on those machines?

(for crypto/modes/gcm128.c, alignment should depend very much on |in|
and |out|, and if you look, you'll see that there are some checks if
STRICT_ALIGNMENT is defined, and you'll find in crypto/modes/modes_lcl.h
that it's undefined, so we obviously think we know what we're doing)

...

Hmmm, I think I know!  The configuration line is (if shortened to an
absolute minimum):

./config enable-ubsan -fno-sanitize-alignment

In 1.1.0 (and in master about a week ago), we got these flags among
the CFLAGS, in this order (actually, the last one is absolutely last):

-fsanitize=undefined -fno-sanitize-recover=all
-fno-omit-frame-pointer -fno-sanitize=alignment

In master now, we get this:

-fno-sanitize=alignment -fsanitize=undefined
-fno-sanitize-recover=all -fno-omit-frame-pointer

I just tried a fresh master and hacked reordered CFLAGS in Makefile to
-fno-sanitize=alignment last, and suddenly, the tests work.

So, err, I screwed up with the recent changes in Configure, in adding
the user added flags much too early to $config{cflags} and so on.

I'm on it, you should see a PR show up soon.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] chatty make output

[Richard Levitte]

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.___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] chatty make output

[Richard Levitte]

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: "levi...@openssl.org" 
>Reply-To: "openssl-project@openssl.org" 
>Date: Thursday, February 1, 2018 at 12:50 PM
>To: "openssl-project@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.___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] chatty make output

[Richard Levitte]

In message <21e9cf89-dbcf-1b0e-5269-fb508e85e...@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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] OS/X builds failing

[Richard Levitte]

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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] should doc-nits flag long lines?

[Richard Levitte]

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.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Fwd: [openssl-commits] Broken: openssl/openssl#15676 (master - e44c7d0)

[Richard Levitte]

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@openssl.org
>https://mta.openssl.org/mailman/listinfo/openssl-project

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl-commits] Copyright warnings for refs/heads/master

[Richard Levitte]

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-...@dev.openssl.org"
> wrote:
>
>The following files seem to need a copyright year update:
>util/openssl-update-copyright
>
>
>___
>openssl-project mailing list
>openssl-project@openssl.org
>https://mta.openssl.org/mailman/listinfo/openssl-project

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Removing assembler for outdated algorithms

[Richard Levitte]

In message <3eac8b7f-ea48-465b-b4be-3d5ac62d9...@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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Removing assembler for outdated algorithms

[Richard Levitte]

In message <0ea60701-6e1a-4fe0-86f8-33b37d016...@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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Removing assembler for outdated algorithms

[Richard Levitte]

In message <20180210223253.gr3...@mournblade.imrryr.org> on Sat, 10 Feb 2018 
22:32:53 +, Viktor Dukhovni  said:

viktor> On Sat, Feb 10, 2018 at 10:19:20PM +, 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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Removing assembler for outdated algorithms

[Richard Levitte]

"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@openssl.org
>https://mta.openssl.org/mailman/listinfo/openssl-project

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Removing assembler for outdated algorithms

[Richard Levitte]

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@openssl.org
>https://mta.openssl.org/mailman/listinfo/openssl-project

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Code freeze later today

[Richard Levitte]

In message <0334edc9-5b9c-8fd4-66a8-ea0b277e9...@openssl.org> on Mon, 12 Feb 
2018 11:24:24 +, 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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Code Freeze!!!

[Richard Levitte]

In message <48d370b8-6fbc-2047-3b02-35049d010...@openssl.org> on Mon, 12 Feb 
2018 15:04:36 +, 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.openssl.org freeze openssl matt
matt> 
matt> Thanks

Done

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] VOTE on travel reimbursement policy

[Richard Levitte]

In message <20180214212414.ga13...@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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Sick with the flu

[Richard Levitte]

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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] to fully overlap or not to

[Richard Levitte]

In message <39cb0562-d313-c2d7-8d84-58badaaaf...@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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] External contributors and the next release

[Richard Levitte]

In message <51cf9902-32af-4d08-82ec-6bca04af5...@akamai.com> on Wed, 7 Mar 2018 
01:20:41 +, "Salz, Rich"  said:

rsalz> I think we should make sure to set aside time to review as many
rsalz> of the non-project pull requests as possible. I think it is
rsalz> important to show a commitment to the larger community.

I agree.

rsalz> One way to do this is to say that we will extend the BETA date
rsalz> by a week, and in that week no new code from the team, only
rsalz> third-party existing pull requests will be considered

I like this idea.  +1

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] VOTE report: Push the release of 1.1.1 beta1 (pre3) forward one week

[Richard Levitte]

I started a vote moments ago on the OMC list with the content that
follows.  The OMC will vote on it, hopefully on time, and the
resulting tally will be posted here.

Vote text:

NOTE: THREE DAY VOTE
Why?  Because beta1 is currently scheduled to be released in three
days.  A longer voting period would hold the release hostage in
practice, and thereby force a push of the release date regardless of
the vote result.

--
topic: Push the release of 1.1.1 beta1 (pre3) forward one week

   Reason: we have a number of unreviewed PRs on github marked
   1.1.1 and time is getting short.

   All other current future release dates will be pushed one week as well.
   https://www.openssl.org/policies/releasestrat.html will be updated.
   An official announcement should be made.
Proposed by Richard Levitte
Public: yes
opened: 2018-03-10
closed: -mm-dd
THREE DAY VOTE!

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] VOTE report: Push the release of 1.1.1 beta1 (pre3) forward one week

[Richard Levitte]

In message <20180310124318.ga26...@roeckx.be> on Sat, 10 Mar 2018 13:43:18 
+0100, Kurt Roeckx  said:

kurt> On Sat, Mar 10, 2018 at 11:45:46AM +0100, Richard Levitte wrote:
kurt> > Vote text:
kurt> > 
kurt> > NOTE: THREE DAY VOTE
kurt> > Why?  Because beta1 is currently scheduled to be released in three
kurt> > days.  A longer voting period would hold the release hostage in
kurt> > practice, and thereby force a push of the release date regardless of
kurt> > the vote result.
kurt> 
kurt> As explained by Rich on the OMC list, we can't have that. I assume
kurt> it's a 1 week vote. But the vote can be closed earlier.

Well, the condition for this vote is a bit extraordinary as well.  I
couldn't in good conscience propose a week long vote, because that
potentially would have the effect to push the release a week anyway,
because the release would have to wait for the result of the vote.

Basically, it's a catch 22 that noone thought of...

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] VOTE report: Push the release of 1.1.1 beta1 (pre3) forward one week

[Richard Levitte]

The vote closes today with 6 +1's, 0 -1's and one not voted.

In other words, the 1.1.1 pre3 (beta1) release is pushed to Tuesday,
March 20th, and the dates following are to be adjusted accordingly.

Cheers,
Richard

In message <20180310.114546.780593698922932617.levi...@openssl.org> on Sat, 10 
Mar 2018 11:45:46 +0100 (CET), Richard Levitte  said:

levitte> I started a vote moments ago on the OMC list with the content that
levitte> follows.  The OMC will vote on it, hopefully on time, and the
levitte> resulting tally will be posted here.
levitte> 
levitte> Vote text:
levitte> 
levitte> NOTE: THREE DAY VOTE
levitte> Why?  Because beta1 is currently scheduled to be released in three
levitte> days.  A longer voting period would hold the release hostage in
levitte> practice, and thereby force a push of the release date regardless of
levitte> the vote result.
levitte> 
levitte> --
levitte> topic: Push the release of 1.1.1 beta1 (pre3) forward one week
levitte> 
levitte>Reason: we have a number of unreviewed PRs on github marked
levitte>1.1.1 and time is getting short.
levitte> 
levitte>All other current future release dates will be pushed one week 
as well.
levitte>https://www.openssl.org/policies/releasestrat.html will be 
updated.
levitte>    An official announcement should be made.
levitte> Proposed by Richard Levitte
levitte> Public: yes
levitte> opened: 2018-03-10
levitte> closed: -mm-dd
levitte> THREE DAY VOTE!
levitte> 
levitte> -- 
levitte> Richard Levitte levi...@openssl.org
levitte> OpenSSL Project http://www.openssl.org/~levitte/
levitte> ___
levitte> openssl-project mailing list
levitte> openssl-project@openssl.org
levitte> https://mta.openssl.org/mailman/listinfo/openssl-project
levitte> 
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Updated 1.1.1 release timetable

[Richard Levitte]

Following the vote to change the coming release dates, the release
timetable has been change to the following:

  * 13th February 2018, alpha release 1 (pre1)
  * 27th February 2018, alpha release 2 (pre2)
  * 20th March 2018, beta release 1 (pre3)
- OpenSSL_1_1_1-stable created (feature freeze)
- master becomes basis for 1.1.2 or 1.2.0 (TBD)
  * 3rd April 2018, beta release 2 (pre4)
  * 17th April 2018, beta release 3 (pre5)
  * 1st May 2018, beta release 4 (pre6)
  * 8th May 2018, release readiness check (new release cycles added if
required, first possible final release date: 15th May 2018)

See https://www.openssl.org/policies/releasestrat.html for a reminder
of all details.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] OID policy

[Richard Levitte]

In message <6f9a7c53-f40f-4794-bf1a-f59eb1db6d4b@default> on Wed, 14 Mar 2018 
16:40:24 -0700 (PDT), Paul Dale  said:

paul.dale> > We should have OID's for the things we implement
paul.dale> 
paul.dale> Sounds like a policy :)
paul.dale> Vote time?

Not sure if there's a need for a vote.  I'll just wait for the PR ;-)

Thing is, we probably have no need for the OIDs in the library, just
the names, as long as they don't have to be included in any DER stuff
we generate or parse.  Each name becomes an object and a NID anyway,
and that's all we need internally.

So in some cases, OIDs are more "nice to have" than useful, although
they might become useful in the future, so it's never wrong to include
the actual official OIDs when they're available.

So can I assume there's a PR coming up?  Policy wise, I think that's
what it takes, plus the approval.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] OID policy

[Richard Levitte]

In message <20180315.090502.2143972695067215526.levi...@openssl.org> on Thu, 15 
Mar 2018 09:05:02 +0100 (CET), Richard Levitte  said:

levitte> So can I assume there's a PR coming up?

Ah, saw it!

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] GitHub milestone for 1.1.1

[Richard Levitte]

Andy has indicated that the rather special construction to get command line C 
macro definitions and include paths specs collected in one place (*) is perhaps 
too special and could be handle by parsing CPPFLAGS and extra multiple 
definitions to get them collected in one spot.

I have some ideas on how to do that, but wonder if that would be considered a 
new feature with regards to the beta release (we can stop talking now in that 
case) or if this would be considered a fix. That will decide if it's even worth 
an effort.

Note: this affects VMS only, at least re make variables.

Cheers
Richard

(*) Unix and windows handles those with -D and -I flags that can be spread out 
all over the command line. VMS command lines work a bit differently, and the C 
compiler complies with that standard, so *all* macros must be collected in 
*one* qualifiers (VMS terminology where the Unix guy would say "flag" or 
possibly "option"), like this:

 /DEFINE=(MACRO1, MACRO2="Foo", "Macro3=bar")

The same goes for include paths, similarly collected in the qualifier /INCLUDE


Matt Caswell  skrev: (19 mars 2018 10:12:06 CET)
>
>
>On 19/03/18 08:27, Dr. Matthias St. Pierre wrote:
>> Hi,
>> 
>> in view of the upcoming beta release and the release strategy (see
>> below) it is a little bit disturbing that our GitHub milestone for
>1.1.1
>>  shows only 30%
>> completion. How are we going to deal with this?
>
>Up until now, understandably, people have been focusing on getting the
>required features in. My expectation is that, once we're past the beta
>release and new features are no longer allowed for 1.1.1, focus will
>shift to closing off as many of the open issues/PRs as possible.
>
>> Shouldn't the PR's and
>> issues be examined and categorized into bugs and features? The former
>> could still be merged during beta, but what happens to the latter?
>What
>> is with outstanding documentation (e.g. #5461, #5629), will it be
>> treated like a bugfix and be mergeable past the beta freeze?
>
>Mostly, I think what remains are bugs and not features. If there are
>features then no one cared enough about them to push them forward to
>get
>into 1.1.1 and so we should reclassify them with a post-1.1.1
>milestone.
>In some exceptional cases, if someone can make a good enough case, we
>might consider merging them during the beta - but that might take an
>omc
>vote, so the case would have to be very strong.
>
>We have always treated missing documentation as a bug so I don't see a
>problem there.
>
>Matt
>
>> 
>> Regards,
>> Matthias
>> 
>> --
>> We have defined the following release criteria for 1.1.1:
>> 
>> All open github issues/PRs older than 2 weeks at the time of release
>to
>> be assessed for relevance to 1.1.1. Any flagged with the 1.1.1
>milestone
>> to be closed (see below)
>> Clean builds in Travis and Appveyor for two days
>> run-checker.sh to be showing as clean 2 days before release
>> No open Coverity issues (not flagged as "False Positive" or "Ignore")
>> TLSv1.3 RFC published
>> https://www.openssl.org/policies/releasestrat.html
>> 
>> 
>> ___
>> openssl-project mailing list
>> openssl-project@openssl.org
>> https://mta.openssl.org/mailman/listinfo/openssl-project
>> 
>___
>openssl-project mailing list
>openssl-project@openssl.org
>https://mta.openssl.org/mailman/listinfo/openssl-project

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] GitHub milestone for 1.1.1

[Richard Levitte]

In message <15c91d39-bf3c-86e7--756bc942d...@ncp-e.com> on Mon, 19 Mar 2018 
09:27:40 +0100, "Dr. Matthias St. Pierre"  said:

Matthias.St.Pierre> Hi,
Matthias.St.Pierre> 
Matthias.St.Pierre> in view of the upcoming beta release and the release 
strategy (see
Matthias.St.Pierre> below) it is a little bit disturbing that our GitHub 
milestone for 1.1.1
Matthias.St.Pierre> <https://github.com/openssl/openssl/milestone/9> shows only 
30%
Matthias.St.Pierre> completion. How are we going to deal with this? Shouldn't 
the PR's and
Matthias.St.Pierre> issues be examined and categorized into bugs and features? 
The former
Matthias.St.Pierre> could still be merged during beta, but what happens to the 
latter? What
Matthias.St.Pierre> is with outstanding documentation (e.g. #5461, #5629), will 
it be
Matthias.St.Pierre> treated like a bugfix and be mergeable past the beta freeze?

I'd categorically say that missing documentation is a bug.  That
should make categorisation a bit easier...

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] GitHub milestone for 1.1.1

[Richard Levitte]

In message <7aa44215-febf-73d2-3d0f-12f99b44b...@openssl.org> on Mon, 19 Mar 
2018 11:14:27 +, Matt Caswell  said:

matt> 
matt> 
matt> On 19/03/18 10:58, Richard Levitte wrote:
matt> > Andy has indicated that the rather special construction to get command 
line C macro definitions and include paths specs collected in one place (*) is 
perhaps too special and could be handle by parsing CPPFLAGS and extra multiple 
definitions to get them collected in one spot.
matt> > 
matt> > I have some ideas on how to do that, but wonder if that would be 
considered a new feature with regards to the beta release (we can stop talking 
now in that case) or if this would be considered a fix. That will decide if 
it's even worth an effort.
matt> 
matt> Well what is a "fix" has always been a bit of a grey area.
matt> 
matt> Does the proposed change offer new capabilities to the user that they
matt> didn't have before?
matt> 
matt> If the answer is "yes" that tends to indicate a feature.

So I'll answer "yes and no", with a bit of explanation.

The whole thing with supporting the use of "make variables" with
Configure in GNU autoconf style is a new feature, but that's already
in, so I count that is already existing capabilities re the beta
release.

Being able to define macros and include directories via CPPFLAGS is
thusly already available...  except that for VMS users, we have
CPPDEFINES and CPPINCLUDES to deal with the VMS command line syntax.

So phrased "being able to define extra C macros and include
directories via 'make variables' when configuring", this is not a new
capability.  However, phrased "being able to define extra C macros and
include directories via CPPFLAGS in when configuring", this could be
viewed as a new capability.

matt> Does the proposed change fix existing capabilities so that they
matt> work as originally intended?
matt> 
matt> An answer of "yes" to that tends to indicate a fix.

Well, I could say "yes" if the original intent is phrased "CPPFLAGS
is used for all C preprocessor flags"...  which is the usual intent,
at least on platforms with Unix style flags, and considering CPPFLAGS
has originated on Unix as far as I know, ...

matt> I haven't got a good understanding of the particular change you
matt> are proposing to be able to say where in all of this that one
matt> fits.

The idea I have would affect Configurations/descrip.mms.tmpl more or
less entirely, and would be to parse $config{CPPFLAGS}, extract and
put aside any macro definitions and include directory specs and put
back the rest of what was parsed back in $config{CPPFLAGS}, and use
the extracted macro definitions and include directory specs further
on, in these lines:

DEFINES={- our $defines1 = join('', map { ",$_" } @{$config{CPPDEFINES}}) -}
INCLUDES={- our $includes1 = join(',', @{$config{CPPINCLUDES}}) -}

What happens in practice is that $config{CPPDEFINES} and
$config{CPPINCLUDES} would stop existing, and template internal
variables would take their place in those two lines.

And of course, all traces of CPPDEFINES and CPPINCLUDES would be
removed anywhere else...  that's mostly config and Configure.

Cheers,
Richard

matt> 
matt> Matt
matt> 
matt> > 
matt> > Note: this affects VMS only, at least re make variables.
matt> > 
matt> > Cheers
matt> > Richard
matt> > 
matt> > (*) Unix and windows handles those with -D and -I flags that can be 
spread out all over the command line. VMS command lines work a bit differently, 
and the C compiler complies with that standard, so *all* macros must be 
collected in *one* qualifiers (VMS terminology where the Unix guy would say 
"flag" or possibly "option"), like this:
matt> > 
matt> >  /DEFINE=(MACRO1, MACRO2="Foo", "Macro3=bar")
matt> > 
matt> > The same goes for include paths, similarly collected in the qualifier 
/INCLUDE
matt> > 
matt> > 
matt> > Matt Caswell  skrev: (19 mars 2018 10:12:06 CET)
matt> >>
matt> >>
matt> >> On 19/03/18 08:27, Dr. Matthias St. Pierre wrote:
matt> >>> Hi,
matt> >>>
matt> >>> in view of the upcoming beta release and the release strategy (see
matt> >>> below) it is a little bit disturbing that our GitHub milestone for
matt> >> 1.1.1
matt> >>> <https://github.com/openssl/openssl/milestone/9> shows only 30%
matt> >>> completion. How are we going to deal with this?
matt> >>
matt> >> Up until now, understandably, people have been focusing on getting the
matt> >> required features in. My expectation is that, once we're past the beta
matt> &g

Re: [openssl-project] GitHub milestone for 1.1.1

[Richard Levitte]

Ok.  I see it the same way, and indications are that others would
agree as well...

In message  on Mon, 19 Mar 
2018 11:56:23 +, Matt Caswell  said:

matt> This is definitely in the grey area, but I tend to think it is more
matt> towards the "fix" side than the "feature" side. Also the risk is
matt> significantly mitigated by it only impacting VMS.
matt> 
matt> Matt
matt> 
matt> 
matt> On 19/03/18 11:52, Richard Levitte wrote:
matt> > In message <7aa44215-febf-73d2-3d0f-12f99b44b...@openssl.org> on Mon, 
19 Mar 2018 11:14:27 +, Matt Caswell  said:
matt> > 
matt> > matt> 
matt> > matt> 
matt> > matt> On 19/03/18 10:58, Richard Levitte wrote:
matt> > matt> > Andy has indicated that the rather special construction to get 
command line C macro definitions and include paths specs collected in one place 
(*) is perhaps too special and could be handle by parsing CPPFLAGS and extra 
multiple definitions to get them collected in one spot.
matt> > matt> > 
matt> > matt> > I have some ideas on how to do that, but wonder if that would 
be considered a new feature with regards to the beta release (we can stop 
talking now in that case) or if this would be considered a fix. That will 
decide if it's even worth an effort.
matt> > matt> 
matt> > matt> Well what is a "fix" has always been a bit of a grey area.
matt> > matt> 
matt> > matt> Does the proposed change offer new capabilities to the user that 
they
matt> > matt> didn't have before?
matt> > matt> 
matt> > matt> If the answer is "yes" that tends to indicate a feature.
matt> > 
matt> > So I'll answer "yes and no", with a bit of explanation.
matt> > 
matt> > The whole thing with supporting the use of "make variables" with
matt> > Configure in GNU autoconf style is a new feature, but that's already
matt> > in, so I count that is already existing capabilities re the beta
matt> > release.
matt> > 
matt> > Being able to define macros and include directories via CPPFLAGS is
matt> > thusly already available...  except that for VMS users, we have
matt> > CPPDEFINES and CPPINCLUDES to deal with the VMS command line syntax.
matt> > 
matt> > So phrased "being able to define extra C macros and include
matt> > directories via 'make variables' when configuring", this is not a new
matt> > capability.  However, phrased "being able to define extra C macros and
matt> > include directories via CPPFLAGS in when configuring", this could be
matt> > viewed as a new capability.
matt> > 
matt> > matt> Does the proposed change fix existing capabilities so that they
matt> > matt> work as originally intended?
matt> > matt> 
matt> > matt> An answer of "yes" to that tends to indicate a fix.
matt> > 
matt> > Well, I could say "yes" if the original intent is phrased "CPPFLAGS
matt> > is used for all C preprocessor flags"...  which is the usual intent,
matt> > at least on platforms with Unix style flags, and considering CPPFLAGS
matt> > has originated on Unix as far as I know, ...
matt> > 
matt> > matt> I haven't got a good understanding of the particular change you
matt> > matt> are proposing to be able to say where in all of this that one
matt> > matt> fits.
matt> > 
matt> > The idea I have would affect Configurations/descrip.mms.tmpl more or
matt> > less entirely, and would be to parse $config{CPPFLAGS}, extract and
matt> > put aside any macro definitions and include directory specs and put
matt> > back the rest of what was parsed back in $config{CPPFLAGS}, and use
matt> > the extracted macro definitions and include directory specs further
matt> > on, in these lines:
matt> > 
matt> > DEFINES={- our $defines1 = join('', map { ",$_" } 
@{$config{CPPDEFINES}}) -}
matt> > INCLUDES={- our $includes1 = join(',', @{$config{CPPINCLUDES}}) -}
matt> > 
matt> > What happens in practice is that $config{CPPDEFINES} and
matt> > $config{CPPINCLUDES} would stop existing, and template internal
matt> > variables would take their place in those two lines.
matt> > 
matt> > And of course, all traces of CPPDEFINES and CPPINCLUDES would be
matt> > removed anywhere else...  that's mostly config and Configure.
matt> > 
matt> > Cheers,
matt> > Richard
matt> > 
matt> > matt> 
matt> > matt> Matt
matt> > matt> 
matt> > matt> > 
matt> > matt> > Note: this affects VMS only, at least re make 

Re: [openssl-project] GitHub milestone for 1.1.1

[Richard Levitte]

In message <001364a7-e3c5-4e2b-8f0b-6ed1a041f...@akamai.com> on Mon, 19 Mar 
2018 12:27:19 +, "Salz, Rich"  said:

rsalz> I would consider it a bug-fix FWIW.
rsalz> 
rsalz> I thought we extended the deadline so that we could review more
rsalz> third-party PR's.I'm still waiting on an e_os/Microsoft
rsalz> cleanup, but getting community stuff in is more important.

I did a quick sweep last week through those that were marked with
milestone 1.1.1 or no milestone at all, and found most to be of the
category "fix"...  there were a few that I was wondering about, and I
hope I at least pinged them.

There's one I know where we need to make a judgement call.  PR 4793
"(WIP) An implementation of the Chinese SM2 ECC".  I intended to have
a look last week, but didn't.  That one's a lot for me to take in, and
ECC is most decidly not one of my fortes...

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] GitHub milestone for 1.1.1

[Richard Levitte]

In message <97cff4a5-de0e-4d17-8a07-242961d6f...@akamai.com> on Mon, 19 Mar 
2018 12:47:05 +, "Salz, Rich"  said:

rsalz> Yes, SM2 ECC is a big one that seems to have fallen thru the cracks. And 
4848. That is *very* unfortunate.
rsalz> 
rsalz> Instead time and energy went to FIXING Android, configure command-line, 
and various no-XXX builds. 

I just looked through the SM2 PR and apart from a need for rebase
(which is all about 'make update', so quite frankly, I think that can
fall on whoever merges...  I'm just tried, it took me 5 minutes).

I'm willing to approve it as it stands.  Everything that stung my eye
earlier has been changed to something a lot better.  The only thing
that still stings my eye is those public SM2 functions, but I would
see their removal as a fix, so...

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Anything else to go in before I call the freeze?

[Richard Levitte]

In message <1ab966c8-02d4-cf1f-504a-a54999a7c...@openssl.org> on Mon, 19 Mar 
2018 16:33:57 +, Matt Caswell  said:

matt> Let me know asap...

#5662 #5663

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Code Repo

[Richard Levitte]

Why do you want to rush it?  A month earlier than what we've currently
scheduled is in 4 weeks.  I think the added stress will do nothing
good for us, or our community.

In message  on Tue, 20 Mar 
2018 17:57:45 +, "Salz, Rich"  said:

rsalz> Therefore, we could have the release done a month earlier if we
rsalz> wanted to open master for non-release things.
rsalz> 
rsalz> 
rsalz> On 3/20/18, 1:54 PM, "Benjamin Kaduk"  wrote:
rsalz> 
rsalz> On Wed, Mar 21, 2018 at 12:27:13AM +1000, Tim Hudson wrote:
rsalz> > We have been holding off on post-1.1.1 feature development for a 
long time
rsalz> > now - on the grounds that TLSv1.3 was just around the corner etc 
and the
rsalz> > release was close - and then we formed a release plan which we 
pushed back
rsalz> > a week.
rsalz> 
rsalz> I expect TLS 1.3 to be sent to the RFC Editor in the next day.
rsalz> 
rsalz> -Ben
rsalz> ___
rsalz> openssl-project mailing list
rsalz> openssl-project@openssl.org
rsalz> https://mta.openssl.org/mailman/listinfo/openssl-project
rsalz> 
rsalz> 
rsalz> ___
rsalz> openssl-project mailing list
rsalz> openssl-project@openssl.org
rsalz> https://mta.openssl.org/mailman/listinfo/openssl-project
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] constification on already released branches

[Richard Levitte]

In message  
on Mon, 26 Mar 2018 08:36:17 +1000, Tim Hudson  said:

tjh> https://github.com/openssl/openssl/pull/2181
tjh> and
tjh> https://github.com/openssl/openssl/pull/1603#issuecomment-248649700
tjh> 
tjh> One thing that should be noted is that if you are building with
tjh> -Wall -Werror (which many projects do) and you are using OpenSSL
tjh> and things change from a const perspective builds break - and
tjh> that then ends up people having to change code on released
tjh> versions.
tjh> 
tjh> Adding or removing const changes the API.

I would like to point out that we're looking at two different const
changes, and the distinction *is* important.

One constification is changing the constness of a function's input
parameter.
Another constification is changing a function's return type.

The impact of these two types of constification is very different (I
would say "obviously", but I might be wrong, it might not be obvious
to everyone), and they should be regarded different, not piled
together in one "we do / do not allow constification in released
branches".  I'm going to argue that even though there are cases where
one type of constification affects the other (such as constifying an
input parameter might force a constification of the return type), they
can still be looked at individually, and policy can be made on them
individually.

tjh> We should have a clear policy on doing this sort of thing in
tjh> released code - either it is okay to do and we should accept
tjh> patches - or it should never actually be done. I don't see this
tjh> as a case-by-case basis for determination at all - basically it
tjh> is a single type of API change we either should be allowing or
tjh> disallowing.

(a reminder: we're talking about *two* types of API changes that both
involve 'const', not a single API change).

I agree.  We currently have a kinda sorta policy that's quite vaguely
formulated in the FAQ (https://www.openssl.org/docs/faq.html#MISC7),
and we do have something formulated in the release strategy
(https://www.openssl.org/policies/releasestrat.html) as well.  I'll
note that none of them says "the API must not change".  As a matter of
fact, the release strategy only mentions binary compatibility (i.e.
talks exclusively about ABI compatibility).  The FAQ does mention
source (i.e. API) compatibility, formulated as an implication:

   Changes to the middle number are considered major releases and
   neither source nor binary compatibility is guaranteed.

This implies that we do guarantee source and binary compatibility.
What that means exactly is left for us to discuss and decide upon.
I would like to suggest that there should be a document where we
collect what we think "compatibility" means, i.e. what we allow and
disallow ourselves to do.  Kind of a declaration of intention, if you
will.  This should be a document that can be edited over time (but
with great care), and such changes should be voted on, of course.

tjh> There is a similar type of API change which is adding typedefs in
tjh> for callbacks - which technically also don't change the ABI - and
tjh> if we allow any form of API change that also could be
tjh> considered.
tjh> 
tjh> We should discuss this separate from any specific PR and vote to
tjh> set a policy one way or the other in my view.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] cppflags, cflags and ldflags

[Richard Levitte]

Note: this mail follows the discussion on github started here:
https://github.com/openssl/openssl/pull/5742#discussion_r176919954
That discussion started as a simple side note, but I should probably
have known better...  it ends up derailing a PR that shouldn't really
be affected, so I'm bringing the discussion here.

The discussion is about the division of flags for the different parts
of building programs, shared libraries and DSOs.

So we have one side that argues for putting the majority of the flags
in the cflags variable / config attribute.  To quote from the github
discussion:

> Or to put a little bit more practical spin on it. Since we *do* pass
> cflags at *all* stages, it's only appropriate to assign multi-stage
> flags [such as -pthread] to cflags. Viewing it from another angle,
> only pure single-stage flags [such as -L ,-l, -I, -D] are
> appropriate to separate as make variables. And to variables specific
> to corresponding stage, not some other grouping. Last remark is
> reference to the fact and if one follows suggested logic [that
> presented classification imposes specific separation as make
> variables], you'd have to pass -L at pre-processor stage and -I at
> linker, because they both are listed in "Directory Options".

My spin on it goes in a different direction.  It's true that we
*currently* pass cflags to all stages.  I would argue, though, that
this is mostly because we assume that the cc command is an appropriate
frontend for everything involving building the stuff.  Enters the odd
ball that needs to use the linker (som form of ld) directly [1],
because that's what makes practical sense, or simply because that's
how things work on that platform, and suddenly, it's obviously
*inappropriate* to pass cflags on that command.  In assuming that we
can always pass cflags, we're making live difficult for those who want
to make things work on platforms that don't quite meet that assumption.

So following my spin, I would rather say that any flag that affects
preprocessing should go into cppflags, any flag that affects linking
should go into ldflags (the attribute lflags), the rest can go to
cflags.  And for compartmentalization, I'd like to see that:

- for preprocessing, only cppflags are used.  (note: this is more of a
  wishlist, not really terribly important for now...)
- for compiling (i.e. source code to object code), cppflags and cflags
  are used (I cannot see how one would make that differently).
- for linking, only ldflags should be used.  (this I think is
  important!)


[1] Just in case you wonder, there is a use case for using the linker
directly instead of using cc as a frontend:
https://github.com/openssl/openssl/issues/5087

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] rule-based building attributes (Re: cppflags, cflags and ldflags)

[Richard Levitte]

Branching a specific thread around these ideas.

In message  on Sun, 25 Mar 
2018 18:45:40 +0200, Andy Polyakov  said:

appro> > Another side thing that I've been thinking of for quite a while, and I
appro> > think you may have argued for even though I feel a bit unsure, and
appro> > that's to support command line attributes as an alternative to that
appro> > increasing amount of specialised attributes, so something like this:
appro> > 
appro> >link => '$(CCLD) $(LDFLAGS) -o $@ ...',
appro> 
appro> You've mentioned once that it would take a special language to do that
appro> something, and I recall myself thinking "why not just use make syntax".
appro> I'm unsure if I actually said this, but I did think the thought. So that
appro> I for one wouldn't actually be opposed to something like this. It's just
appro> a way to specify "override" rule (and on per-toolchain basis:-).
appro> However! It all depends on whether or not straight make syntax would
appro> actually be expressive enough in the context. If it is, then it would be
appro> totally appropriate. But if not, then ... I'm not so sure. Maybe[!]
appro> if-else in makefile template could turn out to be more appropriate.
appro> (Once again, each clause in if-else is isolated and complexity is
appro> linearly proportional to number of clauses in if-else, which is viewed
appro> as advantage.)

Straight make syntax will probably not cut it.  How would you pass a
list of object file names to something that might have a limited
command line length, for example?  With nmake, we do have a feature we
can use, the inline file text thing, but others may not be so lucky
(the nonstop case I mentioned is such a case), and one might need to
do a bit of pre-processing with perl-level variables (an idea could be
to have some well defined hooks that users can define values for, such
as function names...  again, this is a draft of an idea).  For
example, imagine that we have something that dumps object file names
into a text file and then expects that file name to appear in the
linking command line (for example, and typically in our case), how do
we pass the text file name to the command line, and where in the
command line?

So no, a straight makefile rule for a config attribute value isn't
going to be good enough.


Coming back to costs, I would think that this direction might actually
reduce it for us as it avoids all those gazillion specialized
attributes (I've grown to dislike them too, FYI), and at the same time
become general enough to help users who want to use our stuff for
their own oddball platform to do so, with our blessing...  and I hope
that it helps us as well.

But, this line of ideas is a major change in the how the config
targets work (although I can see a smooth transition from one to the
other, so it's not like we *have* to wait until OpenSSL 1.2 to
implement it), and it is some work to get through with it.  I see
enough benefits to want to, though, and am currently in the mood of
bouncing ideas as time permits (*).

Cheers,
Richard

(*) no, I haven't forgotten that we have a primary focus in fixing
stuff that needs fixing before the final 1.1.1 release.  But it's
Sunday right now, tomorrow will be more focused.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] cppflags, cflags and ldflags

[Richard Levitte]

s more of an incidental thing that really comes down to my
laziness.  And frankly, I have *zero* desire to lock them in
permanently for specific compilers and will not work for such lock
in).

And yeah, I get that the config targets need to be reshaped for this.
That's your main argument, isn't it?  Is that so actually so costly?

Another side thing that I've been thinking of for quite a while, and I
think you may have argued for even though I feel a bit unsure, and
that's to support command line attributes as an alternative to that
increasing amount of specialised attributes, so something like this:

link => '$(CCLD) $(LDFLAGS) -o $@ ...',

Note that I haven't really thought it through, this is really a draft
of a possible idea, and it might end up having a very different form.
But still, that might be better than the proliferation of gazillions
of little flags, and would probably also help those who want or need
to do certain things slightly differently.

Also, note that I don't think this is appropriate to introduce for
1.1.1, it's way too late for that.

appro> > So following my spin, I would rather say that any flag that affects
appro> > preprocessing should go into cppflags, any flag that affects linking
appro> > should go into ldflags (the attribute lflags), the rest can go to
appro> > cflags.  And for compartmentalization, I'd like to see that:
appro> > 
appro> > - for preprocessing, only cppflags are used.  (note: this is more of a
appro> >   wishlist, not really terribly important for now...)
appro> 
appro> It has already been established that it doesn't work. Because there are
appro> flags that are customarily viewed as compile-time, but that affect
appro> pre-defined macros that we relay upon. In other words pre-processing has
appro> to be performed with cppflags *and* cflags, just like
appro> compiling.

And do note that I said "wishlist"...  I'm not sure all agree with
you, but not important enough to fight about.

appro> > - for compiling (i.e. source code to object code), cppflags and cflags
appro> >   are used (I cannot see how one would make that differently).
appro> > - for linking, only ldflags should be used.  (this I think is
appro> >   important!)
appro> 
appro> As implied above, there are (and always will be) flags that are
appro> required at *all* stages on quite a number[!] of platforms. So
appro> that one can argue in favour of adding one to capture
appro> specifically this. "target_arch" might be appropriate if one
appro> follows the make's lead. In such case it would be possible to
appro> arrange it as cflags+cppflags+target_arch for pre-processing
appro> and compiling, and as ldflags+target_arch for linking. As it
appro> can be seen cppflags can actually be merged with cflags, so
appro> that cflags+target_arch and ldflags+target_arch would suffice(*).

(I was about to argue, but noticed the '(*)' at the last moment...)

However, you're saying it yourself:

appro> However, target_arch poses a non-trivial practical problem.
appro> Namely how do we know which of the additional flags user passes
appro> as additional arguments to configure belong in target_arch?
appro> With this in mind, i.e. as long as we don't want to get into
appro> business of tracking which additional flags should be assigned
appro> to target_arch, we would be better off passing cflags at all
appro> stages. [And handling odd-ball platform as exception, not
appro> rule.]

Newsflash: it's actually possible to repeat the same flag in more than
one variable!  And this is also something I see people do a little now
and then, so I wouldn't be at all surprised to see something like
CPPFLAGS='-m64 ...' LDFLAGS='-m64 ...' (that would cover all the
bases)...

appro> (*) Obviously modulo fact that we probably want to keep CPPFLAGS,
appro> because that's what users would expect they can affect.

Yes.

You know, while bouncing ideas, whatever we end up doing will be
post-1.1.1, so we have time to argue some more and hopefully end up
with a bunch of ideas to do things better, going forward.  That is,
after all, my desire (as well as generalization as much as possible,
that should probably be clear by now)

Going back to the 'link' attribute as an alternative to a gazillion
specialise attributes, does that seem like an idea to you?  Was that
what you have been trying to argue for some time?  Either way, this
said without locking into a particular form.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] rule-based building attributes

[Richard Levitte]

In message <072aaeb6-59b9-0e8a-f33e-35572350c...@openssl.org> on Mon, 26 Mar 
2018 14:15:24 +0200, Andy Polyakov  said:

appro> > So no, a straight makefile rule for a config attribute value isn't
appro> > going to be good enough.
appro> 
appro> How about this. We have touched this when discussing windows-makefile. I
appro> mean when I called it VC-specific, you disagreed, and I said that
appro> embedding manifest effectively makes it VC-specific. In the context I
appro> also suggested post-link stage, a command one could *add* to rule. Or
appro> let's rephrase this and say that you can simply specify multiple
appro> commands in an override rule. So with this in mind.
appro> 
appro> link => [ 'script-that-composes-list-of-objects $@.$$',
appro>   'link -o $@ -list $@.$$' ]

So zooming in on this particular idea, I was concerned about how those
object file names would be passed to the script...  but then you
mention manifests, and it dawns on me that there's *nothing* stopping
us from generating a file with the list of object files when building
the Makefile.  That does make some kind of sense to me.

Or were you thinking something different?  It would of course be
possible to have the script you suggest pull data from configdata.pm,
right?  But considering we're talking about third parties building
their own, that raises another concern, that we suddenly give the
whole %unified_info structure public exposure that I'm not entirely
sure were ready for.  Most of it is pretty straight forward (at least
to me, but that's no big surprise), but I have the nagging suspition
that there may be details that will get people stumped, and that will
hit us back.  It's possible, though, that I'm more concerned than
necessary...

(quite frankly, I was hoping we could avoid the proliferation of a
gazillion little scripts, but perhaps that's too much to hope for.
C'est la vie)

appro> Of course I'm not suggesting to take this for immediate
appro> implementation, these are just ideas to ponder about. They
appro> might turn unusable (or give a spark for some other idea :-)

Agreed, and I have the same intention.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Speeding up the fuzz test...

[Richard Levitte]

Hey,

Matt and I talked a bit about the fuzz test recipe and how
*incredibly* slow it is, especially on all things Windows.  We
realised fairly quickly that this is caused by a gazillion program
invokations (once for every corpora file, that's more than 15000 of
them), and then we started thinking about archiving the corpora
somehow.

After having a look through diverse format, I kinda fell for the cpio
formats.  They're very simple, putting together a reader was fairly
easy, and well, the result of running a modified test_fuzz.t that uses
the cpio files instead of the corpora files directly was quite a
dramatic change!

Running with the raw corpora files:

: ; make test TESTS=test_fuzz
...
All tests successful.
Files=1, Tests=11, 457 wallclock secs ( 3.54 usr  0.28 sys + 330.48 cusr 
189.06 csys = 523.36 CPU)
Result: PASS

And the cpio variant:

: ; make test TESTS=test_fuzz_new
...
All tests successful.
Files=1, Tests=11, 35 wallclock secs ( 0.01 usr  0.00 sys + 35.17 cusr  
0.11 csys = 35.29 CPU)
Result: PASS

And this was a Linux, which is substantially faster than my Windows 10
box, where I can wait for quite a while (we're talking half an hour,
maybe more).  I just wonder what kind of results I'll see there.

Now, I wonder how that will impact on Kurt, who sometimes produce
these files, and on Google's oss-fuzz project, who do use this.
My desire is to replace the current corpora with the corresponding
cpio files, one for each test program (i.e. fuzz/corpora/asn1/* gets
archived into fuzz/corpora/asn1.cpio, and so on and so forth).

I've changed fuzz/test-corpus.c so it can take a flag '-cpio' to tell
it to read the files as cpio archives, otherwise it read the file raw,
as before.

Thoughts?  Comments?  (Kurt?)

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] About PR 5702, etc.

[Richard Levitte]

In message <4e32b364-3ed3-9101-158c-09338f96e...@openssl.org> on Thu, 29 Mar 
2018 11:06:46 +0100, Matt Caswell  said:

matt> How about this for the vote text:
matt> 
matt> "Feature changes in 1.1.1 directly related to TLSv1.3 will be allowed
matt> during the beta as long as at least 3 OMC members approve the change"

I can get behind that.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Is making tests faster a bugfix?

[Richard Levitte]

In message  on Thu, 29 Mar 
2018 14:03:06 +0100, Matt Caswell  said:

matt> 
matt> 
matt> On 29/03/18 14:00, Salz, Rich wrote:
matt> > Please see https://github.com/openssl/openssl/pull/5788
matt> > 
matt> > I don’t think it is, but I’d like to know what others think.
matt> 
matt> I do think this should be applied. The tests in question are not just
matt> slow but *really* slow to the point that I often exit them before they
matt> have completed. This removes the benefits of having the tests in the
matt> first place. From that perspective I view this as a bug fix.

Something to remember is that no user will ever complain about this,
because we don't deliver the contents of fuzz/corpora in our tarballs.

In other words, this is a developer only change of our current tests,
and you will only hear from developers who do engage in fuzz testing,
i.e. those who do these tests as part of a release, just to pick a
very recent example.

Also, you may note that this test re-engages fuzz testing as part of
our normal tests that are run for every PR, which means that we will
catch errors that the fuzzers can detect much earlier.  Because the
fuzz testing took so long time, we had them only engaged with
[extended tests], something that's almost never used.

So I would argue that faster fuzz testing means more fuzz testing, and
hopefully better testing of stuff that's harder to catch otherwise.

Cheers,
Richard ( plus, from a very personal point of view, it's *my* time,
  and Matt's, and whoever else's who tests for releases, that
  gets substantially less wasted! )

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Code freeze later today

[Richard Levitte]

Hi,

A reminder, we're releasing beta 2 tomorrow.  In preparation, we will
do as usual, freeze the repo, which will happen some time this evening
(Swedish time).

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Code freeze later today

[Richard Levitte]

In message <20180402213936.ga29...@roeckx.be> on Mon, 2 Apr 2018 23:39:36 
+0200, Kurt Roeckx  said:

kurt> On Mon, Apr 02, 2018 at 10:13:53AM +0200, Richard Levitte wrote:
kurt> > Hi,
kurt> > 
kurt> > A reminder, we're releasing beta 2 tomorrow.  In preparation, we will
kurt> > do as usual, freeze the repo, which will happen some time this evening
kurt> > (Swedish time).
kurt> 
kurt> So when will that be?

Now.

I'm sorry, I fell asleep very early yesterday, only to wake up just
after midnight.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Richard Levitte]

In message  on Tue, 3 Apr 2018 
12:52:50 +, "Salz, Rich"  said:

rsalz> I had not realized that we just increased the “entropy”
rsalz> requirements by 50%, from 256 to 384. The original DRBG
rsalz> submission that I did only required 128 bits.  I think that is
rsalz> wrong, and I think the PR that did it (#5503) should be
rsalz> reverted.
rsalz> 
rsalz> I am concerned that we are trying to meet requirements that we
rsalz> really don’t have.  The original code was a huge improvement.
rsalz> 
rsalz> Requiring 384 bits of random seed is silly.  I think it is
rsalz> ridiculous.  One way or another we HAVE to fix that before the
rsalz> release.
rsalz> 
rsalz> Thoughts?

FYI, here's the magic number that lies behind this:

: ; git grep RAND_DRBG_STRENGTH
...
include/openssl/rand_drbg.h:# define RAND_DRBG_STRENGTH 256

The requirement change from 128 to 256 happened with this commit:

commit 32bda2b2e4900308cb025020d8c8692e1d3c2ba9
Author: Kurt Roeckx 
Date:   Sun Feb 18 19:16:13 2018 +0100

Switch the DRBGs from AES-128-CTR to AES-256-CTR

Reviewed-by: Dr. Matthias St. Pierre 
GH: #5401

And then there's this one, which did the added 50%:

commit 2a70d65b99e1f2376be705d18bca88703b7e774a
Author: Kurt Roeckx 
AuthorDate: Sat Mar 3 23:19:03 2018 +0100
Commit: Kurt Roeckx 
CommitDate: Sun Apr 1 21:11:26 2018 +0200

Make sure we use a nonce when a nonce is required

If a nonce is required and the get_nonce callback is NULL, request 50%
more entropy following NIST SP800-90Ar1 section 9.1.

Reviewed-by: Dr. Matthias St. Pierre 
GH: #5503

Each of them seen by itself make sense.  The combined result, though,
leaves me wondering...

(I'm tempted to try this with /dev/random only on Unix...  do I
remember it right, that it blocks for a while after every 8 byte chunk
on some Unixen?)

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: April Crypto Bulletin from Cryptosense

[Richard Levitte]

While I totally agree with the direction Tim is taking on this, we
need to remember that there's another condition as well: access to the
platform in question, either directly by one of us, or through someone
in the community.  Otherwise, we can have as many tests as we want, it
still won't test *that* code (be it assembler or something else)

In message  
on Tue, 03 Apr 2018 15:36:15 +, Tim Hudson  said:

tjh> And it should have a test - which has nothing to do with ASM and 
everything to do with improving
tjh> test coverage.
tjh> 
tjh> Bugs are bugs - and any form of meaningful test would have caught this.
tjh> 
tjh> For the majority of the ASM code - the algorithm implementations we have 
tests that cover things
tjh> in a decent manner.
tjh> 
tjh> Improving tests is the solution - not whacking ASM code. Tests will catch 
issues across *all*
tjh> implementations.
tjh> 
tjh> Tim.
tjh> 
tjh> On Tue, 3 Apr. 2018, 8:29 am Salz, Rich,  wrote:
tjh> 
tjh>  On 03/04/18 15:55, Salz, Rich wrote:
tjh>  > This is one reason why keeping around old assembly code can have a 
cost. :(
tjh> 
tjh>  Although in this case the code is <2 years old:
tjh> 
tjh>  So? It's code that we do not test, and have not tested in years. And 
guess what? Critical CVE.
tjh> 
tjh>  ___
tjh>  openssl-project mailing list
tjh>  openssl-project@openssl.org
tjh>  https://mta.openssl.org/mailman/listinfo/openssl-project
tjh> 
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Fw: [openssl/openssl] 1.1.0h build issue on SPARC/Solaris and maybe HPUX (#5867)

[Richard Levitte]

The attached report talks about CPP being required, but that's not the
intention.  Rather, this is an unnoticed mistake when cherry-picking
from master to 1.1.0.

The fix itself is easy (just add a line saying 'CPP=$(CC) -E'), and
that's not what I'm here to talk about, but rather how we want to act
in cases like this.  Do we make a new release?  Do we create an
official patch?  Do we make a link to the corrective github PR?
My own sense is that we should put up something, and it should be
visible on our download page and in our source archives.

Whatever we decide should become policy.

Cheers,
Richard
--- Begin Message ---
The Makefile for 1.1.0h now requires CPP to be set but config doesn't set it.

Typical errors are a number of unknown symbols:
 _sparcv9_rdtick ./libcrypto.so
bn_mul_mont_int   ./libcrypto.so

The easy solution is to run:
CPP=cpp make

This was tested on Solaris 9 and 11.  It appears that "make clean" also fails 
to remove some of the SPARC assembly object files so it won't rebuild after a 
"make clean;CPP=cpp make"   removing the .o files fixes that problem.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openssl/openssl/issues/5867--- End Message ---
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Fw: [openssl/openssl] 1.1.0h build issue on SPARC/Solaris and maybe HPUX (#5867)

[Richard Levitte]

In message <20180404.103237.14102346559301117.levi...@openssl.org> on Wed, 04 
Apr 2018 10:32:37 +0200 (CEST), Richard Levitte  said:

levitte> The attached report talks about CPP being required, but that's not the
levitte> intention.  Rather, this is an unnoticed mistake when cherry-picking
levitte> from master to 1.1.0.
levitte> 
levitte> The fix itself is easy (just add a line saying 'CPP=$(CC) -E'), and
levitte> that's not what I'm here to talk about, but rather how we want to act
levitte> in cases like this.  Do we make a new release?  Do we create an
levitte> official patch?  Do we make a link to the corrective github PR?
levitte> My own sense is that we should put up something, and it should be
levitte> visible on our download page and in our source archives.

I forgot to add facts.  This mistakes affects assembler building on
IA64, Sparc and s390x:

: ; find . -name '*.S'
./crypto/s390xcpuid.S
./crypto/md5/asm/md5-ia64.S
./crypto/aes/asm/aes-ia64.S
./crypto/sparccpuid.S
./crypto/bn/asm/sparcv8plus.S
./crypto/bn/asm/ia64.S
./crypto/bn/asm/sparcv8.S
    ./crypto/bn/asm/s390x.S
./crypto/ia64cpuid.S

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Fw: [openssl/openssl] 1.1.0h build issue on SPARC/Solaris and maybe HPUX (#5867)

[Richard Levitte]

I would like to have it more prominent.  I mean, yes, there should
probably be a known issues page, but I think that whatever we do, we
should have a line close to the one liking to the 1.1.0h tarball.  Why
send people chasing for it on other pages?

Also, some people are watching the source archive (https://ftp.openssl.org/)
directly, so the more I think about it, the more it makes sense to me
to place a patch there.  openssl-1.1.0h-errata.patch ?  That could
easily be linked into the list of downloadable things in
https://www.openssl.org/downloads/ with just a small tweak of the
script we use to generate that list.

In message <8e5b8aa9-c9f9-cbde-f030-6568a48eb...@openssl.org> on Wed, 4 Apr 
2018 09:38:26 +0100, Matt Caswell  said:

matt> I'd say where we have introduced a regression in the latest release it
matt> wouldn't hurt to have a "known issues" page, or similar, which links to
matt> commits or other information about how to patch or work around an issue.
matt> 
matt> I see no reason to make a new release unless we think the issue is
matt> sufficiently serious and/or affects large numbers of users.
matt> 
matt> Matt
matt> 
matt> 
matt> On 04/04/18 09:32, Richard Levitte wrote:
matt> > The attached report talks about CPP being required, but that's not the
matt> > intention.  Rather, this is an unnoticed mistake when cherry-picking
matt> > from master to 1.1.0.
matt> > 
matt> > The fix itself is easy (just add a line saying 'CPP=$(CC) -E'), and
matt> > that's not what I'm here to talk about, but rather how we want to act
matt> > in cases like this.  Do we make a new release?  Do we create an
matt> > official patch?  Do we make a link to the corrective github PR?
matt> > My own sense is that we should put up something, and it should be
matt> > visible on our download page and in our source archives.
matt> > 
matt> > Whatever we decide should become policy.
matt> > 
matt> > Cheers,
matt> > Richard
matt> > 
matt> > 
matt> > 
matt> > ___
matt> > openssl-project mailing list
matt> > openssl-project@openssl.org
matt> > https://mta.openssl.org/mailman/listinfo/openssl-project
matt> > 
matt> ___
matt> openssl-project mailing list
matt> openssl-project@openssl.org
matt> https://mta.openssl.org/mailman/listinfo/openssl-project
matt> 
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Richard Levitte]

In message <122b3c36-21ad-4904-a692-351ade567...@akamai.com> on Wed, 4 Apr 2018 
11:58:54 +, "Salz, Rich"  said:

rsalz> Is it expected that the number of bits of seed must equal the
rsalz> number of bits in the key strength?

It is expected that the number of bits of entropy in the seed (the VMS
function declares 4 bits of entropy per byte, considering the sources
it uses) equals a requirement, and it seems that the requirement is to
have the DRBG strength (which is measure in number of entropy bits)
match the number of bits of the block cipher used to generate the
randomness bits.  If I understand things correctly...  and that does
seem to match what's specified in SP800-90A r1.  I suggest a quick
study of table 3 in section 10 (Definitions for the CTR_DRBG), seen on
page 58 in 
https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-90ar1.pdf
Very specifically, there's the row with the title "Seed length
(seedlen = outlen + keylen)" that very clearly says 384 bits for
AES-256.

"Seed length" itself is defined in section 8:

8.6.4 Seed Length 

The minimum length of the seed depends on the DRBG mechanism and the
security strength required by the consuming application, but shall be
at least the number of bits of entropy required. See the tables in
Section 10.

rsalz> But at any rate, raising the seed size to 256 seems mildly
rsalz> tolerable, although I would prefer to keep it at 128.  Raising
rsalz> it to 384 is wrong.

Note that with a nonce, that'll be 192 bits, unless I'm thinking
wrong...  But I agree with you, at least from a very practical point
of view.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] build broken?

[Richard Levitte]

So, uhmmm, why didn't you make a PR from this?

In message  on Thu, 5 Apr 2018 
17:18:13 +, "Salz, Rich"  said:

rsalz> Making update
rsalz> CONF function code 122 collision at CONF_F_SSL_MODULE_INIT
rsalz> 
rsalz> diff --git a/crypto/err/openssl.txt b/crypto/err/openssl.txt
rsalz> index d1cc039..de3dacc 100644
rsalz> --- a/crypto/err/openssl.txt
rsalz> +++ b/crypto/err/openssl.txt
rsalz> @@ -335,7 +335,7 @@ CONF_F_NCONF_LOAD_BIO:110:NCONF_load_bio
rsalz> CONF_F_NCONF_LOAD_FP:114:NCONF_load_fp
rsalz> CONF_F_NCONF_NEW:111:NCONF_new
rsalz> CONF_F_PROCESS_INCLUDE:116:process_include
rsalz> -CONF_F_SSL_MODULE_INIT:122:ssl_module_init
rsalz> +CONF_F_SSL_MODULE_INIT:123:ssl_module_init
rsalz> CONF_F_STR_COPY:101:str_copy
rsalz> CRYPTO_F_CRYPTO_DUP_EX_DATA:110:CRYPTO_dup_ex_data
rsalz> CRYPTO_F_CRYPTO_FREE_EX_DATA:111:CRYPTO_free_ex_data
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: April Crypto Bulletin from Cryptosense

[Richard Levitte]

In message <20180406170540.gk80...@mit.edu> on Fri, 6 Apr 2018 12:05:43 -0500, 
Benjamin Kaduk  said:

kaduk> On Fri, Apr 06, 2018 at 04:23:02PM +0200, Andy Polyakov wrote:
kaduk> > > This is one reason why keeping around old assembly code can have a 
cost. :(
kaduk> > > 
kaduk> > > https://github.com/openssl/openssl/pull/5320
kaduk> > 
kaduk> > There is nothing I can add to what I've already said. To quote myself.
kaduk> > "None of what I say means that everything *has to* be kept, but as
kaduk> > already said, some of them serve meaningful purpose..."
kaduk> > 
kaduk> > Well, I also said that "I'm *not* saying that bit-rot is not a concern,
kaduk> > only that it's not really assembly-specific." And I can probably add
kaduk> > something here, in addition to already mentioned example of legacy code
kaduk> > relying on formally undefined or implementation-specific behaviour. 
It's
kaduk> > not actually that uncommon that *new* C code is committed[!!!]
kaduk> > "bit-rotten". So one can *just as well* say that supporting another
kaduk> > operating system has a cost, and so does using another compiler... Why
kaduk> > not get "angry" about that? What's the difference really? Relevant
kaduk> 
kaduk> Yes, supporting another operating system has a cost!
kaduk> At risk of drawing Richard's ire, if we did not intend to support
kaduk> (e.g.) VMS, we might have been able to get away with not writing our
kaduk> own custom build system in favor of some "industry standard".
kaduk> Supporting non-POSIX systems (e.g., Windows) also adds overhead in
kaduk> how we implement many of our interfaces (file handling, thread
kaduk> handling, locking, randomness, etc.).

I can channel my ire, thank you ;-)

But speaking of these things, I somewhat understand where you're
coming from, and somehow, this makes me think of the way the OpenBSD
folks do things, starting with something that's purely and entirely
for OpenBSD, and then expanding it with platform ports, and that's
actually a line of thought I could live with... BUT, and yeah, that's
a bit BUT...  our layering principles currently suck enormously, and
that also adds to the total cost of maintaining stuff.  Basically, we
have a number of platform specific stuff injected in the code a little
here and there, when we really should make the effort of putting
together an architecture independent layer that anyone would much more
easily write an implementation of for whatever new platform that comes
around, and could even come as a separate porting package that someone
else provides.

In a way, the new build system that I put together is exactly meant to
be a thing that makes it easier to port to other platforms, and at
least try to make it so that port could be delivered as a separate
package.  That was always my goal, and that was also the reason I
decided to write it in perl, 'cause that language is already ported to
all kinds of platforms like no other scripting language.  Not even
python, which is actually quite well ported, reaches as far.
(auto* tools are an abomination to try to port to anything that
doesn't look like a POSIX environment.  I tried, about 20 years ago.
Cmake, which was otherwise a strong candidate i my book, has presented
some challenges to port to VMS as well...  others have tried.  I don't
know so many others that have become popular enough to be considered
"industry standards")

But going back to what I said higher up, I very much wish we had an
actual consistent architecture agnostic layer.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Richard Levitte]

In message <8c39cdf4-a91e-4dfb-be67-6799e07d3...@akamai.com> on Tue, 3 Apr 2018 
16:58:17 +, "Salz, Rich"  said:

rsalz> >Please note that that 50% extra is only used for
rsalz> >instantiating the DRBG. On reseed we it only uses 256
rsalz> >bits.

Instantiating is exactly the problem.  The VMS
rand_pool_acquire_entropy() currently generates 256 bits of entropy on
each call.  No more, no less.  And that's at an estimated 4 bits of
entropy per byte, and estimation that's from long ago.  Either way,
because instantiation demands more than 256 bits, the whole RNG breaks
down, and everything related to it in some way along with it.  In
other words, OpenSSL on VMS dies.

rsalz> True.  And now we're finding that VMS won't work.  And I bet
rsalz> there are other systems that will also find this amount
rsalz> excessive.

I'm thinking that for any platform that can support that, I don't see
a problem, at all.

So the current short term solution for this is to simply default to
AES-128-CTR instead of AES-256-CTR, specifically on VMS, which is
currently sitting in PR#5904.  It seems like the option to make
everyone happy, and everyone ends up with a better randomness
implementation either way (compared to OpenSSL 1.1.0 and older).

In the mean time, I've spent a few days going through the docs on all
kinds of data that you can get out from the VMS kernel, most notably
through a system service called sys$getrmi()...  there's a gazillion
data points, a treasure trove for anyone that's into statistics.  And
I intend to spend some time trying to estimate what kind of entropy I
can get out of them...

... and that's where Kurt came in:

> Can I suggest you try something like
> https://github.com/usnistgov/SP800-90B_EntropyAssessment to at least
> get an idea? You would need to sample 1 variable and feed that into
> it.

And yeah, sure, especially if all it takes is to produce a stream of
bits from a source and feed that to the assessment program.  As long
as I don't have to port a C++11 program to VMS, 'cause unfortunately,
the existing C++ compiler hasn't had a real update for quite a while
:-/ (I'm sure that VSI is quite busy updating all they can, but they
haven't let anything out yet)

But either way, creating a better entropy gatherer is the longer term
goal.  I hope I get that part done before the release.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

Like I said in the post I just made, I see zero problems with having
that requirement on systems that can support it.  I don't see why we
must lower the bar for *everyone* just because we currently need to do
so for VMS

Cheers,
Richard

In message <116a311c-48b3-4181-9e68-b2fcc8d2d...@akamai.com> on Sat, 7 Apr 2018 
14:15:51 +, "Salz, Rich"  said:

rsalz> I would like to see this put on hold until we fix the ‘now requires 50% 
more random seeding’ issue.
rsalz> 
rsalz> What should I do to force that issue?
rsalz> 
rsalz> From: Richard Levitte 
rsalz> Reply-To: openssl/openssl
rsalz> 

rsalz> 
rsalz> Date: Saturday, April 7, 2018 at 7:36 AM
rsalz> To: openssl/openssl 
rsalz> Cc: Subscribed 
rsalz> Subject: [openssl/openssl] VMS: lower the entropy demand for this 
platform specifically (#5904)
rsalz> 
rsalz> Currently, the VMS version of rand_pool_acquire_entropy() delivers 256
rsalz> bits of entropy. The DRBG using AES-256-CTR and wanting 50% extra
rsalz> bits for the nonce demands 384 bits of entropy. Obviously, this makes
rsalz> anything random related to fail on VMS.
rsalz> 
rsalz> The solution for now, until we get the VMS rand_pool_acquire_entropy()
rsalz> to deliver more entropy, is to lower the bar for VMS specifically,
rsalz> i.e. making the default scrambling cipher AES-128-CTR instead of
rsalz> AES-256-CTR.
rsalz> 
rsalz> Fixes #5849
rsalz> 
rsalz> 
---
rsalz> 
rsalz> You can view, comment on, or merge this pull request online at:
rsalz> 
rsalz> https://github.com/openssl/openssl/pull/5904
rsalz> 
rsalz> Commit Summary
rsalz> 
rsalz> * VMS: lower the entropy demand for this platform specifically
rsalz> 
rsalz> File Changes
rsalz> 
rsalz> * M include/openssl/rand_drbg.h (10)
rsalz> 
rsalz> Patch Links:
rsalz> 
rsalz> * https://github.com/openssl/openssl/pull/5904.patch
rsalz> 
rsalz> * https://github.com/openssl/openssl/pull/5904.diff
rsalz> 
rsalz> ―
rsalz> You are receiving this because you are subscribed to this thread.
rsalz> Reply to this email directly, view it on GitHub, or mute the thread.
rsalz> 
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

In message <20180407154649.ga12...@roeckx.be> on Sat, 7 Apr 2018 17:46:50 
+0200, Kurt Roeckx  said:

kurt> On Sat, Apr 07, 2018 at 02:15:51PM +, Salz, Rich wrote:
kurt> > I would like to see this put on hold until we fix the ‘now requires 50% 
more random seeding’ issue.
kurt> > 
kurt> > What should I do to force that issue?
kurt> 
kurt> NIST SP800-90A rev1 section 8.6.7 has:
kurt> | A nonce may be required in the construction of a seed during
kurt> | instantiation in order to provide a security cushion to block
kurt> | certain attacks. The nonce shall be either:
kurt> |
kurt> | a. A value with at least (security_strength/2) bits of entropy, or
kurt> | b. A value that is expected to repeat no more often than a
kurt> | (security_strength/2)-bit random string would be expected to repeat.
kurt> |
kurt> | Each nonce shall be unique to the cryptographic module in which
kurt> | instantiation is performed, but need not be secret. When used, the
kurt> | nonce shall be considered to be a critical security parameter.
kurt> |
kurt> | A nonce may be composed of one (or more) of the following
kurt> | components (other components may also be appropriate):
kurt> | 1. A random value that is generated anew for each nonce, using an
kurt> | approved random bit generator.
kurt> | 2. A timestamp of sufficient resolution (detail) so that it is
kurt> | different each time it is used.
kurt> | 3. A monotonically increasing sequence number, or
kurt> | 4. A combination of a timestamp and a monotonically increasing
kurt> | sequence number, such that the sequence number is reset when and
kurt> | only when the timestamp changes. For example, a timestamp may show
kurt> | the date but not the time of day, so a sequence number is appended
kurt> | that will not repeat during a particular day.
kurt> |
kurt> | For case 1 above, the random value could be acquired from the same
kurt> | source and at the same time as the entropy input. In this case,
kurt> | the seed could be considered to be constructed from an
kurt> | “extra strong” entropy input and the optional personalization
kurt> | string, where the entropy for the entropy input is equal to or
kurt> | greater than (3/2 security_strength) bits.
kurt> |
kurt> | For case 2 above, the timestamp must be trusted. A trusted
kurt> | timestamp is generated and signed by an entity that is trusted
kurt> | to provide accurate time information.
kurt> 
kurt> Case 1 requires an approved random bit generator, which we don't
kurt> have by default.
kurt> 
kurt> Case 2 requires the timestamp to be trusted. I think that applies
kurt> to case 4 too. This is also something we can't do by default.

I'm not sure what you mean with "trusted"...

kurt> I think case 3 requires us keep a counter even after restarting
kurt> the application, which seems unlikely that we will implement it.
kurt> 
kurt> So by default we can't do any of them. But you can argue that we
kurt> can do case 1, 2 and 4 close enough. Case 1 is what we do now.

H...  case 4 shouldn't pose too much problems unless you restart
the application more than once every second or so (for a 1 second
resolution).  On VMS, the system time is kept with 100 nanosecond
granularity...  this doesn't mean that it's actually updated every 100
nanosecond, but the possibility is there when VMS runs on fast enough
hardware (a VAX is decidedly not in that range, Alpha has a minimum
update rate of 1ms, Itaniums are faster than most Alphas...).  Either
way, the timestamp is 64 bits, it seems that then, we'd add a 64-bit
counter to match the 128 bit nonce requirement, do I get that right?

kurt> I think we can do case 2 with something like gettimeofday() or
kurt> clock_gettime() which I think provide plenty of resolution
kurt> that it's unlikely to repeat.
kurt> 
kurt> You can combine that with a counter to get case 4 if you really
kurt> wanted.
kurt> 
kurt> All you have to do is implement a get_nonce() function and set
kurt> it by default. You can keep the behaviour that if no get_nonce
kurt> function is set that it increases the entropy requirement.

Aha ok!  Yeahok, I see, so if I implement a rand_drbg_get_nonce in
rand_vms.c, we're basically set...  but that means we need to
implement a generic one as well, no?

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Richard Levitte]

In message <20180407160031.gb12...@roeckx.be> on Sat, 7 Apr 2018 18:00:32 
+0200, Kurt Roeckx  said:

kurt> On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote:
kurt> > > Can I suggest you try something like
kurt> > > https://github.com/usnistgov/SP800-90B_EntropyAssessment to at least
kurt> > > get an idea? You would need to sample 1 variable and feed that into
kurt> > > it.
kurt> > 
kurt> > And yeah, sure, especially if all it takes is to produce a stream of
kurt> > bits from a source and feed that to the assessment program.  As long
kurt> > as I don't have to port a C++11 program to VMS, 'cause unfortunately,
kurt> > the existing C++ compiler hasn't had a real update for quite a while
kurt> > :-/ (I'm sure that VSI is quite busy updating all they can, but they
kurt> > haven't let anything out yet)
kurt> 
kurt> You only need to generate the bits on VMS, you can run the tool on
kurt> some other machine.

Cool.

kurt> If you have such a program that collects the bits, I would like
kurt> to review it. I would also like to test something like that over
kurt> a range of machines it's expected to run on.

Errr  I have no idea what you're talking about.  I know of no
other operating system that provides the system services VMS does, so
I wonder how you expect to run the program gathering those data on
anything other than VMS.

If you wanna know what I'm talking about, just have a look at this
page:

http://h41379.www4.hpe.com/doc/84final/4527/4527pro_contents.html

Every "command" that starts with a '$' is a system service.  The C API
has them prefixed with 'sys$'.  The one of hightes interest seems to
be $GETRMI (or sys$getrmi), which has all sorts of counters and other
data.

kurt> I wonder if it's useful to have a thread of VMS that collects
kurt> such bits all the time, like the kernel is doing.

I was pondering something like that, and it does make sense.  That, or
creating a generic device driver (RND0:) that works a bit like the
random driver on Linux, or perhaps the one from OpenBSD...

kurt> I'm going to guess that the 4 bit you count now is an overestimate.

Don't look at me, it was I who made that estimate...  but I agree with
your guess.

kurt> And I would like to be very conservative in estimating something
kurt> like that, and even divide what the tool returns by 10.

That's a reason I want to go for a computed estimate instead...  the
3rd order delta that Linux' random driver does with jiffies seemed
like a simple enough strategy.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Richard Levitte]

In message <20180407174527.gc20...@roeckx.be> on Sat, 7 Apr 2018 19:45:28 
+0200, Kurt Roeckx  said:

kurt> On Sat, Apr 07, 2018 at 07:00:21PM +0200, Richard Levitte wrote:
kurt> > In message <20180407160031.gb12...@roeckx.be> on Sat, 7 Apr 2018 
18:00:32 +0200, Kurt Roeckx  said:
kurt> > 
kurt> > kurt> If you have such a program that collects the bits, I would like
kurt> > kurt> to review it. I would also like to test something like that over
kurt> > kurt> a range of machines it's expected to run on.
kurt> > 
kurt> > Errr  I have no idea what you're talking about.  I know of no
kurt> > other operating system that provides the system services VMS does, so
kurt> > I wonder how you expect to run the program gathering those data on
kurt> > anything other than VMS.
kurt> 
kurt> I mean multiple VMS machines on different processors / hardware.

VMS exists for Alpha and Itanium for the moment.  VSI is working on a
x86_64 port, with the first early adopters kit available late this
year (see http://www.vmssoftware.com/pdfs/VSI_Roadmap_20171215.pdf)

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

In message <20180407185034.ga25...@roeckx.be> on Sat, 7 Apr 2018 20:50:35 
+0200, Kurt Roeckx  said:

kurt> > In going from 1.1.0 to 1.1.1, breaking platforms that used to
kurt> > work is just plain wrong.
kurt> 
kurt> So then I suggest we support the syscalls on all platforms that
kurt> provide it.

I'm sorry, I'm lost.  "the syscalls"?  You started refering to
syscalls when discussing getrandom(), so I'm going to assume that it's
related, but I fail to understand how it's related to platforms that
break, and most specifically to VMS.  What "syscalls" do you expect?

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

In message <20180407190250.ga27...@roeckx.be> on Sat, 7 Apr 2018 21:02:51 
+0200, Kurt Roeckx  said:

kurt> On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
kurt> > H...  case 4 shouldn't pose too much problems unless you restart
kurt> > the application more than once every second or so (for a 1 second
kurt> > resolution).  On VMS, the system time is kept with 100 nanosecond
kurt> > granularity...  this doesn't mean that it's actually updated every 100
kurt> > nanosecond, but the possibility is there when VMS runs on fast enough
kurt> > hardware (a VAX is decidedly not in that range, Alpha has a minimum
kurt> > update rate of 1ms, Itaniums are faster than most Alphas...).  Either
kurt> > way, the timestamp is 64 bits, it seems that then, we'd add a 64-bit
kurt> > counter to match the 128 bit nonce requirement, do I get that right?
kurt> 
kurt> The requirement is not to have it 128 bit. Just that it doesn't
kurt> repeat as often as a 128 random number. You're most likely not
kurt> going to instantiate it 2^64 times. As long as the combination is
kurt> unique, it should be fine.

"The requirements" depend on where you look.  Looking at the code, or
more specifically drbg_ctr_init in drbg_ctr.c, about line 421, I see
this:

drbg->min_noncelen = drbg->min_entropylen / 2;

So the DRBG CTR code currently requires 128 bits minimum by default,
unconditionally.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

In message <20180408080942.gb3...@roeckx.be> on Sun, 8 Apr 2018 10:09:42 +0200, 
Kurt Roeckx  said:

kurt> On Sun, Apr 08, 2018 at 07:39:30AM +0200, Richard Levitte wrote:
kurt> > In message <20180407190250.ga27...@roeckx.be> on Sat, 7 Apr 2018 
21:02:51 +0200, Kurt Roeckx  said:
kurt> > 
kurt> > kurt> On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
kurt> > kurt> > H...  case 4 shouldn't pose too much problems unless you 
restart
kurt> > kurt> > the application more than once every second or so (for a 1 
second
kurt> > kurt> > resolution).  On VMS, the system time is kept with 100 
nanosecond
kurt> > kurt> > granularity...  this doesn't mean that it's actually updated 
every 100
kurt> > kurt> > nanosecond, but the possibility is there when VMS runs on fast 
enough
kurt> > kurt> > hardware (a VAX is decidedly not in that range, Alpha has a 
minimum
kurt> > kurt> > update rate of 1ms, Itaniums are faster than most Alphas...).  
Either
kurt> > kurt> > way, the timestamp is 64 bits, it seems that then, we'd add a 
64-bit
kurt> > kurt> > counter to match the 128 bit nonce requirement, do I get that 
right?
kurt> > kurt> 
kurt> > kurt> The requirement is not to have it 128 bit. Just that it doesn't
kurt> > kurt> repeat as often as a 128 random number. You're most likely not
kurt> > kurt> going to instantiate it 2^64 times. As long as the combination is
kurt> > kurt> unique, it should be fine.
kurt> > 
kurt> > "The requirements" depend on where you look.  Looking at the code, or
kurt> > more specifically drbg_ctr_init in drbg_ctr.c, about line 421, I see
kurt> > this:
kurt> > 
kurt> > drbg->min_noncelen = drbg->min_entropylen / 2;
kurt> > 
kurt> > So the DRBG CTR code currently requires 128 bits minimum by default,
kurt> > unconditionally.
kurt> 
kurt> The standard does not require this 128 bit. This 128 bit is only
kurt> required for the random value. The example even has a nonce of 32
kurt> bit.

So then maybe the code in drbg_ctr_init() shouldn't set such a high
minimum when drbg->get_nonce is defined?  That, or RAND_DRBG_instantiate()
shouldn't try to check against drbg->min_noncelen, i.e. the latter
should only be used when drbg->get_nonce is undefined.

I don't know enough to decide what's appropriate here...

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

In message  on Sun, 8 Apr 2018 
12:24:08 +, "Salz, Rich"  said:

rsalz> >Yes, after what I all said previously, it's clear the code could
rsalz> use improvements. I think at least Matthias and I assumed the code
rsalz> about the minimum size was correct and that there was a minimum
rsalz> requirement of 128 bit.
rsalz>   
rsalz> My expectation was that the *maximum* would also be 128 bits.

Not sure what you're saying there.  If the entropy acquisition
routines is over enthusiastic and delivers 277 bits of entropy, are
you saying it shouldn't be allowed to?

rsalz> I deliberately stayed away from all RAND stuff after the
rsalz> initial PR, because I didn't want to step on anyone else's toes
rsalz> and "hog" the work.  I knew others (including Kurt) were very
rsalz> interested in this.
rsalz> Who is going to ensure that we improve the code?

All things considered, I think "we" will.  There seems to be enough
discussion going on among interested parties, and it does sound like
we want to find a common ground.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

Kurt Roeckx  skrev: (8 april 2018 17:36:27 CEST)
>On Sat, Apr 07, 2018 at 08:50:35PM +0200, Kurt Roeckx wrote:
>> On Sat, Apr 07, 2018 at 05:55:14PM +, Salz, Rich wrote:
>> > > Because
>> > >  - It is not clear we need to do so
>> > 
>> > >That we need to do what?
>> > 
>> > Do FIPS compliant random numbers in this release.
>> 
>> We will never have that in any release by default, like I already
>> stated a few times.
>> 
>> > Everything is a trade-off.  Please explain why you want AES256-CTR
>with a nonce, and why AES128-CTR with personalization (and/or a DF) is
>not sufficient.
>> 
>> RAND_DRBG_set() takes 2 parameters: type and flags.
>> 
>> Type can be:
>> - NID_aes_128_ctr
>> - NID_aes_192_ctr
>> - NID_aes_256_ctr
>> 
>> The only flag is RAND_DRBG_FLAG_CTR_NO_DF. When using a DF a nonce
>> is required. When not using a DF the nonce is not used.
>> 
>> We always use a personalization string.
>> 
>> The requirements for not using a DF means that you need to use
>> "full entropy", which is even more strict then when using a DF.
>> Since we don't have a "full entropy" source, we can generate it
>> ourself, but it would require the double amount of entropy, so 512
>> bit. We have no code currently to do this, but there is an open
>> issue about it.
>
>This is actually wrong. When not using a DF, the seed length = 384
>for NID_aes_256_ctr. So we would need 768 bits of entropy if we
>don't have access to full entropy.

Wait what? This sounds nuts... Can you refer to something that backs your 
claim? 

>
>
>Kurt
>
>___
>openssl-project mailing list
>openssl-project@openssl.org
>https://mta.openssl.org/mailman/listinfo/openssl-project

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

In message <83ae9015-a766-4497-a71d-d537837cf...@openssl.org> on Sun, 08 Apr 
2018 19:15:16 +0200, Richard Levitte  said:

levitte> 
levitte> 
levitte> Kurt Roeckx  skrev: (8 april 2018 17:36:27 CEST)
levitte> >On Sat, Apr 07, 2018 at 08:50:35PM +0200, Kurt Roeckx wrote:
levitte> >> On Sat, Apr 07, 2018 at 05:55:14PM +, Salz, Rich wrote:
levitte> >> > > Because
levitte> >> > > - It is not clear we need to do so
levitte> >> > 
levitte> >> > >That we need to do what?
levitte> >> > 
levitte> >> > Do FIPS compliant random numbers in this release.
levitte> >> 
levitte> >> We will never have that in any release by default, like I already
levitte> >> stated a few times.
levitte> >> 
levitte> >> > Everything is a trade-off.  Please explain why you want AES256-CTR
levitte> >with a nonce, and why AES128-CTR with personalization (and/or a DF) is
levitte> >not sufficient.
levitte> >> 
levitte> >> RAND_DRBG_set() takes 2 parameters: type and flags.
levitte> >> 
levitte> >> Type can be:
levitte> >> - NID_aes_128_ctr
levitte> >> - NID_aes_192_ctr
levitte> >> - NID_aes_256_ctr
levitte> >> 
levitte> >> The only flag is RAND_DRBG_FLAG_CTR_NO_DF. When using a DF a nonce
levitte> >> is required. When not using a DF the nonce is not used.
levitte> >> 
levitte> >> We always use a personalization string.
levitte> >> 
levitte> >> The requirements for not using a DF means that you need to use
levitte> >> "full entropy", which is even more strict then when using a DF.
levitte> >> Since we don't have a "full entropy" source, we can generate it
levitte> >> ourself, but it would require the double amount of entropy, so 512
levitte> >> bit. We have no code currently to do this, but there is an open
levitte> >> issue about it.
levitte> >
levitte> >This is actually wrong. When not using a DF, the seed length = 384
levitte> >for NID_aes_256_ctr. So we would need 768 bits of entropy if we
levitte> >don't have access to full entropy.
levitte> 
levitte> Wait what? This sounds nuts... Can you refer to something that backs 
your claim? 

Ah, hold on, that was without a DF, but we *are* using a DF by
default, which makes sense since we can't possibly assume that we have
an approved RBG or an entropy source that provides "full entropy",
hence, according to 10.2.1 in SP800-90Ar1:

| The use of the derivation function is optional if either an
| *approved* RBG or an entropy source provides full entropy output
| when entropy input is requested by the DRBG mechanism. Otherwise,
| the derivation function *shall* be used.

This also puts into question the no_df tests in test/drbgtest.c, how
can we possibly, under the diverse conditions we're facing, assume to
know if those tests will succeed or fail?

So I guess I'm still on track with wanting to specify a get_nonce
function for VMS.  Speaking of that, got any ideas on how to hook that
on appropriately, without butchering the current DRBG code?

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

In message  on Sun, 8 Apr 2018 
20:10:22 +, "Salz, Rich"  said:

rsalz> >The 384 comes straight out of SP800-90A, see the table 10.2.1.
rsalz>   
rsalz> I think we're getting close to needing a team vote on whether
rsalz> or not we want to follow SP800-90A for this release.

Hold that thought a moment more...

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

In message  on Sun, 8 Apr 2018 
21:51:52 +, "Dr. Matthias St. Pierre"  said:

Matthias.St.Pierre> > So I guess I'm still on track with wanting to specify a 
get_nonce
Matthias.St.Pierre> > function for VMS.  Speaking of that, got any ideas on how 
to hook that
Matthias.St.Pierre> > on appropriately, without butchering the current DRBG 
code?
Matthias.St.Pierre> 
Matthias.St.Pierre> Hold the line, I'm currently working on it...  

Cool, I'll hold.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Some TLS 1.3 drafts don't have branches

[Richard Levitte]

In message  on Thu, 12 Apr 
2018 10:51:49 +0100, Matt Caswell  said:

matt> I'd suggest these tags for the various draft versions:
matt> 
matt> tls1.3-draft-20 9561e2a169
matt> tls1.3-draft-21 f90852093f
matt> tls1.3-draft-22 eee8a40aa5
matt> tls1.3-draft-23 95ea8da176
matt> 
matt> The current version number declared in supported_versions at the head of
matt> master is draft-26 (we skipped support for draft-24 and draft-25). This
matt> seems to be the one everyone else is still using. The current document
matt> is at draft-28 but there have been no incompatible changes (other than
matt> the draft version number itself).
matt> 
matt> If someone gives me a +1 I'll create the above.

+1

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

Hi,

First, a note: I don't want this discussion to be just about technical
details, but also about philosophy, and guidance for policy making in
the long run.  My feeling is that we've been...  well, a bit lax with
regards to library upgrade and program relinking (explicit or
implicit, that shouldn't really matter).

Some time ago, I engaged in the exercise to see how well the test
programs from the 1.1.0 branch would do if linked with the 1.1.1
libraries (i.e. simulating a shared library upgrade from 1.1.0 to
1.1.1).  See https://github.com/openssl/openssl/issues/5661

The conclusion drawn from this exercise is that TLSv1.3 has introduced
a behaviour in libssl 1.1.1 that is incompatible with libssl 1.1.0.
Not in every function, so for example, running basic s_server or
s_client without any special options will work without issues, but
just the fact that some amount of 1.1.0 tests fail when faced with
libssl 1.1.1 tells me that there are some incompatibilities to deal
with.

Of course, one might argue that one can assume that a program that
can't deal with certain details will tell libssl to stick with TLSv1.2
or older...  but I'm unsure if such assumptions are realistic, and I'm
again looking at the 1.1.0 test failures.  Obviously, *we* didn't work
along such assumptions.

So regarding assumptions, there's only one assumption that I'm ready
to make: a program that worked correctly with libssl 1.1.0 and uses
its functionality as advertised should work the same with libssl
1.1.1.  Note that I'm not saying that this excludes new features
"under the hood", but in that case, those new features should work
transparently enough that a program doesn't need to be changed because
of them.  Also, note again that I'm not talking about recompilation,
but the implicit relinking that is what happens when a shared library
is upgraded but keeps the same library version number (no "bump").
(mind you, explicit relinking would make no different in this regard).

Does anyone disagree with that assumption?

So, how to deal with this?

1. There's the option of making the new release 1.2.0 instead of 1.1.1.
   I think most of us aren't keen on this, but it has to be said.

2. Make TLSv1.2 the absolutely maximum TLS version available for
   programs linked with libssl 1.1.0.  This is what's done in this PR:
   https://github.com/openssl/openssl/pull/5945
   This makes sense insofar that it's safe, it works within the known
   parameters for the library these programs were built for.
   It also makes sense if we view TLSv1.3 as new functionality, and
   new functionality is usually only available to those who
   explicitely build their programs for the new library version.
   TLSv1.3 is unusual in this sense because it's at least it great
   part "under the hood", just no 100% transparently so.

3.   I dunno, please share ideas if you have them.


Side discussion:  Some of the failing 1.1.0 tests shows that we've
made some changes in 1.1.1 that we might not have thought would
disrupt anything.

a. 1.1.0's test/recipes/70-test_sslextension.t has a couple of tests
   that are meant to fail (i.e. if the individual tests fail, the
   recipe is successful).  When run against 1.1.1 libraries, the
   recipe fails, i.e. the injection of double hellos didn't get the
   communication to fail, or so it seems...

b. 1.1.0's test/recipes/80-test_ssl_new.t fails in the second test
   (protocol version checks) because it expects an InternalError
   alert, but gets ClientFail instead.  So the question here is, what
   if some program actually pays attention to them?  ...  and it also
   begs the question if the alert type change was a bug fix, and in
   that case, why didn't it propagate to 1.1.0?  Should it?

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

In message <20180414194244.ga27...@roeckx.be> on Sat, 14 Apr 2018 21:42:45 
+0200, Kurt Roeckx  said:

kurt> On Sat, Apr 14, 2018 at 09:32:31PM +0200, Richard Levitte wrote:
kurt> > 
kurt> > a. 1.1.0's test/recipes/70-test_sslextension.t has a couple of tests
kurt> >that are meant to fail (i.e. if the individual tests fail, the
kurt> >recipe is successful).  When run against 1.1.1 libraries, the
kurt> >recipe fails, i.e. the injection of double hellos didn't get the
kurt> >communication to fail, or so it seems...
kurt> 
kurt> This seems to be a test that is very aware of the protocol, and
kurt> what should fail and what shouldn't. If you introduce a new
kurt> protocol, the things it check might need to be updated. This is
kurt> not something a normal application will be doing, so I don't see
kurt> this as a problem.

Yes, I agree that the TLSProxy tests aren't the most important in this
regard.  Also note that this part was a side note.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

In message <352ebaa2-b2d4-4a2e-adc4-1033a1735...@dukhovni.org> on Sat, 14 Apr 
2018 16:01:42 -0400, Viktor Dukhovni  said:

openssl-users> > 2. Make TLSv1.2 the absolutely maximum TLS version available 
for
openssl-users> >   programs linked with libssl 1.1.0.  This is what's done in 
this PR:
openssl-users> >   https://github.com/openssl/openssl/pull/5945
openssl-users> >   This makes sense insofar that it's safe, it works within the 
known
openssl-users> >   parameters for the library these programs were built for.
openssl-users> >   It also makes sense if we view TLSv1.3 as new functionality, 
and
openssl-users> >   new functionality is usually only available to those who
openssl-users> >   explicitely build their programs for the new library version.
openssl-users> >   TLSv1.3 is unusual in this sense because it's at least it 
great
openssl-users> >   part "under the hood", just no 100% transparently so.
openssl-users> 
openssl-users> This should NOT be necessary.  What it is about enabling TLS 1.3
openssl-users> that breaks existing code?  Let's fix that.

I'm not savvy enough to answer that properly.  I'm mostly observing
from the exterior.

openssl-users> > 3.   I dunno, please share ideas if you have them.
openssl-users> 
openssl-users> We need to make sure that the introduction of TLS 1.3 is 
transparent,
openssl-users> aside from occasionally leading to a connection that uses TLS 
1.3.
openssl-users> 
openssl-users> If all that's failing is our test-suite, which is too sensitive 
to the
openssl-users> underlying implementation details, that's fine, not all the 
tests are 
openssl-users> designed to run cross-library.
openssl-users> 
openssl-users> Will real applications run into any meaningful problems?

This is an argument that I find *terribly* frustrating.  Are you
suggesting that we have no test that tries to do what can be expect
from a "real" application?  What do you expect a "real" application to
limit itself to?  Do you expect a "real" application to always set a
maximum TLS version?  Do you expect a "real" application to expect
failure because it hasn't?  Was any of the limitations you might think
of advertised?  In the 1.1.0 manual pages?  Elsewhere?

Also, I imagine that test_ssl_old, test_ssl_new and test_sslapi are
three tests that do try to mimic "real world" use of libssl.

openssl-users> While can artificially limit the max protocol in applications 
compiled
openssl-users> for 1.1.0, I don't think that's a compelling design choice.  We 
have
openssl-users> support in 1.1.0 for min/max protocol, applications can use those
openssl-users> controls explicitly.

Yes, they can, but they won't necessarely.  Just as an example, our
1.1.0 test programs didn't before I stoopidly made them do so (I'm
reverting that with https://github.com/openssl/openssl/pull/5947,
because it was an enormously stoopid move that only showed that an
upgrade to 1.1.1 *required* at least the addition of such controls)

openssl-users> In any case in order of preference, I'd like to see:
openssl-users> 
openssl-users>   1. Fix any issues so that it is safe to upgrade.
openssl-users>   2. Make the library version 1.2
openssl-users>   3. Hack the API to cap the protocol version based on 
compile-time
openssl-users>  maximum.
openssl-users> 
openssl-users> -- 
openssl-users> -- 
openssl-users>  Viktor.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

In message <44fe0745-31df-41c3-b697-97025643c...@dukhovni.org> on Sat, 14 Apr 
2018 16:24:56 -0400, Viktor Dukhovni  said:

openssl-users> 
openssl-users> 
openssl-users> > On Apr 14, 2018, at 4:18 PM, Richard Levitte 
 wrote:
openssl-users> > 
openssl-users> >> Will real applications run into any meaningful problems?
openssl-users> > 
openssl-users> > This is an argument that I find *terribly* frustrating.  Are 
you
openssl-users> > suggesting that we have no test that tries to do what can be 
expect
openssl-users> > from a "real" application?
openssl-users> 
openssl-users> I am suggesting that we ignore test failures that test for rather
openssl-users> artificial conditions.  If our test negotiates TLS with our own
openssl-users> server and tests that it got exactly TLS 1.2 (because that's the
openssl-users> highest version our test expected to support by default) that's 
an
openssl-users> artificial test, and its failure is fine.

Do all the tests do that, i.e. actually check that they got nothing
higher than TLSv1.2?  This is an open question, I haven't dived enough
into the TLS stuff to know (but will next week unless someone can say
for sure).  If that is the case, then I agree that it's quite
artificial.  Otherwise, not so much.

openssl-users> Real applications that want no more than TLS 1.2 need
openssl-users> to set the max version, or not expect that maximum.
openssl-users> Anything else is an application bug.

Would you say that it's an application bug if it stumbles on a change
in API behavior that isn't due to a bug fix?  (and even better, if it
worked according to documentation?)

openssl-users> Do we have any meaningful test failures that are not
openssl-users> artificial like the above?  If so, we should fix them,
openssl-users> if not we possibly need more tests, but are otherwise
openssl-users> fine as best we know.

I disagree with us being fine, unless the possible issue I'm raising
can be disqualified with certainty.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

In message  on Sat, 14 Apr 
2018 16:46:56 -0400, Viktor Dukhovni  said:

openssl-users> > On Apr 14, 2018, at 4:40 PM, Richard Levitte 
 wrote:
openssl-users> > 
openssl-users> > Would you say that it's an application bug if it stumbles on a 
change
openssl-users> > in API behavior that isn't due to a bug fix?  (and even 
better, if it
openssl-users> > worked according to documentation?)
openssl-users> 
openssl-users> Negotiating a new version of TLS is not a change in API 
behaviour.  The
openssl-users> application asks for a TLS session (of no particular maximum 
version),
openssl-users> and it gets one that both the client library and the peer 
support.
openssl-users> 
openssl-users> I just tested posttls-finger compiled for 1.1.0 running with a 
1.1.1
openssl-users> library against a TLS 1.2 server and it worked fine.

Does this answer the whole question, or do they just do the most basic
stuff that our public headers make available?

To put it another way, I would absolutely hate it if, after 1.1.1
(assuming that's what we go for) is released, people came back
screaming at us because their program toppled over or bailed out in a
virtual panic attack just because of a shared library upgrade.
I would prefer if we treated this with *certainties* rather than
*probabilities*, and for the moment, it feels like I'm being fed with
the latter rather than the former.

openssl-users> What version of OpenSSL is Postfix linked against on 
mta.openssl.org?
openssl-users> Care to upgrade it to 1.1.0 if not already?  Then replace the 
libraries
openssl-users> with the 1.1.1 versions?  I can then retest...

mta.openssl.org runs Ubuntu 16.04 and the as up to date packages as I
get.  I prefer to run things with vendor packages, so we have an easy
path for updates, and considering that's our central mail hub, I'm not
at all keen on potentially screwing things up there.

But tell you what, there's a test machine as well, which I did set up
specifically for trying this sort of thing.  I can certainly screw
around with all of that there.

openssl-users> Running an MTA built for 1.1.0 against 1.1.1 libraries
openssl-users> might be a reasonable way to "eat our own dog food".

Yeeehhh, ya know, I do believe in eating your own dog food, but
only to a level.  Central production machinery that we all depend on
is a big no-no in my admin brain.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

In message  on Sat, 14 Apr 
2018 21:13:47 +, "Salz, Rich"  said:

rsalz> We have *no* data points, except our tests, that anything fails to work.
rsalz> In fact, we are increasingly collecting data that shows everything is 
just fine.

Errr, are we?  Please inform me, because I cannot remember having seen
tests that specifically targets the case of programs built with 1.1.0
that get implicitly relinked with 1.1.1 libraries (that's what you
call "going forward", isn't it?), or data collection for that matter.
I may have missed something, but I am interested.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

In message  on Sun, 15 Apr 
2018 13:27:15 +0200, Andy Polyakov  said:

appro> To summarize, failing tests in 110 should be revisited to see if they
appro> are actually representative, before one can consider as drastic measures
appro> as #5945.

At this point, I agree.  Viktor's look at several applications and
Kurt's report of successful did convince me that I might by crying
wolf a bit much.  I've started looking a bit deeper at the failing
tests, for exactly the reasons you mention.

Now, there was a point brought on by a couple of issues mentioned,
I'll take that in a separate email.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Proto over ciphers or ciphers over proto? (was: The problem of (implicit) relinking and changed behaviour)

[Richard Levitte]

In message 

 on Sun, 15 Apr 2018 06:24:48 +, Bernd Edlinger  
said:

bernd.edlinger> One possible example of application failure that I am aware of 
is #5743:
bernd.edlinger> A certificate that is incompatible with TLS1.3 but works with 
TLS1.2.
bernd.edlinger> Admittedly that I did come up with that scenario only because I 
saw
bernd.edlinger> a possible issue per code inspection.

This touches an issue that's already mentioned in Matt's blog, and I
gotta ask how the protocols so be presented for negotiation are chosen
(yes, I know, I could dive into the code...  and I will unless there's
a quick answer).  Does libssl just pick the max version chosen (within
the range that we support unless the application has narrowed it
down), or does it also look at other facts, such as chosen server or
client certs to see what protocol version range would actually work
with those collected facts?  #5743 seems to say that libssl doesn't
look at such facts, and can end up in the absurd situation that things
stop working because it selected TLSv1.3 over TLSv1.2 when the latter
couldn't possibly work right, while TLSv1.2 does.

I can't really say what's right or wrong in this case, this really is
a philosophical question more than anything else.  Is it all right to
just pick a proto version that cannot work and then virtually flip it
to the unsuspecting application that wasn't prepared with better data
(such as a cert that's also valid in TLSv1.3) or is that essentially
wrong, even though easier to deal with in code?  Is that what libssl
is doing, or does it have more of a "look at all the facts" approach
before choosing the proto range to negotiate with the other end?

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

In message <877ep8s738@fifthhorseman.net> on Sun, 15 Apr 2018 10:38:35 
-0700, Daniel Kahn Gillmor  said:

dkg> Ideally, the semantics of the OpenSSL API for *most* users of the
dkg> library should be roughly "give me the best TLS session you can give".
dkg> There's no breakage in that API if the underlying library suddenly
dkg> starts negotiating TLS 1.3.

I generally agree.

dkg> An application which uses that API and then breaks because it got a
dkg> version of TLS or a ciphersuite that it didn't expect is mis-using the
dkg> API (or, is part of the test suite, which is actually testing the
dkg> internals of the library it was built against and we should expect a
dkg> failure if the library used is changed out from under it).

Generally speaking, I don't necesseraly agree.  If the use of an API
is perfectly valid for the conditions a program was built for, and
then suddenly breaks down because the new kid in town wanna play,
I find it hard to call that mis-use.  I would much rather have libssl
do something along the lines of "oh, you're one of the old guys, let's
use something that works for you".

dkg> I'm all for making a breaking changes in the OpenSSL API to discourage
dkg> use of bad/legacy API.

That calls for a major version change (in OpenSSL versioning, that
would be 1.2.0).  I think we've all come to some kind of agreement
that doing this isn't desirable at this point...

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Release of OpenSSL beta release 3 (pre5) happens

[Richard Levitte]

Hi,

just a reminder that we're scheduled to release openssl-1.1.1-pre5
today.

I'll do the release this time.

If someone could freeze the repo for me, I'd be grateful:

ssh openssl-...@git.openssl.org freeze openssl levitte

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Release done, repository unfrozen

[Richard Levitte]

OpenSSL 1.1.1 pre release 5 done!
Repository is now unfrozen.

Thank you Matt for the review!

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

In message <87d0yxq0m7@fifthhorseman.net> on Tue, 17 Apr 2018 09:05:52 
-0700, Daniel Kahn Gillmor  said:

dkg> On Mon 2018-04-16 08:22:59 +0200, Richard Levitte wrote:
dkg> > Generally speaking, I don't necesseraly agree.  If the use of an API
dkg> > is perfectly valid for the conditions a program was built for, and
dkg> > then suddenly breaks down because the new kid in town wanna play,
dkg> > I find it hard to call that mis-use.  I would much rather have libssl
dkg> > do something along the lines of "oh, you're one of the old guys, let's
dkg> > use something that works for you".
dkg> 
dkg> But if that's the only API semantics, then there's no way for my project
dkg> that depends on libssl to say "do the best thing you know how to do", so
dkg> that i can get benefits from a simple upgrade.

Depends on what "the best thing you know to do" is.  In my mind,
simply refusing to run as before because the new kid in town didn't
like the environment (for example a cert that's perfectly valid for
TLSv1.2 but invalid for TLSv1.3) it ended up in isn't "the best thing
you know to do".

But I get you, your idea of "the best thing you know to do" is to run
the newest protocol unconditionally unless the user / application says
otherwise, regardless of if it's at all possible given the environment
(like said cert).

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

[Richard Levitte]

In message  on Tue, 17 Apr 
2018 14:32:37 -0400, Viktor Dukhovni  said:

openssl-users> 
openssl-users> 
openssl-users> > On Apr 17, 2018, at 2:15 PM, Richard Levitte 
 wrote:
openssl-users> > 
openssl-users> > Depends on what "the best thing you know to do" is.  In my 
mind,
openssl-users> > simply refusing to run as before because the new kid in town 
didn't
openssl-users> > like the environment (for example a cert that's perfectly 
valid for
openssl-users> > TLSv1.2 but invalid for TLSv1.3) it ended up in isn't "the 
best thing
openssl-users> > you know to do".
openssl-users> > 
openssl-users> > But I get you, your idea of "the best thing you know to do" is 
to run
openssl-users> > the newest protocol unconditionally unless the user / 
application says
openssl-users> > otherwise, regardless of if it's at all possible given the 
environment
openssl-users> > (like said cert).
openssl-users> 
openssl-users> If there were a non-negligible use of certificates that work 
with TLS 1.2,
openssl-users> and that (implementation bugs aside) can't work with TLS 1.3, 
I'd support
openssl-users> your position strongly.  As it stands, I think you're right in 
principle,
openssl-users> but not yet in practice.  If we find no show-stopper issues, we 
should
openssl-users> allow TLS 1.3 to happen.

The troublesome thing with "but not yet in practice" is that we won't
know before 1.1.1 is finally released and has been deployed in a
larger scale.  In my mind, that's too late.  So my view is much more
black and white, like is it at all possible that there will be
certificates or other "stuff" out there that will have libssl fail
setting up communication because TLSv1.3?  If the answer is yes, I
find it hard to ignore this.

openssl-users> I'm far more concerned about lingering middle-box issues, than 
about some
openssl-users> edge-case certificates...

There's that too, yeah.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Problems with waiting for specific person to merge

[Richard Levitte]

When someone with write access to the main repo makes a PR and it gets
approved, we usually wait for the person to do the final merge.  This
is perfectly fine to expect from us who are so called fellows, i.e.
who are payed directly to work on OpenSSL...  but to ask this of
everyone else, when their $DAYJOB may suck them into something
entirely different at any given time?  I think that may be quite
unfair, and is bad for the project.

So I think it's time we address this cultural thing (*), and also
perhaps take a closer look at PRs that have been left hanging for this
reason, and take it upon ourselves to help each other merge when we
notice that it doesn't happen on its own.

Cheers,
Richard

(*) It appears to be deep seated...  there have been times when I knew
I was going to be away, and said that anyone is free to merge a PR I
submitted when it's approved, and it still didn't happen before I was
back and did it myself.
--- Begin Message ---
I see no reason not to merge this.  It's been approved a long time ago, and the 
discussion that followed only clarifies the semantics, so...

I know that @ekasper is quite busy elsewhere, so I'll merge now.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openssl/openssl/pull/4955#issuecomment-382640850--- End Message ---
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Problems with waiting for specific person to merge

[Richard Levitte]

In message <9d1d9c5d9b0c4d54ae72d0759d0da...@ex13.ncp.local> on Thu, 19 Apr 
2018 08:30:03 +, "Dr. Matthias St. Pierre"  
said:

Matthias.St.Pierre> Speaking as one of the committer with $PAYROLL !=
Matthias.St.Pierre> "OpenSSL", I would like to add two remarks.
Matthias.St.Pierre> 
Matthias.St.Pierre> I think the reluctance to merge other committer's
Matthias.St.Pierre> pull requests comes from the thought that it might
Matthias.St.Pierre> appear impolite or that one does not want to
Matthias.St.Pierre> interfere with the other's business. Personally, I
Matthias.St.Pierre> don't have a problemat all if my pull requests are
Matthias.St.Pierre> merged by others when I don't have the time to do
Matthias.St.Pierre> it myself. When somebody notices that a pull
Matthias.St.Pierre> request went stale after approval, I would suggest
Matthias.St.Pierre> to ping the owner and give him/her a grace period
Matthias.St.Pierre> of at least 24 hours to do it by it him/herself.
Matthias.St.Pierre> After that it is perfectly ok to merge it.

Yeah, I get that point, and you're right, there should be an attempt
at a polite exchange first.  In my defence, I had a quick chat with
Emilia a couple of weeks ago, and it became clear that she has a busy
period for the moment.

Matthias.St.Pierre> For tickets owned by non-committers, my
Matthias.St.Pierre> observation is that it is often not clear who will
Matthias.St.Pierre> merge. I for myself follow the habbit of
Matthias.St.Pierre> self-assigning a ticket as indication that I
Matthias.St.Pierre> intend to do the merge. Sometimes others do it the
Matthias.St.Pierre> same way, but it is not a general practice. Maybe
Matthias.St.Pierre> we could make this a general pattern?

This has actually varied a bit.  What I've observed is that the first
to approve is oftentimes the one that merges, unless something else is
said (there have been some PRs where people have asked each other).
Self assigning is a good habit...  unless you have my tendencies, to
*ahem* forget that you've self assigned something.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Problems with waiting for specific person to merge

[Richard Levitte]

In message  on Thu, 19 Apr 
2018 12:57:39 +, "Salz, Rich"  said:

rsalz> 
rsalz> >Self assigning is a good habit...  unless you have my tendencies, to
rsalz> *ahem* forget that you've self assigned something.
rsalz>   
rsalz> There's a built-in filter that says "find my PR's"  It's just
rsalz> on the left side of the search box.

Thanks...  Now to remember to go there ;-) (I usually start from the
notifications page and relatively seldom go to the PR list...  it's a
habit I probably should change)

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] When to enable TLS 1.3

[Richard Levitte]

In message  on Thu, 19 Apr 
2018 19:16:04 -0400, Viktor Dukhovni  said:

openssl-users> But not all the friction can be eliminated, and likely not
openssl-users> all providers can be persuaded to be more accommodating.
openssl-users> Which leaves us with some difficult judgement calls:
openssl-users> 
openssl-users>   * Restrict TLS 1.3 support to just applications compiled
openssl-users> against 1.1.1?  A weak signal, but likely correlates at
openssl-users> least somewhat with the application being ready.
openssl-users> 
openssl-users>   * Determine whether the application is likely to be compatible
openssl-users> at runtime by looking at the provided configuration.  Is SNI
openssl-users> enabled?  Is the certificate chain weird enough to break with
openssl-users> TLS 1.3.  Has the application turned off critical algorithms?

Of those two, the second provides for a smoother transition to using
TLSv1.3, all it might take is changing a configuration, getting a
newer certificate with a more compatible chain, changing an engine
module.  Some of those may take some time (even purchasing a new cert,
what do I know?), but still.  If at all possible, the second choice
seems like the better one.

The only reason I can see for the first option is if there are things
that cannot be detected in run-time that would cause the use of older
protocols rather than TLSv1.3.  I suspect a too early call of
SSL_version might be one that's hard to cope with...

openssl-users>   * Do nothing, let the applications adapt or stick with older
openssl-users> libraries?

I don't see this as acceptable.  Let's remember that 1.1.0 -> 1.1.1 is
a *minor* upgrade, i.e. should be a drop-in backward compatible
replacement.  If that upgrade causes applications to suddenly stop
working because we're force feeding them TLSv1.3, then we've failed
that technical promise.  If I was a user in that scenario, I'd be
furious.

openssl-users>   * Something else?

Making this a *major* upgrade, i.e. 1.2.0.

openssl-users> We don't have much time before release, what do we do?

If we can't resolve this, there is the option of delaying the
release.  The release strategy is clear on this: "This may be amended
at any time as the need arises."
(https://www.openssl.org/policies/releasestrat.html)

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Absence now until Tuesday

[Richard Levitte]

I will be pretty much absent starting now and until tuesday.  Monday
and Tuesday, I'm attending this event:
https://www.eventbrite.com/e/hp-connect-sweden-vms-sig-annual-meeting-tickets-42639545027

I might be responding to email sporadically.  Don't wait up ;-)

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] When to enable TLS 1.3

[Richard Levitte]

In message <431270c5-3da3-4a9d-9292-12adc46cc...@dukhovni.org> on Sat, 21 Apr 
2018 14:45:34 -0400, Viktor Dukhovni  said:

openssl-users> > We are considering if we should enable TLS 1.3 by default or 
not,
openssl-users> > or when it should be enabled. For that, we would like to know 
how
openssl-users> > applications behave with the current version.
openssl-users> 
openssl-users> It is perhaps unclear in the last sentence what "the current 
version"
openssl-users> means.

I took that to mean "the 1.1.0 series"

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to Postfix test

[Richard Levitte]

In message  on Sun, 22 Apr 
2018 21:49:42 -0400, Viktor Dukhovni  said:

openssl-users>   * Postfix logs a warning when the compile-time and runtime
openssl-users> libraries are not exactly the same (once per process start),
openssl-users> this is expected.  Perhaps we should provide a means for
openssl-users> users to turn that off.

With our current version scheme, you should use the compatibility mask
0xFFF0
(maybe we should have that value in opensslv.h...  Matthias St. Pierre
might have an idea or two on the matter, too)

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Richard Levitte]

Like I think I mentioned a few days ago, I'm currently on a conference. I'll 
take this up in more depth later this week.

I have a question, though... Kurt said at some point that all that was needed 
on the VMS side was to collect data, the rest can be done elsewhere 
(thankfully). However, I don't really understand what the collected data is 
supposed to be. Just the same stream of bytes that I would feed the entropy 
acquisition, or something else? Is the time delta between samples a factor in 
this?

Cheers
Richard 

Paul Dale  skrev: (24 april 2018 00:31:39 CEST)
>I can possibly provide some input having done similar for a number of
>platforms and written faster but equivalent entropy assessment code to
>NIST's (for the second draft of SP 800-90B rather than the final
>version).
>
>I'm not knowledgeable about VMS though.
>
>We could discuss further at ICMC if you're in the area.
>
>
>Pauli

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Upcoming 1.1.1 audit?

[Richard Levitte]

I kept seeing tweets about a future OSTIF audit, and just saw that they now 
have funding:

https://twitter.com/OSTIFofficial/status/989421638960713728

Is this interesting to us? Should we synchronize with them?

Cheers
Richard 
-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Richard Levitte]

In message <20180424172439.ga8...@roeckx.be> on Tue, 24 Apr 2018 19:24:40 
+0200, Kurt Roeckx  said:

kurt> On Tue, Apr 24, 2018 at 07:20:42AM +0200, Richard Levitte wrote:
kurt> > Like I think I mentioned a few days ago, I'm currently on a conference. 
I'll take this up in more depth later this week.
kurt> > 
kurt> > I have a question, though... Kurt said at some point that all that was 
needed on the VMS side was to collect data, the rest can be done elsewhere 
(thankfully). However, I don't really understand what the collected data is 
supposed to be. Just the same stream of bytes that I would feed the entropy 
acquisition, or something else? Is the time delta between samples a factor in 
this?
kurt> 
kurt> The API support getting data that has 1 bit of entropy per 128 bit
kurt> received (DRBG_MINMAX_FACTOR). If it's worse than that, you might
kurt> have to write your own extract method.

I might have to either way, don't I.  A method I'm pondering is to
pass all the data gathered (700-something bytes) through sha512 and
add the result to the pool.  I have no idea what that says about the
entropy of the original data, which is at somewhere between 0.1 and
0.2 entropy bits per data bit according the 3rd order entropy
calculation that I replicated from the Linux /dev/urandom driver.

kurt> A stream of bytes it just fine.
kurt> 
kurt> I think the tme delta will really depend on your source. If it
kurt> really changes all the time, it really doesn't matter much how
kurt> fast you do it. But I think some (most?) of the variables don't
kurt> change that often.

It doesn't change *all* the time, but with a 1-10 second sleep between
data gatherings, there's always *something* that has changed enough
to give a 3rd order diff from previous sampling that's > 0.

So what I've done for now is to make two files, one that's the raw
data, repeatedly gathered every 1-10 seconds until I got about 1 Mib
of data, the other being a concatenation of sha512 calculations of
those same (*) data until I filled that file up to 1 Mib.  I suspect
that the latter isn't quite valid, considering Paul said something
about no transformation whatsoever, but I thought it would be worth a
try.

I'll have to try and feed this to the entropy test programs you
indicated earlier...

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Richard Levitte]

In message <20180430131000.ga25...@roeckx.be> on Mon, 30 Apr 2018 15:10:01 
+0200, Kurt Roeckx  said:

kurt> The comment about not hashing it is if you want to use the tool to
kurt> do entropy estimation. Hashing it will not increase the entropy,
kurt> but the estimation will be totally wrong.
kurt> 
kurt> Passing the hashed data to the drbg as entropy input is fine if
kurt> you already know how much entropy that it contains.

Thanks, that's what I suspected.  Ok, on to the next step

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Richard Levitte]

In message <20180430.152609.587396153749337701.levi...@openssl.org> on Mon, 30 
Apr 2018 15:26:09 +0200 (CEST), Richard Levitte  said:

levitte> In message <20180430131000.ga25...@roeckx.be> on Mon, 30 Apr 2018 
15:10:01 +0200, Kurt Roeckx  said:
levitte> 
levitte> kurt> The comment about not hashing it is if you want to use the tool 
to
levitte> kurt> do entropy estimation. Hashing it will not increase the entropy,
levitte> kurt> but the estimation will be totally wrong.
levitte> kurt> 
levitte> kurt> Passing the hashed data to the drbg as entropy input is fine if
levitte> kurt> you already know how much entropy that it contains.
levitte> 
levitte> Thanks, that's what I suspected.  Ok, on to the next step

Not done running, but does show some promise...

: ; ./a.out 
../../../levitte/vms-experiments/entropy-gathering/entropy-stats.bin  8 -v
Opening file: 
../../../levitte/vms-experiments/entropy-gathering/entropy-stats.bin

Running non-IID tests...

Entropic statistic estimates:
Most Common Value Estimate = 0.975224
Collision Test Estimate = 0.902997
Markov Test Estimate = 0.410808
Compression Test Estimate = 0.811274

I assume that estimate is per "word" (i.e. per 8 bits of data in this
case).

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Richard Levitte]

In message <20180430.164908.1424770216194967097.levi...@openssl.org> on Mon, 30 
Apr 2018 16:49:08 +0200 (CEST), Richard Levitte  said:

levitte> In message <20180430.152609.587396153749337701.levi...@openssl.org> on 
Mon, 30 Apr 2018 15:26:09 +0200 (CEST), Richard Levitte  
said:
levitte> 
levitte> levitte> In message <20180430131000.ga25...@roeckx.be> on Mon, 30 Apr 
2018 15:10:01 +0200, Kurt Roeckx  said:
levitte> levitte> 
levitte> levitte> kurt> The comment about not hashing it is if you want to use 
the tool to
levitte> levitte> kurt> do entropy estimation. Hashing it will not increase the 
entropy,
levitte> levitte> kurt> but the estimation will be totally wrong.
levitte> levitte> kurt> 
levitte> levitte> kurt> Passing the hashed data to the drbg as entropy input is 
fine if
levitte> levitte> kurt> you already know how much entropy that it contains.
levitte> levitte> 
levitte> levitte> Thanks, that's what I suspected.  Ok, on to the next step
levitte> 
levitte> Not done running, but does show some promise...
levitte> 
levitte> : ; ./a.out 
../../../levitte/vms-experiments/entropy-gathering/entropy-stats.bin  8 -v
levitte> Opening file: 
../../../levitte/vms-experiments/entropy-gathering/entropy-stats.bin
levitte> 
levitte> Running non-IID tests...
levitte> 
levitte> Entropic statistic estimates:
levitte> Most Common Value Estimate = 0.975224
levitte> Collision Test Estimate = 0.902997
levitte> Markov Test Estimate = 0.410808
levitte> Compression Test Estimate = 0.811274
levitte> 
levitte> I assume that estimate is per "word" (i.e. per 8 bits of data in this
levitte> case).

Ok, done running...  suffice to say, the first tests left me ever so
hopeful...

: ; ./a.out 
../../../levitte/vms-experiments/entropy-gathering/entropy-stats.bin  8 -v
Opening file: 
../../../levitte/vms-experiments/entropy-gathering/entropy-stats.bin

Running non-IID tests...

Entropic statistic estimates:
Most Common Value Estimate = 0.975224
Collision Test Estimate = 0.902997
Markov Test Estimate = 0.410808
Compression Test Estimate = 0.811274
t-Tuple Test Estimate = 0.0818796
Longest Reapeated Substring Test Estimate = 0.0818772

Predictor estimates:
Multi Most Common in Window (MultiMCW) Test: 100% complete
Correct: 507351
P_avg (global): 0.508671
P_run (local): 0.587891
Multi Most Common in Window (Multi MCW) Test = 0.76638
Lag Test: 100% complete
Correct: 269907
P_avg (global): 0.271051
P_run (local): 0.347168
Lag Prediction Test = 1.52629
MultiMMC Test: 100% complete
Correct: 11700
P_avg (global): 0.011977
P_run (local): 0.444824
Multi Markov Model with Counting (MultiMMC) Prediction Test = 1.16869
LZ78Y Test: 99% complete
Correct: 572107
P_avg (global): 0.573391
P_run (local): 0.615723
LZ78Y Prediction Test = 0.699647
Min Entropy: 0.0818772

So I'd like to have it confirmed that I'm reading this right, that's
about 0.08 entropy bits per 8 data bits?  Or is it per data bit?
Depending on the interpretation, we either have 1 bit of entropy per
12 data bits...  or per 100 data bits...  The latter has my heart
sinking...

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Richard Levitte]

In message <20180430162209.ga4...@roeckx.be> on Mon, 30 Apr 2018 18:22:09 
+0200, Kurt Roeckx  said:

kurt> On Mon, Apr 30, 2018 at 06:00:20PM +0200, Richard Levitte wrote:
kurt> > 
kurt> > So I'd like to have it confirmed that I'm reading this right, that's
kurt> > about 0.08 entropy bits per 8 data bits?  Or is it per data bit?
kurt> 
kurt> Per symbol, being 8 bits for what you provided.
kurt> 
kurt> > Depending on the interpretation, we either have 1 bit of entropy per
kurt> > 12 data bits...  or per 100 data bits...  The latter has my heart
kurt> > sinking...
kurt> 
kurt> It's per 100 bits, and that's really still an overestimate. One
kurt> of the models they used was able to predict it that well.

That well?  I'm not sure I understand, the final min-entropy value is
the *lowest* of all different estimates.  Also, I'm not sure what
makes you say it's an overestimate...  are you simply speculating?

Either way, this is quite discouraging, because this means that with
that estimate, I need to gather about 25 KiB of data to meet the
requirements of our DRBG.  Right?

kurt> It might be possible to create a better model.

I'm not sure I understand what you mean.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Richard Levitte]

In message <20180501.060913.811991315461935857.levi...@openssl.org> on Tue, 01 
May 2018 06:09:13 +0200 (CEST), Richard Levitte  said:

levitte> Either way, this is quite discouraging, because this means that with
levitte> that estimate, I need to gather about 25 KiB of data to meet the
levitte> requirements of our DRBG.  Right?

Gah!  Too early in the morning to keep bits and bytes apart!  So, err,
about 3 KiB plus change...  Still not the most encouraging thought...

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Richard Levitte]

In message <20180501084317.ga32...@roeckx.be> on Tue, 1 May 2018 10:43:17 
+0200, Kurt Roeckx  said:

kurt> If you actually follow SP800-90B, you should make a theoretical
kurt> model of how much entropy you expect, and then use the tool
kurt> to verify that your model is correct.

E...  look, I'm kind of a rookie in this particular area, so errr,
I'm not sure I have the knowledge to think of a theoretical model.
Given a crash course, I can probably come up with *something*, but at
this moment, I don't know where to start.

A side note to this discussion, the way the rand pool routines are
currently implemented, specifically rand_pool_bytes_needed(), we
cannot handle a source with less than 1 entropy bit per 8 bits of
data.  Or well, it can, if that particular routine isn't used, but
considering it's a fairly crucial routine for entropy acquisition, I'd
say it needs a small change.  PR coming up.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project