Re: [openssl-project] Local kid does good

2018-01-30 Thread Paul Dale
Great going Ben!

 

Pauli

-- 

Oracle

Dr Paul Dale | Cryptographer | Network Security & Encryption 

Phone +61 7 3031 7217

Oracle Australia

 

From: Salz, Rich [mailto:rs...@akamai.com] 
Sent: Wednesday, 31 January 2018 2:14 AM
To: openssl-project@openssl.org
Subject: [openssl-project] Local kid does good

 

One of our own, Ben Kaduk, was just picked to be the Security Area co-Director 
in the IETF!

 

Conratulations.

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

Re: [openssl-project] Local kid does good

2018-01-30 Thread Dr. Matthias St. Pierre
Wow! Congratulations, Ben!

Am 30.01.2018 um 17:13 schrieb Salz, Rich:
>
> One of our own, Ben Kaduk, was just picked to be the Security Area
> co-Director in the IETF!
>
>  
>

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

Re: [openssl-project] Local kid does good

2018-01-30 Thread Benjamin Kaduk
On Tue, Jan 30, 2018 at 04:14:52PM +, Matt Caswell wrote:
> 
> 
> On 30/01/18 16:13, Salz, Rich wrote:
> > One of our own, Ben Kaduk, was just picked to be the Security Area
> > co-Director in the IETF!
> 
> Awesome! Well done Ben!

Thanks!

It does seem likely to imply that I will be spending less time on
code (reviews), though.

-Ben
___
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?

2018-01-30 Thread 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] travis builds failing with aligment errors?

2018-01-30 Thread Matt Caswell


On 30/01/18 14:30, Matt Caswell wrote:
> 
> 
> On 30/01/18 14:27, Benjamin Kaduk wrote:
>> It seems that we've started getting issues with a single build
>> configuration, e.g.,
>> https://travis-ci.org/openssl/openssl/jobs/335110257
>>
>> Lots of complaints about alignment, like:
>>
>> crypto/modes/gcm128.c:1090:36: runtime error: load of misaligned
>> address 0x02350ce5 for type 'const size_t' (aka 'const unsigned
>> long'), which requires 8 byte alignment
>> 0x02350ce5: note: pointer points here
>>  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
>>  ^ 
>> I didn't see anything particularly special about that configuration
>> on a quick once-over; any ideas?
> 
> I raised an issue on this with some of my thoughts and investigation:
> 
> https://github.com/openssl/openssl/issues/5203
> 
> 
> The error message about unsigned int requiring 8 byte alignment seems
> suspicious to me. Shouldn't it be 4?

Oh...sorry just realised this is a slightly different but very similar
error. In my issue it is complaining about an unsigned int requiring 8
byte alignment. This issue is for an unsigned long.

Matt

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


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

2018-01-30 Thread Benjamin Kaduk
It seems that we've started getting issues with a single build
configuration, e.g.,
https://travis-ci.org/openssl/openssl/jobs/335110257

Lots of complaints about alignment, like:

crypto/modes/gcm128.c:1090:36: runtime error: load of misaligned
address 0x02350ce5 for type 'const size_t' (aka 'const unsigned
long'), which requires 8 byte alignment
0x02350ce5: note: pointer points here
 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
 ^ 
I didn't see anything particularly special about that configuration
on a quick once-over; any ideas?

-Ben
___
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)

2018-01-30 Thread Matt Caswell


On 29/01/18 11:04, Matt Caswell wrote:
> 
> 
> On 25/01/18 19:08, Matt Caswell wrote:
>>
>>
>> On 25/01/18 11:59, Salz, Rich wrote:
>>> As long as we have the freedom to release earlier, this looks okay to me.
>>
>> I added this sentence to make that freedom crystal clear:
>>
>> "This may be amended at any time as the need arises"
>>
>> I have taken this proposal and made it into a PR for updating the
>> release strategy. The PR is here:
>>
>> https://github.com/openssl/web/pull/41
>>
>> Please provide any review comments there. Once any reviews seem to have
>> settled down to a consensus I will propose an OMC vote.
> 
> I've had several approvals and no objections on this PR so I think we
> should go ahead with a vote. My proposed vote text is:
> 
> "We should update the release strategy as shown in
> https://github.com/openssl/web/pull/41, commit id 52d9ea8fb"
> 
> Any objections to the wording before I raise this?

No feedback so I started the vote:

topic: We should update the release strategy as shown in
https://github.com/openssl/web/pull/41, commit id 52d9ea8fb
Proposed by Matt Caswell
Public: yes
opened: 2018-01-30
closed: -mm-dd
ONE WEEK VOTE

I will report back here with the result once the vote is complete.

> 
> Matt
> 
>>
>> Matt
>>
>>
>>
>>>
>>> On 1/25/18, 6:00 AM, "Matt Caswell"  wrote:
>>>
>>> 
>>> 
>>> On 25/01/18 07:39, Richard Levitte wrote:
>>> > 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)
>>> 
>>> Absolutely. As I said in the email that started this thread part of the
>>> release criteria include:
>>> 
>>> - TLSv1.3 RFC published
>>> 
>>> And then I later said:
>>> 
>>> "If the TLSv1.3 RFC is not published by the time we are ready to
>>> release,or we haven't made the progress we want on the other release
>>> criteria then we can add additional betas as we see fit until such time
>>> as we are ready."
>>> 
>>> A two week release cadence might look like this:
>>> 
>>> 13th February 2018, alpha release 1 (pre1)
>>> 27th February 2018, alpha release 2 (pre2)
>>> 13th 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)
>>> 27th March 2018, beta release 2 (pre4)
>>> 10th April 2018, beta release 3 (pre5)
>>> 24th April 2018, beta release 4 (pre6)
>>> 1st May 2018, release readiness check (new release cycles added if
>>> required, first possible final release date: 8th May 2018)
>>> 
>>> Instead of putting the final release date into the plan (which would
>>> have been 8th May), I have put the the final step as a "release
>>> readiness check", 1 week after beta4. This puts an explicit opportunity
>>> for us to see how we are doing against the criteria. If we are ready
>>> then we could push ahead for an 8th May release, otherwise we extend it
>>> out as needed.
>>> 
>>> This plan uses up 6 of our maximum possible 14 pre-releases. If we go
>>> with this approach and we get to the release readiness check without an
>>> RFC then we should probably slow down our release cadence at that point.
>>> 
>>> 
>>> Matt
>>> ___
>>> openssl-project mailing list
>>> openssl-project@openssl.org
>>>