Improvements for distribution #417
Conversation
This can't happen.
It's for local usage. Do not delete.
Yes. I don't want to do anything outside the normal flow.
No, I am not OK with that. |
|
To see what we do today: https://github.com/jarun/nnn/wiki/Release-checklist |
If we can't make CircleCI create the signature (because CircleCI does not have your PGP private key), then signature needs to be create where your private key is present - on your computer. So CircleCI will create all release assets except the signature and upload them to Github release, and locally you will run
OK, I'll have a look, I'm almost sure it's possible to achieve with a plain This is outdated, I don't have a reference right now, but since recently git archives are guaranteed to be reproducible. |
|
Also the other reason is, if we move away from github tomorrow we'll have to get rid of these deps too. |
|
See if we can use our generated package. Also once done, please udpaet the release checklist with the steps. |
Gotcha, makes sense. In this case I simply changed the way archive is generated, now this is exactly the same Git archive as Github is generating, so even if you switch away from Github, the archive and its checksums will remain the same, and your PGP signature will remain valid.
Ah, I see! I returned it, and kept unchanged, it does not generate git archive (just in case you use Will have a look at how to upload PGP signature to github release without any dependencies after a short break 😉 |
|
Could you please have another look? I made To create a new token, go here, select |
|
Does all this mean no one other than me can make a release? |
|
From a packager's point of view it's not a problem at all, I can create a list of PGP keys that are allowed to sign sources. Let's just document in README whose keys can be used to sign the tarball. I can update README in this PR, should I only put your key for the moment? |
|
@maximbaz if the answer to my question is "yes" then it's a serious issue. We can't create tokens for everyone. The packages we provide are ad-hoc and we always suggest the distro repositories to have the latest versions available. When you suggested the idea I was thinking of having checksum available along with the packages like this: https://ubuntu.com/download/desktop/thank-you?country=IN&version=18.04.3&architecture=amd64 to avoid any tampering with the auto-generated packages. However, now I see a tight coupling of the packaging using access token, private keys and so on. As soon as I do that there's additional imposed responsibility and I can be traced back from the packages. It's becoming a overkill in the name of security and trust. |
|
The answer is "no", and token is only needed if you want to upload the signature to Github via a script, whoever doesn't want to use the script doesn't need to generate tokens and can just drag-n-drop the signature via Github UI. However, from the looks of it, it is only you who are creating releases anyway, isn't it? |
For now yes. But may not be not true forever. And I decline to sign packages with my personal keys either. |
Why so, if I may ask? 🙂 You sign commits with your personal key it seems? To reiterate, there is no restriction how many people can sign packages, in principal everyone can do it, we just need to list in README whose signatures should be considered as trusted. |
The code is plaintext. You can read it and verify yourself. Also let me put it this way: do I have the right to decide what I sign and what I don't with a digital signature that can be traced back to my personal system? @zmwangx I need a second opinion on this. Is it worth adding this complexity to the distribution of a open source project package? The code is always available for audits. As per my understanding if we can provide the packages and their checksums from two different severs it's reduces the chance that both are compromised. |
|
Additional note: I am also concerned about legal. The LICENSE protects the code and devs by it's clause of no guarantee. However, the auto-generated binary may not be. If I sign the binary today and it malfunctions on a system, would I be legally vulnerable to the point that some stricter law (say, in the EU) holds me responsible for the damage done by the package? |
|
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... |
|
Signing the package does not make you any more accountable for the package quality than claimed by the license, don't worry, the license is what matters and it already claims that there is no liability and warranty for the provided software, so that's it 🙂 The key does not even need to be linked to any personal identifying information of yours, you can create a brand new PGP key for a fake name; all we need is the key ID and put this ID in the README so that users can verify the signature against that key if they want to. Deploying release artifacts to two different servers does not help users (nobody will bother to download the same archive from two servers and compare them). Hashsums help ensuring that download was not corrupted, but it doesn't protect against man-in-the-moddle attacks as there is no guarantee that hashsums were not compromised as well (especially if they are generated on the same CircleCI server). PGP signature provides the same check against corrupted downloads, but additionally provides protection against man-in-the-middle attacks, because attackers cannot compromise the signature. Basically having a signature file will help users be certain that their Given that it will only take you extra 10 seconds to run one more command after every release (every 2 months?), I personally think it's a worthy improvement.
What about all the users who install nnn via OS packages, like brew, or pacman? All of these tools support verifying gpg signatures, this impacts thousands of users. Currently they trust package maintainers, but if you provide gpg signature, they will be trusting you instead. 😉 |
|
brew does not support verifying gpg signatures. As a former maintainer I'm pretty sure... |
|
Oh, really? Ok, sorry, I am mostly familiar with Arch 🙂 But many others do support them, I'm sure. |
not the same archive. the package and the checksum.
We can have a script that downloads the files and generates the checksum locally.
Instead of the signature I would like to go by the checksum generated locally.
Those packages installed by users through package managers are generated downstream from source. If the maintainer is willing (s)he can sign. I am concerned about the packages we are auto-generating in each release. And I think when you mentioned distribution, you specifically meant the source code from the perspective of a maintainer. |
Something I really don't care about given I am not involved in generating the package that goes to the user. |
|
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 |
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.
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. |
What goes from this repo is the source code. The package that a malicious maintainer is generating can include something that's malicious. Why should I take responsibility for that? There is no way for me to sign that package. What I wanted to guard are the auto-generated non-source installation packages.
If you are testing, generating binary, packaging and uploading a package in your package manager where's my involvement? What you are asking for here is a signed source archive. Let's say you have it. But still you can tamper and upload something that's not |
Exactly my point. Thanks for wording it. |
I have a package that downloads sources tarball from Github, and uses it to compile the binary. If I had a PGP signature for this sources tarball, I would be able to verify that
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 🙂
Correct, there are some measures against that too. But for the moment I'm assuming the package maintainer is not malicious person here, but this package maintainer can be man-in-the-middled, and a PGP signature will help protecting against this. |
|
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.
And that's somehow not already protected by a SHA-256 checksum? |
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... |
Of course not, SHA-256 sum will be different for every release, there is no way to spot if a new release is compromised because someone guessed @jarun's Github password and created a new release with malicious nnn code, and submitted a new SHA-256 checksum for this malicious source code. Now if we all knew that @jarun signs his releases with a specific PGP key with a certain ID, if someone guesses his Github password and uploads a new release with malicious code, they cannot provide PGP signature from the same key ID - at best they can create a new key, with different ID, and this will raise questions from everybody. |
|
I don't need to meet @jarun in person, whoever has access to @jarun's github account right now can post here "my PGP key id is: XXXX", and I will take a note of it. If someone later comes and tells us that PGP key id changed, yes we will all be suspicious, and we will try to figure out what's going on. But if nobody will come and try to change key ID, and months go by, we will just keep trusting this exact PGP key, because it keeps signing the good code. |
|
I would hope downstream packagers do more diligence vetting changes than assuming @jarun released it, hence good. |
I think we are getting paranoid here. Just FYI, I use a 2-step and if that's compromised, we would have much more to worry about than
Wrong! What if my laptop is also compromised? |
What do you expect from them, that they read the entire codebase before packaging every release? 🙂 |
|
I do try to read commit log when I update packages. I assume Debian Developers probably do that too, but that's just an assumption. |
I think we are doing rounds on who will take responsibility of a package gone bad - maintainer or packager. |
|
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. |
|
Yes, let's summarize 🙂 The point is to find a good balance between security and usability. The point of proposal in this PR is that there is a very specific step that will take you 10 seconds at most, that you can run once per every new release (i.e. once every 2 months if I read history correctly), and it will provide us with all these benefits regardless of how good your github password is 😉 Yes it will not be a 100% proof (your point of compromising your laptop), but in my mind it will be improvement over the current state. You decide now 👍 |
|
For storing the token, please use an env variable: |
|
I think we have discussed some good points. Let me think about it. |
|
OK, let's have this for your peace of mind. Please update the release checklist in wiki as well. |
|
Thank you for your contribution! |
|
Awesome! Could you please run "make sign" to create and upload the signature for the last release? I'm already away from computer, but I want to test tomorrow that everything works as expected and thus is ready for the next release - let me know if something is not working or making you trouble on your end too! |
|
Sure! Give me a few minutes. |
|
I have uploaded the signature. |
|
Updated the release checklist as well. So we are good here. |
|
Good morning, thanks, I confirm that the signature is passing my checks and all is good, thanks for doing this and updating the wiki 👍 😉 |
|
Awesome! We are all good then! |
* Revert "Undo changes from #417" * Do not remove .git folder
Let's start on #416, I would need your feedback to better understand your current workflow, because I want to integrate the signing process as seamlessly as possible in your current release procedure.
My current assumptions:
package-and-publishis triggered and it creates Github release with all the assets.make distis not used whatsoever (I will delete it).I updated CircleCI not to generate sources tarball, we need to remember to notify other package maintainers that they need to switch to the source tarball generated by Github itself:
I created
make signthat assumes the repo is already tagged withv$(VERSION), it uses Git command to generate the exact same bit-by-bit identical tarball, signs it and removes the tarball.You will need to upload the
nnn-$(VERSION).tar.gz.sigfile to Github afterwards. Would you like me to try to find some ways to automate this? We could maybe usegithub.com/tcnksm/ghrif you are okay with installing that locally?To test, run
make signtoday, download the source tarball from Github, and run:It should report
Good signature.I made
make signonly prepare signature for the source tarball, because it's easy to replicate creation of this tarball locally without downloading anything, and because that's the only signature I personally need for Arch Linux 😉. If you'd like to sign the rest of the release assets, we would need to download stuff from Github release, sign them, and then upload the signatures. This might be an overkill for now, but let me know what you prefer.Fixes #416. So happy that you agreed to provide signatures! 🎉