I think as an invited outsider I've said enough.
I do believe maintainer sustainability trumps security theater; a burned out maintainer isn't going to create any code, secure or compromised (maybe that's the goal?). People who are genuinely concerned can choose to use something else that meets their opsec standard.
> Meanwhile, random upstreams publishing random signatures -- mostly meaningless.
To expand on that, this is like PGP support on PyPI. Python developers paying some attention to the packaging story should know how well that worked...
To make sure I don't sound completely dismissive of package signing: I heard that Debian Developers actually meet in person to exchange keys when they onboard; now that's something. You're trusting them and their gatekeeping, and the signatures are proofs that they vetted the software (although you still have to make sure the key you initially downloaded from debian.org isn't compromised). Meanwhile, random upstreams publishing random signatures -- mostly meaningless.
> For example Arch package will have this key fingerprint as part of PKGBUILD; if key fingerprint suddenly changes, it will not be blindly updated, someone (e.g. package maintainer) will go to Github and try to figure out why the key has changed. It's not pointless 🙂
And that's somehow not already protected by a SHA-256 checksum?
> Ok, sorry, I am mostly familiar with Arch 🙂 But many others do support them, I'm sure.
I did add a clarification "excluding automated checks by distro package managers". I think we're talking about signing artifacts on the GitHub release page, which users have to manually verify, no? (To be clear, I'm not convinced signatures from random upstream developers provide any tangible benefits not provided by a SHA-256 checksum; IIRC this was the Homebrew team's majority opinion too. I can also cite other debates, but this is mostly beside the point, so let's focus on manual verification.) Unless you want to create an AUR package pulling in a binary artifact...
Again I don't think users who download from the GitHub release page (mostly as a last resort, I suppose) instead of compiling from source would be manually verifying the signature.
> I find it surprising, if you are not involved in generating packages that go to thousands of users, I would think you would care very much that these thousands of users don't risk of getting a malicious software that pretends to be a nnn tool written by jarun?
First I would be genuinely surprised if thousands of users are downloading binary artifacts from the GitHub release page; secondly if https://github.com is MITM'ed for them, the fingerprint you publish on README is MITM'ed too, so it's kinda pointless. There's no IRL identity verification here, WoT doesn't work.
Speaking from my experience of being a package manager maintainer and a casual observer of a few more package managers (general purpose & language specific), I'd say the percentage of users who bother to check PGP signatures (clarification: excluding automated checks by distro package managers) is probably <0.01% and those users are either building from source or installing from their trusted repo instead of downloading binaries from GitHub release pages. So I personally wouldn't bother...