Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
start refusing to pull packages from unauthenticated upstreams #3004
Comments
dunn
added a commit
to dunn/melpa
that referenced
this issue
Dec 26, 2015
dunn
added a commit
to dunn/melpa
that referenced
this issue
Dec 26, 2015
jeffgran
added a commit
to jeffgran/melpa
that referenced
this issue
Jan 5, 2016
|
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. |
tarsius
added
the
feature
label
Aug 14, 2016
tarsius
added
policy
and removed
feature
labels
Mar 12, 2017
glyph
commented
Apr 4, 2017
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). |
glyph
commented
Apr 4, 2017
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 |
joewreschnig
referenced this issue
in factor/factor
Aug 4, 2017
Closed
Access to the the Factor site / Fuel repository over HTTPS #1849
|
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. |
joewreschnig
referenced this issue
in factor/factor
Aug 4, 2017
Closed
factorcode.org SSL cert expired #1815
|
I've updated #4913 and the table with deft, fuel, and zeitgeist. |
|
And now also updated with with sml-modeline. I dug through the bzr source and yes, bzr's lp: protocol is HTTP for anonymous clones, but HTTPS works. Even with the explicit URL, bzr seems to fail open validating certificates by default when it can't find roots; hopefully most uses are on an OS where it can find the roots... |
joewreschnig
added a commit
to joewreschnig/melpa
that referenced
this issue
Sep 16, 2017
joewreschnig
referenced this issue
Sep 16, 2017
Merged
Remove org-mac-iCal and org-mac-link recipes. #5011
purcell
added a commit
that referenced
this issue
Sep 16, 2017
|
After some more recipe removals:
w3m is effectively the only package left using CVS (shimbun is in the same repo). This is a very popular package, but CVS is a very bad security hole. I have not emailed Katsumi Yamaoka because I've seen other people say they already have, but maybe it's time to try again? |
|
The Redshank author appears to be @michaelw here - Michael, would you consider moving your old redshank repo to github, so that we can fetch it via a more secure method than the plain |
|
I've sent an email to the maintainer of |
|
|
|
|
|
The difference between the wiki and git is quite different.
…
|
tarsius
added
the
emacswiki
label
Oct 2, 2017
|
The current anything maintainer seems to be @rubikitch - would you consider moving it from repo.or.cz to GitHub? Or is it no longer relevant with Helm? |
|
Howm is now anonymously clonable at https://scm.osdn.net/gitroot/howm/howm.git (and also every other OSDN project - https://osdn.net/ticket/browse.php?group_id=10743&tid=37552 - thank you ISHIKAWA Mutsumi and Tatsuki Sugiura!) Unfortunately I cannot prepare a PR right now as my development computer is broken. |
glyph commentedAug 9, 2015
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.