Please have a look at this PR

2020-03-31 Thread Bernd Edlinger 
As discussed in the meeting today,

I'd like to have my PR
Remove x86/x86_64 BSAES and AES_ASM support #9677

be approved soon, as it is holding up other
work I plan to do.


Thanks
Bernd.

Re: 1.1.1f

2020-03-29 Thread Bernd Edlinger 
Aehm, do you remember the PR #9864
were we (not me, I did approve, but I was unable to get a second approval)
failed to approve the PR, so the author just closed his PR
and went fishing instead.

I think we need to revive that PR somehow.

That is IMHO a security relevant issue when you
cannot use the correct prefix with spaces, as they
are in Windows.

Can that one at least considered for inclusion?


Thanks
Bernd.

On 3/26/20 9:13 PM, Bernd Edlinger wrote:
> 
> 
> On 3/26/20 9:10 PM, Tim Hudson wrote:
>> We don't guarantee constant time.
>>
> 
> #11411 does, I don't see why we hurry so much for 1.1.1f
> 
> we got into this situation because everything moves so quickly,
> why does everyone here think we should move even faster now?
> 
> What is the reason for this?
> 
> Bernd.
> 
>> Tim.
>>
>> On Fri, 27 Mar 2020, 5:41 am Bernd Edlinger, 
>> wrote:
>>
>>> So I disagree, it is a bug when it is not constant time.
>>>
>>>
>>> On 3/26/20 8:26 PM, Tim Hudson wrote:
>>>> +1 for a release - and soon - and without bundling any more changes. The
>>>> circumstances justify getting this fix out. But I also think we need to
>>>> keep improvements that aren't bug fixes out of stable branches.
>>>>
>>>> Tim.
>>>>
>>>> On Fri, 27 Mar 2020, 3:12 am Matt Caswell,  wrote:
>>>>
>>>>> On 26/03/2020 15:14, Short, Todd wrote:
>>>>>> This type of API-braking change should be reserved for something like
>>>>>> 3.0, not a patch release.
>>>>>>
>>>>>> Despite it being a "incorrect", it is expected behavior.
>>>>>>
>>>>>
>>>>> Right - but the question now is not whether we should revert it (it has
>>>>> been reverted) - but whether this should trigger a 1.1.1f release soon?
>>>>>
>>>>> Matt
>>>>>
>>>>>> --
>>>>>> -Todd Short
>>>>>> // tsh...@akamai.com <mailto:tsh...@akamai.com>
>>>>>> // “One if by land, two if by sea, three if by the Internet."
>>>>>>
>>>>>>> On Mar 26, 2020, at 11:03 AM, Dr. Matthias St. Pierre
>>>>>>> mailto:matthias.st.pie...@ncp-e.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I agree, go ahead.
>>>>>>>
>>>>>>> Please also consider reverting the change for the 3.0 alpha release as
>>>>>>> well, see Daniel Stenbergs comment
>>>>>>>
>>> https://github.com/openssl/openssl/issues/11378#issuecomment-603730581
>>>>>>> <
>>>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_issues_11378-23issuecomment-2D603730581=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=djWoIIXyggxwOfbwrmYGrSJdR5tWm06IdzY9x9tDxkA=
>>>>>>
>>>>>>>
>>>>>>> Matthias
>>>>>>>
>>>>>>>
>>>>>>> *From**:* openssl-project >>>>>> <mailto:openssl-project-boun...@openssl.org>> *On Behalf Of *Dmitry
>>>>>>> Belyavsky
>>>>>>> *Sent:* Thursday, March 26, 2020 3:48 PM
>>>>>>> *To:* Matt Caswell mailto:m...@openssl.org>>
>>>>>>> *Cc:* openssl-project@openssl.org <mailto:openssl-project@openssl.org
>>>>
>>>>>>> *Subject:* Re: 1.1.1f
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell >>>>>> <mailto:m...@openssl.org>> wrote:
>>>>>>>
>>>>>>> The EOF issue (https://github.com/openssl/openssl/issues/11378
>>>>>>> <
>>>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_issues_11378=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=MAiLjfGJWaKvnBvqnM4fcyvGVfUyj9CDANO_vh4wfco=
>>>>>> )
>>>>>>> has
>>>>>>> resulted in us reverting the original EOF change in the 1.1.1
>>> branch
>>>>>>> (https://github.com/openssl/openssl/pull/11400
>>>>>>> <
>>>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_11400=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=3hBU2pt84DQlrY1dCnSn9x1ah1gSzH6NEO_bNRH-6DE=
>>>>>> ).
>>>>>>>
>>>>>>> Given that this seems to have broken quite a bit of stuff, I
>>> propose
>>>>>>> that we do a 1.1.1f soon (possibly next Tuesday - 31st March).
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>>
>>>>>>> I strongly support this idea.
>>>>>>>
>>>>>>> --
>>>>>>> SY, Dmitry Belyavsky
>>>>>>
>>>>>
>>>>
>>>
>>

Re: 1.1.1f

2020-03-26 Thread Bernd Edlinger 



On 3/26/20 9:10 PM, Tim Hudson wrote:
> We don't guarantee constant time.
> 

#11411 does, I don't see why we hurry so much for 1.1.1f

we got into this situation because everything moves so quickly,
why does everyone here think we should move even faster now?

What is the reason for this?

Bernd.

> Tim.
> 
> On Fri, 27 Mar 2020, 5:41 am Bernd Edlinger, 
> wrote:
> 
>> So I disagree, it is a bug when it is not constant time.
>>
>>
>> On 3/26/20 8:26 PM, Tim Hudson wrote:
>>> +1 for a release - and soon - and without bundling any more changes. The
>>> circumstances justify getting this fix out. But I also think we need to
>>> keep improvements that aren't bug fixes out of stable branches.
>>>
>>> Tim.
>>>
>>> On Fri, 27 Mar 2020, 3:12 am Matt Caswell,  wrote:
>>>
>>>> On 26/03/2020 15:14, Short, Todd wrote:
>>>>> This type of API-braking change should be reserved for something like
>>>>> 3.0, not a patch release.
>>>>>
>>>>> Despite it being a "incorrect", it is expected behavior.
>>>>>
>>>>
>>>> Right - but the question now is not whether we should revert it (it has
>>>> been reverted) - but whether this should trigger a 1.1.1f release soon?
>>>>
>>>> Matt
>>>>
>>>>> --
>>>>> -Todd Short
>>>>> // tsh...@akamai.com <mailto:tsh...@akamai.com>
>>>>> // “One if by land, two if by sea, three if by the Internet."
>>>>>
>>>>>> On Mar 26, 2020, at 11:03 AM, Dr. Matthias St. Pierre
>>>>>> mailto:matthias.st.pie...@ncp-e.com>>
>>>>>> wrote:
>>>>>>
>>>>>> I agree, go ahead.
>>>>>>
>>>>>> Please also consider reverting the change for the 3.0 alpha release as
>>>>>> well, see Daniel Stenbergs comment
>>>>>>
>> https://github.com/openssl/openssl/issues/11378#issuecomment-603730581
>>>>>> <
>>>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_issues_11378-23issuecomment-2D603730581=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=djWoIIXyggxwOfbwrmYGrSJdR5tWm06IdzY9x9tDxkA=
>>>>>
>>>>>>
>>>>>> Matthias
>>>>>>
>>>>>>
>>>>>> *From**:* openssl-project >>>>> <mailto:openssl-project-boun...@openssl.org>> *On Behalf Of *Dmitry
>>>>>> Belyavsky
>>>>>> *Sent:* Thursday, March 26, 2020 3:48 PM
>>>>>> *To:* Matt Caswell mailto:m...@openssl.org>>
>>>>>> *Cc:* openssl-project@openssl.org <mailto:openssl-project@openssl.org
>>>
>>>>>> *Subject:* Re: 1.1.1f
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell >>>>> <mailto:m...@openssl.org>> wrote:
>>>>>>
>>>>>> The EOF issue (https://github.com/openssl/openssl/issues/11378
>>>>>> <
>>>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_issues_11378=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=MAiLjfGJWaKvnBvqnM4fcyvGVfUyj9CDANO_vh4wfco=
>>>>> )
>>>>>> has
>>>>>> resulted in us reverting the original EOF change in the 1.1.1
>> branch
>>>>>> (https://github.com/openssl/openssl/pull/11400
>>>>>> <
>>>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_11400=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=3hBU2pt84DQlrY1dCnSn9x1ah1gSzH6NEO_bNRH-6DE=
>>>>> ).
>>>>>>
>>>>>> Given that this seems to have broken quite a bit of stuff, I
>> propose
>>>>>> that we do a 1.1.1f soon (possibly next Tuesday - 31st March).
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>>
>>>>>> I strongly support this idea.
>>>>>>
>>>>>> --
>>>>>> SY, Dmitry Belyavsky
>>>>>
>>>>
>>>
>>
>

Re: 1.1.1f

2020-03-26 Thread Bernd Edlinger 
So I disagree, it is a bug when it is not constant time.


On 3/26/20 8:26 PM, Tim Hudson wrote:
> +1 for a release - and soon - and without bundling any more changes. The
> circumstances justify getting this fix out. But I also think we need to
> keep improvements that aren't bug fixes out of stable branches.
> 
> Tim.
> 
> On Fri, 27 Mar 2020, 3:12 am Matt Caswell,  wrote:
> 
>> On 26/03/2020 15:14, Short, Todd wrote:
>>> This type of API-braking change should be reserved for something like
>>> 3.0, not a patch release.
>>>
>>> Despite it being a "incorrect", it is expected behavior.
>>>
>>
>> Right - but the question now is not whether we should revert it (it has
>> been reverted) - but whether this should trigger a 1.1.1f release soon?
>>
>> Matt
>>
>>> --
>>> -Todd Short
>>> // tsh...@akamai.com 
>>> // “One if by land, two if by sea, three if by the Internet."
>>>
 On Mar 26, 2020, at 11:03 AM, Dr. Matthias St. Pierre
 mailto:matthias.st.pie...@ncp-e.com>>
 wrote:

 I agree, go ahead.

 Please also consider reverting the change for the 3.0 alpha release as
 well, see Daniel Stenbergs comment
 https://github.com/openssl/openssl/issues/11378#issuecomment-603730581
 <
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_issues_11378-23issuecomment-2D603730581=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=djWoIIXyggxwOfbwrmYGrSJdR5tWm06IdzY9x9tDxkA=
>>>

 Matthias


 *From**:* openssl-project >>> > *On Behalf Of *Dmitry
 Belyavsky
 *Sent:* Thursday, March 26, 2020 3:48 PM
 *To:* Matt Caswell mailto:m...@openssl.org>>
 *Cc:* openssl-project@openssl.org 
 *Subject:* Re: 1.1.1f


 On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell >>> > wrote:

 The EOF issue (https://github.com/openssl/openssl/issues/11378
 <
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_issues_11378=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=MAiLjfGJWaKvnBvqnM4fcyvGVfUyj9CDANO_vh4wfco=
>>> )
 has
 resulted in us reverting the original EOF change in the 1.1.1 branch
 (https://github.com/openssl/openssl/pull/11400
 <
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_11400=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=3hBU2pt84DQlrY1dCnSn9x1ah1gSzH6NEO_bNRH-6DE=
>>> ).

 Given that this seems to have broken quite a bit of stuff, I propose
 that we do a 1.1.1f soon (possibly next Tuesday - 31st March).

 Thoughts?


 I strongly support this idea.

 --
 SY, Dmitry Belyavsky
>>>
>>
>

Re: 1.1.1f

2020-03-26 Thread Bernd Edlinger 
On 3/26/20 3:14 PM, Matt Caswell wrote:
> The EOF issue (https://github.com/openssl/openssl/issues/11378) has
> resulted in us reverting the original EOF change in the 1.1.1 branch
> (https://github.com/openssl/openssl/pull/11400).
> 
> Given that this seems to have broken quite a bit of stuff, I propose
> that we do a 1.1.1f soon (possibly next Tuesday - 31st March).
> 
> Thoughts?
> 

How about adding #11411 constant time AES no-asm support then?
that should be safe, as it is something that is not enabled by default.

> Matt
>

Re: 1.1.1f

2020-03-26 Thread Bernd Edlinger 



On 3/26/20 3:14 PM, Matt Caswell wrote:
> The EOF issue (https://github.com/openssl/openssl/issues/11378) has
> resulted in us reverting the original EOF change in the 1.1.1 branch
> (https://github.com/openssl/openssl/pull/11400).
> 
> Given that this seems to have broken quite a bit of stuff, I propose
> that we do a 1.1.1f soon (possibly next Tuesday - 31st March).
> 
> Thoughts?
> 

slow down?


> Matt
>

Re: Repo Frozen

2019-09-11 Thread Bernd Edlinger 
will we release today?

On 9/9/19 5:31 PM, Matt Caswell wrote:
> Richard has just frozen the repo in advance of the releases tomorrow.
> 
> There are still some PRs outstanding that we are expecting to be included and 
> I
> will push as they become available:
> 
> 
> https://github.com/openssl/openssl/pull/9777
> Fix a padding oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey
> 
> Awaiting an update from Bernd
> 
> 
> https://github.com/openssl/openssl/pull/9802
> drbg: ensure fork-safety [1.1.1]
> 
> Approved, but awaiting input from Kurt
> 
> 
> https://github.com/openssl/openssl/pull/9811
> [1.0.2-bp][ec] match built-in curves on EC_GROUP_new_from_ecparameters
> 
> Not sure if Nicola wanted to do a final update, but otherwise its approved and
> ready to go.
> 
> 
> There will also be some CHANGES/NEWS type updates required
> 
> 
> Matt
> 
>

Re: Repo Frozen

2019-09-09 Thread Bernd Edlinger 
On 9/9/19 5:31 PM, Matt Caswell wrote:
> Richard has just frozen the repo in advance of the releases tomorrow.
> 
> There are still some PRs outstanding that we are expecting to be included and 
> I
> will push as they become available:
> 
> 
> https://github.com/openssl/openssl/pull/9777
> Fix a padding oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey
> 
> Awaiting an update from Bernd
> 

Done.

I have yet another PR, which is needed for 1.1.1
https://github.com/openssl/openssl/pull/9687
Fix a potential crash in rand_unix.c

Initially it was just a strict-warning issue,
then in the review we found a potential crash which
can happen after the entropy buffer grow patch was added,
which makes this a regression introduced after 1.1.1c.


Bernd.

> 
> https://github.com/openssl/openssl/pull/9802
> drbg: ensure fork-safety [1.1.1]
> 
> Approved, but awaiting input from Kurt
> 
> 
> https://github.com/openssl/openssl/pull/9811
> [1.0.2-bp][ec] match built-in curves on EC_GROUP_new_from_ecparameters
> 
> Not sure if Nicola wanted to do a final update, but otherwise its approved and
> ready to go.
> 
> 
> There will also be some CHANGES/NEWS type updates required
> 
> 
> Matt
> 
>

Re: [openssl-project] inline functions

2019-01-27 Thread Bernd Edlinger 
./config -fkeep-inline-functions && make
-> build fails with unresolved externals in test/rsa_complex and 
test/shlibloadtest

On 1/27/19 2:23 PM, Dr Paul Dale wrote:
> Yes, those are the problematic cases.  I think that making the symbols weak 
> is “good enough” for the moment.  Longer term, we could do with a better 
> solution.  Moving the implementations into another file is one option.  There 
> is another longer term alternative: migrate OpenSSL away from lhash and 
> safestack by introducing new internal functionality that replaces them.  We 
> can’t remove either in case users user them but we could stop using them 
> ourselves.
> 
> Lhash is based on a clever hash table that dynamically resizes (both 
> increasing and decreasing) and amortises the rehashing costs over time.  If 
> the OpenSSL source code is looked through, there are relatively few removals 
> from the hash table.  I.e. the size decrease isn’t used much, if at all.  
> Likewise, the rehashing checks one bit in the hash for each item and moves it 
> into one of two lists based based on the result.  I.e. rehashing should be a 
> fast operation and amortising it doesn’t feel like a win.  On the down side, 
> lhash runs with a fairly high level of loading (many entries relative to 
> table size) and its collision resolution is a linked list (i.e. O(n) worst 
> case instead of O(1)).  There have also been improvements in hash technology 
> since the lhash algorithm was created — cache coherent algorithms and lock 
> free ones spring to mind.
> 
> Safestack isn’t a stack anymore.  It is used as a vector, an array 
> substitute, a queue and more.  I don’t think I’ve seen it used as a stack but 
> it probably is.  We should have separate data structures for the different 
> uses, each optimised for its specific usage.
> 
> 
> This would be a long path (and I’m hijacking this thread a bit), but it is 
> something I’ve been wanting to do for a while now.
> 
> 
> Pauli
> 
> 
> ___
> 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

Re: [openssl-project] OpenSSL 1.1.1 Blog

2018-09-12 Thread Bernd Edlinger 
Hi,

I just read this in the blog article: New OMC Member and New Committers
https://www.openssl.org/blog/blog/2018/08/22/updates/

"The latest additions to the committers (in alphabetical order) are:

Paul Yang
Nicola Tuveri
"

aehm, maybe we should fix the alphabetical order ? :-)

Bernd.


From: openssl-project  on behalf of Matt 
Caswell 
Sent: Tuesday, September 11, 2018 15:56
To: openssl-annou...@openssl.org; openssl-project@openssl.org; 
openssl-us...@openssl.org
Subject: [openssl-project] OpenSSL 1.1.1 Blog

Our new Long Term Support release, OpenSSL 1.1.1, including TLSv1.3, has
been released today. Please download and upgrade!

There is a blog post about the new release and the status of the older
releases here:
https://www.openssl.org/blog/blog/2018/09/11/release111/

Matt
___
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

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Bernd Edlinger 
On 06/11/18 17:40, Richard Levitte wrote:
> In message <8ee45344-9bfc-44f9-9db2-c384f7645...@akamai.com> on Mon, 11 Jun 
> 2018 15:25:23 +, "Salz, Rich"  said:
> 
> rsalz> >*must* do when getting '-pass8bit' is to do a naïve UTF-8 encode 
> of
> rsalz> the input pass phrase string.  PKCS12_generate_mac() will then 
> decode
> rsalz>
> rsalz> I disagree.
> rsalz>
> rsalz> There are two reasons why users enter "illegal" passwords now,
> rsalz> and by now requiring them to make it explicit we can (a) check
> rsalz> only for ASCII on current inputs; (b) make them thing about
> rsalz> what they're doing and require them to specify; (c) set the
> rsalz> expectation that something will change in the future.
> 
> [btw, PKCS12_gen_mac(), not PKCS12_generate_mac()]
> 
> So wait, if the user enters this:
> 
>  openssl pkcs12 -export -in foo.pem -out foo.p12 \
>  -pass8bit -password pass:`echo 72c3a46b61 | xxd -r -p`
> 
> ...  then it seems "natural" that the user would expect the resulting
> BMPString to become this set of bytes, right?
> 
>  0x00, 0x72, 0x00, 0xc3, 0x00, 0xa4, 0x00, 0x6b, 0x00, 0x61, 0x00, 0x00
> 
> However, what's going to happen is that PKCS12_gen_mac() will generate
> this for a BMPString:
> 
>  0x00, 0x72, 0x00, 0xe4, 0x00, 0x6b, 0x00, 0x61, 0x00, 0x00
> 
> Why?  Because the input pass phrase can be interpreted as a UTF-8
> encoded string, and PKCS12_gen_mac() will decode it thusly.
> 
>  From a user interface point of view, I would fine such behavior very
> surprising, and not at all what I'd expect for a flag named '-pass8bit'
> 

I think there are many ways for the user to shoot into his own knee with
entering unicode glyphs accidentally, with are even invisible when
printed to the console, just think of the EM DASH U+2014: "—"
Or unicode non break space U+00A0 which looks like an ordinary space but
is something different

As a user, I would not be happy if one of these slipped into a password,
that's certainly sure.

So in my opinion when entering new passwords it should be restricted to
7bit ASCII printable characters, except if advised otherwise by an
option like -pass8bit.


Bernd.
___
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

2018-04-15 Thread Bernd Edlinger 
On 04/15/18 07:53, Viktor Dukhovni wrote:
> 
> 
>> On Apr 15, 2018, at 1:38 AM, Richard Levitte  wrote:
>>
>> 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.
> 
> It think it is most prudent to not fall into the trap of debating this
> particular side-issue.  I commend your initiative of running the 1.1.0
> tests against the 1.1.1 libraries, that's fantastic.  And I further
> commend attention to the failure cases.  Thank you.
> 
> With that out of the way, it seems to me that apart from some fixes in
> the test framework, and tests that did not expect protocol versions
> higher than TLS 1.2, no *interesting* issues have turned up.
> 
> If such issue did or will turn up let's fix them, but there should not
> be fundamental obstacles to an ABI-compatible 1.1.1 library with the
> same SONAME as its 1.1.0 predecessor.  The new library may negotiate
> TLS 1.3 which 1.1.0 did not, but I don't see that as an incompatibility
> that requires an SONAME version bump.
> 
> Which is not to say I could not be convinced otherwise, but at present
> I don't see a need for the bump, or for work-arounds to limit the
> negotiated protocols for code compiled against 1.1.0 that happens to
> run against 1.1.1.
> 
> Let's stay alert, but not overreact to minor issues we can resolve.
> 

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


Bernd.
___
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)

2018-04-08 Thread Bernd Edlinger 
On 04/08/18 09:49, Kurt Roeckx wrote:
> On Sun, Apr 08, 2018 at 07:15:32AM +0200, Richard Levitte wrote:
>> 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?
> 
> This is not related to VMS. What I see as most likely to break
> going from 1.1.0 to 1.1.1 is reseeding in a chroot. This can be
> solved by using a system call instead of /dev/urandom if it's
> available.
> 
> 

You say /dev/urandom is accessible on startup but no longer after
the process calls chroot?

If that is the problem, maybe the device could be opened on startup
and just left open for later reseeding?


Bernd.
___
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?

2018-03-19 Thread Bernd Edlinger 
OK, I freezed the repository for you.

On 03/19/18 19:25, Matt Caswell wrote:
> Please can someone freeze the repo for me:
> 
> $ ssh openssl-...@git.openssl.org freeze openssl matt
> 
> I will still take #5677 "Fix no-sm3 (and no-sm2)" after the freeze. Also
> if anyone can come up with a fix for the failing master in Travis that
> would be good.
> 
> Matt
> 
> 
> On 19/03/18 16:48, Matt Caswell wrote:
>> BTW please review #5673. I'd like a clean run from run-checker for the
>> release tomorrow.
>>
>> Matt
>>
>> On 19/03/18 16:33, Matt Caswell wrote:
>>> Let me know asap...
>>>
>>>
>>> Matt
>>> ___
>>> 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
> 
___
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

2018-03-09 Thread Bernd Edlinger 
On 03/08/18 12:06, Andy Polyakov wrote:
> 
>> Andy pointed out that my last e-mail was probably not clear enough.
>>
>> I want to drop the current partially overlapping checks
>> on the WRAP mode ciphers (which were ineffective anyways).
>>
>> And allow the following additional use case for any cipher
>>
>> unsigned char *in = buf + sizeof(buf) - X, *out = buf;
>> EVP_EncryptUpdate(ctx, out, , , sizeof(head));
>> out += outl;
>> EVP_EncryptUpdate(ctx, out, , in, X);
>> out += outl;
>> EVP_EncryptUpdate(ctx, out, , , sizeof(tail));
>> out += outl;
>>
>> with X > 75% sizeof(buf)
>> sizeof(head), sizeof(tail) not necessary multiple of block size
>>
>> And make the definition of allowed in-place partially overlapping
>> effectively be driven by the implementation requirements.
> 
> Nobody? OK. *Formal* objection to this is that you are making assumption
> that underlying implementation processes data in specific order. Note
> that it's not actually unreasonable assumption(*), yet in most general
> sense it's an assumption, and question rather is if you are in position
> to **formally** make it(**). One can argue that all our underlying
> implementations do that, process data in expected order that is, but it
> doesn't lift the question. One can even argue that suggested code worked
> in 1.0.1, yet it doesn't lift the question. So instead one simply aims
> for not making the assumption [or making least amount of assumptions].
> Yes, you can sense contradiction, because in-place processing also rests
> on an assumption. Yeah, world is not ideal and life is full of
> compromises. I mean there are pros and cons, and in-place is considered
> to bring more pros.
> 
> (*) And in some cases it's even 100% justified, most notably in CBC
> encrypt case, when each block is dependent on previous.
> 
> (**) Note that you can avoid the question by processing data strictly on
> per-block basis, so that you'll be in control of accessing data in
> specific order, not underlying implementation. But that's not what is
> suggested, right?

No.  The intention is to make the partially overlapping check follow
the underlying cipher's implementation needs, not the other way round.
And to document that the term "partially overlapping" is meant this way.


Bernd.
___
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

2018-03-06 Thread Bernd Edlinger 
Hi,

Andy pointed out that my last e-mail was probably not clear enough.

I want to drop the current partially overlapping checks
on the WRAP mode ciphers (which were ineffective anyways).

And allow the following additional use case for any cipher

unsigned char *in = buf + sizeof(buf) - X, *out = buf;
EVP_EncryptUpdate(ctx, out, , , sizeof(head));
out += outl;
EVP_EncryptUpdate(ctx, out, , in, X);
out += outl;
EVP_EncryptUpdate(ctx, out, , , sizeof(tail));
out += outl;

with X > 75% sizeof(buf)
sizeof(head), sizeof(tail) not necessary multiple of block size

And make the definition of allowed in-place partially overlapping
effectively be driven by the implementation requirements.


Bernd.

On 03/03/18 13:25, Bernd Edlinger wrote:
> On 03/01/18 10:59, Andy Polyakov wrote:
>>>>> I'd like to request more opinions on
>>>>> https://github.com/openssl/openssl/pull/5427. Key dispute question is
>>>>> whether or not following fragment should work
>>>>>
>>>>>  unsigned char *inp = buf, *out = buf;
>>>>>
>>>>>  for (i = 0; i < sizeof(buf); i++) {
>>>>>  EVP_EncryptUpdate(ctx, out, , inp++, 1);
>>>>> out += outl;
>>>>>  }
>>>>
>>>> This should work.
>>>>
>>>
>>> It does only work, if you know that ctx->buf_len == 0
>>> before the loop is entered.
>>
>> It's naturally implied that ctx is used *consistently*. I mean it's not
>> like it's suggested that you can just use the above snippet in random
>> place. Application would have to adhere to above pattern all along, for
>> the life time of in-place processing "session". [I write "session" in
>> quotes, because there might be better term.]
>>
>>> It does not work with CFB1, CCM, XTS and WRAP modes.
>>
>> Yes, some modes are so to say "one-shot", i.e. you have to pass all the
>> data there is at once, no increments are allowed. But what does it have
>> to do with question at hand, question about in-place processing that is?
>> These two things are independent. So that question is rather should the
>> snippet work in cases when incremental processing is an option. Related
>> thing to recognize in the context is that *disputable* condition, the
>> one that triggered this discussion, is exercised only when
>> ctx->block_size is larger than 1, because then ctx->buf_len remains 0.
>> Note that ctx->block_size for CFB1, CCM and XTS is 1. As for WRAP, yeah,
>> it's special...
>>
>>> There is no access function to get the internal state of the cipher
>>> context.
>>
>> But there is notion of in-place processing "session".
>>
> 
> Well, I'd say, apparently the consensus is at least not to restrict
> what is currently recognized as "fully" overlapping.
> 
> All depends obviously on how "partially" overlapping is defined:
> a) by humans
> b) by OpenSSL
> 
> a)
> I think humans would normally say two objects are partially overlapping
> when they overlap, but do not fully overlap, in other words partially
> overlapping in and out do have some common bytes, but do not start at
> the same address, thus in != out.
> 
> b)
> What is currently recognized as partially overlapping in the evp_enc.c
> is a) but adds some I would say ad-hoc exceptions to accommodate one
> special use case with certain block ciphers.  Yet it does for instance
> artificially restrict use cases where other ciphers work just fine.
> 
> I think for instance of WRAP mode, where the primitive basically
> supports arbitrary overlapping (uses memmove) but we can no longer
> use that feature because of the partially overlapping check in the
> EVP cipher handling.
> 
> And the other use case, which I think is worth to mention is
> 
> unsigned char *inp = buf + sizeof(buf) - 1, *out = buf;
> for (i = 0; i<sizeof(buf)-X; i++) {
>      *inp = getc();
>      EVP_EncryptUpdate(ctx, out, , inp, 1);
>      out += outl;
> }
> 
> This could work for some cipher modes at least.
> 
> And I think our overall assumption here is the user knows perfectly
> well how the internal state of the ctx is at any time, otherwise
> EVP_EncryptUpdate would probably need to have an input parameter to
> tell how large the output buffer is in reality :)
> 
> So I think maybe we can just change the definition for b) to be
> 
> Partially overlapping is any kind of overlapping that is known to be
> not working in the evp cipher update function.
> It is dependent on the cipher mode, and dependent on the internal state
> of the cipher context.
> 
> It is often the case that partially overlapping means overlapping
> with in != out but most importantly the code in evp_enc.c is known
> to fail if it was allowed to continue after EVP_R_PARTIALLY_OVERLAPPING.
> 
> 
> Bernd.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project