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
> On 22 Feb 2020, at 1:36 pm, Viktor Dukhovni
> wrote:
>
> But there's nothing like
> using a screwdriver to turn a screw, rather than banging it in with
> an all-purpose hammer!
If we are trying to tell users to not use the low level API’s, and then we go
and use them everywhere in apps it
On Sat, Feb 22, 2020 at 12:51:17AM +0100, Kurt Roeckx wrote:
> > (I just realised that what the CHANGES entry says is that
> > dhparam/dsaparam are deprecated in favour of pkeyparam - but actually I
> > think the equivalent functionality is more split between genpkey and
> > pkeyparam)
>
> Some
On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote:
> dhparam itself has been deprecated. For that reason we are not
> attempting to rewrite it to use non-deprecated APIs. The informed
> decision we have made about DH_check use in dhparam is to not build the
> whole application in a
On Fri, Feb 21, 2020 at 11:27:55PM +, Matt Caswell wrote:
>
>
> On 21/02/2020 23:18, Kurt Roeckx wrote:
> > On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote:
> >>
> >> dhparam itself has been deprecated. For that reason we are not
> >> attempting to rewrite it to use
I think any deprecated apps or options that must be kept and not implemented in
the new interface should print a warning when used in that case then, and only
do that when it's impossible to implement it in the current release.
That's not at all clear with the speed app for example. (That speed
On 21/02/2020 23:18, Kurt Roeckx wrote:
> On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote:
>>
>> dhparam itself has been deprecated. For that reason we are not
>> attempting to rewrite it to use non-deprecated APIs. The informed
>> decision we have made about DH_check use in
On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote:
>
> dhparam itself has been deprecated. For that reason we are not
> attempting to rewrite it to use non-deprecated APIs. The informed
> decision we have made about DH_check use in dhparam is to not build the
> whole application in a
On 21/02/2020 20:33, Matthew Lindner wrote:
> I think any deprecated apps or options that must be kept and not
> implemented in the new interface should print a warning when used in
> that case then, and only do that when it's impossible to implement it
> in the current release.
I agree with
On 21/02/2020 22:17, Kurt Roeckx wrote:
> On Fri, Feb 21, 2020 at 09:50:10AM +, Matt Caswell wrote:
>>
>>
>> On 21/02/2020 08:06, Kurt Roeckx wrote:
>>> In the apps, a lot of the files define
>>> OPENSSL_SUPPRESS_DEPRECATED, which I think is the wrong way to do
>>> it. We should stop using
On Fri, Feb 21, 2020 at 09:50:10AM +, Matt Caswell wrote:
>
>
> On 21/02/2020 08:06, Kurt Roeckx wrote:
> > In the apps, a lot of the files define
> > OPENSSL_SUPPRESS_DEPRECATED, which I think is the wrong way to do
> > it. We should stop using the deprecated functions ourself. If
> > there
On 21/02/2020 19:45, Matthew Lindner wrote:
> As a user I'm strongly in favor of this. It gives an example of how
> to implement something using the new interfaces. Even in 1.1.1 there
> are things that are impossible to implement without using low level
> interfaces. The applications should be
As a user I'm strongly in favor of this. It gives an example of how to
implement something using the new interfaces. Even in 1.1.1 there are things
that are impossible to implement without using low level interfaces. The
applications should be guides on how to correctly implement something and
>A small note about the 'no-deprecated' configuration option: this is an
> option to simulate the far future when the deprecated stuff has been removed
> from the public eye. Deprecated openssl commands should not build with such a
> configuration.
How can that work? If the deprecated
"Salz, Rich" skrev: (21 februari 2020 17:17:54 CET)
>>A small note about the 'no-deprecated' configuration option: this
>is an option to simulate the far future when the deprecated stuff has
>been removed from the public eye. Deprecated openssl commands should
>not build with such a
A small note about the 'no-deprecated' configuration option: this is an option
to simulate the far future when the deprecated stuff has been removed from the
public eye. Deprecated openssl commands should not build with such a
configuration.
Cheers
Richard
Kurt Roeckx skrev: (21
On 21/02/2020 08:06, Kurt Roeckx wrote:
> In the apps, a lot of the files define
> OPENSSL_SUPPRESS_DEPRECATED, which I think is the wrong way to do
> it. We should stop using the deprecated functions ourself. If
> there is no way to do this using non-deprecated functions, the
> function should
Hi,
We seem to be deprecating a lot of the old APIs, which I think is
a good thing. But I think we might either be deprecating too much,
or not actually using the alternatives ourself.
In the apps, a lot of the files define
OPENSSL_SUPPRESS_DEPRECATED, which I think is the wrong way to do
it. We
18 matches
Mail list logo
