On 11/4/20 5:47 PM, Geert Hendrickx via pacman-dev wrote:
On Wed, Nov 04, 2020 at 16:30:19 -0500, Eli Schwartz wrote:
Currently pacman assumes gpgme from >= the year 2010, is that sufficient to read ed25519? (idk, it's shelling out to gpg and thus likely doesn't care?) Maybe we should bump this anyway in the expectation that requiring a ~2015 version of gpgme will naturally lead to gpg versions that support generating such keys.
This change only affects new installations, existing ones will continue using their rsa2048 (or recently rsa4096) master keys, until they re-run pacman-key --init.
That's really not my point at all. My point is that rerunning --init does something the project dependencies don't describe as a requirement to support.
This will also become the default in the next version of GnuPG.
I see such a commit on GnuPG's master branch but not on the stable branch. When do you expect this to be released...
Good question, I don't know. The point is that the trend is clearly towards EdDSA rather than larger RSA. And GnuPG (as well as openssh etc) need to be conservative, as they must be interoperable with other or older implementations, pacman doesn't even have that limitation.
Why doesn't pacman have this limitation? Because it is only used in Arch Linux? Untrue, there is an active MSYS2 community using it, and we support running on macOS/BSD and occasionally get people posting compilation fixes on those platforms. Who knows what version of GnuPG various minor users might have? It's not ridiculous to consider *if* we can declare a dependency on the proposed, updated runtime workflow requirement. Likewise, I think "GnuPG did not actually change this default and won't for some time" is a meaningful point of discussion; Jonas pointed out the key strength actually decreases, while the smaller key size is not obviously beneficial as it is only used for web of trust signing. TBH, I'm -1 on any change that is being done without any rationale other than "because it's the modern way of the future". Changes should be done because they are better, or safer, or some other practical application. This may or may not be the case here, I haven't pondered it much yet. But... it's not being highlighted in the current discussion. -- Eli Schwartz Bug Wrangler and Trusted User