[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DEC09A5F-2AE7-405F-AC80-5E672B8451A6@amazon.com>
Date: Wed, 15 Jul 2015 01:57:17 +0000
From: "MacCarthaigh, Colm" <colmmacc@...zon.com>
To: Anthony Liguori <aliguori@...n.com>, Kurt Seifried <kseifried@...hat.com>,
"oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>,
"Assign
a CVE Identifier" <cve-assign@...re.org>,
Colm MacCarthaigh
<colmmacc@...n.com>
Subject: Re: CVE Request: AWS s2n
Thanks for forwarding Anthony,
I want to thank Markus for reporting the issue to us and following our reporting process, it’s great to have early interest in s2n. We do have an issue management process defined on our side, which includes requesting CVEs and disclosing the issues in our release notes (once we make a release) and issue tracker.
As others have mentioned, we’re not treating it as a CVE issue because client mode is disabled and not supported, and that’s something we highlight in our docs (https://github.com/awslabs/s2n/blob/master/docs/USAGE-GUIDE.md#client-mode); that the support is there only for testing and development work. Client mode support is also our number one feature request from early developers, so I think it's clear to any adopters that it isn’t supported. Even the s2nc CLI requires you to manually set the environment variable, which you have to find for yourself in the docs. By default it simply tells you that client mode is disabled.
Notably, s2n does not yet include any X509 or certificate validation, and we haven’t focused our testing on how it behaves as a client. Essentially the mode is there so that we can two-way end-to-end tests and those tests have to awkwardly set an environment variable. Our focus is definitely on the server side.
Right now s2n is also in a pre-release mode; we’re not providing API or ABI stability guarantees (https://github.com/awslabs/s2n/blob/master/docs/USAGE-GUIDE.md#s2n-api) just yet - so that we can be responsive to adopter’s suggestions if they don’t like our first cut. That restriction also means that we’re not seeing any production usage from downstream adopters, or downstream packaging. I’m not aware of anyone using s2n as a client.
On 7/14/15, 5:58 PM, "Anthony Liguori" <aliguori@...n.com> wrote:
>Kurt Seifried <kseifried@...hat.com> writes:
>
>> On 07/14/2015 04:03 PM, Markus Vervier wrote:
>>>
>>> On 14.07.2015 17:48, Kurt Seifried wrote:
>>>> Reminder: Client mode is disabled and won't be enabled until X509 validation is ready. But we
>>> can still make improvements and fixes in the meantime.
>>>> so I'm not sure this needs a CVE as the code is not yet enabled.
>>> Hi Kurt,
>>>
>>> that is a valid point from you and not for me to decide.
>>> Yet with default settings a binary is compiled (bin/s2nc) which will
>>> work in client mode when environment variable S2N_ENABLE_CLIENT_MODE=1
>>> is set (as documented). So it is possible several people were tempted to
>>> use s2n in client mode already as the client mode code is actually
>>> compiled into the lib and useable by default.
>>> I guess it depends on your definition of "enabled".
>>>
>>> Markus
>>
>> Ah, I didn't know that, Mitre I'm leaving this one up to you (way to
>> much of a gray area for me to even poke with a stick).
>
>Adding Colm from s2n upstream in case he would like to comment here.
>
>Regards,
>
>Anthony Liguori
>
>>
>>
>> --
>> Kurt Seifried -- Red Hat -- Product Security -- Cloud
>> PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
>> Red Hat Product Security contact: secalert@...hat.com
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
