I just finished implementing sha1collision detection, and it will be integrated into rpgp soon https://github.com/rpgp/rpgp/issues/293

This is the same algorithm used by git.

There are higher level implementations that use the dates on signatures to straight out reject sha1 material, but that gives only a limited protection.

I am not aware of any outstanding SHA-1 issues that would require a change in the current RFC4880 OpenPGP standard. There was an obscure attack that involved generating two keypairs with colliding SHA-1 signatures and getting a third party to sign one of them but you can just use a different hash (say SHA256). The SHA-1 used in the MDC portion of the authenticated encryption mode doesn't and is very unlikely to ever represent any security weakness (the hash used there doesn't require any particular cryptographic properties). SHA-1 is used for the key fingerprint, but the use of a hash with collision resistance is not required in general for key fingerprints. An attacker could in theory create two different keys with the same fingerprint, but then they would just own two keys that would be hard for to distinguish from one another. You don't sign the fingerprints, you sign the actual public key. In general, it would be a bad idea to specify that the hash used for a key fingerprint required collision resistance as that would mean that the fingerprint would have to be something like an unusable 256 bits long to prevent birthday attacks.

it‘s not builtin, but possible to integrate with

@wiktor-k is working on a tool to use rpgp to provide a simple solution to work with smartcards