Skip to content

DSA: deprecate the low level functions.#10977

Closed
paulidale wants to merge 9 commits intoopenssl:masterfrom
paulidale:dep-dsa
Closed

DSA: deprecate the low level functions.#10977
paulidale wants to merge 9 commits intoopenssl:masterfrom
paulidale:dep-dsa

Conversation

@paulidale
Copy link
Contributor

  • documentation is added or updated
  • tests are added or updated

@paulidale paulidale added the branch: master Applies to master branch label Jan 31, 2020
@paulidale
Copy link
Contributor Author

Still WIP: evp_extra_test needs to be updated to not use the low level calls.

@slontis
Copy link
Member

slontis commented Jan 31, 2020

I foresee some merge problems for me.

Copy link
Member

@levitte levitte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Poor @paulidale... between @mattcaswell and me, life can't be easy 😉

@paulidale paulidale force-pushed the dep-dsa branch 2 times, most recently from 4555edd to 9427410 Compare February 3, 2020 02:53
@paulidale
Copy link
Contributor Author

Poor @paulidale...

This is the least of my problems...

@paulidale paulidale force-pushed the dep-dsa branch 3 times, most recently from 2a847ad to 946cda9 Compare February 3, 2020 04:52
@paulidale
Copy link
Contributor Author

paulidale commented Feb 3, 2020

Open questions are:

  1. DSA_SIG related function -- deprecate or not?
  2. ASN.1 functions -- deprecate or not?
  3. printing functions -- deprecate or not?
  4. DSA_size, DSA_bits, DSA_security_bits functions -- deprecate or not?

@levitte
Copy link
Member

levitte commented Feb 3, 2020

The general viewpoint that at least @mattcaswell and I share nowadays is that the key creation functions should not be deprecated, but the rest goes. In other words, it should remain possible to DSA_new(), then a bit of DSA_set0_pqg() and DSA_set0_key(), and finish it off with EVP_PKEY_assign_DSA(), and anything else should become a matter of using functions that accept a EVP_PKEY.

That's at least how I understood things. But it dawns on me now that @mattcaswell talked about deprecating the functions that do calculations using the keys (encryption, decryption, ...), so it seems like he has a more conservative viewpoint than me, after all.

But on direct questions:

  1. DSA_SIG functions need to stay for the moment, for the simple reason that we don't have a replacement. We should, however, have a think of making a signature not only a provided method, but also a first class object on the provider level, allowing us to pick out its pieces with OSSL_PARAM arrays just like any other provider object.
  2. ASN.1 encoding/decoding functions should essentially become increasingly deprecated, as we add serializers and deserializers. We already have the serializers in place, but not the deserializers, and I think it's fine to wait until they are implemented.
  3. I would deprecate the printing functions without any hesitation, especially since they are just wrappers around the EVP_PKEY printing functions.

@mattcaswell
Copy link
Member

IMO:

  • DSA_SIG functions should stay.
  • ASN1 encoding/decoding should stay
  • I'm ok with deprecating the printing functions
  • size/bits/security_bits seems like a bit of a grey area to me. Is it more like getting parameters "p/q/g" which we allow, or is it more like a "crypto" operation. On reflection, I suppose there may actually be some "calculation" involved to return these values - so I'm ok to deprecate.

@paulidale paulidale force-pushed the dep-dsa branch 3 times, most recently from 9647406 to ce3c254 Compare February 4, 2020 00:46
@paulidale
Copy link
Contributor Author

Thanks for the prompt feedback. Okay, DSA_SIG and ASN.1 are staying. The printing and bits/size functions are deprecated. Clarity is achieved :)

Travis is relevant...

@paulidale
Copy link
Contributor Author

Travis is fixed.

Time to open the review floodgates ...

@paulidale paulidale marked this pull request as ready for review February 4, 2020 04:46
@paulidale
Copy link
Contributor Author

Rebased to avoid conflicts.
Added deprecation warnings when command line apps are started.

Copy link
Member

@levitte levitte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a no-deprecated configuration, we shouldn't even build the dsa (and dh, since you're already on a path to include that in this deprecation) related apps source. The formula for this in build.info is:

IF[{- !$disabled{deprecated} || $config{api} < 30000 -}]
  SOURCE[openssl]=dsa.c dsaparam.c
ENDIF

apps/progs.pl Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Er, did you actually mean to have that in this PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I intend to push this as a separate commit.
I am willing to make it a separate PR if required, but it's easier here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Reopening this conversation after seeing comments from Matt on the subject.]

It turns out that these deprecations are premature.

@paulidale
Copy link
Contributor Author

In a no-deprecated configuration, we shouldn't even build the dsa (and dh, since you're already on a path to include that in this deprecation) related apps source.

This cascades to test failures. I tried :)

@paulidale
Copy link
Contributor Author

The partial dh deprecation is here only because dh relies on dsa for parameter generation. Fully deprecating dh is a lot more effort which I've got underway.

@levitte
Copy link
Member

levitte commented Feb 5, 2020

This cascades to test failures. I tried :)

Yup, there are a lot of tests that need a similar check. #10797 had a lot of failures related to exactly this, but from a different viewpoint.

Copy link
Member

@mattcaswell mattcaswell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mattcaswell mattcaswell added approval: done This pull request has the required number of approvals and removed approval: review pending This pull request needs review by a committer labels Feb 10, 2020
paulidale and others added 7 commits February 11, 2020 09:07
Use of the low level DSA functions has been informally discouraged for a
long time. We now formally deprecate them.
Do not run programs that depend on deprecated APIs when
'no-deprecated' is configured.

We still retain the conversion tests that use 'openssl pkey', and add
the one that's missing.
speed is updated to not support DSA instead of being removed.

The dhparam, dsaparam, dsa and gendsa commands are deprecated but still
exist without NO_DEPRECATED defined.
@petrovr
Copy link

petrovr commented Feb 11, 2020 via email

@levitte
Copy link
Member

levitte commented Feb 11, 2020

And this is my point - to mark as deprecated in 5.0 when is expected to exist valuable alternative.

Huh? Of course, it depends on what you mean with "valuable", but the EVP API with provider backing is the alternative.
(as a matter of fact, we have been pushing for EVP use for a long time, so even without the providers, it would have been perfectly sensible to deprecate the low-level functions)

@mattcaswell
Copy link
Member

And the error is in design - some symbols are marked depreciated without
alternative.

If you believe that then I'd like to understand what symbols you think they are. AFAIK all symbols that we are deprecating have an alternative.

openssl-machine pushed a commit that referenced this pull request Feb 11, 2020
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from #10977)
openssl-machine pushed a commit that referenced this pull request Feb 11, 2020
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from #10977)
openssl-machine pushed a commit that referenced this pull request Feb 11, 2020
Use of the low level DSA functions has been informally discouraged for a
long time. We now formally deprecate them.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from #10977)
openssl-machine pushed a commit that referenced this pull request Feb 11, 2020
Do not run programs that depend on deprecated APIs when
'no-deprecated' is configured.

We still retain the conversion tests that use 'openssl pkey', and add
the one that's missing.

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from #10977)
openssl-machine pushed a commit that referenced this pull request Feb 11, 2020
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from #10977)
openssl-machine pushed a commit that referenced this pull request Feb 11, 2020
Use 'openssl genpkey' instead.

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from #10977)
openssl-machine pushed a commit that referenced this pull request Feb 11, 2020
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from #10977)
openssl-machine pushed a commit that referenced this pull request Feb 11, 2020
speed is updated to not support DSA instead of being removed.

The dhparam, dsaparam, dsa and gendsa commands are deprecated but still
exist without NO_DEPRECATED defined.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from #10977)
openssl-machine pushed a commit that referenced this pull request Feb 11, 2020
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from #10977)
@paulidale
Copy link
Contributor Author

Merged to master. Thanks for the reviews and feedback.

@paulidale paulidale closed this Feb 11, 2020
@paulidale paulidale deleted the dep-dsa branch February 11, 2020 22:55
@paulidale paulidale added approval: ready to merge The 24 hour grace period has passed, ready to merge and removed approval: done This pull request has the required number of approvals labels Feb 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approval: ready to merge The 24 hour grace period has passed, ready to merge branch: master Applies to master branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants