Go-tools: How to handle the crypto/dsa deprecation

Created on 19 Feb 2021  路  7Comments  路  Source: dominikh/go-tools

Go 1.16 has deprecated crypto/dsa. Technically, viable alternatives exist since probably Go 1.0. If left to its defaults, SA1019 will flag all imports of crypto/dsa. I am not sure that is the right decision. The majority of people who still use DSA probably do so because of an external requirement, having to interface with other systems that still use DSA. As such, the deprecation warning would only act as unactionable noise and be ignored by users. I am inclined to not flag imports of crypto/dsa.

/cc @FiloSottile

enhancement help wanted needs-decision

Most helpful comment

Howdy @dominikh and @FiloSottile . Coming over from the ZLint repo that got cross linked to this issue.

I would say that we are not a great example of a project that is particularly "dependent" upon this.

  1. We have the zcrypto project which serves as a our own fork of various golang x509, pki, and crypto libraries specifically for shenanigans such as this (and we have already vendored crypto/dsa into the project).
  2. We are a linter ourselves. Our usecase for importing crypto/dsa was to make sure that OTHER people weren't generating x509 certificates using crypto/dsa. In that regard, we quite agree that this package is deprecated. This is just an unfortunate/interesting interaction between our two projects.

All 7 comments

The majority of people who still use DSA probably do so because of an external requirement

Do you have user reports about this? Most uses of the package I've seen were more of the "support all the algorithms" kind.

Do you have user reports about this?

None yet, and admittedly I guessed. Systems that require DSA do exist, and I couldn't believe that new code would willingly use it, given the choice.

I would be curious to see if any show up.

I try to swing the deprecation hammer sparingly, because I know it will show up in users' faces, but crypto/dsa is meaningfully different from crypto/rsa in ways that might not be obvious to users. For example, I am working on moving math/big out of the security perimeter, but crypto/dsa will be left behind, and due to its parameters is way more susceptible to all kinds of attacks.

Even NIST, which is notoriously conservative, bans the use of DSA for signing, so I am not very convinced these intentional DSA deployments actually exist.

In that case I shall do nothing for now and see if anyone actually complains about the warning.

Thank you, Filippo.

Thank you! Feel free to cc me on any DSA (or crypto) related report.

@FiloSottile In case you are interested, here are people running into the warning: https://github.com/zmap/zlint/pull/578

Howdy @dominikh and @FiloSottile . Coming over from the ZLint repo that got cross linked to this issue.

I would say that we are not a great example of a project that is particularly "dependent" upon this.

  1. We have the zcrypto project which serves as a our own fork of various golang x509, pki, and crypto libraries specifically for shenanigans such as this (and we have already vendored crypto/dsa into the project).
  2. We are a linter ourselves. Our usecase for importing crypto/dsa was to make sure that OTHER people weren't generating x509 certificates using crypto/dsa. In that regard, we quite agree that this package is deprecated. This is just an unfortunate/interesting interaction between our two projects.
Was this page helpful?
0 / 5 - 0 ratings

Related issues

jtreleaven picture jtreleaven  路  3Comments

igungor picture igungor  路  3Comments

MarkSonghurst picture MarkSonghurst  路  4Comments

ryboe picture ryboe  路  3Comments

stamm picture stamm  路  4Comments