start refusing to pull packages from unauthenticated upstreams #3004
Comments
Refs: - melpa#2342 - melpa#3004 - melpa#3005
Refs: - melpa#2342 - melpa#3004 - melpa#3005
Refs: - melpa#2342 - melpa#3004 - melpa#3005
|
Where do signed git tags/commits figure into this? They're very easy to use. Of course, if the GPG key is not fetched securely, and/or if it's not signed by a known trustworthy key, it's not technically authenticated (cf. Debian's key-signing parties). But it would still be nice to have support for it. And if MELPA stored the already-fetched GPG keys on its server, it could detect if a signing key changed, and it could refuse to build signed packages if they were signed by a different key, or unsigned packages if their previous releases were signed. This would be a nice step in the right direction. HTTPS/TLS is nice, but it's not a panacea, and it doesn't protect against something like GitHub being compromised. |
Git signatures rely on sha1, which has been more or less completely compromised by Google this year, so they don't provide a strong guarantee of authenticity either. Probably not worth bothering with. (There's also the fact that commit-signing is not itself more meaningful than "this came from this repository" unless the signer verifies the contents of every file, since the parent commit was not itself signed.)
Disagree. GPG's web of trust is so confusing that, as far as I know, there are no crypto experts who believe they can use it without serious preparation. Unfortunately, the mode that makes the most sense for using GPG is when one is verifying a signature that can only have come from one key (like debian / apt signatures). |
Provider-independent security is always a good goal, but let's not try to build rocketships before we can even crawl. This ticket is about beginning to refuse to pull from package sources that are entirely unauthenticated, and it's been open for almost 2 years. Let's please have MELPA do that before getting off into the crypto-utopian weeds with peer-to-peer signatures. |
I'm not sure I understand what you mean.
So, signed git tags are useful for authenticity now and should remain so in the future.
Not sure what you mean here either. Git inherently provides resistance to change detection, as an author who tried to push a commit to a sabotaged repo would get a push failure since his commit would not be a child of the altered commit. When a committer signs a tag, it effectively signs both that commit and the whole chain of parent commits. We assume that an author would not hard-reset his own repo to a sabotaged remote ref, then sign and push his own commit on top of that, just as we assume that an author will not give out his SSH key passphrase, etc. The threats being protected against are MITM attacks and attacks on the author's git repos, e.g. on GitHub's file servers.
What I mean is that they are easy to use for the signer: just run
For MELPA, it should be as simple as adding each author's PGP key to the MELPA keyring when their first recipe is accepted, then automatically verifying the signature on each recipe's git tags. That's very straightforward, and it provides provider-independent security. |
If I understand git's signing of tags (and commits) correctly, the problem is that when signing a tag, what you're signing is the SHA1 hash of the given commit, with some metadata (dates, name of tagger, message), not the underlying source code. Hence, if an attacker manages to produce a commit with the same SHA1 hash as a commit by the original author, then a signed tag won't protect you. (Signed tags will protect you, assuming that SHA1 is not completely broken, from a MITM attack or a rogue party having write access to the repository.) Disclaimer: IANAC |
A commit hash is a hash of the entire tree at that commit, which includes hashes of all the files. That's how git knows if a file is changed. That's the whole point. A signed tag testifies that the commit hash was signed by the author's PGP key.
As I said, there is no SHA1 preimage attack; there's not even an MD5 preimage attack yet. Google's SHA1 attack took like 100 years of GPU time and produced a collision in a specially crafted PDF. SHA1 is not broken in this way and it's a long ways from being so. Signed git tags would go a long way toward protecting MELPA, at least for the packages whose authors are willing to use them. |
I'm derailing the discussion, but the point is that the commit object (whose hash is the commit hash) contains the hash of the tree object and the parent commit (plus metadata). The tree object, in turn contains, as you wrote, the hashes of all the files, plus their sizes. As a result, if hypothetically someone manages to produce a file which has the same SHA1 hash, and the same size, as a file in the original repository (or ideally in the latest commit that hasn't yet been fetched by MELPA), then the "tree hash" and consequently the commit hash will be the same, so the signature will still be valid. Obviously there's a huge jump between producing a set of pairs of PDFs that collide, in a year, to a preimage attack (actually more, since we need the sizes to match) within the four hours between successive MELPA rebuilds, but the original assertion, that I was defending, that "Git signatures [...] don't provide a strong guarantee of authenticity either" is more-or-less true. (Again, this is not to say that git signatures wouldn't be nice to have, anyway, in an ideal world.) In any case, the topic of implementing a web of trust, using author-signed commits etc. should probably be in a separate issue. |
This is the crux of the issue. And, no--with respect--I think you are completely wrong. They currently do provide a strong guarantee of authenticity. In order to break that guarantee, either PGP or SHA1 would have to be broken. Neither of them are broken, nor are either of them close to being broken. Remember, it's effectively the same system Debian has used for years: hash packages with MD5/SHA1 (and now SHA256 as well) and PGP-sign the hashes. It's very secure--practically as secure as you can get. If it's good enough for Debian, it's good enough for MELPA. ;) |
|
On the topic of https, I think that these are the packages that are fetched unauthenticated (40 in total):
The two most popular (I think) are undo-tree and notmuch. Neither allows cloning via https (in the case of notmuch it's weird, as they have a valid certificate for the domain, but they just don't seem to support https as a protocol for git), but both do have tags that are signed. Perhaps, verifying the signature of tags could potentially be used as a supplement for requiring https (i.e. either require https or tags signed by authors). |
|
@aplaice Thanks for putting that info together! |
|
It seems that, actually, quite a few of these repositories do now support https, even if they didn't when the recipes were written. 13 need just a change of protocol and 4 also needed a slight adjustment of the URL (in the case of savannah — e.g. git://git.savannah.gnu.org/gettext.git -> https://git.savannah.gnu.org/git/gettext.git ). Full table of changes needed, below: Testing on Ubuntu 16.04, all of these can be cloned (or branched/checked out) with the relevant commands. For the remaining repositories, the fact that I was unable to find a way to fetch in an authenticated way does not mean that it's not possible. In the case of To the MELPA maintainers: I have not tested whether the packages would actually build, though I have no reason to believe they would not. Should I patch the recipes and send a pull request? |
@aplaice Yes please! Thanks for digging into this. Let's keep the |
|
@purcell I've sent a pull request. I could break this up into several pieces, for ease of reversion, if need be, but the packages seem to build and install cleanly, locally. |
|
Sorry for the noise, just realized that I need to update I see some mirrors of the CVS repo on GitHub, but, assuming they pull automatically from CVS, using them for MELPA wouldn't increase security. Ideally we could convince the author of w3m to switch to Git, but I'm assuming that he's still using CVS for a reason... :/ |
|
Some more domains have got HTTPS, and some others have official GitHub mirrors:
EIDE has got an HTTPS repository but it's very slow to clone (I gave up after 3MB and ten minutes, vs. a few seconds for raw Git) so they probably don't really intend to serve over it:
What's left (hoping I caught them all):
Many of these sites have HTTPS certificates, but not served correctly or expired. orgmode.org uses a self-signed cert. :( |
|
Thanks for keeping up with this! freedesktop.org apparently also uses https with the URL Edit: Also, |
|
The |
|
repo.or.cz uses an intentionally bizarre (non-CA root signing something that lasts 10,000 years) SSL certificate, which is also part of their authorization system, so could be very painful for them to change. If it's absolutely necessary to support these repositories, one option would be to add the ability to pin a root or server cert to the recipe directly. But IMO their security architecture is reckless and should be discouraged. |
Melpa used to fetch these packages from the Emacsmirror, which in turn imported these (and many more) packages by downloading individual libraries over insecure connections. The Emacsmirror no longer imports any packages over insecure connections and because various attempts to get the maintainers to use https have failed, these packages have been move to the Emacsattic. Once a package is in the Emacsattic, it is no longer updated. We have decided to remove insecure packages from Melpa too (#3004).
|
@tarsius should elpa be using the version at https://github.com/emacsorphanage/undo-tree? It looks like the version on elpa is 0.6.5 and yours is 0.6.6. |
|
Yes it should, but as the description of my fork says:
I don't really want to deal with this anymore. I have opened a debbugs issue about this, but nothing has happened. You are welcome to try again to get these changes merged. |
|
Ah, I understand now, thanks. Okay, I'll just point to your fork for now. I can't be bothered to try any harder 😄 Thanks! |
|
Any update on this? |
|
MELPA itself now only fetches from git and mercurial repositories, and only via I think that the only (potentially) affected packages are those from the SELECT class,url FROM packages WHERE name in ('"darcsum"','"edit-list"','"po-mode"','"dsvn"','"cg"','"helm-ls-svn"','"quack"','"clang-format"','"tex-smart-umlauts"');there are 8 which are "file" packages (they're pulled from upstream as a plain file, ignoring whatever VCS, if any, is used upstream) and 1 which is a "subtree" package (their git repo is fetched and they're "extracted" with ( Overall, I think that the issue is now fixed. (There's still the problem with the maintenance of Thanks @glyph for having filed this, in the first place! |
|
Okay: in light of all that, let’s call it done! |
|
@aplaice summed it up nicely. I agree we are "done". Thanks! |
|
I feel extremely naggish bringing this up, again, but looking at the
Regarding the remaining two, none of the obvious possibilities for fetching them over
Should I contact or ping the maintainers? In case somebody comes here without having followed the entire above thread, the issues with fetching via an insecure transport are that:
Switching to (FWIW I came back here accidentally, while trying to find |
Please do. And I agree we should do something to prevent this from happening again. Not sure where to do it though, probably |
|
I'll start with the simplest approach, first. @tgvaughan, @jamzattack I'm sorry for bothering you, but is there a way of fetching the code from your repositories for The potential security issues with pulling using an unauthenticated transport are described elsewhere in this thread, for instance here. Sorry again for taking your time and thanks for writing the interesting packages in the first place! |
|
@aplaice Thanks for getting in touch! This isn't possible with my existing server configuration, but should be possible to set up. I'll have a go at tackling this on the weekend and report back. |
|
@aplace @tarsius After an arduous battle with apache conf syntax, I got it working. The repository can now be accessed via `git clone https://git.jamzattack.xyz/eshell-outline`, feel free to update the recipe. Cheers.
|
See melpa#3004. Thanks @jamzattack for enabling this!
|
@aplace @tarsius After an arduous battle with apache conf syntax, I
got it working. The repository can now be accessed via `git clone
https://git.jamzattack.xyz/eshell-outline`, feel free to update the
recipe. Cheers.
@jamzattack Thanks very much! It's greatly appreciated!
|
See #3004. Thanks @jamzattack for enabling this!
|
@tgvaughan Hey Tim, I ha mr grad for e paar Minute uebrlegt oeps nit langsam mol a dr Zit waer in Basel e Emacstraefe z organisiert. Waersch interessiert? |
|
Ups do hani doch glad d Pandemi fuer e Momaently vrgaesse, abr wenn den alles vrbi isch... |
|
@aplace Took a bit longer than expected, but the elpher repo should now be accessible via @tarsius In principle I'm interested in Basel emacs meetups, but as you say this isn't the best time.. :-( I also only speak English and very very scratchy Hochdeutsch. |
|
I've just updated the recipe. |
|
Thanks Jonas! |
A number of recipes retrieve code using either
http://orgit://transports; these should not be allowed.My understanding is that typing
makein themelparepository is what does the actual building of packages, so it would be melpa doing the package signing when #1749 is implemented. If my understanding is correct, I think it would be irresponsible to codesign a package that was just some code automatically scraped off of a wiki.The text was updated successfully, but these errors were encountered: