>Moreover, the deprecated commands print something to the effect of: "The
>command dsa is deprecated. Use ‘pkey’ instead." when executed.
I hope it only does that
If (isatty(0) && isatty(1) && isatty(2)) {
BIO_printf(bio_errerr, “%s: This command
one +61 7 3031 7217
>> Oracle Australia
>>
>>
>>
>>
>>> On 5 Mar 2020, at 5:15 am, Kurt Roeckx >> <mailto:k...@roeckx.be>> wrote:
>>>
>>> On Mon, Mar 02, 2020 at 11:41:57AM +, Matt Caswell wrote:
>>>>
On Mon, Mar 02, 2020 at 11:41:57AM +, Matt Caswell wrote:
On 28/02/2020 23:43, Dr Paul Dale wrote:
Any suggestions for a consensus on this thread?
I think we can probably agree that:
- Command option deprecations should be handled better
- We should look at whether we can resurrec
2020 at 11:41:57AM +, Matt Caswell wrote:
>>
>>
>> On 28/02/2020 23:43, Dr Paul Dale wrote:
>>> Any suggestions for a consensus on this thread?
>>
>> I think we can probably agree that:
>>
>> - Command option deprecations should be handled b
On 04/03/2020 19:15, Kurt Roeckx wrote:
> On Mon, Mar 02, 2020 at 11:41:57AM +, Matt Caswell wrote:
>>
>>
>> On 28/02/2020 23:43, Dr Paul Dale wrote:
>>> Any suggestions for a consensus on this thread?
>>
>> I think we can probably agree that:
On Mon, Mar 02, 2020 at 11:41:57AM +, Matt Caswell wrote:
>
>
> On 28/02/2020 23:43, Dr Paul Dale wrote:
> > Any suggestions for a consensus on this thread?
>
> I think we can probably agree that:
>
> - Command option deprecations should be handled better
>
Mar 2020, at 9:41 pm, Matt Caswell wrote:
>
>
>
> On 28/02/2020 23:43, Dr Paul Dale wrote:
>> Any suggestions for a consensus on this thread?
>
> I think we can probably agree that:
>
> - Command option deprecations should be handled better
> - We should l
On 28/02/2020 23:43, Dr Paul Dale wrote:
> Any suggestions for a consensus on this thread?
I think we can probably agree that:
- Command option deprecations should be handled better
- We should look at whether we can resurrect some of the "old" commands
(possibly by writing the
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. One didn’t
Most of the conversions to using PKEY were straightforward. One didn’t require
any changes (dsa but my memory is suspect). One seemed quite difficult. Some
I didn’t check.
Modifying the commands so that they continue to work and print (to stderr) an
alternative pkey based command might be
> On Feb 22, 2020, at 4:53 AM, Richard Levitte wrote:
>
> Something that could be done is to take all those aged commands and
> rewrite them as wrappers for genpkey, pkey and pkeyutl. Simply create
> and populate a new argv and call genpkey_main(), pkey_main() or
> pkeyutl_main().
Agreed, that
On Sat, 22 Feb 2020 00:51:17 +0100,
Kurt Roeckx wrote:
> Some equivalants:
> openssl dhparam 2048
> openssl genpkey -genparam --algorithm DH -pkeyopt dh_paramgen_prime_len:2048
>
> openssl dsaparam 2048
> openssl genpkey -genparam -algorithm DSA -pkeyopt dsa_paramgen_bits:2048
Side note: I never
On Sat, 22 Feb 2020 00:03:05 +0100,
Matt Caswell wrote:
> 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
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
31 matches
Mail list logo
