whipper-team
GPG signatures for source validation
As we all know, today more than ever before, it is crucial to be able to trust our computing environments. One of the main difficulties that package maintainers of Linux distributions face, is the difficulty to verify the authenticity and the integrity of the source code.
The Arch Linux team would appreciate it if you would provide us GPG signatures in order to verify easily and quickly of your source code releases.
Overview of the required tasks:
- [ ] Please create and/or use a 4096-bit RSA keypair for the file signing
- The key may be used for email encryption too
- Keep your key secret, use a strong unique passphrase for the key
- [ ] Upload the public key to a key server
- [ ] Sign every new commit by default
- [ ] Sign new tags
- Verify the Github Release tarball download against your local source
- [ ] Sign Github Release tarballs
Additional Information:
- https://help.github.com/categories/gpg/
- https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
- https://www.qubes-os.org/doc/verifying-signatures/
- https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https
Thanks.
I think it's better to wait at least until we've reached milestone 1 (or 2). This can be also considered when asking major distributions for official packaging.
I am willing to package whipper for archlinux for [community] if gpg signatures are used. It would still increase the security of the AUR package. Especially because of AUR itself. Signing the git history is better to start sooner than later.
I am willing to package whipper for archlinux for [community] if gpg signatures are used. It would still increase the security of the AUR package. Especially because of AUR itself.
Great, thanks. We'll decide how to proceed exactly after milestone 1 has been reached.
There are two prospective TUs who are not only willing but want to package and maintain whipper for [community] (and AUR) even without using GPG to hold it hostage/blackmail. (That said, GPG is great, and it should be used to sign commits too! But that should not keep it from being packaged if you actually wanted to maintain it in the first place.)
Sure you can move it to community without gpg. The question is, if it is a good idea to do so. Because the security of the users is not guaranteed. Security is not a game and in this case it is not only of high importance but also very simple to realize.
I even wrote a script that automates the whole process. Even uploading to github will follow soon. Please have a look: https://github.com/NicoHood/gpgit
Please consider to use gpg, no matter who packages this software. People will be thankful for more security. Thanks :)
@NicoHood Putting our project in your "Hall of Shame" is a bit pathetic. We simply need to first finish some essential features before we make a first "official" release. We'll get to it. It's not an outright refusal, it's a "give us some time, we have to sort out a few other things first". You're not helping your cause here with this "Hall of Shame". I use OpenPGP for plenty of things, and your zealousness here is a bit upsetting.
The fact is that a safe GPG workflow isn't something which can be so easily automated without sacrificing REAL security or done without being tedious / complicated (for example I'm thinking about safe private key handling / signing).
I'll repeat what I've already said: I'll start considering this one seriously only after milestone 1 has been reached.
It can be automated and it is not complicated. All you need to do it to use a strong and secure password. You can store it inside your head, or use a password safe such as keepass or mooltipass. I personally use mooltipass as offline password keeper.
You should possibly try out my script. Its simpler that you think.
@NicoHood No, I agree with @JoeLametta that automated means sacrificing REAL security in PGP world. If you’re really are that after security, you should rather teach people how to do PGP right than urge them to release sigs using blackmailing-like techs (this “hall of shame things”, seriously…). Like having the master key offline, in the sense of “on a device never connected to internet”. And explaining WoT concept.
Also, for password safe vs strong and secure password, you’re wrong too. You’ll have to remember a strong password for the password safe anyway, but doing so you increase attack surface, something that is OK for your website passwords (because the safe is not available on the internet), but not for PGP/SSH keys (that already rely on this security layer that is your computer not being a web server).
Regarding whipper, I entirely trust @JoeLametta and the others to do the right things when this will make sense, i.e. when milestone 1.0 will have been reach and whipper is ready for wide adoption. I definitively prefer them to spend their time fixing and enhancing things for now than on setting a proper PGP workflow, which requires time in contrary to what you think.
whipper is not the most important piece of software when it comes to security, so PGP isn’t first priority issue.
