| ▲ | xorcist 19 hours ago | ||||||||||||||||
These are not vulnerabilities in the "remote exploit" sense. They should be taken seriously, you should be careful not to run local software on untrusted data, and GPG should probably do more to protect users from shooting themselves in the foot, but the worst thing you could do is panic and throw out a process your partners and colleagues trust. There is nothing here that will disturb your workflow signing commits or apt-get install-ing from your distribution. If you use crypographic command line tools to verify data sent to you, be mindful on what you are doing and make sure to understand the attacks presented here. One of the slides is titled "should we even use command line tools" and yes, we should because the alternative is worse, but we must be diligent in treating all untrusted data as adversarial. | |||||||||||||||||
| ▲ | akerl_ 19 hours ago | parent | next [-] | ||||||||||||||||
A huge part of GPG’s purported use case is getting a signed/encrypted/both blob from somebody and using GPG to confirm it’s authentic. This is true for packages you download and for commits with signatures. Handling untrusted input is core to that. | |||||||||||||||||
| |||||||||||||||||
| ▲ | tgsovlerkhgsel 16 hours ago | parent | prev [-] | ||||||||||||||||
It reads to me like attempting to verify a malicious ascii-armoured signature is potential RCE. | |||||||||||||||||