René Engelhard <r...@rene-engelhard.de> writes: > If you divert /usr/bin/gpg, IMHO you need to behave like gpg.
gpg doesn't behave like gpg. Just look at all the version-specific hacks in GPGME if you don't take my word for it. Any code relying on a specific behavior of gpg is broken. > This includes accepting what gpg accepts. What gpg accepts is unacceptable. Just to provide some context, here is the second paragraph of https://en.wikipedia.org/wiki/SHA-1 Since 2005, SHA-1 has not been considered secure against well-funded opponents;[11] as of 2010 many organizations have recommended its replacement.[12][10][13] NIST formally deprecated use of SHA-1 in 2011 and disallowed its use for digital signatures in 2013, and declared that it should be phased out by 2030.[14] As of 2020, chosen-prefix attacks against SHA-1 are practical.[6][8] As such, it is recommended to remove SHA-1 from products as soon as possible and instead use SHA-2 or SHA-3. Replacing SHA-1 is urgent where it is used for digital signatures. It is sad that gpg let some LibreOffice contributor create a certificate with SHA-1 binding signatures in 2017. Saying any replacement must be as lenient as the software that let this happen in the first place makes it really hard for anyone to improve the status quo. > Otherwise such surprises happen. I disagree. I have worked with many downstream test suites, and the problem is having fixed cryptographic artifacts in them. They will go stale. This is not a question of if, but when. Preferably, test artifacts with cryptographic artifacts should be created during the test suite run. However, one often wants to anchor the implementation using pre-generated artifacts as well, and one needs to be careful not to let them go stale (and, not generate artifacts that are bad in the first place, like it happened here). Best, Justus
signature.asc
Description: PGP signature
