On Wed, 15 Jan 2020 21:07:54 +0100,
Benjamin Kaduk wrote:
>
> Hi Pauli,
>
> On Tue, Jan 14, 2020 at 09:34:40PM +1000, Dr Paul Dale wrote:
> > The OMC vote is closed.
> >
> > The vote text being:
> >
> > The legacy provider should be disabled by defa
My abstain vote was a carefully considered neutral stance backed
by many paragraphs of rationale.
The gist of which is that given that the decision to load or not
the provider is in the configuration file, the party ultimately
making the decision is whoever packages the software, not the
OpenSSL
On Thu, Jan 16, 2020 at 06:57:49AM +1000, Dr Paul Dale wrote:
> I’m not sure what more I can write.
>
> I proposed the vote text around the time I sent the notification here: no
> comments.
> I created the vote, early in the voting period, the clarification was sought
> and made.
> All OMC
>>
>> The vote text being:
>>
>> The legacy provider should be disabled by default in 3.0
>>
>> With the clarification that "disabled" in this context means "not loaded”.
>>
>> The vote passed (two for, one against, four abstain)
>
> I
Hi Pauli,
On Tue, Jan 14, 2020 at 09:34:40PM +1000, Dr Paul Dale wrote:
> The OMC vote is closed.
>
> The vote text being:
>
> The legacy provider should be disabled by default in 3.0
>
> With the clarification that "disabled" in this context means "no
The OMC vote is closed.
The vote text being:
The legacy provider should be disabled by default in 3.0
With the clarification that "disabled" in this context means "not loaded”.
The vote passed (two for, one against, four abstain)
Pauli
--
Dr Paul Dale | Distingu
an 2020, at 6:30 am, Kurt Roeckx wrote:
>
> On Tue, Jan 07, 2020 at 09:57:55AM +1000, Dr Paul Dale wrote:
>> The refactoring/FIPS work needs the question resolved about loading the
>> legacy provider or not by default. We’ve been through this before on the
>> project lis
On Tue, Jan 07, 2020 at 09:57:55AM +1000, Dr Paul Dale wrote:
> The refactoring/FIPS work needs the question resolved about loading the
> legacy provider or not by default. We’ve been through this before on the
> project list [1] and in at least one PR [2].
>
> I expect that
The refactoring/FIPS work needs the question resolved about loading the legacy
provider or not by default. We’ve been through this before on the project list
[1] and in at least one PR [2].
I expect that its resolution will require an OMC vote.
Regardless of the outcome, the current intention
On Mon, Jul 15, 2019 at 02:19:22PM +0100, Matt Caswell wrote:
>
>
> On 15/07/2019 13:58, Tomas Mraz wrote:
>
> >
> > I understand that for the current digest algos implemented in the
> > legacy provider the problem might not be as pressing as these
> > al
My view point (which has been stated elsewhere) is that OpenSSL-3.0 is
about internal restructuring to allow for the various things noted in the
design documents.
It is not about changing the feature set (in a feature reduction sense).
In future releases we will make the mixture of providers
> If DSA is almost never used, why enable it by default?
I am amused/bemused that, after years of saying we do not know what people are
doing with OpenSSL, it now is now becoming common practice to blithely assert
"this is not used" when it fits the personal viewpoint of some folks.
On Tue, Jul 16, 2019 at 03:06:28PM -0400, Viktor Dukhovni wrote:
> On Mon, Jul 15, 2019 at 02:27:44PM +, Salz, Rich wrote:
>
> > >>DSA
> > >
> > > What is the cryptographic weakness of DSA that you are avoiding?
> >
> > It's a good question. I don't recall the
On Mon, Jul 15, 2019 at 02:27:44PM +, Salz, Rich wrote:
> >>DSA
> >
> > What is the cryptographic weakness of DSA that you are avoiding?
>
> It's a good question. I don't recall the specific reason why that was
> added to
> the list. Perhaps others can comment.
On Mon, Jul 15, 2019 at 02:58:42PM +0200, Tomas Mraz wrote:
> Wouldn't it be better to make the legacy provider opt-out? I.E. require
> explicit configuration or explicit API call to not load the legacy
> provider.
I'm not even sure why they need to move to a different provider
(at
hat. I'm just saying it should be better
> > advertised
> > and that internally openssl should not use the "load legacy
> > provider by
> > having it in default config file" to actively encourage the "load
> > legacy provider only if you *really* nee
>>DSA
>
> What is the cryptographic weakness of DSA that you are avoiding?
It's a good question. I don't recall the specific reason why that was added
to
the list. Perhaps others can comment.
The only weakness I know about is that if you re-use the nonce, the
uld not use the "load legacy provider by
> having it in default config file" to actively encourage the "load
> legacy provider only if you *really* need it" behavior.
I'm a little confused. "configuration changes" is about "having it in
the config file
t;>>>>
>>>> IMO this is a major release and therefore we should be taking the
>>>> opportunity to
>>>> encourage applications to move away from these legacy algorithms.
>>>> That's kind of
>>>> the point of having a legacy p
release and therefore we should be taking the
> > > opportunity to
> > > encourage applications to move away from these legacy algorithms.
> > > That's kind of
> > > the point of having a legacy provider in the first place. Most
> > > applications
> > > should n
>DSA
What is the cryptographic weakness of DSA that you are avoiding?
On 15/07/2019 14:46, Salz, Rich wrote:
>
>>DSA
>
> What is the cryptographic weakness of DSA that you are avoiding?
It's a good question. I don't recall the specific reason why that was added to
the list. Perhaps others can comment.
Matt
e disregard this but otherwise I'd like this e-mail to be a
>>> starting point for discussion.
>>>
>>> I suppose the current intention is to make the legacy provider as
>>> opt-
>>> in only by either application explicitly loading it or by having it
>
; > starting point for discussion.
> >
> > I suppose the current intention is to make the legacy provider as
> > opt-
> > in only by either application explicitly loading it or by having it
> > added to the default configuration file.
>
> The current plan is
On 15/07/2019 13:58, Tomas Mraz wrote:
> Hi everyone,
>
> if the Subject was already fully discussed and thought through then
> please disregard this but otherwise I'd like this e-mail to be a
> starting point for discussion.
>
> I suppose the current intention is to mak
Hi everyone,
if the Subject was already fully discussed and thought through then
please disregard this but otherwise I'd like this e-mail to be a
starting point for discussion.
I suppose the current intention is to make the legacy provider as opt-
in only by either application explicitly loading
26 matches
Mail list logo
