requests continuing.
It’s the rest that is more concerning.
Does anyone else have a similar view?
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> BTW: It took me all my force of will to resist the temptation of making a pun
> by naming the label [urgent: beta blocker].
Failed you have. Your training is not yet compete :)
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
of a stretch as a comparison.
The API renaming discussion *must* reach a conclusion before beta.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 10 Sep 2020, at 8:40 pm, Matt Caswell wrote:
>
>
>
> On 09/09/2
: required changes see
review/comments” might be workable.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 10 Sep 2020, at 4:03 pm, Dr. Matthias St. Pierre
> wrote:
>
>> Just wondering if we should have
826#pullrequestreview-485480847>).
These would give a clear indication of what additional material is being
expected as per CLA required and need rebase.
A “hold: code needed" seems less useful :)
Thoughts or should we just add them?
Pauli
--
Dr Paul Dale | Distinguished Architect | Cr
Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 10 Sep 2020, at 12:08 am, Tomas Mraz wrote:
>
> On Wed, 2020-09-09 at 22:29 +1000, Dr Paul Dale wrote:
>>> On 9 Sep 2020, at 9:38 pm, Tomas Mraz wrote:
>>>
> On 9 Sep 2020, at 9:38 pm, Tomas Mraz wrote:
>
> We could even provide a convenience thread local stack of lib contexts
> so the caller would not have to keep the old value but would just push
> the new libctx when entering and pop the old one when leaving. With
> that, I think the changes
It is also worth noting that new features will not be accepted during the beta
period.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 27 Aug 2020, at 1:58 am, Matt Caswell wrote:
>
> Hi all
>
&
This might be interesting to some:
https://tls13.ulfheim.net <https://tls13.ulfheim.net/>
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
I’ve closed the vote. Five for, none against, the vote passes. RAND_DRBG will
be absent in 3.0.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
So far a universal voice for removal of the DRBG_RAND APIs.
I’ll write up an OMC vote.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 27 Jul 2020, at 6:51 pm, Matt Caswell wrote:
>
> I'm ok with
name and might change — this is not
relevant to this discussion.
4. The RAND_DRBG APIs are unlikely to be widely used — they were introduced in
1.1.1. The two users I know of (Akamai and NCP) are both fine with them being
removed.
Thoughts anyone?
Pauli
--
Dr Paul Dale | Distinguished
I think the types should change to match any function name changes.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 24 Jul 2020, at 2:45 am, Short, Todd wrote:
>
> They also correspond directly to EVP_MAC an
get longer and would have the same issue.
Then there are the inevitable merge conflicts….
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 24 Jul 2020, at 6:15 pm, Dr. Matthias St. Pierre
> wrote:
>
>&
The exact same points apply to EVP_MAC & EVP_KDF.
We have also been telling people “use EVP” for ages.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 24 Jul 2020, at 3:20 pm, Richard Levitte wrote:
>
There has been a suggestion to rename EVP_RAND to OSSL_RAND. This seems
reasonable. Would it also make sense to rename the other new APIs similarly.
More specifically, EVP_MAC and EVP_KDF to OSSL_MAC and OSSL_KDF respectively?
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic
I’d agree it’s major for for SHA1 but not for MD5.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 18 Jun 2020, at 12:20 pm, Tim Hudson wrote:
>
> Given that this change impacts interoperability in a
for possible
breakage but the bulk of the changes are S390x specific.
I support formalising the rules better than we have at the moment. Even if
this is in conflict with the above.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle
and CMS calls removed from
the KDF and the various structures constructed piecemeal using calls that
already exist within the FIPS provider.
If somebody is willing to take this work on, it will likely be included in the
FIPS validation for 3.0.
If not, it won’t be.
Pauli
--
Dr Paul Dale
topic: Accept and merge #11577.
comment: #11577 reduces the maximum length of TLS labels.
It also breaks standards compliance.
8 against, none for, no abstentions, 3 not yet voted.
The vote failed, the PR will be closed.
Pauli
--
Dr Paul Dale | Distinguished Architect
This vote has passed: 3 for, 1 against and 2 abstentions.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 8 May 2020, at 3:08 pm, Dr Paul Dale wrote:
>
> PR 11575 <https://github.com/openssl/openssl/pul
would mean
removing them once quantum computers are shown to be effective. Without
deprecation now, we can’t remove them until a lot later.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
The vote:
Remove the calls FIPS_mode() & FIPS_mode_set() in 3.0.
Has closed.
For: 3
Against: 1
Abstain: 2
The vote passes.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
My concern is are 1.1.1 and 3.0 really all that different?
The core is quite different but the cryptographic algorithms aren’t. CMS,
x509, …?
I’d rather not introduce a burden where it isn’t necessary.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7
Might the demos be useful for something like this?
I know they aren’t in great state and could do with better documentation but
they seem to fulfil most of the suggested goals.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
Matthew,
Good idea. I’ll add it.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 5 Mar 2020, at 8:55 am, Matthew Lindner wrote:
>
> Shouldn't the deprecation notice that's printed also print th
to the effect of: "The
command dsa is deprecated. Use ‘pkey’ instead." when executed.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 5 Mar 2020, at 5:15 am, Kurt Roeckx wrote:
>
> On Mon, Mar 02,
.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
to be somewhat problematic.
There isn’t a 1:1 conversion and some of the legacy options simply aren’t
supported.
I’m hoping to have a preliminary PR up later this week.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 2
Any suggestions for a consensus on this thread?
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 24 Feb 2020, at 5:08 pm, Dr Paul Dale wrote:
>
> Most of the conversions to using PKEY were straightforward. O
be workable too.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 24 Feb 2020, at 5:53 am, Viktor Dukhovni
> wrote:
>
>> On Feb 22, 2020, at 4:53 AM, Richard Levitte wrote:
>>
>> Something th
The added complexity was of some concern to me when doing the deprecations.
I suspect we’ll also encounter difficulties getting 100% equivalent behaviour
via PKEY. There are some pretty arcane options in some of these.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic
An alternative would be to only run a cut down selection of tests with msan.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 14 Feb 2020, at 11:00 pm, Matt Caswell wrote:
>
>
>
> On 14/02/2020 12:23
uecomment-585603911>
And a further one via private email.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 14 Feb 2020, at 7:37 pm, Matt Caswell wrote:
>
>
>
> On 14/02/2020 02:30, Dr Paul Dale wrote:
>&g
and switching to the provider model.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
d to judge the relevancy.
Agreed also over the “urgent” label.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 9 Feb 2020, at 1:56 am, Mark J Cox wrote:
>
> I've currently got a cron job running every hour th
I thought I was subscribed but don’t seem to see the failures.
I do get the (very many) PR activity emails….
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 1 Feb 2020, at 8:35 pm, Dr. Matthias St. Pierre
>
Thanks for the feedback everyone.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
I meant “what default makes the most sense for the passwd command line
application?”
It was crypt which is deprecated. Should it be BSD’s MD5? One of the SHA2
based algorithms? Or should it produce an error if no algorithm is selected?
Pauli
--
Dr Paul Dale | Distinguished Architect
Could the people who work with distros confirm this default choice or suggest
what they use please?
Thanks,
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 18 Jan 2020, at 10:05 am, Dr Paul Dale wrote:
>
Okay, it looks like the consensus is option 3 — deprecate and forget.
As far as I can tell, they are only used (by us) in one place outside of
libcrypto, so that will deprecate as well.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle
.
Removing these calls will require an OMC vote as a breaking API change. I’m
fine to call one if it seems justified.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 17 Jan 2020, at 5:41 pm, Viktor Dukhovni
>
the password derivation functions into KDFs
if necessary.
Thoughts? Other alternatives?
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
r Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 16 Jan 2020, at 6:07 am, 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 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
Kurt,
It’s a policy decision: should we cause pain for users (& Matt) or effectively
delay the end for these old/broken algorithms.
Technically it is easy.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 9 J
is that the low level direct
access functions (e.g. IDEA_encrypt) will continue to work (albeit deprecated),
only the EVP access will go (again, by default).
Before the vote is called, are there any additional thoughts from the past six
months?
Pauli
--
Dr Paul Dale | Distinguished
A better example of this problem: #10607. Both Paul and I approved it
yesterday and I merged it today without noticing until too late that it was
tagged “CLA: trivial” :(
I’ve not reverted it at this point but will if necessary.
Let’s get the label in.
Pauli
--
Dr Paul Dale | Distinguished
A red blocker along the lines of: “Triviality Unconfirmed”. One of the
reviewers needs to remove this before the PR can be merged.
It’s in our face, it prevent accidental merges and its low overhead.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031
Before we start over engineering a solution, how about we try just having an
automatic visual indicator for trivial PRs.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 13 Dec 2019, at 3:24 am, Kurt Roeckx wr
tter would be to add it only if the submitter doesn’t have a CLA on
file but either works.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 12 Dec 2019, at 7:20 pm, Matt Caswell wrote:
>
> I noti
Oops, you are correct. I was under the mistaken impression that ossl_assert
compiled to nothing outside of debug mode.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 29 Nov 2019, at 7:22 pm, Matt Caswell wr
from this point of view but it can cause a
performance hit — most of the time it wouldn’t matter but when it does it would
be a big deal. The middle ground doesn’t entail any performance loss in
production code (it does in debug but that shouldn’t be relevant).
Pauli
--
Dr Paul Dale
of
these.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 21 Nov 2019, at 1:26 pm, Dmitry Belyavsky wrote:
>
> Hello,
>
> Observing a series of similar bugs related to a lack of checks of the malloc
>
The consensus seems to be to add the deprecated API to 3.0.
I’ve removed the hold.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 15 Nov 2019, at 10:40 pm, Matthias St. Pierre
> wrote:
>
>
>
>
l have to support
the new API for a long time and it is one which we are currently trying to move
away from.
Thoughts or comments anyone?
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
to face, I agree wholeheartedly.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 4 Oct 2019, at 5:39 pm, Matt Caswell wrote:
>
>
>
> On 04/10/2019 08:15, Dr. Matthias St. Pierre wrote:
>> D
Go for it, the antipodean contingent aren’t busy this weekend.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 28 Sep 2019, at 5:05 pm, Dr. Matthias St. Pierre
> wrote:
>
>> Merge early is pretty
Matt, thanks for the clarification. I’ve looked at the DRBG setup code dozens
of times and it never clicked.
It seems we’re down to making the DRBGs and, perhaps, the seed source available
using fetch.
That doesn’t seem anything like as difficult.
Pauli
--
Dr Paul Dale | Distinguished
the seed source for FIPS (so long as the DRBGs
seed from inside their own provider).
Thoughts or input anyone?
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
I’m not disputing the great effort put into this.
My dispute is that it should be under the openssl list command…..
I agree, this shouldn’t have been a “good first issue”.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
ordering for grabbing locks which is also
bad.
Pauli
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
> On 31 Jul 2019, at 2:10 pm, Viktor Dukhovni
> wrote:
>
>> On Jul 30, 2019, at 10:02 PM, Dr Paul Dale wrot
uct provider_store_st *store = get_provider_store(ctx);
CRYPTO_THREAD_read_lock(store->lock);
Pauli
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
> On 30 Jul 2019, at 8:52 pm, Matthias St. Pierre
> wrote:
>
dependent algorithms as part of the registration process. The
particular algorithm could be preloaded somehow. I’m not sure how ugly this
will become but it will need names (nids) for each possible DRBG type.
Thoughts anyone?
Any better solutions?
Any other solutions?
Pauli
--
Dr Paul Dale
The following vote passed 6 to 0.
topic: Accept the changes to the OpenSSL policies as per PR#133 (openssl/web).
comment: The definition of trivial being clarified and moved to the web page
that the missing CLA note references.
Pauli
--
Dr Paul Dale | Cryptographer | Network Security
*);
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
> On 14 Jun 2019, at 12:04 pm, Viktor Dukhovni
> wrote:
>
> On Wed, Jun 12, 2019 at 05:51:44AM +0200, Richard Levitte wrote:
>
>> A discussion point in that
random has actually been seeded.
I’ve not attempted to code this, persistent files containing seed material
potentially introduce other problems.
Pauli
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
on.
This is just saying that 3.0.0 *will* have some mechanism.
Pauli
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
The OSSL_PARAM structure needs to be visible and not subject to change.
Providers shouldn’t necessarily have a dependency on functions from libcrypto.
Pauli
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
> On 5 Jun 2019, at 1
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
> On 5 Jun 2019, at 12:47 pm, Richard Levitte wrote:
> But you're talking about allocating the whole OSSL_PARAM array on the
> heap, aren't you? While not structly opposed
Richard wrote:
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
> So while this is an issue for *us*, it isn't necessarily an issue for
> our users, all depending on what C language version they use.
Supporting things *we* can’t
?
Pauli
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
> On 5 Jun 2019, at 10:50 am, Dr Paul Dale wrote:
>
> I thought the references were to allow const arrays of OSSL_PARAM to be
> viable.
>
> A quick check th
structured manner.
Thoughts?
Pauli
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
This seems reasonable to me.
Pauli
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
> On 6 May 2019, at 5:40 pm, Richard Levitte wrote:
>
> Our last update release was by the end of February. With our usual
> 3-is
.
My thought: add the provider data field. Use that when it can be done
directly, use unique functions otherwise.
The example with key and iv lengths would be a direct use. Code that dives
through a function pointer or a switch statement would be an example of not.
Pauli
--
Dr Paul Dale
means we’ve a compatibility issue. The functions are in a public header,
they can be used by any application. We need to continue supporting such use.
Asking a user to add a DEFINE_ line is API breaking.
I would be pro making such a change but we’d need to accept the consequences.
Pauli
--
the DECLARE_LHASH_OF macro to prototype the functions.
The .c file uses the DEFINE_LHASH_OF macro to create them.
I chose lhash here because it is the simpler of the two, safestack has more
options and is a bit more convoluted. I’m willing to make a stab at a PR for
this.
Pauli
--
Dr Paul
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
--
Dr Paul Dale | Cryptographer | Network Security
and their
instantiation and move the latter into its own C file.
Pauli
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
> On 27 Jan 2019, at 8:33 pm, Tim Hudson wrote:
>
> From https://github.com/openssl/openssl/pull/7
Thanks, Richard. I’ll merge tomorrow and publish CVE 20181030.
Pauli
> On 29 Oct 2018, at 8:21 pm, Richard Levitte wrote:
>
> In message <785270db-e18c-4c5a-a961-765859cd6...@oracle.com> on Mon, 29 Oct
> 2018 19:45:36 +1000, Dr Paul Dale said:
>
>> I’d like a
I’d like a prompt review of #7513 so I can push the second CVE out.
#7512 is kind of related but not CVE level.
Pauli
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
I also believe that we shouldn’t be relying on locale, it is a Pandora’s box we
don’t want to open.
Even claiming that OpenSSL is UTF-8 compliant is probably a stretch (e.g. the
isXXX functions aren’t).
Saying we accept unsigned eight bit byte inputs and process them unmodified is
as far as I’d
101 - 182 of 182 matches
Mail list logo