Signing packages

[purcell]

It's possible to provide .sig signatures for packages. We should do that, if reasonably convenient, because recent versions of package.el are requesting the .sig files from our server anyway.

[tzz]

Would you expect the Emacs side to have a way to verify those signatures, or will you expect users to trust your keys manually?

[purcell]

I believe that package.el uses epg to verify signatures, and I therefore assume that the user will be prompted to accept or decline as invalid any signatures made by an unrecognised key. The key trust step always has to be manual, in any case.

[milkypostman]

the only thing we are saying though is that the package was created by our builder. it doesn't verify anything about the actual contents of the packages.

On Wed, Jun 4, 2014 at 10:10 AM, Steve Purcell notifications@github.com wrote:

I believe that package.el uses epg to verify signatures, and I therefore assume that the user will be prompted to accept or decline as invalid any signatures made by an unrecognised key. The key trust step always has to be manual, in any case.

— Reply to this email directly or view it on GitHub https://github.com/milkypostman/melpa/issues/1749#issuecomment-45120886.

[tzz]

@purcell yes, it uses EPG/EPA to verify the signatures, but we've discussed adding the GNU ELPA maintainers' public keys to a default verification keychain, separate from the user's keychains. I was wondering if you have ideas about that, and yes it's entirely hypothetical.

[purcell]

I'd be wary of adding a bunch of individual authors' signatures to a keychain that you'd then have to distribute, if that's the suggestion. Seems to me that users should simply be prompted to accept a key specific to each archive.

[tzz]

It wouldn't be individual keys but the signing key that was added.

I mention this because there are some plans to add the GNU ELPA key to such a keychain. This was added to package.texi by Glenn very recently and we've discussed it in the past:

+@c Uncomment this if it becomes true.
+@ignore
+The public key for the GNU package archive is distributed with Emacs,
+in the @file{etc/package-keyring.gpg}.  Emacs uses it automatically.
+@end ignore

...which means that, if this plan happens, you can instruct the user to add the MELPA key to that keychain instead of waiting for a prompt (in a multi-user system that would be especially sensible). Anyhow, I'm just bringing it up for your information, there's no action needed.

[purcell]

Aha, okay, makes sense -- so that's just like the Debian APT key scheme. Thanks for the explanation. I wonder what would happen to those with old Emacs installations if you update the ELPA key, though. Debian can ship new authorized key signatures as packages, but ELPA wouldn't be able to. I guess the user would just be prompted if a new key was presented by ELPA.

In a multi-user system with a shared Emacs installation, the packages would still be installed under ~/.emacs.d/elpa, and we wouldn't want to update files under /etc, so it seems like prompting each user to accept the MELPA key would be an appropriate outcome.

[chloe-zen]

ping?

[milkypostman]

sorry, still on the backburner.

[tzz]

The emacs-24 branch now has everything in place, including the function package-import-keyring to transparently import the GNU ELPA maintainer keys. It should be fairly simple to provide in the MELPA docs a command-line invocation of emacs --batch to import the MELPA maintainer keys. I don't think a key update procedure or prompt exists right now, it would have to be done with calls to EPG functions or to GnuPG directly. But please check.

Because the process uses the ~/.emacs.d/elpa/gnupg directory (well, with the appropriate Emacs variables instead of hard-coded) as the GnuPG homedir, you can provide a new key through GnuPG only. I hope that helps a little.

[purcell]

Thanks for the update Ted!

[glyph]

I'm a little confused as to what the proposed threat model is here.

A signature is a cryptographic assertion of ... something. If a package is signed through MELPA, what exactly is being asserted about it? Has someone inspected the code? Does someone have some level of trust in the individual who has uploaded the package or committed to github? I definitely don't want to import a key into my GPG keyring that signs random stuff via an unmonitored, automated system that anyone can inject stuff into...

Particularly, if a user has to accept new root signing keys on a regular basis, then part of the regular user experience is getting man-in-the-middled and hitting "OK, this is fine, update packages from this unknown and unexpected source".

[purcell]

If a package is signed through MELPA, what exactly is being asserted about it? Has someone inspected the code? Does someone have some level of trust in the individual who has uploaded the package or committed to github? I definitely don't want to import a key into my GPG keyring that signs random stuff via an unmonitored, automated system that anyone can inject stuff into...

Nobody inspects the code which gets into MELPA, other than when recipes are first added. Like most package systems, we implicitly trust that authors will not introduce malicious code: building packages directly from those authors' version control systems is how we verify that the code is from the authors. (Other package repositories instead allow registered users - who may not be verified authors - to upload content.)

Package signatures would indicate that the corresponding packages were built on our server using the recipes and the corresponding source fetched from upstream repositories, but they're no guarantee of safe content.

Serving unsigned packages over SSL would provide a similar level of assurance to users, but users have experienced various issues since Marmalade switched to HTTPS, which makes me think that the signing route is worth investigating.

Ultimately, we can serve signed packages over SSL, but when those packages are built from upstream sources, we can't guarantee their safety for users.

[glyph]

If you send packages over TLS, then the assurance is fairly clear: the trust roots are the more or less immutable CA cartel. This isn't the best, but at least it's consistent: users shouldn't ever accept a random trust root, and you know that you're always talking to MELPA at least. For a package-signing solution to provide a useful level of assurance, the trust roots must be similarly immutable, so directly trusting Melpa to be its own CA creates a bootstrapping problem.

Presuming that you have some way of addressing the bootstrapping issue of getting the key to users in a way which doesn't transparently invite MITM of that step... If you don't inspect the code, then the trust path would presumably be something like:

MELPA trusts github to properly authenticate the author, and the author to properly manage their credentials. MELPA furthermore has inspected the package and certifies that it will be securely retrieved into the build system (by trusting HTTPS and the CA cartel for the clone? or github's SSH key? which is ... verified because it was retrieved over HTTPS?) And MELPA furthermore treats the namespace on a first-come/first-serve basis so this same trust path will be ensured for updates to the package, random attackers can't update arbitrary packages (although perhaps they could add their own).

Does that sound right?

[purcell]

MELPA trusts github to properly authenticate the author, and the author to properly manage their credentials. MELPA furthermore has inspected the package and certifies that it will be securely retrieved into the build system (by trusting HTTPS and the CA cartel for the clone? or github's SSH key? which is ... verified because it was retrieved over HTTPS?)

Correct, with the exception of the minority of upstream sources which are retrieved over http or other unsecured connections, e.g. CVS, SVN, EmacsWiki. (That last one will disappear over time as we phase it out, but it's currently a gaping security hole -- certain packages like dired+ are relatively popularly and freely editable on EmacsWiki.

And MELPA furthermore treats the namespace on a first-come/first-serve basis so this same trust path will be ensured for updates to the package, random attackers can't update arbitrary packages (although perhaps they could add their own).

Yes, with the exception of authors always having the ability to monkey-patch code in other packages.

[glyph]

Yes, with the exception of authors always having the ability to monkey-patch code in other packages

Sure, but at that point you're talking about the runtime, not the bytes in the package itself. Plus, I'm sure nobody expects MELPA to fix the disaster that is elisp singlehandedly :smile: .

[glyph]

Correct, with the exception of the minority of upstream sources which are retrieved over http or other unsecured connections, e.g. CVS, SVN, EmacsWiki ... certain packages … are … freely editable on EmacsWiki …

Wow, that sounds like a super bad scene. Is there a checkbox in the package.el UI somewhere that says "this package is definitely malware, throw your computer in a lake"? :smile:

[glyph]

More seriously, would turning those package sources off entirely be an option?

[purcell]

Wow, that sounds like a super bad scene. Is there a checkbox in the package.el UI somewhere that says "this package is definitely malware, throw your computer in a lake"?

:-)

More seriously, would turning those package sources off entirely be an option?

We're working on that. See #2342. At the moment there are non-Wiki packages which depend on Wiki-sourced packages, so there's some untangling to be done if we're to keep everything installable. Note that MELPA Stable doesn't contain any Wiki packages, but it also doesn't contain most of the non-Wiki packages, which means it's of limited utility to users as a sole package source (see also #1955)...

[alphapapa]

Forgive the intrusion, but IIUC, there's nothing stopping a malicious actor from editing a wiki-sourced package to do something like run rm -rf ~/ on load, and then MELPA would build that package, and then everyone who upgraded that package would get their home directory wiped. Is that right?

[tzz]

I suggest moving MELPA to a pinned model against VCS-sourced packages, similar to how Docker operates their official repositories: https://docs.docker.com/docker-hub/official_repos/#how-can-i-get-involved (note the necessarily complex roles and process).

If there's something Emacs can provide to help the work, great. But if there's things MELPA needs from volunteers, that should be clear as well. Right now this has been waiting for many months without any progress or plan, and the security risks are not just limited to the EmacsWiki-sourced packages.

[alphapapa]

Long term, I dream of a system like Debian has, where new package versions would be put into an unstable repo, and automatically migrated to testing after a couple of weeks without any serious bugs being reported. That way, if anything bad did happen, it would likely be limited to the users who chose to use the "bleeding edge" packages, and most users could run from testing and be more protected against malicious attacks and human error.

I do realize that this would be a major restructuring under-the-hood. But for users, it might be doable in a transparent way: just create an unstable repo for new package versions, and make the existing non-stable MELPA repo the testing one. That way existing users would automatically end up using it, and they'd have to opt-in to the unstable one.

Not sure how the existing MELPA Stable would fit into this scheme. In a way it could almost obsolete it, but I'd still prefer to keep tagged versions available.

[Fuco1]

MELPA Stable is the way to go, but that will only gain traction if the "regular" MELPA is discontinued, which will probably never happen. Many packages in the Emacs world (some of mine included) aren't "released" in any meaningful way and people are just expected to run whatever is on master. This is terrible and I'm now trying to release my packages in more reasonable manner.

But the culture in Emacsland is just so terrible that you would have to inconvenience many many people to inflict some change, and that is something peolpe are unwilling to do (eventhough MELPA now has basically a monopol and smart people running it who could dictate meaningful change).

There are still many problems with it like serving only the latest version (maybe this is package.el problem?) so rollbacks or support for multiple emacs Versions are impossible (and dependency conflicts can happen which will destroy your setup).

The fact that users update their packages rather unfrequently and don't much need reproducability also doesn't help much, because nobody values things like locking enough to implement it (package.el only included package name locking in e25, so we'll wait 2 more releases for version locking).

Sometimes I wonder why not just copy some "modern" package solution like npm/yarn or composer...

[alphapapa]

Not npm, please! D: And PHP scares me...

Everything else I agree with. ;)

Seriously though, you're right that most package authors don't release packages in a serious, versioned way. Sad but true.

So if that's the reality that we have to work with, what about the unstable->testing idea? Making up numbers here, if 10% of the MELPA users being on unstable could save the other 90% of users (who would use testing) from suffering breakage, without having to impose any additional restrictions or expectations on authors, would that be worth considering?

I guess the chief problem with the idea is, as you said, the lack of version pinning. If package A is updated to work with breaking changes in package B, and package A migrated to testing but package B remained in unstable (not big surprise, since it's making breaking changes), that would effectively break the version of package A in testing, so even the more cautious users, who stick with testing, would get the breakage.

I guess there's not much that can be done until we get version pinning. Even then, as long as we're using made-up, date-based version numbers, there doesn't seem to be much of a way to guarantee that packages that depend on each other will have compatible versions installed. Maybe, theoretically, MELPA could somehow track the date-based versions and try to migrate packages together, but just thinking about how it might work seems like it would lead to a combinatorial explosion of complexity when confronted with the whole archive.

Another possibility (though still not very appealing): when we get working version pinning, interested volunteers could maintain a kind of "overlay" or "virtual" repo on top of MELPA which would point to specific versions of packages that would be known to be compatible and relatively bug-free. Actually, I guess that could be done now using, e.g. Quelpa, which can pin specific commits of each package. The end result would be sort of like how Debian works, with a middleman bringing sanity and compatibility to the wild world of independently developed software.

That actually seems like a fairly workable solution, technically. The problem would of course be the human effort required to maintain it.

[purcell]

But the culture in Emacsland is just so terrible that you would have to inconvenience many many people to inflict some change, and that is something peolpe are unwilling to do (eventhough MELPA now has basically a monopol and smart people running it who could dictate meaningful change).

We're open to doing that where it makes sense, but don't forget that our time is limited.

While version pinning seems like a prerequisite, we could start by building & keeping older versions of packages in MELPA Stable, which might help drive upstream/3rd-party support for pinning. I've filed #4712 to track this, so please take any related discussions over there.

[kirk86]

Hi guys, can someone verify this for me:

Certificate information
Issued by:          Let's Encrypt Authority X3                      
Issued to:          CN=melpa.org                                      
Hostname:           melpa.org                                         
Public key:         RSA, signature: RSA-SHA256                        
Protocol:           TLS1.2, key: ECDHE-RSA, cipher: AES-128-GCM, mac: AEAD
Security level:     Medium                                            
Valid:              From 2017-07-17 to 2017-10-15                     

The TLS connection to melpa.org:443 is insecure for the following 
reasons:                                                              
certificate was signed with an insecure algorithm                     
the certificate was signed by an unknown and therefore untrusted authority
certificate could not be verified

I just updated emacs and now every time that I refresh the packages I get the following message. Previously I didn't used to get this message. Has something changed or is this a bug related issue? Thanks!

[alphapapa]

@kirk86 This bug is about signing packages, not the TLS cert for the MELPA site.

Your problem is most likely not specific to MELPA either, but probably an issue with your system cert store or with the way your Emacs package was put together. This is probably a distro-level issue, or an issue with your personal config outside of Emacs.

[kirk86]

@alphapapa yeah you're right upon closer look I found that this was related to prelude. I reported the issue there. When using plain emacs though contacting gnu archive resolves in an error. I guess that's unrelated to melpa but I though that somebody else might stumble upon the same error.

[wyuenho]

Has there been any progress for getting packages signed on Melpa?