I like the OSSL_ prefix for new APIs as proposed by Richard. And I agree with
Shane
that we should go for a single prefix and not have two alternatives. Existing
prefixes
for things like feature macros should remain as they are, but if the OSSL_
prefix is
our choice for the future, we should sta
> I think the KDF and MAC got back ported also...
In this case it would be no question that we should keep the names EVP_KDF and
EVP_MAC.
I was thinking OSSL_LIBCTX?
> On 24 Jul 2020, at 5:38 pm, Dr. Matthias St. Pierre
> wrote:
>
> I like the OSSL_ prefix for new APIs as proposed by Richard. And I agree with
> Shane
> that we should go for a single prefix and not have two alternatives. Existing
> prefixes
> for things like fea
As @levitte pointed out - it was not back ported (not sure why I thought it
was)
> On 24 Jul 2020, at 5:40 pm, Dr. Matthias St. Pierre
> wrote:
>
> > I think the KDF and MAC got back ported also...
>
> In this case it would be no question that we should keep the names EVP_KDF
> and EVP_MAC
> I was thinking OSSL_LIBCTX?
That's a good choice and consistent with how we name the variable in most (but
not all) places:
OPENSSL_CTX *libctx;
I volunteer to raise a pull request which does a scripted bulk rename, as soon
as we have made
a decision. Ideally, the bulk renaming shoul
They also correspond directly to EVP_MAC and EVP_KDF types. Would the types
change as well?
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet."
> On Jul 23, 2020, at 11:56 AM, Matt Caswell wrote:
>
>
>
> On 23/07/2020 16:52, Richard Levitte wrote:
> They also correspond directly to EVP_MAC and EVP_KDF types. Would the types
> change as well?
Yes, if we would decide to change the EVP_MAC and EVP_KDF prefix, then this
would not only
apply to the functions, but to the types as well.
Matthias
Adherence to the code style will also be required (indentation will change).
This will be harder to automate.
Changing EVP_RAND -> OSSL_RAND is worse because it will change line breaks as
well as indentation. OSSL_RNG avoids this, if we accept not using RAND in the
name.
KDF and MAC also get
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 and EVP_KDF
We're talking APIs (*), that includes the types. So yes, that's a
safe assumption.
Cheers,
Richard
(*) if people stopped using "API" when they mean "function", that
would save the world from a pile of confusion.
On Thu, 23 Jul 2020 18:45:49 +0200,
Short, Todd wrote:
>
>
> They also corres
Why? Just because some of us used such variable names when there was
a need to distinguish it from other contexts that are sometimes
juggled with at the time time?
(and yeah, I've made that a habit... but why that would determine the
type name, I cannot understand)
Cheers,
Richard
On Fri, 24 J
11 matches
Mail list logo
