ELPA security

ELPA security

[George Kadianakis]

Hi,

I've been looking into ELPA (the Emacs Lisp Package Archive) and I
noticed that package.el provides no security of any kind. It doesn't
do signatures, SSL, timestamps or anything.

Are you actually considering deploying a system that downloads
untrusted code from the Internet every time a user asks for a new
package or asks to upgrade his current packages?

Package management is serious business [0]. It's sad to see ELPA
approaching the problem so insecurely.

Can't you at the very least, enable HTTPS on tromey.com and pin its
public key on package.el?

Thanks!

[0]:
http://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.pdf
https://www.cs.arizona.edu/stork/packagemanagersecurity/
or just search google for "package manager security".

Re: ELPA security

[Nic Ferrier]

George Kadianakis <desnacked@riseup.net> writes:

> I've been looking into ELPA (the Emacs Lisp Package Archive) and I
> noticed that package.el provides no security of any kind. It doesn't
> do signatures, SSL, timestamps or anything.
>
> Are you actually considering deploying a system that downloads
> untrusted code from the Internet every time a user asks for a new
> package or asks to upgrade his current packages?
>
> Package management is serious business [0]. It's sad to see ELPA
> approaching the problem so insecurely.
>
> Can't you at the very least, enable HTTPS on tromey.com and pin its
> public key on package.el?

1. you're right! it isn't very secure. a few of us have been grumbling
about this for a while.

2. it's free software! you don't have to use it!

3. it's free software! you can fix it with patches!

4. marmalade repo is a free software package repository (an additional
repository to ELPA) which I maintain. I would welcome patches!

  https://github.com/nicferrier/marmalade

5. tromey.com should not be used anymore, it's elpa.gnu.org now.



Nic Ferrier

Re: ELPA security

[Ted Zlatanov]

On Sun, 09 Dec 2012 16:41:50 +0200 George Kadianakis <desnacked@riseup.net> wrote: 

GK> I've been looking into ELPA (the Emacs Lisp Package Archive) and I
GK> noticed that package.el provides no security of any kind. It doesn't
GK> do signatures, SSL, timestamps or anything.

GK> Are you actually considering deploying a system that downloads
GK> untrusted code from the Internet every time a user asks for a new
GK> package or asks to upgrade his current packages?

Who would *you* like to entrust with the user's security?

I am not questioning your direction, just thinking about it.

GK> Package management is serious business [0]. It's sad to see ELPA
GK> approaching the problem so insecurely.

GK> Can't you at the very least, enable HTTPS on tromey.com and pin its
GK> public key on package.el?

SSL can easily be compromised and may not be available on all
platforms.

I think the signing solution should be per-package, optional, functional
in older Emacsen without binary dependencies, and the user should be
able to override it on an individual or global basis.  So it can't use
`curl', `gpg', or GnuTLS...

I also think `M-x list-packages' should define a `v' shortcut to file-find
the .el file or tarball that constitutes the package without installing
it.  That will contribute to security and it's really convenient, too.

Ted

Re: ELPA security

[Xue Fuqiao]

On Fri, 21 Dec 2012 09:32:22 -0500
Ted Zlatanov <tzz@lifelogs.com> wrote:

> I also think `M-x list-packages' should define a `v' shortcut to file-find
> the .el file or tarball that constitutes the package without installing
> it.  That will contribute to security and it's really convenient, too.

I think so, too.
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re: ELPA security

[Bastien]

What about simply distributing, within GNU Emacs the
list of md5 hashes of valid(ated) packages?

We could do this for GNU ELPA at least, it seems quite
straightforward to me -- but I'm not expert.

-- 
 Bastien

Re: ELPA security

[Xue Fuqiao]

On Sat, 22 Dec 2012 06:07:19 +0100
Bastien <bzg@gnu.org> wrote:

> What about simply distributing, within GNU Emacs the
> list of md5 hashes of valid(ated) packages?

It's quite easy and straightforward.  And maybe functions like SHA-3 or MD6 are even better.
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re: ELPA security

[Stephen J. Turnbull]

Xue Fuqiao writes:
 > On Sat, 22 Dec 2012 06:07:19 +0100
 > Bastien <bzg@gnu.org> wrote:
 > 
 > > What about simply distributing, within GNU Emacs the
 > > list of md5 hashes of valid(ated) packages?

Doesn't solve any problems that I can see.  You'll still need to
distribute the hashes for newly added or updated packages somehow.
People aren't going to reinstall Emacs just because of a package
update they might like to try, and even if they would, the burden on
the maintainers would be substantial.

 > It's quite easy and straightforward.  And maybe functions like
 > SHA-3 or MD6 are even better.

Get advice from someone who knows what they're talking about (which
isn't me, but I do know how much I don't know ;-).  As far as I can
tell, MD5 is clearly out of the question any more for security
purposes.  A hash believed secure for the foreseeable future is not a
huge computational burden in this application.  The only real question
is whether it's installed on the users' systems or not.

Re: ELPA security

[Bastien]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Xue Fuqiao writes:
>  > On Sat, 22 Dec 2012 06:07:19 +0100
>  > Bastien <bzg@gnu.org> wrote:
>  > 
>  > > What about simply distributing, within GNU Emacs the
>  > > list of md5 hashes of valid(ated) packages?
>
> Doesn't solve any problems that I can see.  You'll still need to
> distribute the hashes for newly added or updated packages somehow.
> People aren't going to reinstall Emacs just because of a package
> update they might like to try, and even if they would, the burden on
> the maintainers would be substantial.

Well, if Emacs distributes the hashes and have a notion of certified
package for some of the GNU ELPA packages, that's already a progress.

I'm not expert, so I can't think of a better progress.  Hopefully
someone will come up with a better solution.

-- 
 Bastien

Re: ELPA security

[Bastien]

Bastien <bzg@gnu.org> writes:

> Well, if Emacs distributes the hashes and have a notion of certified
> package for some of the GNU ELPA packages, that's already a progress.

Actually, we could have a trusted packages that people can updated to
get trusted new hashes from GNU ELPA packages.  That'd help solving the
problem of updating the hashes.

-- 
 Bastien

package.el + DVCS for security and convenience (was: ELPA security)

[Ted Zlatanov]

I propose to require signatures for ELPA packages and make package.el
aware of signatures:

http://doc.bazaar.canonical.com/beta/en/user-guide/gpg_signatures.html

(the same idea for Git: http://git-scm.com/book/en/Git-Basics-Tagging)

The key is to make package.el talk to a repository, not to a web site.

Then, package.el can verify the history of the package as a series of
revisions and verify their signatures.  That would require much better
integration with Bazaar and Git for package.el, but I actually think
that's a good thing and would give users convenient tools like seeing
the history of a package with all the commits.

Maybe `vc-dir' already has code to do this, so package.el can simply
ride on top of it.

This has several benefits:

- doesn't introduce new infrastructure or ELPA/Emacs packages

- is entirely optional to package.el, so repositories and individual
  packages within them can choose to use this mechanism

- does not depend on a central authority like SSL

- if the tools to verify the GPG signature are not available, we can
  fall back to warning the user instead of failing altogether

Ted

Re: package.el + DVCS for security and convenience

[Nic Ferrier]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I propose to require signatures for ELPA packages and make package.el
> aware of signatures:

Requiring signatures would be VERY bad at this stage because you would
break all the repositories that people get code from that do not support
signing.

Instead some form of tainting should be supported.

Re: package.el + DVCS for security and convenience

[Bastien]

Hi Nic,

Nic Ferrier <nferrier@ferrier.me.uk> writes:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> I propose to require signatures for ELPA packages and make package.el
>> aware of signatures:
>
> Requiring signatures would be VERY bad at this stage because you would
> break all the repositories that people get code from that do not support
> signing.

I may be wrong but I think Ted's suggestion is not for all repository
but for GNU ELPA, in which case I think it makes sense.

-- 
 Bastien

Re: package.el + DVCS for security and convenience

[Ted Zlatanov]

On Mon, 24 Dec 2012 13:55:33 +0100 Bastien <bzg@gnu.org> wrote: 

B> Nic Ferrier <nferrier@ferrier.me.uk> writes:

>> Ted Zlatanov <tzz@lifelogs.com> writes:
>> 
>>> I propose to require signatures for ELPA packages and make package.el
>>> aware of signatures:
>> 
>> Requiring signatures would be VERY bad at this stage because you would
>> break all the repositories that people get code from that do not support
>> signing.

B> I may be wrong but I think Ted's suggestion is not for all repository
B> but for GNU ELPA, in which case I think it makes sense.

Right.  I think any ELPA repositories that are not the GNU ELPA will
quickly switch over, however, because it makes a lot of sense and will
be little work on the maintainer end.  The bulk of the work will be in
package.el to support tag/commit signing when it's enabled (through
vc-dir and friends, if possible) and expose it to the user.

Ted

Re: package.el + DVCS for security and convenience

[Xue Fuqiao]

On Mon, 24 Dec 2012 13:55:33 +0100
Bastien <bzg@gnu.org> wrote:

> I may be wrong but I think Ted's suggestion is not for all repository
> but for GNU ELPA, in which case I think it makes sense.

I think so, too.  And GNU ELPA should learn from homebrew or something like apt and yum.
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re: package.el + DVCS for security and convenience

[Stefan Monnier]

> Maybe `vc-dir' already has code to do this, so package.el can simply
> ride on top of it.

I'm afraid VC does not have much of that code yet.

An alternative is to only protect the communication between elpa.gnu.org
and the end client: add a "GPG signature" to each entry of the
`archive-contents' file, so they can be checked after the download.


        Stefan

Re: package.el + DVCS for security and convenience

[Ted Zlatanov]

On Mon, 24 Dec 2012 11:17:28 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> Maybe `vc-dir' already has code to do this, so package.el can simply
>> ride on top of it.

SM> I'm afraid VC does not have much of that code yet.

It seems not too hard to add it: verifying signed commits/tags uses
orthogonal commands that don't affect the general VC workflow.

If no one else is interested I can add it to my TODO list.  But see below.

SM> An alternative is to only protect the communication between elpa.gnu.org
SM> and the end client: add a "GPG signature" to each entry of the
SM> `archive-contents' file, so they can be checked after the download.

The problem then is how to verify GPG signatures, especially if GnuPG is
not installed.  OTOH verifying signed tags in Git and signed commits in
Bazaar is part of the base packages, so it requires no more than having
them installed.

Still... how does it all work if Bazaar or Git are not installed?  Emacs
could verify GPG signatures directly.  I have looked at the protocol and
it's not terribly difficult, and in fact the GnuTLS integration brought
in most of the ciphers and decoders we would need to verify those
signatures, but then we'd require GnuTLS... argh, the dreaded bootstrap
problem.  Making it work on all platforms is not trivial.  In the core,
I think we only have `sha1' built-in.

I still think public-key cryptography and asymmetric ciphers are the
answer here, but I don't know how much we want to depend on external
tools or libraries for package installations, and how willing we are to
make installations insecure if those tools or libraries are not
available.  So I need the maintainers' wise opinion :)

Thanks
Ted

Re: package.el + DVCS for security and convenience

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > The problem then is how to verify GPG signatures, especially if GnuPG is
 > not installed.  OTOH verifying signed tags in Git and signed commits in
 > Bazaar is part of the base packages, so it requires no more than having
 > them installed.

Regarding the social side, sure, Windows users and perhaps proprietary
*nix users are less likely to have GPG or (oh, the horrors) PGP
installed, but it's not like they're unavailable.  Even for Mac OS X
(Hurray! er, I mean "Hiss, boo!"), GPG2 is available in all the popular
add-on distributions.

People who for reasons of corporate policy can't install those tools
themselves aren't going to have free access to ELPA, either (and
anyway their security bureaucracy has taken that responsibility on
itself).  People who won't install GPG, won't use the feature anyway
(by which I mean, they will ignore security warnings which are often
false alarms, disable them entirely on the third false alarm, won't go
to the effort of getting updated public keys for when they're offline,
etc), and if key distribution is implemented automatically they're at
great risk from man-in-the-middle and phishing-type attacks.

The GPG documentation is full of warnings about doing it yourself, and
recommends using the GUI or the command-line interface.  ISTR at one
time they didn't even provide libraries (do they now?) for that reason.

I'm sure we've all seen some of the horror stories of what sometimes
happens to competent programmers who implement the protocols
themselves on RISKS (not to mention really terrifying stories like
"The 16,384 Keys of Debian").  Remember, as soon as Emacs distributes
something, hordes of users are potential users of the feature.  That
may make it an attractive target for an attack.  Anything built in to
Emacs needs to be *strong*.  Is it worth that much effort?

Why not just start with the relatively easy optional verification of
signed files based on an installed OpenPG tool, and add pluggable
verification modules as people have interest?

 > I still think public-key cryptography and asymmetric ciphers are the
 > answer here,

I'm pretty sure the people who *really* know what they're doing[1]
will agree with you.

 > but I don't know how much we want to depend on external tools or
 > libraries for package installations, and how willing we are to make
 > installations insecure if those tools or libraries are not
 > available.  So I need the maintainers' wise opinion :)

"Only YOU can prevent forest fires" -- Smokey the Bear

But they happen *unnecessarily* anyway, because people ignore the
simple rules posted at every campground and entrance to wilderness
areas.

FWIW, I recommend providing security features as suggested above for
those who *want* them, at first.  Provide reasonably secure
automation, and enable it by default.  If disabled, encourage
reenabling, perhaps by changing the control variable name every
release ;-).

Footnotes: 
[1]  On the Internet, nobody knows that you're Bruce Schneier.  But
I'm not.  :-)

Re: package.el + DVCS for security and convenience

[Ted Zlatanov]

On Tue, 25 Dec 2012 10:03:28 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> The GPG documentation is full of warnings about doing it yourself, and
SJT> recommends using the GUI or the command-line interface.  ISTR at one
SJT> time they didn't even provide libraries (do they now?) for that reason.

SJT> I'm sure we've all seen some of the horror stories of what sometimes
SJT> happens to competent programmers who implement the protocols
SJT> themselves on RISKS (not to mention really terrifying stories like
SJT> "The 16,384 Keys of Debian").  Remember, as soon as Emacs distributes
SJT> something, hordes of users are potential users of the feature.  That
SJT> may make it an attractive target for an attack.  Anything built in to
SJT> Emacs needs to be *strong*.  Is it worth that much effort?

The same logic applies to using GnuTLS inside Emacs vs. gnutls-cli
externally.  I don't buy either argument.  Emacs is a platform and must
make intelligent choices to protect the security of its users.

Depending on external binaries has always been a security issue that
shifts the burden to the user and the system administrator.

(Also see my earlier suggestions about providing secure data storage at
the C level, so Emacs is not as vulnerable to core dumps to find user
passwords and other secrets.  There are many areas to improve.)

The OpenPGP protocol is described in http://tools.ietf.org/html/rfc4880
and thus fairly standard.  Verifying a signature, in particular, does
not require implementing the full protocol, and that's one of the
reasons I suggested it:

http://tools.ietf.org/html/rfc4880#section-2.5

SJT> Why not just start with the relatively easy optional verification of
SJT> signed files based on an installed OpenPG tool, and add pluggable
SJT> verification modules as people have interest?

I also think that's a good approach, as long as we keep the long-term
goals above in mind.

Ted

Re: package.el + DVCS for security and convenience

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > The same logic applies to using GnuTLS inside Emacs vs. gnutls-cli
 > externally.  I don't buy either argument.

Indeed I did apply it there, and good for you.  But that's *just* you.

 > Emacs is a platform and must make intelligent choices to protect
 > the security of its users.

Yes.  And one of those intelligent choices is to do well what Emacs
can do well, and leave up to the users what they can probably do
equally well, or mess up the best Emacs can do if they choose to be
security-unconscious.

The problem is that Emacs's security not only has to be better than
the users' to be useful, it has to be *much* better.  As soon as *one*
application used by *millions* becomes responsible for security in
some area, it becomes not a security shield, but a vector for mass
attack -- cracked once, it exposes enough users to interest the black
hat pros.[1]  Worse (IMO), that vector exposes security-conscientious
users to an "inside job".

Thing is, viewed from that point of view, I don't buy you (or Paul
Eggert, for that matter) as an authority on security good enough, or
available enough (which might extend to making security your day-in,
day-out contribution to Emacs) to make such decisions *for all Emacs
users*.  You could sell me on that point, though.  *You haven't
tried.*  That is what worries me.  I know, from embarrassing personal
experience, that smart people trying to be secure can be exploited.
It's not a question of your skills as a programmer, it's your attitude
as a "security officer" that doesn't thrill me.

 > Depending on external binaries has always been a security issue that
 > shifts the burden to the user and the system administrator.

That article "the" is a nice try, but I don't admit your sentence's
implicit assumption that the burden is monolithic.  Every complex
system is going to have many security weaknesses, and the user is
*always* going to be #1 on that list (even if his name is "Bond. James
Bond.").  There are many security burdens, and the implementation of
package checking is just one of them.  There is a well-known "law"[2]
in social science called the "principle of second best," which may be
phrased "stronger may be weaker [because of interactions with the rest
of the system]".  (An accurate phrasing would be "independent
component-wise improvements may interact to produce degraded system
performance.")  It surely applies to security.

 > (Also see my earlier suggestions about providing secure data
 > storage at the C level, so Emacs is not as vulnerable to core dumps
 > to find user passwords and other secrets.  There are many areas to
 > improve.)

The question is, which ones can and should Emacs take responsibility
for?  Providing secure storage is surely one of them, because AFAIK
users can't do that themselves with an external tool.  Some people who
do security as their "job number one" (ie, the folks who wrote the GPG
manual, I am not one of them and I don't know how widespread their
opinion is) seem to be saying that implementing the OpenPGP protocol
is not, because GPG provides a perfectly good tool to do the job.

I'm not welded to my "don't do this" position; I just think there are
a lot of things you could better do, and that it's a good idea to
limit the attack surface that *your* work presents.  If you use GPG
cli tools, that surface is limited to the path(s) from the socket
talking to ELPA to the call-process call to gpg2.  If you do signature
verification yourself, you *also* have to audit that implementation.

I think Emacs would be better off if you go after the "only Emacs
itself can do it" tasks first.

 > The OpenPGP protocol is described in http://tools.ietf.org/html/rfc4880
 > and thus fairly standard.  Verifying a signature, in particular, does
 > not require implementing the full protocol,

No, it's not difficult to implement.  But quis custodiet: what makes
you think your implementation itself won't be vulnerable to attacks,
many of which may not be under your implementation's control?

Again, I'm not saying "DON'T EVEN THINK of doing it", I'm suggesting
that you lack the skills and the humility to do a *sufficiently good
job for all Emacs users* because implementing *in* Emacs increases the
required level of quality by *orders of magnitude* as compared to
borrowing an existing, external implementation proved secure by long
experience.  I suspect you lack the time to acquire the skills *and*
apply them *as required by security applications*, and you don't seem
to have a clue about the hubris.

Obviously, I could be wrong -- I *know* that *I* don't have the skills
required to judge whether your implementation is secure or not.  I'd
just be a lot happier for Emacs if you seemed more aware of the
complexity and burden of the task you propose to undertake.  And it
wouldn't hurt if, say, Paul Eggert were to speak up and say he
promises to do thorough reviews[2], and you could cite an authority
saying that the concerns of the GPG manual author are valid but
exaggerated, and ....

Footnotes: 
[1]  Not to mention that given the number of times GNU/FSF sites have
been hacked, some of the black hats seem to have it in for GNU.  One
suspects that a Day Zero attack on ELPA might be quite a trophy in
some circles.

[2]  It's a systematic contruction of counterexamples to monotonicity
rather than a positive law of nonmonotonicity.

[3]  Which he would probably do anyway, of course (I know that he has
a more than passing interest in encryption, and I wouldn't be
surprised if he has qualifications and experience in other areas of
security as well).  The point is that I think that Emacs deserves an
*explicit* commitment to do this well, and in the case of security,
that surely means *explicit* commitments to independent reviews, etc.

Re: package.el + DVCS for security and convenience

[Xue Fuqiao]

On Thu, 27 Dec 2012 12:06:39 +0900
"Stephen J. Turnbull" <stephen@xemacs.org> wrote:

> It's not a question of your skills as a programmer, it's your attitude
> as a "security officer" that doesn't thrill me.

I agree.

> I think Emacs would be better off if you go after the "only Emacs
> itself can do it" tasks first.
I strongly agree this viewpoint.  And they are reflected in part of my wishlist:
http://www.emacswiki.org/emacs/XueFuqiao#toc15
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re: package.el + DVCS for security and convenience

[Ted Zlatanov]

On Thu, 27 Dec 2012 12:06:39 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Thing is, viewed from that point of view, I don't buy you (or Paul
SJT> Eggert, for that matter) as an authority on security good enough, or
SJT> available enough (which might extend to making security your day-in,
SJT> day-out contribution to Emacs) to make such decisions *for all Emacs
SJT> users*.  You could sell me on that point, though.  *You haven't
SJT> tried.*  That is what worries me.  I know, from embarrassing personal
SJT> experience, that smart people trying to be secure can be exploited.
SJT> It's not a question of your skills as a programmer, it's your attitude
SJT> as a "security officer" that doesn't thrill me.

I do not plan to be a "security officer," to prove my credentials to
your satisfaction, or to do it as a full-time job, yet I do plan to
contribute to Emacs security like I have before, gradually and carefully
after public discussion.  I encourage you and others to do the same.

>> (Also see my earlier suggestions about providing secure data
>> storage at the C level, so Emacs is not as vulnerable to core dumps
>> to find user passwords and other secrets.  There are many areas to
>> improve.)

SJT> The question is, which ones can and should Emacs take responsibility
SJT> for?  Providing secure storage is surely one of them, because AFAIK
SJT> users can't do that themselves with an external tool.

I think you agree with the idea of secure storage being an Emacs
facility.  That is a long-term goal, like concurrency or lexical
bindings.

Similarly, Emacs needs a secure way to get data in and out of that
storage from external files or data.  Depending on an external binary
tool, *long-term*, to provide this transfer is IMO a poor security
decision for a platform such as Emacs.

>> The OpenPGP protocol is described in http://tools.ietf.org/html/rfc4880
>> and thus fairly standard.  Verifying a signature, in particular, does
>> not require implementing the full protocol,

SJT> No, it's not difficult to implement.  But quis custodiet: what makes
SJT> you think your implementation itself won't be vulnerable to attacks,
SJT> many of which may not be under your implementation's control?

Because it will be perfect, obviously.

Ted

Re: package.el + DVCS for security and convenience

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > I do not plan to be a "security officer," to prove my credentials to
 > your satisfaction,

I didn't ask you to prove anything.  I was explaining why I was
worried.  I still am.

 > Similarly, Emacs needs a secure way to get data in and out of that
 > storage from external files or data.  Depending on an external binary
 > tool, *long-term*, to provide this transfer is IMO a poor security
 > decision for a platform such as Emacs.

Yeah, well, aren't you the guy who put just such an external binary
tool into Emacs, aka gnutls?  The question is whether dynamic linkage
is any safer than using the command line interface.

 > Because it will be perfect, obviously.

I haven't seen anything obviously perfect since the Cheryl Tiegs
Sports Illustrated cover.  Good luck beating that!<wink/>

Re: package.el + DVCS for security and convenience

[Ted Zlatanov]

On Mon, 31 Dec 2012 21:32:02 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Ted Zlatanov writes:

>> Similarly, Emacs needs a secure way to get data in and out of that
>> storage from external files or data.  Depending on an external binary
>> tool, *long-term*, to provide this transfer is IMO a poor security
>> decision for a platform such as Emacs.

SJT> Yeah, well, aren't you the guy who put just such an external binary
SJT> tool into Emacs, aka gnutls?

The GnuTLS libraries are not an external binary tool.  Do you mean `gnutls-cli'?

SJT> The question is whether dynamic linkage is any safer than using the
SJT> command line interface.

You should ask a security expert.

Ted

Re: package.el + DVCS for security and convenience

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > The GnuTLS libraries are not an external binary tool.  Do you mean
 > `gnutls-cli'?

No, I mean the externally maintained *binary* libraries that will be
linked to, rather than called via fork or similar.  Thus the following
question.

 > SJT> The question is whether dynamic linkage is any safer than using the
 > SJT> command line interface.
 > 
 > You should ask a security expert.

I've already cited a security expert (the GPG team).  You disclaim
expertise, but are willing to say you think following that advice is a
bad idea.  Hm.

Re: package.el + DVCS for security and convenience

[Ted Zlatanov]

On Tue, 01 Jan 2013 01:47:46 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Ted Zlatanov writes:
>> The GnuTLS libraries are not an external binary tool.  Do you mean
>> `gnutls-cli'?

SJT> No, I mean the externally maintained *binary* libraries that will be
SJT> linked to, rather than called via fork or similar.

I see.  Thanks for explaining.

SJT> The question is whether dynamic linkage is any safer than using the
SJT> command line interface.
>> 
>> You should ask a security expert.

SJT> I've already cited a security expert (the GPG team).  You disclaim
SJT> expertise, but are willing to say you think following that advice is a
SJT> bad idea.  Hm.

I did not say the GPG team has given bad advice.

In any case, I think this discussion has served its purpose and hope we
can continue it with facts and code instead of suppositions.  I look
forward to that.

Thanks
Ted

Re: package.el + DVCS for security and convenience

[Stefan Monnier]

> The problem then is how to verify GPG signatures,

Easy: pass them to GPG.

> especially if GnuPG is not installed.

Then don't check.
If the user wants to check his packages, she'll have to install GPG,
which AFAIK is not harder than installing Emacs.


        Stefan

Re: package.el + DVCS for security and convenience

[Ted Zlatanov]

On Sat, 29 Dec 2012 01:19:11 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> The problem then is how to verify GPG signatures,
SM> Easy: pass them to GPG.

>> especially if GnuPG is not installed.

SM> Then don't check.
SM> If the user wants to check his packages, she'll have to install GPG,
SM> which AFAIK is not harder than installing Emacs.

GPG is not always available and I'd rather not call an external tool in
the long term.  But it's an acceptable compromise for now, yes.

Ted

Re: package.el + DVCS for security and convenience

[Stefan Monnier]

>>> The problem then is how to verify GPG signatures,
SM> Easy: pass them to GPG.
>>> especially if GnuPG is not installed.
SM> Then don't check.
SM> If the user wants to check his packages, she'll have to install GPG,
SM> which AFAIK is not harder than installing Emacs.
> GPG is not always available

The important thing is that GPG can always be installed, so if the user
cares about checking integrity, she can install GPG.

> and I'd rather not call an external tool in the long term.  But it's
> an acceptable compromise for now, yes.

When we get a proper FFI, we'll probably get other options.  But rewriting
the code in Elisp doesn't sound like a an attractive option to me.


        Stefan

Re: package.el + DVCS for security and convenience

[Ted Zlatanov]

On Thu, 03 Jan 2013 11:41:10 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> The important thing is that GPG can always be installed, so if the user
SM> cares about checking integrity, she can install GPG.

OK, we're using GPG as you described.

Now, since everyone but Xue Fuqiao has told me that tying package.el to
the DVCS is a bad idea, we need to decide how these signatures will be
stored in the ELPA, and how they can fit into the existing ELPA
structure.  Nic Ferrier's proposal of a "key package" seems workable;
that package can be signed with the GNU ELPA maintainer's public key to
bootstrap the rest of the process.

I asked Tom Tromey and Phil Hagelberg for suggestions but haven't heard
back yet.  I'd like to get their take and yours before jumping to the
coding stage.

Ted

Re: package.el + DVCS for security and convenience

[Stefan Monnier]

> Now, since everyone but Xue Fuqiao has told me that tying package.el to
> the DVCS is a bad idea, we need to decide how these signatures will be
> stored in the ELPA, and how they can fit into the existing ELPA
> structure.  Nic Ferrier's proposal of a "key package" seems workable;
> that package can be signed with the GNU ELPA maintainer's public key to
> bootstrap the rest of the process.

The signatures should be added to the `archive-contents' file.


        Stefan

Re: package.el + DVCS for security and convenience

[Ted Zlatanov]

On Fri, 04 Jan 2013 13:11:09 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> Now, since everyone but Xue Fuqiao has told me that tying package.el to
>> the DVCS is a bad idea, we need to decide how these signatures will be
>> stored in the ELPA, and how they can fit into the existing ELPA
>> structure.  Nic Ferrier's proposal of a "key package" seems workable;
>> that package can be signed with the GNU ELPA maintainer's public key to
>> bootstrap the rest of the process.

SM> The signatures should be added to the `archive-contents' file.

I think `archive-contents' should contain just the keys allowed to sign
the package, not the signatures whole.  Otherwise, for multi-file
packages, the file could get large and the format could be awkward.  To
support both single-file and multi-file packages, I propose a X.sig
signature file for each file X in the package directory hierarchy.

I think it's better to have the GNU ELPA maintainers sign package
releases, not to delegate that to the authors.  That would make it
unnecessary to modify the `archive-contents' format at all to store the
author keys.  It's more work for the GNU ELPA maintainers, but much less
work for the authors.  I imagine it would work, on the maintainer side,
by modifying `archive-contents' with the new version, and then the
deployment script would sign each file as it deploys it in place.

Either way, the entire `archive-contents' file will be signed by one of
the GNU ELPA maintainer keys in `archive-contents.sig', right?  How do
we distribute the GNU ELPA maintainer keys?  With Emacs itself?

Ted

Re: package.el + DVCS for security and convenience

[Stephen J. Turnbull]

Ted Zlatanov writes:
 > On Fri, 04 Jan 2013 13:11:09 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
 > 
 > SM> The signatures should be added to the `archive-contents' file.
 > 
 > I think `archive-contents' should contain just the keys allowed to sign
 > the package, not the signatures whole.  Otherwise, for multi-file
 > packages, the file could get large and the format could be awkward.  To
 > support both single-file and multi-file packages, I propose a X.sig
 > signature file for each file X in the package directory hierarchy.

I think that's a lot uglier, and will force people to use special
tools to manipulate non-Emacs structures conveniently (ie, the file
system).  (N.B. I wrote "convenient", not "possible".)  OTOH, the raw
content of archive-contents is rarely of interest to users, and the
only software that knows how to manipulate archive-contents is Emacs,
anyway.  Write a mode to display archive-contents, suppressing
signatures by default, and you're done AFAICS.

 > I think it's better to have the GNU ELPA maintainers sign package
 > releases, not to delegate that to the authors.

I think that's a bad idea.  The responsibility is with the authors in
the first place; you're suggesting that it be delegated to the ELPA
maintainers.  All the ELPA maintainers can do is testify that they
built the package from sources in the repository.  Unless the
repository contains properly signed commits, that's not saying much.
Even then, for users it's a matter of indirect trust.  So for it
actually to be useful to security-conscious users, the ELPA
maintainers would have to vette the package authors -- *all*
committers.

It's really not that much work, and it's work that can and should be
decentralized.

Re: package.el + DVCS for security and convenience

[Ted Zlatanov]

On Sat, 05 Jan 2013 12:25:41 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Ted Zlatanov writes:
>> On Fri, 04 Jan 2013 13:11:09 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
>> 
SM> The signatures should be added to the `archive-contents' file.
>> 
>> I think `archive-contents' should contain just the keys allowed to sign
>> the package, not the signatures whole.  Otherwise, for multi-file
>> packages, the file could get large and the format could be awkward.  To
>> support both single-file and multi-file packages, I propose a X.sig
>> signature file for each file X in the package directory hierarchy.

SJT> I think that's a lot uglier, and will force people to use special
SJT> tools to manipulate non-Emacs structures conveniently (ie, the file
SJT> system).  (N.B. I wrote "convenient", not "possible".)  OTOH, the raw
SJT> content of archive-contents is rarely of interest to users, and the
SJT> only software that knows how to manipulate archive-contents is Emacs,
SJT> anyway.  Write a mode to display archive-contents, suppressing
SJT> signatures by default, and you're done AFAICS.

I'm OK with either approach, but feel that modifying and re-signing
`archive-contents' every time any file in the GNU ELPA changes is
awkward and not as easy.  In addition, it would make it hard to
distribute a subset of the GNU ELPA (e.g. a single package from it) if
there was a global registry of signatures.

>> I think it's better to have the GNU ELPA maintainers sign package
>> releases, not to delegate that to the authors.

SJT> I think that's a bad idea.  The responsibility is with the authors in
SJT> the first place; you're suggesting that it be delegated to the ELPA
SJT> maintainers.  All the ELPA maintainers can do is testify that they
SJT> built the package from sources in the repository.  Unless the
SJT> repository contains properly signed commits, that's not saying much.
SJT> Even then, for users it's a matter of indirect trust.  So for it
SJT> actually to be useful to security-conscious users, the ELPA
SJT> maintainers would have to vette the package authors -- *all*
SJT> committers.

SJT> It's really not that much work, and it's work that can and should be
SJT> decentralized.

I'm actually suggesting that the GNU ELPA maintainers (note the "GNU
ELPA" part here, this is not any ELPA maintainer) should review and sign
*every* commit to the GNU ELPA.  I feel this is an essential part of
building trust in the GNU ELPA (which started this discussion, and I
feel has been ignored as usual in favor of the technical discussion).

The alternative you propose is to trust many authors, which makes it
more likely that an author will be an attack vector, either through a
compromise of their own key, or by theft of identity, or because the
author was an attacker from the beginning.  I'd rather limit the number
of trusted keys to just a few.

Ted

Re: package.el + DVCS for security and convenience

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > I'm actually suggesting that the GNU ELPA maintainers (note the "GNU
 > ELPA" part here, this is not any ELPA maintainer) should review and sign
 > *every* commit to the GNU ELPA.

I have no idea what you think you're proposing.  Security reviews are
expensive; I doubt you'll have anybody willing to maintain GNU ELPA
after a couple of months of that, unless you pay handsomely, or you
enlist a maintainer per package or so to reduce the burden on
individual maintainers to a manageable level.  The obvious candidates
for the latter are the authors.

If they are not security reviews, what's the point of reviewing at
all?  You just want signed commits, verifying that the commit was
actually received at the GNU ELPA.  AFAICS this can be done by a bot,
which checks the authors' signatures on the commits.

Re: package.el + DVCS for security and convenience

[Ted Zlatanov]

On Mon, 07 Jan 2013 11:03:07 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Ted Zlatanov writes:
>> I'm actually suggesting that the GNU ELPA maintainers (note the "GNU
>> ELPA" part here, this is not any ELPA maintainer) should review and sign
>> *every* commit to the GNU ELPA.

SJT> I have no idea what you think you're proposing.

I hope that doesn't make my proposal less ideal.

SJT> Security reviews are expensive; I doubt you'll have anybody willing
SJT> to maintain GNU ELPA after a couple of months of that, unless you
SJT> pay handsomely, or you enlist a maintainer per package or so to
SJT> reduce the burden on individual maintainers to a manageable level.

Trust is expensive.  The alternative is to say "trust this code, though
we don't know what it is."  That's the current state of affairs.

There is certainly review of code that goes into GNU Emacs itself.  A
security exploit would be caught quickly (I hope, based on previous
cases like the file-local variable exploits).  It's not as high-profile
as the Linux kernel, perhaps, but still an important target.

The GNU ELPA, being enabled by default, should be treated the same.  But
because it's a network resource, we must use signatures to indicate
files in the GNU ELPA can be trusted, since we don't package the GNU
ELPA with Emacs itself.

In other words, we're building a web of trust around GNU Emacs because
we want to be able to install parts of it (hosted in the GNU ELPA)
optionally and over the network.  That's where "trust" matters.

I never said it would be cheap or easy to do this.  But I think the FSF
and GNU volunteers can handle the task, and I firmly believe reviewing
Emacs Lisp code is much easier than C, C++, Perl, etc. code.  I'll
volunteer my own time for these reviews, unless of course you or others
are opposed because it would make me a "security tzar" or because it's
felt I'm unqualified.  As I said, the alternative is the current "just
trust whatever we put online" model, which is certainly cheap to run.

SJT> The obvious candidates for the latter are the authors.

No.

SJT> If they are not security reviews, what's the point of reviewing at
SJT> all?  You just want signed commits, verifying that the commit was
SJT> actually received at the GNU ELPA.  AFAICS this can be done by a bot,
SJT> which checks the authors' signatures on the commits.

No.

Ted

Re: package.el + DVCS for security and convenience

[Stephen J. Turnbull]

Ted Zlatanov writes:
 > On Mon, 07 Jan 2013 11:03:07 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 
 > 
 > SJT> Ted Zlatanov writes:
 > >> I'm actually suggesting that the GNU ELPA maintainers (note the "GNU
 > >> ELPA" part here, this is not any ELPA maintainer) should review and sign
 > >> *every* commit to the GNU ELPA.
 > 
 > SJT> I have no idea what you think you're proposing.
 > 
 > I hope that doesn't make my proposal less ideal.

If I'm not alone, it certainly does.

 > SJT> Security reviews are expensive; I doubt you'll have anybody willing
 > SJT> to maintain GNU ELPA after a couple of months of that, unless you
 > SJT> pay handsomely, or you enlist a maintainer per package or so to
 > SJT> reduce the burden on individual maintainers to a manageable level.
 > 
 > Trust is expensive.

You're scaring me again.  Trust is cheap, but risky.  That's not the
same.

 > The alternative is to say "trust this code, though we don't know
 > what it is."

Your use of the unique quantifier is once again inappropriate.  "We"
does not have to be an undifferentiated blob; it can be personalized.
You could, for example, have each volunteer provide a separate
signature as they review the code.  More reviews, more trust -- maybe,
unless more reviews means each one is less thorough.  Identification
of the reviewer means trust can be a function of the reviewer.
Authors don't make the best reviewers, but they do know the code, and
an author signature is a certificate of authenticity.

In general, having signatures that identify (a) the stage at which the
code was signed and (b) the authority doing the signing are useful
inputs to (some) users' trust functions.  I don't know if it's worth
it, but it certainly proves that your strawman is not the only
alternative.

 > That's the current state of affairs.

And, to a large extent, it will be the state of affairs under your
proposal, unless your "FSF and GNU volunteers" do a certain amount of
work on *every* commit to GNU ELPA.  The only thing that signing (by
itself) proves is provenance.  If it's signed, you know the signer
touched it.  That is valuable information, even though it doesn't
prove the code is clean.  If you actually do reasonably thorough
reviews, though, you will end up with a large backlog of pending
commits unless you have a lot of volunteers.  (At least one hopes that
there will be a lot of code committed to GNU ELPA, right?)

 > There is certainly review of code that goes into GNU Emacs itself.  A
 > security exploit would be caught quickly (I hope, based on previous
 > cases like the file-local variable exploits).

Uh, yeah ... maybe.  AFAICS much code that goes into Emacs doesn't get
reviewed by someone other than the author/committer, most code review
that is done for Emacs itself is hardly security-oriented, and the
exploits were caught after the fact in all cases I know of.[1]  I think
you vastly underestimate the cost to reviewers and authors of doing a
sufficiently good job to justify trusting the code at a significantly
higher level than currently.  (Authors will have to rework features
rejected for security of implementation reasons, and it would be quite
painful to have a whole feature rejected for security reasons).

 > The GNU ELPA, being enabled by default, should be treated the same.  But
 > because it's a network resource, we must use signatures to indicate
 > files in the GNU ELPA can be trusted, since we don't package the GNU
 > ELPA with Emacs itself.

No, what signatures are for is to authenticate the file, ie, to prove
that this is indeed a true GNU ELPA file and not a counterfeit.  Trust
will be allocated to *code received from* GNU ELPA on the basis of the
review policy and its quality of implementation, not simply because
it's signed.

 > In other words, we're building a web of trust around GNU Emacs because
 > we want to be able to install parts of it (hosted in the GNU ELPA)
 > optionally and over the network.  That's where "trust" matters.

Why do you think anybody in this thread doesn't understand that?

 > I never said it would be cheap or easy to do this.

True.  *I* *did* say that it would be expensive.  Very.  What worries
me is that you make statements like

 > But I think the FSF and GNU volunteers can handle the task, and I
 > firmly believe reviewing Emacs Lisp code is much easier than C,
 > C++, Perl, etc. code.

without offer any cost estimate (eg, # of commits per month, amount of
volunteer time per month, amount of time spent doing background checks
on volunteers, amount of time spent making sure that volunteers aren't
conspiring with Untrustworthy Authors, etc).  Nor do I see why
reviewing Emacs Lisp code is *much* easier.  No buffer overflows, it's
true, but magic execution (aka hooks) are all over the place.
Anything that reads a file using find-file (let alone `load') can
execute arbitrary Lisp, in fact, arbitrary executables using
call-process via hooks.

 > I'll volunteer my own time for these reviews, unless of course you
 > or others are opposed because it would make me a "security tzar" or
 > because it's felt I'm unqualified.

I don't think you're unqualified.  I do wonder why you think you're
*more* qualified than package authors.  AFAIK you're not currently a
GNU ELPA maintainer?

 > As I said, the alternative is the current "just trust whatever we
 > put online" model, which is certainly cheap to run.

And you're wrong about that.  People *do* just trust, by and large,
but that is *not* their only option, even under current conditions.
In fact, as far as I know many people are *currently* exercising a
different option by only trusting a few packages that are put online
at ELPA.

 > SJT> The obvious candidates for the latter are the authors.
 > 
 > No.

Yes.  I wrote "candidate", not "automatic pass".  *Many* authors (ie,
committers, since it has to be committed to GNU ELPA) are well-known.
True, it would be a bad idea to allow any random patch author to
certify their work, but if it has passed through the affected
package's community's review and been signed by a well-known package
author (ie, its maintainer), I can't see any claim that a review by an
unspecified "volunteer" who may not know anything about the package is
more trustworthy.  No?

 > SJT> If they are not security reviews, what's the point of reviewing at
 > SJT> all?  You just want signed commits, verifying that the commit was
 > SJT> actually received at the GNU ELPA.  AFAICS this can be done by a bot,
 > SJT> which checks the authors' signatures on the commits.
 > 
 > No.

No what?  That's a moderately complex piece of logic you're denying.

Steve

Footnotes: 
[1]  That could be because Emacs has a security cabal and they don't
discuss their reviews on this list.

Re: package.el + DVCS for security and convenience

[Ted Zlatanov]

On Tue, 08 Jan 2013 10:44:36 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

>> On Mon, 07 Jan 2013 11:03:07 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Ted Zlatanov writes:

>> The alternative is to say "trust this code, though we don't know
>> what it is."

SJT> Your use of the unique quantifier is once again inappropriate.  "We"
SJT> does not have to be an undifferentiated blob; it can be
SJT> personalized.

To an Emacs user, the GNU ELPA is a package archive, not a personality
bazaar.  Our view on emacs-devel is very different and colors our
thinking.  So "we" reflects us, the Emacs developers, of which the GNU
ELPA maintainers are a subset.

SJT> You could, for example, have each volunteer provide a separate
SJT> signature as they review the code.  More reviews, more trust -- maybe,
SJT> unless more reviews means each one is less thorough.  Identification
SJT> of the reviewer means trust can be a function of the reviewer.
SJT> Authors don't make the best reviewers, but they do know the code, and
SJT> an author signature is a certificate of authenticity.

I explained that authors are much easier to compromise than maintainers.

Stefan has confirmed (I believe) the GNU ELPA maintainers will use a
single "GNU ELPA" key to sign package releases.  He has also stated
we'll use signatures to indicate provenance, not security reviews.
Since I won't argue that point further, I've snipped your thoughtful
replies on the topic of security reviews, except where I could clearly
win the argument ;)

SJT> If you actually do reasonably thorough reviews, though, you will
SJT> end up with a large backlog of pending commits unless you have a
SJT> lot of volunteers.

I was planning to outsource it to some Russians.  They are very
thorough, I know the gang leader, er, I mean the project manager,
personally.

SJT> (Authors will have to rework features rejected for security of
SJT> implementation reasons, and it would be quite painful to have a
SJT> whole feature rejected for security reasons).

The authors are free not to host their packages in the GNU ELPA, if they
don't want to worry about security concerns.  Even without security
reviews, I think that should be the case, and the GNU ELPA maintainers
should be free to reject packages on that basis.

SJT> Nor do I see why reviewing Emacs Lisp code is *much* easier.

IMHO suspicious and malicious code is more easily visible in Emacs Lisp.

SJT> AFAIK you're not currently a GNU ELPA maintainer?

I have the access.

SJT> 0.  Emacs should do something about this, and soon.
SJT> 1.  Mission creep should be avoided.
SJT> 2.  The first mission, cheap to implement, is to authenticate the
SJT>     packages that are at GNU ELPA.

I agree.

SJT> 3.  The authentication should be done via a list of authorized
SJT>     signatures, not a single "GNU ELPA Maintainer" (GEM) signature.

SJT> 4.  Package maintainers (PMs) should be considered leading candidates
SJT>     for signing their own packages as pushed to GNU ELPA.  PMs should
SJT>     use a specific key exclusively for signing GNU ELPA packages for
SJT>     authentication purposes.

I think, at least for now, Stefan has decided to use a single signature.

SJT> 5.  The next mission is to develop security criteria for reviews.
SJT>     This will be an ongoing process, with basics ("don't load random
SJT>     libraries from the default directory") coming first, and more
SJT>     extensive reviews ("how could this hook be abused?") postponed
SJT>     until later.

SJT> 6.  Code that has been security reviewed would get a separate "SR"
SJT>     signature (ie, personal to the reviewer and a different key from
SJT>     either the GEM key(s) or the PM keys).

I think that's a good plan, and can coexist with the more urgent need
to sign the package to indicate provenance.

I propose security signatures also live in `archive-contents', as Yet
Another Vector Element, in an alist (reviewer . signature) format.

Ted

Re: package.el + DVCS for security and convenience

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > Our view on emacs-devel is very different and colors our thinking.
 > So "we" reflects us, the Emacs developers, of which the GNU ELPA
 > maintainers are a subset.

So what?  I thought the point was to reassure the users about the
security of the packages they download, not to massage the egos of the
maintainers by reifying "their thinking" in the design of the signing
process.

The users, by and large, do not willy-nilly download all the packages,
and this will not change by adding a signing step to the release
process.  Many users are familiar with the maintainers of the packages
they do want, and would have opinions on the quality (including the
security) of the packages those maintainers upload that vary as a
function of the maintainer.

This *does* matter if it's the security of the package contents that
is represented by the signature.  It doesn't matter if the signature
only authenticates the download as a true GNU ELPA product.

 > Stefan has confirmed (I believe) the GNU ELPA maintainers will use a
 > single "GNU ELPA" key to sign package releases.

Have you given up on having every commit signed?

 > He has also stated we'll use signatures to indicate provenance, not
 > security reviews.

OK, I happen to agree with Stefan that that is the place to start.
And I agree with both of you that in that case a single key used by
all those authorized to push to the "official" repo is appropriate.

 > SJT> (Authors will have to rework features rejected for security of
 > SJT> implementation reasons, and it would be quite painful to have a
 > SJT> whole feature rejected for security reasons).
 > 
 > The authors are free not to host their packages in the GNU ELPA, if they
 > don't want to worry about security concerns.

You are highly skilled at missing the point.  This is a cost, even if
the authors willingly pay it.  What bothers me is proposing to impose
such costs on the project without estimating their size, let alone
explaining where the resources will come from.

Re: package.el + DVCS for security and convenience

[Ted Zlatanov]

On Wed, 09 Jan 2013 02:53:56 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Ted Zlatanov writes:
>> Stefan has confirmed (I believe) the GNU ELPA maintainers will use a
>> single "GNU ELPA" key to sign package releases.

SJT> Have you given up on having every commit signed?

See my summary, posted separately.  Short answer: I want to get
something usable out, rather than argue.

SJT> What bothers me is proposing to impose such costs on the project
SJT> without estimating their size, let alone explaining where the
SJT> resources will come from.

I told you, I'm outsourcing to some Russians I know.  Problem solved.

Ted

Re: package.el + DVCS for security and convenience

[Stefan Monnier]

>> Stefan has confirmed (I believe) the GNU ELPA maintainers will use a
>> single "GNU ELPA" key to sign package releases.
> Have you given up on having every commit signed?

I haven't even tried to sign a single Bzr commit.  Hell, I use GPG
rarely enough, that I typically end up having to create a new key
because I can't remember the password I used for the last one.

And I worry about what happens if/when we restructure the repository
(currently we have a single Bzr branch with all packages in it (except
for Org), but we'll probably want to move to a setup where more packages
have their own branches, also we may move from Bzr to something else).

And I'm not sure what would be the gain with such signatures: I'm
shocked to hear people would trust me, since I don't trust myself (and
some (former?) friends of mine know I'm not trustworthy).
[ For the record, I work in the context of certified programming, where
you don't want to trust people at all, and instead expect them to give
you a formal proof that their code is safe.  ]

> You are highly skilled at missing the point.
Let's try to stay clear of such ad-hominem, please.


        Stefan

Re: package.el + DVCS for security and convenience

[Stephen J. Turnbull]

Stefan Monnier writes:
 > >> Stefan has confirmed (I believe) the GNU ELPA maintainers will use a
 > >> single "GNU ELPA" key to sign package releases.
 > > Have you given up on having every commit signed?
 > 
 > I haven't even tried to sign a single Bzr commit.

That is the way a lot of projects do it.  It's not zero-cost
(indirectly evidenced by the fact that such projects typically have a
lot of people paid directly or indirectly to work on them).

All that the proposed signing system does is eliminate man-in-the-
middle attacks on the transport of packaged Lisp.  This is worth
doing, because apparently it's trivial to suborn parts of the DNS, and
because it makes it possible to authenticate mirrors, all at low cost
to the maintainers and users.

Nevertheless, it does nothing to make GNU ELPA more secure than it
currently is against attacks on the code in the repo itself or on the
release process.  In the long run, is that good enough for Emacs?

 > Hell, I use GPG rarely enough, that I typically end up having to
 > create a new key because I can't remember the password I used for
 > the last one.

Me too. ;-)  I'm going to start learning, though.

 > And I worry about what happens if/when we restructure the repository
 > (currently we have a single Bzr branch with all packages in it (except
 > for Org), but we'll probably want to move to a setup where more packages
 > have their own branches, also we may move from Bzr to something else).

That is indeed potentially costly.  However, if you're not going to
consider eventually bearing such costs, my position is that you should
seriously consider doing nothing, since the system that will be
implemented provides very little assurance that the code is "safe".
Yet many naive users will see the signatures and assume they mean
something they don't.

 > And I'm not sure what would be the gain with such signatures: I'm
 > shocked to hear people would trust me, since I don't trust myself (and
 > some (former?) friends of mine know I'm not trustworthy).

You write as if you think my trust in you is absolute.  It's not; I
simply would trust your code more than I would some other folks'.
Among other things, it's well-organized and easy to read, which means
I can review it myself.

That is the whole point I was trying to make by writing that I would
trust you -- trust is relative, and a function of people as well as
systems.  And I put little weight on your statement that you're
shocked; people are often poor judges of their own worth.

 > [ For the record, I work in the context of certified programming,
 > where you don't want to trust people at all, and instead expect
 > them to give you a formal proof that their code is safe.  ]

I don't understand the relevance of that comment.  Since you have
disclaimed the intent to do security reviews, you obviously can't
possibly be providing formal proofs for code safety.  Nothing is left
except to recognize that in downloading and using packages (and Emacs
itself) users are implicitly trusting contributors who are many, do
not have easily verified identities, and in some cases are effectively
anonymous.  Of course we don't want to trust, but there is no
alternative to trusting somebody.  In the current state, we are forced
to trust everybody to the same degree.

 > > You are highly skilled at missing the point.

 > Let's try to stay clear of such ad-hominem, please.

It's not "argument ad hominem", but since the current plan is to
restrict signatures to authenticating provenance, it has become
irrelevant.  I retract the statement.

Re: package.el + DVCS for security and convenience

[Stephen J. Turnbull]

Ted Zlatanov writes:
 > On Mon, 07 Jan 2013 11:03:07 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 
 > 
 > SJT> Ted Zlatanov writes:

 > SJT> I have no idea what you think you're proposing.

OK, time for me to spit out what *I*'ve implicitly been thinking
should be the process.

0.  Emacs should do something about this, and soon.

    Rationale: As somebody posted earlier [my apologies for failure to
    cite correctly], it's important to do something as soon as
    possible, because resistance to bureacracy etc builds up fast.

1.  Mission creep should be avoided.

    Rationale: For the same reason, it's important to do what you do
    right the first time.  Resistance to change builds up quickly, and
    is stronger if the original effort was not very successful.

2.  The first mission, cheap to implement, is to authenticate the
    packages that are at GNU ELPA.

    Rationale: It's cheap, and everybody (except XEmacs, mea maxima
    culpa) does it so people are familiar with it.

3.  The authentication should be done via a list of authorized
    signatures, not a single "GNU ELPA Maintainer" (GEM) signature.

    Rationale: If a personal signature gets compromised, it's much
    less costly to revoke.  Some users may wish to assign different
    levels of trust to different signatures.  Eg, if Stefan were
    maintaining a package, I would not hesitate to put the highest
    level of trust on his signature.  I wouldn't feel the same way
    about a new package contributor, nor would I feel the same way
    about Stefan signing a package he had never contributed to, and
    certainly not a GNU ELPA Maintainer signature masking a group of
    volunteers most of whom I don't know.  YMMV, this is my
    rationale. ;-)

    Exception: There could be a GNU ELPA bot that does nothing except
    certify that the package is exactly as distributed by GNU ELPA, it
    would have a GEM signature.  Probably not worth it, though, as it
    has little extra value to users but would be an obvious attack
    vector.

4.  Package maintainers (PMs) should be considered leading candidates
    for signing their own packages as pushed to GNU ELPA.  PMs should
    use a specific key exclusively for signing GNU ELPA packages for
    authentication purposes.

    Rationale: *Any* such PM signature authenticates the package as
    having been contributed to GNU ELPA.  Some users might assign more
    trust to individual PM signatures, but that's neither recommended
    nor deprecated by the GNU ELPA.

5.  The next mission is to develop security criteria for reviews.
    This will be an ongoing process, with basics ("don't load random
    libraries from the default directory") coming first, and more
    extensive reviews ("how could this hook be abused?") postponed
    until later.

    Rationale: Without a definition of what is being reviewed, users
    have no basis for assigning trust.  Graded review process is
    important so that in the early stages GNU ELPA can proclaim high
    quality review *as far as it goes* even though the standard is
    weak.  As reviewer resources become available, the standard can be
    strengthened without loss of quality.

6.  Code that has been security reviewed would get a separate "SR"
    signature (ie, personal to the reviewer and a different key from
    either the GEM key(s) or the PM keys).

    Rationale: The signature is separate so that authentication
    signatures can be implemented first.  Rationale for personal keys
    is as for PM signatures.  Also, I personally would put less trust
    in a security review by the author of the code reviewed (from
    introspecting my own blind spots).  The key needs to be separate
    from the GEM and PM keys to make automation of checking for
    security review straightforward.  (POC.  There may be better ways
    of doing this, equally secure and straightforward for users, while
    less burdensome for reviewers.)

Caveat lector: Incomplete and not all that carefully thought-out.

Steve

Re: package.el + DVCS for security and convenience

[Xue Fuqiao]

On Tue, 08 Jan 2013 11:20:16 +0900
"Stephen J. Turnbull" <stephen@xemacs.org> wrote:

> 0.  Emacs should do something about this, and soon.
> 
>     Rationale: As somebody posted earlier [my apologies for failure to
>     cite correctly], it's important to do something as soon as
>     possible, because resistance to bureacracy etc builds up fast.
> 
> 1.  Mission creep should be avoided.
> 
>     Rationale: For the same reason, it's important to do what you do
>     right the first time.  Resistance to change builds up quickly, and
>     is stronger if the original effort was not very successful.

I agree, these two are very important.
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re: package.el + DVCS for security and convenience

[Xue Fuqiao]

On Fri, 04 Jan 2013 11:05:12 -0500
Ted Zlatanov <tzz@lifelogs.com> wrote:

> Now, since everyone but Xue Fuqiao has told me that tying package.el to
> the DVCS is a bad idea, we need to decide how these signatures will be
> stored in the ELPA, and how they can fit into the existing ELPA
> structure.
I've changed my mind about tying package.el to DVCS now.  It require external tools,  so it wouldn't be available to all Emacs users.  If people like this feature, we can make it a package in ELPA to make its use optional.

As for GnuPG and OpenPGP implementation, I prefer the latter(although it is more difficult and may be low-quality), because (at least)I don't like call external tools.
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re:package.el + DVCS for security and convenience (was: ELPA security)

[Phil Hagelberg]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I propose to require signatures for ELPA packages and make package.el
> aware of signatures

Having just gone through this process for the Clojure community
repository, it might be helpful for me to describe what we ended up with
there.

We ended up creating a new repository for the signed releases, but this
had more to do with flaws in the existing repository than anything
related to security. But the gist of it was that each package uploaded
had to be accompanied by an .asc file that was checked at upload time
against a public key that we had on file for the maintainers. The plan
is to also have a repository-level key that's used to verify the fact
that the given signed package was uploaded at a given time; that way
were a key to be compromised it would be possible to ensure that the
package was uploaded before the key was revoked.

We are working on building up a web of trust within the community of
Clojure library developers, but this is a long-term goal. This kind of
model would probably be important to the community repositories like
Marmalade and MELPA, but the GNU repository can sidestep some of this
complexity because there's a central authority that everyone can trust.
However, I'd suggest that rather than having GNU sign the packages
directly, they could sign the keys of those maintainers who have
privileges to upload. That makes revocation possible.

For Clojure right now we have rudimentary checks to ensure that all the
packages in a dependency tree are at least signed, but we don't yet have
a mechanism to walk it to ensure that everything's signed by someone you
trust or trust transitively. But IMO it's important to start collecting
signatures as early as possible even if the tools to check it on the
client don't exist yet; in the long run you want to minimize the number
of published unverifiable packages.

I don't see any benefit to using version control tools on the client
side. It may make sense to use them to build the repository, but having
the repository consist simply of a pile of static files on disk is a
very valuable property that we shouldn't give up lightly.

Adding SSL to the existing implementation would be fairly easy and has
no downsides, so it should be done soon; it's low-hanging fruit that can
be improved quicker than adding signatures.

I would just like to add that I consider writing an OpenPGP
implementation in Emacs to be a very bad idea--we simply do not have the
resources to get the auditing that would be necessary to get this to a
level of quality that we could trust. Using GnuPG would be both quicker
to implement and result in much higher-quality code. If there are
concerns that people may not use it because it's difficult to install
then our efforts would be better spent on making it easier to install.

I'm very glad to see movement on this front though--the current state of
affairs is an improvement over everyone pulling packages in from the
wiki but still has a long way to go before it's something properly
trustworthy.

-Phil

Re: package.el + DVCS for security and convenience

[Ted Zlatanov]

On Mon, 31 Dec 2012 12:06:22 -0800 Phil Hagelberg <phil@hagelb.org> wrote: 

PH> I don't see any benefit to using version control tools on the client
PH> side. It may make sense to use them to build the repository, but having
PH> the repository consist simply of a pile of static files on disk is a
PH> very valuable property that we shouldn't give up lightly.

I proposed some benefits in my followup to Nic Ferrier and before.  But
it seems that the consensus from you, him, and Tom is to avoid the DVCS
integration, so I'll drop the proposal.  Unless my eloquence has
convinced you all in the meanwhile :)

PH> Adding SSL to the existing implementation would be fairly easy and has
PH> no downsides, so it should be done soon; it's low-hanging fruit that can
PH> be improved quicker than adding signatures.

I worry it will lower the incentive to do the signature work, and SSL is
known to be compromised at many levels.

PH> I would just like to add that I consider writing an OpenPGP
PH> implementation in Emacs to be a very bad idea--we simply do not have the
PH> resources to get the auditing that would be necessary to get this to a
PH> level of quality that we could trust. Using GnuPG would be both quicker
PH> to implement and result in much higher-quality code. If there are
PH> concerns that people may not use it because it's difficult to install
PH> then our efforts would be better spent on making it easier to
PH> install.

OK.  Stefan asked for GnuPG as well, so an OpenPGP implementation is not
happening anytime soon.

PH> I'm very glad to see movement on this front though--the current state of
PH> affairs is an improvement over everyone pulling packages in from the
PH> wiki but still has a long way to go before it's something properly
PH> trustworthy.

Your opinions and expertise are greatly appreciated (and also Tom, Nic,
Stefan, Stephen, and everyone else who has contributed to the threads).

Ted

Re: ELPA security

[Stefan Monnier]

> I also think `M-x list-packages' should define a `v' shortcut to file-find
> the .el file or tarball that constitutes the package without installing
> it.  That will contribute to security and it's really convenient, too.

Actually, "installation" has several steps:
- download.
- install per se (i.e. copies the files at an appropriate place).
- compile.
- setup (i.e. arrange things such that the package is in the load-path
  and its autoloads are active next time to start Emacs).

The first two steps can be made to be safe.


        Stefan

Re: ELPA security

[Paul Nathan]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

On Sat, Dec 22, 2012 at 8:20 AM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > I also think `M-x list-packages' should define a `v' shortcut to
> file-find
> > the .el file or tarball that constitutes the package without installing
> > it.  That will contribute to security and it's really convenient, too.
>
> Actually, "installation" has several steps:
> - download.
> - install per se (i.e. copies the files at an appropriate place).
> - compile.
> - setup (i.e. arrange things such that the package is in the load-path
>   and its autoloads are active next time to start Emacs).
>
> The first two steps can be made to be safe.
>
>
>         Stefan
>
>

Hullo,

I would like to humbly provide some ideas here:

- In general, GNU is trusted (after all, we download our emacs from the
GNU). This would imply to me that the GNU can GPG sign packages with a
private/public key (Perhaps the precursor to this is emacs having a gpg
implementation included).

- Then perhaps other repositories, such as marmalade could also sign their
packages, and users could choose to trust that signature or not.

- Of course, this is analogous to the Debian/Launchpad/PPA approach, which
has worked excellently for me and others. It may require quite a great deal
of infrastructure work which I am entirely unfamiliar with.

Regards,
Paul

[-- Attachment #2: Type: text/html, Size: 1944 bytes --]

Re: ELPA security

[Ted Zlatanov]

On Wed, 26 Dec 2012 09:32:44 -0800 Paul Nathan <pnathan.software@gmail.com> wrote: 

PN> - In general, GNU is trusted (after all, we download our emacs from the
PN> GNU). This would imply to me that the GNU can GPG sign packages with a
PN> private/public key (Perhaps the precursor to this is emacs having a gpg
PN> implementation included).

Hmm.  So maybe there can be signed checkpoint commits to a global
ChangeLog file that validate all the commits up to that commit?  Then
package.el would pull that commit from the ELPA DVCS repository and
ignore all later, unconfirmed commits?  That seems very workable for the
maintainers and for package.el:

1. add DVCS support to package.el, supporting Git and Bazaar, with the
notion of "pull packages from repo X at tag/commit Y" in addition to the
current "pull packages from URLs".  The VC package has to be involved
here, instead of writing custom code.

2. when the user requests it and we can support it, we verify that Y is
signed with the ELPA maintainer key.  This will be optional, but for the
GNU ELPA we'll check by default and warn if the verification fails.  The
VC package may be involved here or it could be done in package.el; the
underlying verification will be done by an external tool at first and
may be implemented internally in Emacs later.

3. we may need a way to revoke a signed commit.  Perhaps it can simply
be a revert of the previously committed "bad" code, followed by another
commit, instead of a full revocation process.

4. I don't think we should provide this mechanism without a DVCS that
supports signing a tag or a commit.  In other words, let's not try to
bolt it on top of the current HTTP ELPA structure.

PN> - Then perhaps other repositories, such as marmalade could also sign their
PN> packages, and users could choose to trust that signature or not.

PN> - Of course, this is analogous to the Debian/Launchpad/PPA approach, which
PN> has worked excellently for me and others. It may require quite a great deal
PN> of infrastructure work which I am entirely unfamiliar with.

I think the proposal above minimizes new infrastructure.  It moves the
verification and signing burden to the ELPA (e.g. the GNU ELPA)
maintainers, which I think is the right place.  The new DVCS repo
pointers in package.el can coexist with the current HTTP pointers for a
nice gradual transition.

If this sounds acceptable I will start on a POC.

Ted

Re: ELPA security

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > 3. we may need a way to revoke a signed commit.  Perhaps it can simply
 > be a revert of the previously committed "bad" code, followed by another
 > commit, instead of a full revocation process.

Branches.  It should be possible for a package.el implementation to
call home to the original GNU ELPA and check on the status of the most
recent signed commit.

Package signing infrastructure suggestion (was Re: ELPA security)

[Nic Ferrier]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Hmm.  So maybe there can be signed checkpoint commits to a global
> ChangeLog file that validate all the commits up to that commit?  Then
> package.el would pull that commit from the ELPA DVCS repository and
> ignore all later, unconfirmed commits?  That seems very workable for the
> maintainers and for package.el.

...

> I think the proposal above minimizes new infrastructure.  It moves the
> verification and signing burden to the ELPA (e.g. the GNU ELPA)
> maintainers, which I think is the right place.  The new DVCS repo
> pointers in package.el can coexist with the current HTTP pointers for a
> nice gradual transition.
>
> If this sounds acceptable I will start on a POC.

It sounds like you are mixing up a lot of different things. 

A package is an artifact from a build system and that separation between
packages and repositories is a good thing.

A better solution is to have a standard location for signed packages,
perhaps a derivable HTTP or file URL.

A single package could be used to collect everyone's keys.

When a new maintainer is added the key package would have to be
updated.

The key package could be constructed automatically from gpg key stores
or individual uploads of keys. Something that assures we know who
someone is.

The key package should have a unique name derived from the repository so
other repositories can support the same system if they wish to.

It's quite important, I think, that the maintenance of the key package
is separate from the signed packages themselves.



Nic Ferrier
Elnode, Marmalade, TeamChat.net

Re: Package signing infrastructure suggestion (was Re: ELPA security)

[Ted Zlatanov]

On Mon, 31 Dec 2012 13:39:40 +0000 Nic Ferrier <nferrier@ferrier.me.uk> wrote: 

NF> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Hmm.  So maybe there can be signed checkpoint commits to a global
>> ChangeLog file that validate all the commits up to that commit?  Then
>> package.el would pull that commit from the ELPA DVCS repository and
>> ignore all later, unconfirmed commits?  That seems very workable for the
>> maintainers and for package.el.

NF> ...

>> I think the proposal above minimizes new infrastructure.  It moves the
>> verification and signing burden to the ELPA (e.g. the GNU ELPA)
>> maintainers, which I think is the right place.  The new DVCS repo
>> pointers in package.el can coexist with the current HTTP pointers for a
>> nice gradual transition.
>> 
>> If this sounds acceptable I will start on a POC.

NF> It sounds like you are mixing up a lot of different things. 

NF> A package is an artifact from a build system and that separation between
NF> packages and repositories is a good thing.

In my proposal, the repository is not the classical source repository
that produces packages but a storage space for the ELPA packages, which
is how it's used by the GNU ELPA (a branch in the Emacs Bazaar repo).

I think for the ELPA it makes sense to strenghen that integration in
order to achieve package verification and other useful features, like
retrieving a specific verision of the ELPA repository or mirroring an
ELPA repository easily.

NF> A better solution is to have a standard location for signed packages,
NF> perhaps a derivable HTTP or file URL.

We can sign the key package with a key that's stored in Emacs itself.  I
was hoping not to bolt the security on top of the current HTTP mechanism
but to integrate it with the DVCS better, but if you and Tom and others
think it's better to piggyback on top of HTTP, I'll go along.

NF> A single package could be used to collect everyone's keys.

NF> When a new maintainer is added the key package would have to be
NF> updated.

NF> The key package could be constructed automatically from gpg key stores
NF> or individual uploads of keys. Something that assures we know who
NF> someone is.

NF> The key package should have a unique name derived from the repository so
NF> other repositories can support the same system if they wish to.

NF> It's quite important, I think, that the maintenance of the key package
NF> is separate from the signed packages themselves.

I understand your proposal and think it makes a lot of sense.  But how
is it better than signed commits with Bazaar or signed tags with Git?

With signed commits/tags, only one public key is needed (the repository
maintainer) and it's easy to say "right here, everything in this
repository is approved."  There's also no need to revoke packages in
this scheme, because you'd commit a revert of the earlier bad code and
sign that new commit.  And finally, there is no "key package" or much
else special... you just use the built-in DVCS facilities.

Ted

Re: Package signing infrastructure suggestion (was Re: ELPA security)

[Xue Fuqiao]

On Mon, 31 Dec 2012 17:32:24 -0500
Ted Zlatanov <tzz@lifelogs.com> wrote:

> I think for the ELPA it makes sense to strenghen that integration in
> order to achieve package verification and other useful features, like
> retrieving a specific verision of the ELPA repository or mirroring an
> ELPA repository easily.

I think so, too.  Integrate the security with DVCS is a good choice.
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re: ELPA security

[Tom Tromey]

>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

Ted> 1. add DVCS support to package.el, supporting Git and Bazaar, with the
Ted> notion of "pull packages from repo X at tag/commit Y" in addition to the
Ted> current "pull packages from URLs".  The VC package has to be involved
Ted> here, instead of writing custom code.

What is the reason for this?

FWIW, I considered and rejected this approach when writing package.el.
My reason was that I wanted packaging not to require any external tools,
so it would be available to all Emacs users.  Also, KISS.

Mixing in VC seems to add a lot of potential failure modes.

Tom

RE: ELPA security

[Drew Adams]

> Ted> add DVCS support to package.el, supporting Git and 
> Ted> Bazaar, with the notion of "pull packages from repo X
> Ted> at tag/commit Y" in addition to the current "pull packages
> Ted> from URLs".  The VC package has to be involved
> Ted> here, instead of writing custom code.
> 
> What is the reason for this?
> 
> FWIW, I considered and rejected this approach when writing package.el.
> My reason was that I wanted packaging not to require any 
> external tools, so it would be available to all Emacs users.
> Also, KISS.
> 
> Mixing in VC seems to add a lot of potential failure modes.

+1

If Emacs Dev really wants to do this, why not separate it from package.el and
make its use optional?

Re: ELPA security

[Ted Zlatanov]

On Mon, 31 Dec 2012 11:57:58 -0800 "Drew Adams" <drew.adams@oracle.com> wrote: 

Ted> add DVCS support to package.el, supporting Git and 
Ted> Bazaar, with the notion of "pull packages from repo X
Ted> at tag/commit Y" in addition to the current "pull packages
Ted> from URLs".  The VC package has to be involved
Ted> here, instead of writing custom code.
>> 
>> What is the reason for this?
>> 
>> FWIW, I considered and rejected this approach when writing package.el.
>> My reason was that I wanted packaging not to require any 
>> external tools, so it would be available to all Emacs users.
>> Also, KISS.
>> 
>> Mixing in VC seems to add a lot of potential failure modes.

DA> If Emacs Dev really wants to do this, why not separate it from package.el and
DA> make its use optional?

The intent is to have securely authenticated packagess from the GNU ELPA
by default.  Making the mechanism optional would defeat that plan.  But
it should be easy to override and put in "warn-only" or "I don't care"
modes, I think.

Ted

Re: ELPA security

[Ted Zlatanov]

On Mon, 31 Dec 2012 12:48:44 -0700 Tom Tromey <tromey@redhat.com> wrote: 

>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
Ted> 1. add DVCS support to package.el, supporting Git and Bazaar, with the
Ted> notion of "pull packages from repo X at tag/commit Y" in addition to the
Ted> current "pull packages from URLs".  The VC package has to be involved
Ted> here, instead of writing custom code.

Tom> What is the reason for this?

Right now, it's easy to change the DNS entry for the GNU ELPA and
compromise a user's machine completely.

I proposed a way for package.el to verify packages by looking at signed
DVCS commits (Bazaar) or tags (Git).  This uses public-key cryptography,
which fits well with the decentralized operation of package.el, and
these DVCSs are available on most modern platforms that can run Emacs.
Please see my previous posts to emacs-devel for the details.

Tom> FWIW, I considered and rejected this approach when writing package.el.
Tom> My reason was that I wanted packaging not to require any external tools,
Tom> so it would be available to all Emacs users.  Also, KISS.

OK.  KISS doesn't address package security, unfortunately.  How would
you suggest we verify the packages you've downloaded?  Plain HTTP and
HTTP/S are not sufficient.  We need to build the equivalent of the DVCS
signed commits/tags, in my opinion, and I'd live to avoid that extra
work.  The VC package, present in Emacs already, could provide this.

Tom> Mixing in VC seems to add a lot of potential failure modes.

The current situation is bad enough to warrant this work and potential
complications.  I am open to alternative suggestions.

Ted

Re: ELPA security

[Achim Gratz]

Ted Zlatanov writes:
> SSL can easily be compromised and may not be available on all
> platforms.

I won't comment on that assertion, but in any case transport layer
security solves only a tiny part of the problem.

As far as the end user is concerned, what she really needs to know is
that the files on disk have not been tampered with compared to what the
maintainer intended to distribute.  This is a general problem with
Emacs, not just with ELPA and the solution IMHO doesn't lie with the
development process either (it's good to have a verifyable development
process, but that doesn't address the problem at hand).  So there are at
least three checks to make: check the metadata before the download, then
the downloaded archive itself and then again that the stuff unpacked
from that archive matches the distribution.  Lastly, maybe a fourth
check that after compiling the package no extra or missing files are
recorded.

This can be done via checksumming and comparison with a manifest, which
in turn needs to be signed.  Optimally the manifest would be signed by
the maintainer(s) of the package upon release and then again by whoever
runs the package archive upon publication, preferrably with some note
that the maintainer credentials have been checked successfully and when.
Also the metadata should be signed so that a rogue ELPA server or mirror
can not distribute files to the end user easily.  Since installing a
package produces additional files, they should probably be listed in the
manifest (without checksum) to ensure that no malicious files are
planted upon installation.

That moves all the authenticity issues to the signatures or rather the
trust you have in the keys used to produce them.  CPAN/PAUSE can be used
as an example of how something like this works out in practise (Debian
apt or openSUSE zypper are further examples, but they operate on a
different scale).  Emacs would need to be deployed so that it knows its
own signing key as well as the (preferably separate) key for ELPA.  I
don't think that it should implicitly trust them, though, so the user
should explicitly consent to trusting the key (either temporarily or
permanently).

Note that (D)VCS doesn't come into play at any level of this unless you
intend to publish packages directly from the DVCS they are developed in.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: ELPA security

[Ted Zlatanov]

On Sat, 05 Jan 2013 17:46:19 +0100 Achim Gratz <Stromeko@nexgo.de> wrote: 

AG> Ted Zlatanov writes:
>> SSL can easily be compromised and may not be available on all
>> platforms.

AG> So there are at least three checks to make: check the metadata
AG> before the download, then the downloaded archive itself and then
AG> again that the stuff unpacked from that archive matches the
AG> distribution.  Lastly, maybe a fourth check that after compiling the
AG> package no extra or missing files are recorded.

AG> This can be done via checksumming and comparison with a manifest, which
AG> in turn needs to be signed.

I think it's easier to simply require that every file have its own .sig
and avoid the verification chain from manifest to archive contents.
Then we rely on GPG to handle signing and verification for us, no matter
who actually generates the .sig files (as long as their signing key is
trusted by us).  I don't think checksums have any advantage there, but
maybe you see some?

I think the GNU ELPA maintainers should sign everything, but that's
debatable and not essential to the proposal.

AG> Since installing a package produces additional files, they should
AG> probably be listed in the manifest (without checksum) to ensure that
AG> no malicious files are planted upon installation.

I don't know if that's needed, but have no problem with it as a feature.

AG> That moves all the authenticity issues to the signatures or rather the
AG> trust you have in the keys used to produce them.

Yes, that's exactly what I'm trying to accomplish, instead of relying on
SSL/TLS or other transport-level solutions.

AG> Emacs would need to be deployed so that it knows its own signing key
AG> as well as the (preferably separate) key for ELPA.  I don't think
AG> that it should implicitly trust them, though, so the user should
AG> explicitly consent to trusting the key (either temporarily or
AG> permanently).

I think `package-list' has to work without prompts or configuration.
You should have to specifically exclude the GNU ELPA maintainers' keys
from your default (`emacs -q') configuration in order not to trust them.

Ted

Re: ELPA security

[Paul Nathan]

[-- Attachment #1: Type: text/plain, Size: 2547 bytes --]

[snip]


> I think it's easier to simply require that every file have its own .sig
> and avoid the verification chain from manifest to archive contents.
> Then we rely on GPG to handle signing and verification for us, no matter
> who actually generates the .sig files (as long as their signing key is
> trusted by us).  I don't think checksums have any advantage there, but
> maybe you see some?
>
> I think the GNU ELPA maintainers should sign everything, but that's
> debatable and not essential to the proposal.
>
> AG> Since installing a package produces additional files, they should
> AG> probably be listed in the manifest (without checksum) to ensure that
> AG> no malicious files are planted upon installation.
>
> I don't know if that's needed, but have no problem with it as a feature.
>
> AG> That moves all the authenticity issues to the signatures or rather the
> AG> trust you have in the keys used to produce them.
>
> Yes, that's exactly what I'm trying to accomplish, instead of relying on
> SSL/TLS or other transport-level solutions.
>
>
>
Hullo,

It appears that the simplest so far is to use per-package signature files
for GPG verification, keeping the gpg pubkeys downloaded with gnu emacs or
separately downloaded.  I am perhaps unlearned, but directly using version
control seems like it would add some complexity. The idea of having a data
file and a signature file seems to be much more straightfoward.

Perhaps this could be most easily accomplished by some sort of
post-download hook ("check package file to verify signature authenticity"),
along with a list of known GPG keys stored in some ~/.emacs.d/package-keys
folder.

One downside to this proposal seems to be that it would link gnu emacs with
gnu privacy guard fairly tightly as a dependency. I see several aspects
here (perhaps I am missing something) -

- GPG could be compromised on the user's computer(this probably indicates
all is lost)
- GPG must be distributed with GNU Emacs, or else partially reimplemented
in elisp. Some operating systems are not shipped with gpg.
- The verification and import interfaces must be very simple and obvious to
users ignorant in cryptography. It is no good if many people just disable
it because it is too problematic to use.


I have the idea that this idea is very simple to prototype if gpg can be
shelled out to. A cursory reading of package.el suggests to me that
package-download-transaction could have the verification added.  I could
help out here if it is acceptable for a novice to help.

Kind regards,
Paul

[-- Attachment #2: Type: text/html, Size: 3210 bytes --]

Re: ELPA security

[Jambunathan K]

If GNU packages come with no warranty of any sort, I am wondering why
all this fuzz.

If I am downloading a package from a trustworthy site - "certified" by a
legal entity - I should be doing good, right.

I have never even thought of verifying my Emacs, ever.  If Emacs,
happened to carry a virus or if the rumour-mills go abuzzing about virus
infiltration or if AV packages go bonkers, I may become extra paranoid.

Also, when I am downloading stuff from a distributor I implicitly trust
shouldn't I be doing good.  Can I not rely on the distributor to do the
due diligence?

Again, I am going to be fired from multiple quarters for posting this.
That's fine.  I am willing to face the cannon and hopefully others will
be informed or warned.

ps: I have nothing against elaborate security measures and VVIP gate
passes.  Question is does my house really need it?
-- 

Re: ELPA security

[Paul Nathan]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

> If I am downloading a package from a trustworthy site - "certified" by a
> legal entity - I should be doing good, right.

Jambunathan,

The existing problem statement is that while we (presumably) trust the GNU
Emacs code, we do not per se trust the other packages in existence. How do
we know those packages are what the original authors created?  It is not
the best idea from a security standpoint to download arbitrary code from
the emacs wiki and execute it!

The ELPA infrastructure now allows pulling extensions from multiple non-GNU
repositories. I certainly hope no one hacks them! If someone does, then a
certification mechanism would assist the user in telling them that
something's gone very wrong.  So a signing mechanism allows the distributor
to certify his/her code as being written by his/ger, and you to verify that
the distributor certified their code.  Whether the code itself is any good
is a different question, of course - a malicious distributor that everyone
trusts is a big problem!


Kind regards,
Paul

>
>

[-- Attachment #2: Type: text/html, Size: 1371 bytes --]

Re: ELPA security

[Jambunathan K]

Paul Nathan <pnathan.software@gmail.com> writes:

>> If I am downloading a package from a trustworthy site - "certified"
> by a
>> legal entity - I should be doing good, right.
>
> Jambunathan,
>
> The existing problem statement is that while we (presumably) trust the
> GNU Emacs code, we do not per se trust the other packages in
> existence. How do we know those packages are what the original authors
> created? It is not the best idea from a security standpoint to
> download arbitrary code from the emacs wiki and execute it! 

Thanks for not getting offended and ELI5.  I don't mean to hijack this
thread.

Frankly speaking, I don't rely on Tromey, Marmalade, Emacswiki or
MELPA.  I may consult them but I don't rely on them.

The main problem is not that of security per se.  The main problem is
reliability.  The packages will break, the author wouldn't care about
responding to questions or fixing things, the functionality itself could
be broken in unknown ways etc.

> The ELPA infrastructure now allows pulling extensions from multiple
> non-GNU repositories. I certainly hope no one hacks them! If someone
> does, then a certification mechanism would assist the user in telling
> them that something's gone very wrong. So a signing mechanism allows
> the distributor to certify his/her code as being written by his/ger,
> and you to verify that the distributor certified their code. Whether
> the code itself is any good is a different question, of course - a
> malicious distributor that everyone trusts is a big problem!

I am thinking how many of the existing ELPA repositories will go to the
extent of getting a signature from a legal entity.  Mostly they are
"wannabe-s" or individual efforts.

May be the idea is too ahead for it's time.  I wonder whether another
"serious" distributor like GNU ELPA sprouts forth. 

Is XEmacs a contender here, I don't know.  Stephen T can enlighten us.

> Kind regards,
> Paul
>
>

-- 

Re: ELPA security

[Paul Nathan]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

On Sun, Jan 6, 2013 at 10:09 PM, Jambunathan K <kjambunathan@gmail.com>wrote:

>
> I am thinking how many of the existing ELPA repositories will go to the
> extent of getting a signature from a legal entity.  Mostly they are
> "wannabe-s" or individual efforts.



Unless I am entirely foolish, which is always possible, the idea of having
a legal entity effective notarize the code is not the idea. The general
idea is that the individual (or the package repository maintainer) would
use GPG to sign their code (perhaps with bzr, git, hg, or directly with
gpg), and this pub key would be available for the user to download, much
like Launchpad does for the Debian infrastructure.

I am pretty sure that reliability is not the concern in this thread, but
protecting against malicious behavior, since public/private key crypto is
under consideration.

I am sure that if I am wrong in any of this, more learned and experienced
emacs-devel members will instruct me.

Kind regards,
Paul

[-- Attachment #2: Type: text/html, Size: 1481 bytes --]

Re: ELPA security

[Stephen J. Turnbull]

Jambunathan K writes:

 > May be the idea is too ahead for it's time.  I wonder whether another
 > "serious" distributor like GNU ELPA sprouts forth.

Seems unlikely to me.  Why have more than one?  I suppose that Red Hat
might redistribute GNU ELPA, but I would imagine they would rely on
the GNU ELPA signatures.  Ditto Debian and Ubuntu.

 > Is XEmacs a contender here, I don't know.

No.  There is provision for signing our packages in our package
infrastructure, but currently they aren't signed, and the
functionality is probably pretty bitrotted.  It was way too much
hassle for most users the last time we tried.  Even Steve Baur, a
pretty paranoid dude, never advocated mandatory signature checking.

I imagine the state of the art has improved for PKI, and the situation
deteriorated in terms of the risks of cracking, so we may want to
reconsider.

Steve

Re: ELPA security

[chad]

On 06 Jan 2013, at 22:09, Jambunathan K <kjambunathan@gmail.com> wrote:

> The main problem is not that of security per se.  The main problem is
> reliability.  The packages will break, the author wouldn't care about
> responding to questions or fixing things, the functionality itself could
> be broken in unknown ways etc.

I don't know what you consider the `main' problem, but right now
there are kits out on the web that could pretty easily be adapted
to transparently compromise anyone who ever uses any package
from any package.el repository.  As I understand it, that's the first
line of concern that's sparked the conversation.

I'm not a security expert, but I used to work with several. It's almost
always easier and better to add (basic) security to a system as soon
as you can; the resistance to change and effort builds up very fast.

It might already be too late for the first version of ELPA.

Hope that helps,
~Chad

Re: ELPA security

[Ted Zlatanov]

On Mon, 07 Jan 2013 11:39:19 +0530 Jambunathan K <kjambunathan@gmail.com> wrote: 

JK> Frankly speaking, I don't rely on Tromey, Marmalade, Emacswiki or
JK> MELPA.  I may consult them but I don't rely on them.

We are concerned about the GNU ELPA, enabled by default in GNU Emacs.

The other ELPA repos can choose to follow the GNU ELPA model, whatever
it turns out to be, but that's not the goal right now.  They are also
not enabled by default in GNU Emacs.

Ted

Re: ELPA security

[Stephen J. Turnbull]

Jambunathan K writes:

 > Can I not rely on the distributor to do the due diligence?

No, due diligence does not exist in GNU software because in the FSF's
use of the GPL there is no contract and all warranties are
disclaimed.  You may, in some jurisdictions, be able to sue them
anyway, but lack of due diligence is not going to be grounds.

IANAL-ly y'rs,

Re: ELPA security

[Ted Zlatanov]

On Mon, 07 Jan 2013 11:17:36 +0530 Jambunathan K <kjambunathan@gmail.com> wrote: 

JK> I have never even thought of verifying my Emacs, ever.  If Emacs,
JK> happened to carry a virus or if the rumour-mills go abuzzing about virus
JK> infiltration or if AV packages go bonkers, I may become extra paranoid.

JK> Also, when I am downloading stuff from a distributor I implicitly trust
JK> shouldn't I be doing good.  Can I not rely on the distributor to do the
JK> due diligence?

How do you know that distributor.com is who they say they are?

What if there's a break-in at the distributor.com site and malicious
code is brought online?

These are not theoretical situations.  They have happened many times.

Ted

Re: ELPA security

[Ted Zlatanov]

On Sun, 6 Jan 2013 21:32:11 -0800 Paul Nathan <pnathan.software@gmail.com> wrote: 

PN> It appears that the simplest so far is to use per-package signature files
PN> for GPG verification, keeping the gpg pubkeys downloaded with gnu emacs or
PN> separately downloaded.  I am perhaps unlearned, but directly using version
PN> control seems like it would add some complexity. The idea of having a data
PN> file and a signature file seems to be much more straightfoward.

Yes, I think that's the agreement.  I'd rather keep a .sig for every
file instead of signing the whole package, because then you can package
the whole directory in one tarball or distribute it as source, but
that's a technicality IMO.

PN> Perhaps this could be most easily accomplished by some sort of
PN> post-download hook ("check package file to verify signature authenticity"),
PN> along with a list of known GPG keys stored in some ~/.emacs.d/package-keys
PN> folder.

Yup.  But EasyPG and GPG manage keys already, so perhaps the storage
should be through them, instead of external.

PN> One downside to this proposal seems to be that it would link gnu emacs with
PN> gnu privacy guard fairly tightly as a dependency. I see several aspects
PN> here (perhaps I am missing something) -

PN> - GPG could be compromised on the user's computer(this probably indicates
PN> all is lost)
PN> - GPG must be distributed with GNU Emacs, or else partially reimplemented
PN> in elisp. Some operating systems are not shipped with gpg.
PN> - The verification and import interfaces must be very simple and obvious to
PN> users ignorant in cryptography. It is no good if many people just disable
PN> it because it is too problematic to use.

Yup.  We discussed this and Stefan said that for now at least, we'll
live with the GPG dependency.  I think eventually we'll implement enough
of the OpenPGP protocol to do signature verification in C.  That would
address these concerns which I had as well, but it should not block us now.

PN> I have the idea that this idea is very simple to prototype if gpg can be
PN> shelled out to. A cursory reading of package.el suggests to me that
PN> package-download-transaction could have the verification added.  I could
PN> help out here if it is acceptable for a novice to help.

I believe EasyPG (epg.el) already has the functions to do all the
signature verification work securely (e.g. it does the data transfer to
GPG and back as securely as possible).  So the POC is definitely
possible.

I'd like to settle the signing keys (will it be the authors or a group
of GNU ELPA maintainers?); `archive-contents' (will its format change?);
and signature files (will we have one per file, one per package, etc.?)
questions first.  Also Tom Tromey and Paul Hagelberg and the other
package.el authors have not commented on our latest discussions, and I
think their voices are important as they have contributed so much of the
package.el code and design.

But if you want to start on a POC, please feel free.  I really think it
would be a good start and don't wish to discourage you.

Ted

Re: ELPA security

[Stefan Monnier]

> Yes, I think that's the agreement.  I'd rather keep a .sig for every
> file instead of signing the whole package, because then you can package
> the whole directory in one tarball or distribute it as source, but
> that's a technicality IMO.

The tarball contains nothing else than the source, and it can only be
downloaded as a whole, so there's no point signing each file in
a tarball individually.

> I'd like to settle the signing keys (will it be the authors or a group
> of GNU ELPA maintainers?);

The signing will not guarantee any kind of code quality, it will only
guarantee "this comes from the real GNU ELPA".  So the signing key will
be a "GNU ELPA" key.

> `archive-contents' (will its format change?);

Yes and no: each entry in it will have one more optional field
containing the signature.  AFAIK it should be backward compatible, so
it's a change, but will still work with older package.el.


        Stefan

Re: ELPA security

[Ted Zlatanov]

On Mon, 07 Jan 2013 22:07:05 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> Yes, I think that's the agreement.  I'd rather keep a .sig for every
>> file instead of signing the whole package, because then you can package
>> the whole directory in one tarball or distribute it as source, but
>> that's a technicality IMO.

SM> The tarball contains nothing else than the source, and it can only be
SM> downloaded as a whole, so there's no point signing each file in
SM> a tarball individually.

OK.  So there's one signature, either for a standalone .el file, or for
the whole tarball.  It makes sense, then, to host it in
`archive-contents'.

>> I'd like to settle the signing keys (will it be the authors or a group
>> of GNU ELPA maintainers?);

SM> The signing will not guarantee any kind of code quality, it will only
SM> guarantee "this comes from the real GNU ELPA".  So the signing key will
SM> be a "GNU ELPA" key.

OK, great.

>> `archive-contents' (will its format change?);

SM> Yes and no: each entry in it will have one more optional field
SM> containing the signature.  AFAIK it should be backward compatible, so
SM> it's a change, but will still work with older package.el.

OK, so the package vector will have a new element.  Releasing a package
will require releasing a new `archive-contents' with an updated
signature for that package and re-signing it with the "GNU ELPA"
maintainer key.

Last question: do you want to provide for files that may show up during
compilation?  They could be ignored (current behavior), or warned about,
or could cause installation to be rejected.

Ted

Re: ELPA security

[Stefan Monnier]

> OK, so the package vector will have a new element.  Releasing a package
> will require releasing a new `archive-contents' with an updated
> signature for that package and re-signing it with the "GNU ELPA"
> maintainer key.

The `archive-contents' file is re-created afresh every day via a cron-job.

> Last question: do you want to provide for files that may show up during
> compilation?

Compilation takes place during installation and runs part of the
downloaded code, so by the time we're compiling it's too late to check
for security problems.


        Stefan

Re: ELPA security

[Ted Zlatanov]

On Tue, 08 Jan 2013 11:57:56 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> OK, so the package vector will have a new element.  Releasing a package
>> will require releasing a new `archive-contents' with an updated
>> signature for that package and re-signing it with the "GNU ELPA"
>> maintainer key.

SM> The `archive-contents' file is re-created afresh every day via a cron-job.

SM> So maybe it's better to keep the signatures in a separate file, next
SM> to the signed file (e.g. have foo.tar and foo.tar.gpgsig).

I think that answers all the questions I had.  To summarize:

1) sign `archive-contents' in the cron job when it's generated into
`archive-contents.gpgsig' with the GNU ELPA maintainer key.

2) every package release foo.{el,tar} will have an optional
foo.{el,tar}.gpgsig also signed with the GNU ELPA maintainer key.

3) package.el will optionally test the signatures by calling GPG
externally.  We'll turn that on for the GNU ELPA archive "gnu", but
other repos won't require it.  Maybe `package-archives-signed' can be a
new list of ELPA archives to be verified, by default `("gnu")', or the
format of `package-archives' can change.

3.1) If GPG is not available and the ELPA archive is to be verified, we
prompt the user to override it once or abort.  They won't be allowed to
override it permanently from the prompt--they have to `M-x
customize-variable' to do it.  The prompt will be scary.

4) If the signature checks fail, the user will be prompted to allow it
once or abort.  They won't be allowed to override it permanently from
the prompt--they have to `M-x customize-variable' to do it.  The prompt
will be scary.

5) The GNU ELPA maintainer key will be shipped with the Emacs package.el.

Does all of that sound good?

Ted

Re: ELPA security

[Stefan Monnier]

> 1) sign `archive-contents' in the cron job when it's generated into
> `archive-contents.gpgsig' with the GNU ELPA maintainer key.

Not sure this needs to be signed.  But if you want to do it, that's fine.

> 3.1) If GPG is not available and the ELPA archive is to be verified, we
> prompt the user to override it once or abort.  They won't be allowed to
> override it permanently from the prompt--they have to `M-x
> customize-variable' to do it.  The prompt will be scary.

I don't see a strong need to be scary here.  Just ask the user something
like "Can't verify package signature; continue? (y/n)".

> 5) The GNU ELPA maintainer key will be shipped with the Emacs package.el.
> Does all of that sound good?

Pretty much, yes.  I do wonder about key management, tho: the GNU ELPA
key (note: not "maintainer" because the key does not belong to any
human being) will not last for ever.  We don't have to figure out all
the details now, but it would be good to make sure that when the key
needs to be replaced, we can do so without too much trouble.


        Stefan

Re: ELPA security

[Ted Zlatanov]

On Tue, 08 Jan 2013 15:50:42 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> 1) sign `archive-contents' in the cron job when it's generated into
>> `archive-contents.gpgsig' with the GNU ELPA maintainer key.

SM> Not sure this needs to be signed.  But if you want to do it, that's fine.

I guess there's no need, so OK, no signing of `archive-contents'.

>> 3.1) If GPG is not available and the ELPA archive is to be verified, we
>> prompt the user to override it once or abort.  They won't be allowed to
>> override it permanently from the prompt--they have to `M-x
>> customize-variable' to do it.  The prompt will be scary.

SM> I don't see a strong need to be scary here.  Just ask the user something
SM> like "Can't verify package signature; continue? (y/n)".

OK.

>> 5) The GNU ELPA maintainer key will be shipped with the Emacs package.el.
>> Does all of that sound good?

SM> I do wonder about key management, tho: the GNU ELPA key (note: not
SM> "maintainer" because the key does not belong to any human being)
SM> will not last for ever.

I thought the maintainers would have their own keys, and they would sign
a GNU ELPA "signing subkey" that's only used for releasing.

SM> We don't have to figure out all the details now, but it would be
SM> good to make sure that when the key needs to be replaced, we can do
SM> so without too much trouble.

Debian has good docs on this:

http://www.debian-administration.org/article/450/Generating_a_revocation_certificate_with_gpg
http://www.debian-administration.org/article/451/Submitting_your_GPG_key_to_a_keyserver
http://www.debian-administration.org/article/452/Using_gnupg-agent_to_securely_retain_keys

...and the GPG handbook talks about these topics as well:

http://www.gnupg.org/gph/en/manual.html#AEN385
http://www.gnupg.org/gph/en/manual.html#AEN464
http://www.gnupg.org/gph/en/manual.html#AEN526

Take a look.  I think a signing subkey will work, but will let you
judge.  If you think this is workable, I'll start on the code and put
together a POC.

Ted

Re: ELPA security

[Stefan Monnier]

SM> I do wonder about key management, tho: the GNU ELPA key (note: not
SM> "maintainer" because the key does not belong to any human being)
SM> will not last for ever.
> I thought the maintainers would have their own keys, and they would sign
> a GNU ELPA "signing subkey" that's only used for releasing.

I'm sufficiently unsophisticated that I don't really know what
that means.  I understands keys can expire and can be revoked, but that
doesn't say how the end-user will deal with such a situation.

We need some way to update the signing key in a trustworthy way.


        Stefan

Re: ELPA security

[Ted Zlatanov]

On Tue, 08 Jan 2013 17:46:51 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

SM> I do wonder about key management, tho: the GNU ELPA key (note: not
SM> "maintainer" because the key does not belong to any human being)
SM> will not last for ever.
>> I thought the maintainers would have their own keys, and they would sign
>> a GNU ELPA "signing subkey" that's only used for releasing.

SM> I'm sufficiently unsophisticated that I don't really know what
SM> that means.  I understands keys can expire and can be revoked, but that
SM> doesn't say how the end-user will deal with such a situation.

SM> We need some way to update the signing key in a trustworthy way.

OK, I'll prepare a workflow and offer it for public review as part of
the POC.

Ted

Re: ELPA security

[Ted Zlatanov]

On Tue, 08 Jan 2013 18:30:50 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Tue, 08 Jan 2013 17:46:51 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 
SM> I do wonder about key management, tho: the GNU ELPA key (note: not
SM> "maintainer" because the key does not belong to any human being)
SM> will not last for ever.
>>> I thought the maintainers would have their own keys, and they would sign
>>> a GNU ELPA "signing subkey" that's only used for releasing.

SM> I'm sufficiently unsophisticated that I don't really know what
SM> that means.  I understands keys can expire and can be revoked, but that
SM> doesn't say how the end-user will deal with such a situation.

SM> We need some way to update the signing key in a trustworthy way.

TZ> OK, I'll prepare a workflow and offer it for public review as part of
TZ> the POC.

FYI, I plan to start on the ELPA security (both in code and workflow)
after Daniel Hackney's contribution to standardize package.el's
internals is merged or retracted.  I'll try to keep the code changes
minimal.

Ted

Re: ELPA security

[Stefan Monnier]

> OK, so the package vector will have a new element.  Releasing a package
> will require releasing a new `archive-contents' with an updated
> signature for that package and re-signing it with the "GNU ELPA"
> maintainer key.

Actually, I see a problem with this scheme, now that we also keep around
older versions of the packages.  So maybe it's better to keep the
signatures in a separate file, next to the signed file (e.g. have foo.tar
and foo.tar.gpgsig).


        Stefan

Re: ELPA security

[Achim Gratz]

Stefan Monnier writes:
> Actually, I see a problem with this scheme, now that we also keep around
> older versions of the packages.  So maybe it's better to keep the
> signatures in a separate file, next to the signed file (e.g. have foo.tar
> and foo.tar.gpgsig).

Then maybe the file listed in the package vector should be the *.gpgsig
one, since otherwise it becomes easy to bypass the check by filtering
out any traces of the signature file.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: ELPA security

[Ted Zlatanov]

On Tue, 08 Jan 2013 18:59:02 +0100 Achim Gratz <Stromeko@nexgo.de> wrote: 

AG> Stefan Monnier writes:
>> Actually, I see a problem with this scheme, now that we also keep around
>> older versions of the packages.  So maybe it's better to keep the
>> signatures in a separate file, next to the signed file (e.g. have foo.tar
>> and foo.tar.gpgsig).

AG> Then maybe the file listed in the package vector should be the *.gpgsig
AG> one, since otherwise it becomes easy to bypass the check by filtering
AG> out any traces of the signature file.

Excellent point!

Ted

Re: ELPA security

[Stefan Monnier]

>> Actually, I see a problem with this scheme, now that we also keep around
>> older versions of the packages.  So maybe it's better to keep the
>> signatures in a separate file, next to the signed file (e.g. have foo.tar
>> and foo.tar.gpgsig).
> Then maybe the file listed in the package vector should be the *.gpgsig
> one, since otherwise it becomes easy to bypass the check by filtering
> out any traces of the signature file.

Right, we'd need to indicate somewhere that the sig should be
present, indeed.

A simple way to do that is to tell package.el directly, e.g. via
`package-archives' or just by declaring that all ELPA archives should
always have such signatures (they're pretty easy to add, so I'd expect
marmalade and melpa to adjust pretty quickly).


        Stefan

Re: ELPA security

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 2022 bytes --]

On Tue, 08 Jan 2013 15:59:33 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>>> Actually, I see a problem with this scheme, now that we also keep around
>>> older versions of the packages.  So maybe it's better to keep the
>>> signatures in a separate file, next to the signed file (e.g. have foo.tar
>>> and foo.tar.gpgsig).
>> Then maybe the file listed in the package vector should be the *.gpgsig
>> one, since otherwise it becomes easy to bypass the check by filtering
>> out any traces of the signature file.

SM> Right, we'd need to indicate somewhere that the sig should be
SM> present, indeed.

SM> A simple way to do that is to tell package.el directly, e.g. via
SM> `package-archives' or just by declaring that all ELPA archives should
SM> always have such signatures (they're pretty easy to add, so I'd expect
SM> marmalade and melpa to adjust pretty quickly).

Please see the attached patch.  The code is not ready for testing, it's
just for review before I implement things further.

Changes:

* add `package-signed-archives', a list of logical archive names with
  default '("gnu").  Add `package-archive-signed-p' to check it.

* change `package--with-work-buffer' to take an archive entry instead of
  just the location.  When an archive is `package-archive-signed-p',
  create a signing buffer and load the archive filename with ".gpgsig"
  appended.  Then call `package--verify-signature' on the package buffer
  and the signing buffer.  If it fails, do `y-or-n-p', and if the user
  rejects, error out.

* `package--verify-signature' is mocked to t right now, but will check
  the maintainer signature.

* `package-download-single' and `package-download-tar' now pass the
  archive entry, not just the location, to `package--with-work-buffer'

* rename `package-archive-base' to `package-archive-for'

* installable packages say "signed" or "unsigned" before the archive name

If you're OK with the code changes I'll get them working and start
implementing `package--verify-signature'.

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: package-archive-signed.patch --]
[-- Type: text/x-patch, Size: 7825 bytes --]

=== modified file 'lisp/emacs-lisp/package.el'
--- lisp/emacs-lisp/package.el	2013-06-15 15:36:11 +0000
+++ lisp/emacs-lisp/package.el	2013-06-16 11:05:16 +0000
@@ -229,6 +229,15 @@
   :group 'package
   :version "24.1")
 
+(defcustom package-signed-archives '("gnu")
+  "An list of archives whose contents are signed.
+
+Signed archives trigger verification of each package's contents."
+  :type '(list string :tag "Archive name")
+  :risky t
+  :group 'package
+  :version "24.4")
+
 (defcustom package-pinned-packages nil
   "An alist of packages that are pinned to a specific archive
 
@@ -699,20 +708,39 @@
 	 nil nil nil 'excl))
       (package--make-autoloads-and-compile name pkg-dir))))
 
-(defmacro package--with-work-buffer (location file &rest body)
-  "Run BODY in a buffer containing the contents of FILE at LOCATION.
-LOCATION is the base location of a package archive, and should be
-one of the URLs (or file names) specified in `package-archives'.
+(defun package-archive-signed-p (archive)
+  "Returns whether ARCHIVE is signed.
+ARCHIVE is a package archive in the form (NAME . LOCATION) and should
+be specified in `package-archives'."
+  (member (car archive) package-signed-archives))
+
+(defmacro package--with-work-buffer (archive file &rest body)
+  "Run BODY in a buffer containing the contents of FILE at ARCHIVE.
+ARCHIVE is a package archive in the form (NAME . LOCATION) and should
+be specified in `package-archives'.
 FILE is the name of a file relative to that base location.
 
-This macro retrieves FILE from LOCATION into a temporary buffer,
-and evaluates BODY while that buffer is current.  This work
-buffer is killed afterwards.  Return the last value in BODY."
-  `(let* ((http (string-match "\\`https?:" ,location))
+This macro retrieves FILE from ARCHIVE into a temporary buffer,
+checks its signature if the ARCHIVE is defined to be signed by
+`package-signed-archives', and evaluates BODY while that buffer
+is current.  This work buffer is killed afterwards.  Return the
+last value in BODY."
+  `(let* ((archive-name (car ,archive))
+          (location (cdr ,archive))
+          (sign-file (concat ,file ".gpgsig"))
+          (http (string-match "\\`https?:" location))
+          (sign (when (package-archive-signed-p archive)
+                  (concat location sign-file)))
 	  (buffer
 	   (if http
-	       (url-retrieve-synchronously (concat ,location ,file))
-	     (generate-new-buffer "*package work buffer*"))))
+	       (url-retrieve-synchronously url)
+	     (generate-new-buffer "*package work buffer*")))
+          (sign-buffer (when sign
+                         (if http
+                             ;; Retrieve the signature file too.
+                             (url-retrieve-synchronously
+                              (concat location sign-file))
+                           (generate-new-buffer "*package sign buffer*")))))
      (prog1
 	 (with-current-buffer buffer
 	   (if http
@@ -720,12 +748,32 @@
 		      (re-search-forward "^$" nil 'move)
 		      (forward-char)
 		      (delete-region (point-min) (point)))
-	     (unless (file-name-absolute-p ,location)
+	     (unless (file-name-absolute-p location)
 	       (error "Archive location %s is not an absolute file name"
-		      ,location))
-	     (insert-file-contents (expand-file-name ,file ,location)))
+		      location))
+	     (insert-file-contents (expand-file-name ,file location)))
+           (when sign-buffer
+             (with-current-buffer sign-buffer
+               (if http
+                   (progn (package-handle-response)
+                          (re-search-forward "^$" nil 'move)
+                          (forward-char)
+                          (delete-region (point-min) (point)))
+                 ;; No need to check the location again like we did above.
+                 (insert-file-contents (expand-file-name sign-file location)))
+               (unless (package--verify-signature archive sign-buffer buffer)
+                 (let ((q (format "Can't verify .gpgsig for %s"
+                                  (concat location ,file))))
+                   (unless (y-or-n-p (concat q "; continue? (y/n)"))
+                     (error q))))))
 	   ,@body)
-       (kill-buffer buffer))))
+       (kill-buffer buffer)
+       (when sign-buffer
+         (kill-buffer sign-buffer)))))
+
+(defun package--verify-signature archive sign-buffer buffer
+  "Verify SIGN-BUFFER signs BUFFER correctly for ARCHIVE."
+  t)
 
 (defun package-handle-response ()
   "Handle the response from a `url-retrieve-synchronously' call.
@@ -742,16 +790,16 @@
 
 (defun package-download-single (name version desc requires)
   "Download and install a single-file package."
-  (let ((location (package-archive-base name))
+  (let ((archive (package-archive-for name))
 	(file (concat (symbol-name name) "-" version ".el")))
-    (package--with-work-buffer location file
+    (package--with-work-buffer archive file
       (package-unpack-single name version desc requires))))
 
 (defun package-download-tar (name version)
   "Download and install a tar package."
-  (let ((location (package-archive-base name))
+  (let ((archive (package-archive-for name))
 	(file (concat (symbol-name name) "-" version ".tar")))
-    (package--with-work-buffer location file
+    (package--with-work-buffer archive file
       (package-unpack name version))))
 
 (defvar package--initialized nil)
@@ -875,6 +923,7 @@
 (defun package--add-to-archive-contents (package archive)
   "Add the PACKAGE from the given ARCHIVE if necessary.
 PACKAGE should have the form (NAME . PACKAGE--AC-DESC).
+
 Also, add the originating archive to the `package-desc' structure."
   (let* ((name (car package))
          (version (package--ac-desc-version (cdr package)))
@@ -1094,10 +1143,10 @@
       (error "Package `%s' is a system package, not deleting"
 	     (package-desc-full-name pkg-desc)))))
 
-(defun package-archive-base (name)
+(defun package-archive-for (name)
   "Return the archive containing the package NAME."
   (let ((desc (cdr (assq (intern-soft name) package-archive-contents))))
-    (cdr (assoc (package-desc-archive desc) package-archives))))
+    (assoc (package-desc-archive desc) package-archives)))
 
 (defun package--download-one-archive (archive file)
   "Retrieve an archive file FILE from ARCHIVE, and cache it.
@@ -1106,7 +1155,7 @@
 \"archives/NAME/archive-contents\" in `package-user-dir'."
   (let* ((dir (expand-file-name (format "archives/%s" (car archive))
                                 package-user-dir)))
-    (package--with-work-buffer (cdr archive) file
+    (package--with-work-buffer archive file
       ;; Read the retrieved buffer to make sure it is valid (e.g. it
       ;; may fetch a URL redirect page).
       (when (listp (read buffer))
@@ -1229,7 +1278,11 @@
                                    'font-lock-face 'font-lock-builtin-face)
 		       "  Alternate version available")
 	     (insert "Available"))
-	   (insert " from " archive)
+	   (insert " from " (if (package-archive-signed-p
+                                 (assoc archive package-archives))
+                                "signed"
+                              "unsigned")
+                   " " archive)
 	   (insert " -- ")
 	   (let ((button-text (if (display-graphic-p) "Install" "[Install]"))
 		 (button-face (if (display-graphic-p)
@@ -1287,7 +1340,7 @@
 	;; For elpa packages, try downloading the commentary.  If that
 	;; fails, try an existing readme file in `package-user-dir'.
 	(cond ((condition-case nil
-		   (package--with-work-buffer (package-archive-base package)
+		   (package--with-work-buffer (package-archive-for package)
 					      (concat package-name "-readme.txt")
 		     (setq buffer-file-name
 			   (expand-file-name readme package-user-dir))

Re: ELPA security

[Stefan Monnier]

> * add `package-signed-archives', a list of logical archive names with
>   default '("gnu").  Add `package-archive-signed-p' to check it.

I'd opt for the opposite, i.e. list the archives that aren't signed.

And maybe automatically eliminate an archive from that "not signed"
list if we ever find a signature in it.

> If you're OK with the code changes I'll get them working and start
> implementing `package--verify-signature'.

Go ahead,


        Stefan

Re: ELPA security

[Stephen J. Turnbull]

Stefan Monnier writes:

 > And maybe automatically eliminate an archive from that "not signed"
 > list if we ever find a signature in it.

If this is about security rather than adding to your BrightShinyThings
collection, you should have a signed-and-verified-and-checked-for-
expired-or-revoked-on-$DATE list, and eliminate any packages from the
list if they fail any of the hyphenated conditions.

And of course you probably want $DATE to change frequently.

And the list should be signed....

Re: ELPA security

[Ted Zlatanov]

On Mon, 17 Jun 2013 10:56:28 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Stefan Monnier writes:
>> And maybe automatically eliminate an archive from that "not signed"
>> list if we ever find a signature in it.

SJT> If this is about security rather than adding to your BrightShinyThings
SJT> collection,

It's ALWAYS about bright-shiny-things, programmers are magpies :)

SJT> you should have a signed-and-verified-and-checked-for-
SJT> expired-or-revoked-on-$DATE list, and eliminate any packages from
SJT> the list if they fail any of the hyphenated conditions.

SJT> And of course you probably want $DATE to change frequently.

SJT> And the list should be signed....

I'd rather not build a certificate infrastructure ourselves.  CRLs are
especially tricky.  Trusting a maintainer signature at the archive level
and verifying it for each package when it's downloaded seems like a good
compromise for Emacs.

Ted

Re: ELPA security

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > I'd rather not build a certificate infrastructure ourselves.

I have no problem with that.

 > CRLs are especially tricky.  Trusting a maintainer signature at the
 > archive level and verifying it for each package when it's
 > downloaded seems like a good compromise for Emacs.

Then there's no need for a signed or unsigned list.

Re: ELPA security

[Ted Zlatanov]

On Tue, 18 Jun 2013 00:54:32 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Ted Zlatanov writes:
>> CRLs are especially tricky.  Trusting a maintainer signature at the
>> archive level and verifying it for each package when it's
>> downloaded seems like a good compromise for Emacs.

SJT> Then there's no need for a signed or unsigned list.

We need a list of exceptions from the "normal" and we need to decide if
signed or unsigned is "normal."

Ted

Re: ELPA security

[Stefan Monnier]

>> And maybe automatically eliminate an archive from that "not signed"
>> list if we ever find a signature in it.

> If this is about security rather than adding to your BrightShinyThings
> collection, you should have a signed-and-verified-and-checked-for-
> expired-or-revoked-on-$DATE list, and eliminate any packages from the
> list if they fail any of the hyphenated conditions.

We're really far from that.  The config under discussion is one that
indicates whether it's normal that the archive (the whole archive, not
a specific package) doesn't have signatures.


        Stefan

Re: ELPA security

[Ted Zlatanov]

On Sun, 16 Jun 2013 19:12:02 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> * add `package-signed-archives', a list of logical archive names with
>> default '("gnu").  Add `package-archive-signed-p' to check it.

SM> I'd opt for the opposite, i.e. list the archives that aren't signed.

SM> And maybe automatically eliminate an archive from that "not signed"
SM> list if we ever find a signature in it.

How about basing the decision on the existence of
etc/elpa/ARCHIVE-NAME.signed which can then tell us more about the way
the archive is signed without customizing ELisp code?  Like a Yum or APT
repository description you can drop in?  I could use it to automatically
augment `package-archives' if you think that's useful, so it becomes
very manageable for a whole site.

>> If you're OK with the code changes I'll get them working and start
>> implementing `package--verify-signature'.

SM> Go ahead,

OK, thanks for the review.

Ted

Re: ELPA security

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 2309 bytes --]

On Mon, 17 Jun 2013 03:20:41 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Sun, 16 Jun 2013 19:12:02 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
>>> * add `package-signed-archives', a list of logical archive names with
>>> default '("gnu").  Add `package-archive-signed-p' to check it.

SM> I'd opt for the opposite, i.e. list the archives that aren't signed.

SM> And maybe automatically eliminate an archive from that "not signed"
SM> list if we ever find a signature in it.

TZ> How about basing the decision on the existence of
TZ> etc/elpa/ARCHIVE-NAME.signed which can then tell us more about the way
TZ> the archive is signed without customizing ELisp code?  Like a Yum or APT
TZ> repository description you can drop in?  I could use it to automatically
TZ> augment `package-archives' if you think that's useful, so it becomes
TZ> very manageable for a whole site.

I haven't made this change.  I'll wait for some opinions.  I think the
".signed" extension is unnecessary.

etc/elpa/ARCHIVE-NAME can contain the actual armored GPG signature but
it can also have more metadata about the archive.  So the format could
be:

url=ARCHIVE-URL
other-metadata=whatever
then-a-new-line=ends metadata

SIGNATURE

and if SIGNATURE is missing, the archive is not signed.

This would augment `package-archives' on startup and on demand.

>>> If you're OK with the code changes I'll get them working and start
>>> implementing `package--verify-signature'.

SM> Go ahead,

The attached patch implements `package--verify-signature' and
`package--create-detached-signature' using EPG functions, against the
currently-loaded GPG keys.  Otherwise it's the same as before.
`package--create-detached-signature' is pretty easy from the command
line as well (see http://gnupg.org/gph/en/manual/x135.html).

From the command line, exporting and importing public GPG keys is easy,
e.g. "gpg --armor --output /tmp/tzz.gpg --export tzz@lifelogs.com".  So
the workflow is not difficult.

Using EPG functions, however, I could not figure out how to verify with
an external public GPG key.  I don't see that option with any of the
context functions.  Perhaps someone knows?  Without that option, the
user has to explicitly load the maintainer's public GPG key, which is
very impractical around package.el.

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: package-archive-signed-2.patch --]
[-- Type: text/x-patch, Size: 8687 bytes --]

=== modified file 'lisp/emacs-lisp/package.el'
--- lisp/emacs-lisp/package.el	2013-06-18 01:26:47 +0000
+++ lisp/emacs-lisp/package.el	2013-06-19 04:42:45 +0000
@@ -164,6 +164,7 @@
 
 (eval-when-compile (require 'cl-lib))
 
+(require 'epg nil t)
 (require 'tabulated-list)
 
 (defgroup package nil
@@ -229,6 +230,16 @@
   :group 'package
   :version "24.1")
 
+;; TODO: maybe base this on the existence of etc/elpa/ARCHIVE.gpgsig
+(defcustom package-signed-archives '("gnu")
+  "An list of archives whose contents are signed.
+
+Signed archives trigger verification of each package's contents."
+  :type '(list string :tag "Archive name")
+  :risky t
+  :group 'package
+  :version "24.4")
+
 (defcustom package-pinned-packages nil
   "An alist of packages that are pinned to a specific archive
 
@@ -700,20 +711,39 @@
       (package--make-autoloads-and-compile name pkg-dir)
       pkg-dir)))
 
-(defmacro package--with-work-buffer (location file &rest body)
-  "Run BODY in a buffer containing the contents of FILE at LOCATION.
-LOCATION is the base location of a package archive, and should be
-one of the URLs (or file names) specified in `package-archives'.
+(defun package-archive-signed-p (archive)
+  "Returns whether ARCHIVE is signed.
+ARCHIVE is a package archive in the form (NAME . LOCATION) and should
+be specified in `package-archives'."
+  (member (car archive) package-signed-archives))
+
+(defmacro package--with-work-buffer (archive file &rest body)
+  "Run BODY in a buffer containing the contents of FILE at ARCHIVE.
+ARCHIVE is a package archive in the form (NAME . LOCATION) and should
+be specified in `package-archives'.
 FILE is the name of a file relative to that base location.
 
-This macro retrieves FILE from LOCATION into a temporary buffer,
-and evaluates BODY while that buffer is current.  This work
-buffer is killed afterwards.  Return the last value in BODY."
-  `(let* ((http (string-match "\\`https?:" ,location))
+This macro retrieves FILE from ARCHIVE into a temporary buffer,
+checks its signature if the ARCHIVE is defined to be signed by
+`package-signed-archives', and evaluates BODY while that buffer
+is current.  This work buffer is killed afterwards.  Return the
+last value in BODY."
+  `(let* ((archive-name (car ,archive))
+          (location (cdr ,archive))
+          (sign-file (concat ,file ".gpgsig"))
+          (http (string-match "\\`https?:" location))
+          (sign (when (package-archive-signed-p archive)
+                  (concat location sign-file)))
 	  (buffer
 	   (if http
-	       (url-retrieve-synchronously (concat ,location ,file))
-	     (generate-new-buffer "*package work buffer*"))))
+	       (url-retrieve-synchronously url)
+	     (generate-new-buffer "*package work buffer*")))
+          (sign-buffer (when sign
+                         (if http
+                             ;; Retrieve the signature file too.
+                             (url-retrieve-synchronously
+                              (concat location sign-file))
+                           (generate-new-buffer "*package sign buffer*")))))
      (prog1
 	 (with-current-buffer buffer
 	   (if http
@@ -721,12 +751,49 @@
 		      (re-search-forward "^$" nil 'move)
 		      (forward-char)
 		      (delete-region (point-min) (point)))
-	     (unless (file-name-absolute-p ,location)
+	     (unless (file-name-absolute-p location)
 	       (error "Archive location %s is not an absolute file name"
-		      ,location))
-	     (insert-file-contents (expand-file-name ,file ,location)))
+		      location))
+	     (insert-file-contents (expand-file-name ,file location)))
+           (when sign-buffer
+             (with-current-buffer sign-buffer
+               (if http
+                   (progn (package-handle-response)
+                          (re-search-forward "^$" nil 'move)
+                          (forward-char)
+                          (delete-region (point-min) (point)))
+                 ;; No need to check the location again like we did above.
+                 (insert-file-contents (expand-file-name sign-file location)))
+               (unless (package--verify-signature archive sign-buffer buffer)
+                 (let ((q (format "Can't verify .gpgsig for %s"
+                                  (concat location ,file))))
+                   (unless (y-or-n-p (concat q "; continue? (y/n)"))
+                     (error q))))))
 	   ,@body)
-       (kill-buffer buffer))))
+       (kill-buffer buffer)
+       (when sign-buffer
+         (kill-buffer sign-buffer)))))
+
+(defun package--verify-signature (archive sign-buffer buffer)
+  "Verify SIGN-BUFFER signs BUFFER correctly for ARCHIVE.
+
+The signing key may be specifically indicated later, but right
+now we let EPG determine which one to use."
+  (let ((ctx (epg-make-context))
+        (signature (with-current-buffer sign-buffer
+                     (buffer-string)))
+        (data (with-current-buffer buffer
+                     (buffer-string))))
+    (epg-verify-string ctx signature data)))
+
+(defun package--create-detached-signature (file)
+  "Create FILE.gpgsig for FILE using EPG."
+  (unless (featurep 'epg)
+    (error "Sorry, EPG could not be loaded."))
+  (let ((sig (concat file ".gpgsig"))
+        (ctx (epg-make-context)))
+    (epg-sign-file ctx file sig 'detached)
+    sig))
 
 (defun package-handle-response ()
   "Handle the response from a `url-retrieve-synchronously' call.
@@ -743,16 +810,16 @@
 
 (defun package-download-single (name version desc requires)
   "Download and install a single-file package."
-  (let ((location (package-archive-base name))
+  (let ((archive (package-archive-for name))
 	(file (concat (symbol-name name) "-" version ".el")))
-    (package--with-work-buffer location file
+    (package--with-work-buffer archive file
       (package-unpack-single name version desc requires))))
 
 (defun package-download-tar (name version)
   "Download and install a tar package."
-  (let ((location (package-archive-base name))
+  (let ((archive (package-archive-for name))
 	(file (concat (symbol-name name) "-" version ".tar")))
-    (package--with-work-buffer location file
+    (package--with-work-buffer archive file
       (package-unpack name version))))
 
 (defvar package--initialized nil)
@@ -876,6 +943,7 @@
 (defun package--add-to-archive-contents (package archive)
   "Add the PACKAGE from the given ARCHIVE if necessary.
 PACKAGE should have the form (NAME . PACKAGE--AC-DESC).
+
 Also, add the originating archive to the `package-desc' structure."
   (let* ((name (car package))
          (version (package--ac-desc-version (cdr package)))
@@ -1099,10 +1167,10 @@
       (error "Package `%s' is a system package, not deleting"
 	     (package-desc-full-name pkg-desc)))))
 
-(defun package-archive-base (name)
+(defun package-archive-for (name)
   "Return the archive containing the package NAME."
   (let ((desc (cdr (assq (intern-soft name) package-archive-contents))))
-    (cdr (assoc (package-desc-archive desc) package-archives))))
+    (assoc (package-desc-archive desc) package-archives)))
 
 (defun package--download-one-archive (archive file)
   "Retrieve an archive file FILE from ARCHIVE, and cache it.
@@ -1111,7 +1179,7 @@
 \"archives/NAME/archive-contents\" in `package-user-dir'."
   (let* ((dir (expand-file-name (format "archives/%s" (car archive))
                                 package-user-dir)))
-    (package--with-work-buffer (cdr archive) file
+    (package--with-work-buffer archive file
       ;; Read the retrieved buffer to make sure it is valid (e.g. it
       ;; may fetch a URL redirect page).
       (when (listp (read buffer))
@@ -1234,7 +1302,11 @@
                                    'font-lock-face 'font-lock-builtin-face)
 		       "  Alternate version available")
 	     (insert "Available"))
-	   (insert " from " archive)
+	   (insert " from " (if (package-archive-signed-p
+                                 (assoc archive package-archives))
+                                "signed"
+                              "unsigned")
+                   " " archive)
 	   (insert " -- ")
 	   (let ((button-text (if (display-graphic-p) "Install" "[Install]"))
 		 (button-face (if (display-graphic-p)
@@ -1292,7 +1364,7 @@
 	;; For elpa packages, try downloading the commentary.  If that
 	;; fails, try an existing readme file in `package-user-dir'.
 	(cond ((condition-case nil
-		   (package--with-work-buffer (package-archive-base package)
+		   (package--with-work-buffer (package-archive-for package)
 					      (concat package-name "-readme.txt")
 		     (setq buffer-file-name
 			   (expand-file-name readme package-user-dir))

Re: ELPA security

[Stefan Monnier]

> +;; TODO: maybe base this on the existence of etc/elpa/ARCHIVE.gpgsig
> +(defcustom package-signed-archives '("gnu")

I think the assumption should be that real-soon-now all archives will be
signed, so we should only need a short list of exceptions.


        Stefan

Re: ELPA security

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 1840 bytes --]

On Wed, 19 Jun 2013 01:02:16 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> etc/elpa/ARCHIVE-NAME can contain the actual armored GPG signature but
TZ> it can also have more metadata about the archive.  So the format could
TZ> be:

TZ> url=ARCHIVE-URL
TZ> other-metadata=whatever
TZ> then-a-new-line=ends metadata

TZ> SIGNATURE

TZ> and if SIGNATURE is missing, the archive is not signed.

TZ> This would augment `package-archives' on startup and on demand.

Any opinions here?

For now I'm using the old format.  Archives are signed by default as
requested.  I've rebased the patch against the changes to package.el.

If we push this change, it will break all users against all ELPA
archives until all their files are signed (they will have to answer 'y'
every time files are retrieved).  I think that's pretty radical.  Maybe
we should coordinate the change with all the repo maintainers?  Or come
back to my original setup, where archives are unsigned by default?

Finally, for easier testing I think we should put a fake archive with 1
package in test/elpa/packages.  If you agree I'll push that as a
separate commit, including a small self-contained test.  I didn't do it
because Stefan mentioned Daniel Hackney's changes included some testing
code and I didn't want to confuse matters.

TZ> Using EPG functions, however, I could not figure out how to verify with
TZ> an external public GPG key.  I don't see that option with any of the
TZ> context functions.  Perhaps someone knows?  Without that option, the
TZ> user has to explicitly load the maintainer's public GPG key, which is
TZ> very impractical around package.el.

I need to know the above to make the patch usable, so I won't commit for
now.

Also the signature has to be named .gpgsig because the extension .gpg
(the default) makes EPA/EPG attempt to decrypt it.

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: package-archive-signed-3.patch --]
[-- Type: text/x-patch, Size: 8204 bytes --]

=== modified file 'lisp/emacs-lisp/package.el'
--- lisp/emacs-lisp/package.el	2013-06-22 20:09:19 +0000
+++ lisp/emacs-lisp/package.el	2013-06-23 11:44:08 +0000
@@ -164,6 +164,7 @@
 
 (eval-when-compile (require 'cl-lib))
 
+(require 'epg nil t)
 (require 'tabulated-list)
 
 (defgroup package nil
@@ -228,6 +229,16 @@
   :group 'package
   :version "24.1")
 
+;; TODO: maybe base this on the existence of etc/elpa/ARCHIVE.gpgsig
+(defcustom package-unsigned-archives nil
+  "An list of archives whose contents are not signed.
+
+Signed archives trigger verification of each package's contents."
+  :type '(list string :tag "Archive name")
+  :risky t
+  :group 'package
+  :version "24.4")
+
 (defcustom package-pinned-packages nil
   "An alist of packages that are pinned to a specific archive
 
@@ -692,21 +703,39 @@
   (let ((buffer-file-coding-system 'no-conversion))
     (write-region (point-min) (point-max) file-name)))
 
-(defmacro package--with-work-buffer (location file &rest body)
-  "Run BODY in a buffer containing the contents of FILE at LOCATION.
-LOCATION is the base location of a package archive, and should be
-one of the URLs (or file names) specified in `package-archives'.
-FILE is the name of a file relative to that base location.
-
-This macro retrieves FILE from LOCATION into a temporary buffer,
+(defun package-archive-signed-p (archive)
+  "Returns whether ARCHIVE is signed.
+ARCHIVE is specified in `package-archives'."
+  (not (member (car archive) package-unsigned-archives)))
+
+(defmacro package--with-work-buffer (archive file &rest body)
+  "Run BODY in a buffer containing the contents of FILE from ARCHIVE.
+ARCHIVE is a package archive specified in `package-archives'.
+FILE is the name of a file relative to that archive's location.
+
+This macro retrieves FILE from ARCHIVE into a temporary buffer,
 and evaluates BODY while that buffer is current.  This work
-buffer is killed afterwards.  Return the last value in BODY."
+buffer is killed afterwards.  Return the last value in BODY.
+
+If ARCHIVE is not in `package-unsigned-archives', FILE.gpg is
+verified against FILE."
   (declare (indent 2) (debug t))
-  `(let* ((http (string-match "\\`https?:" ,location))
+  `(let* ((archive-name (car ,archive))
+	  (location (cdr ,archive))
+	  (sign-file (concat ,file ".gpgsig"))
+	  (http (string-match "\\`https?:" location))
+	  (sign (when (package-archive-signed-p ,archive)
+		  (concat location sign-file)))
 	  (buffer
 	   (if http
-	       (url-retrieve-synchronously (concat ,location ,file))
-	     (generate-new-buffer "*package work buffer*"))))
+	       (url-retrieve-synchronously (concat location ,file))
+	     (generate-new-buffer "*package work buffer*")))
+	  (sign-buffer (when sign
+			 (if http
+			     ;; Retrieve the signature file too.
+			     (url-retrieve-synchronously
+			      (concat location sign-file))
+			   (generate-new-buffer "*package sign buffer*")))))
      (prog1
 	 (with-current-buffer buffer
 	   (if http
@@ -714,12 +743,49 @@
 		      (re-search-forward "^$" nil 'move)
 		      (forward-char)
 		      (delete-region (point-min) (point)))
-	     (unless (file-name-absolute-p ,location)
+	     (unless (file-name-absolute-p location)
 	       (error "Archive location %s is not an absolute file name"
-		      ,location))
-	     (insert-file-contents (expand-file-name ,file ,location)))
+		      location))
+	     (insert-file-contents (expand-file-name ,file location)))
+           (when sign-buffer
+             (with-current-buffer sign-buffer
+               (if http
+                   (progn (package-handle-response)
+                          (re-search-forward "^$" nil 'move)
+                          (forward-char)
+                          (delete-region (point-min) (point)))
+                 ;; No need to check the location again like we did above.
+                 (insert-file-contents (expand-file-name sign-file location)))
+               (unless (package--verify-signature archive sign-buffer buffer)
+                 (let ((q (format "Can't verify .gpgsig for %s"
+                                  (concat location ,file))))
+                   (unless (y-or-n-p (concat q "; continue? (y/n)"))
+                     (error q))))))
 	   ,@body)
-       (kill-buffer buffer))))
+       (kill-buffer buffer)
+       (when sign-buffer
+         (kill-buffer sign-buffer)))))
+
+(defun package--verify-signature (archive sign-buffer buffer)
+  "Verify SIGN-BUFFER signs BUFFER correctly for ARCHIVE.
+
+The signing key may be specifically indicated later, but right
+now we let EPG determine which one to use."
+  (let ((ctx (epg-make-context))
+        (signature (with-current-buffer sign-buffer
+                     (buffer-string)))
+        (data (with-current-buffer buffer
+                     (buffer-string))))
+    (epg-verify-string ctx signature data)))
+
+(defun package--create-detached-signature (file)
+  "Create FILE.gpgsig for FILE using EPG."
+  (unless (featurep 'epg)
+    (error "Sorry, EPG could not be loaded."))
+  (let ((sig (concat file ".gpgsig"))
+        (ctx (epg-make-context)))
+    (epg-sign-file ctx file sig 'detached)
+    sig))
 
 (defun package-handle-response ()
   "Handle the response from a `url-retrieve-synchronously' call.
@@ -736,10 +802,9 @@
 
 (defun package-install-from-archive (pkg-desc)
   "Download and install a tar package."
-  (let ((location (package-archive-base pkg-desc))
-	(file (concat (package-desc-full-name pkg-desc)
+  (let ((file (concat (package-desc-full-name pkg-desc)
                       (package-desc-suffix pkg-desc))))
-    (package--with-work-buffer location file
+    (package--with-work-buffer (package-archive-for pkg-desc) file
       (package-unpack pkg-desc))))
 
 (defvar package--initialized nil)
@@ -864,6 +929,7 @@
 (defun package--add-to-archive-contents (package archive)
   "Add the PACKAGE from the given ARCHIVE if necessary.
 PACKAGE should have the form (NAME . PACKAGE--AC-DESC).
+
 Also, add the originating archive to the `package-desc' structure."
   (let* ((name (car package))
          (version (package--ac-desc-version (cdr package)))
@@ -1054,8 +1120,12 @@
 	     (package-desc-full-name pkg-desc)))))
 
 (defun package-archive-base (desc)
-  "Return the archive containing the package NAME."
-  (cdr (assoc (package-desc-archive desc) package-archives)))
+  "Return the archive location containing the package DESC."
+  (cdr (package-archive-for desc)))
+
+(defun package-archive-for (desc)
+  "Return the archive containing the package DESC."
+  (assoc (package-desc-archive desc) package-archives))
 
 (defun package--download-one-archive (archive file)
   "Retrieve an archive file FILE from ARCHIVE, and cache it.
@@ -1064,7 +1134,7 @@
 \"archives/NAME/archive-contents\" in `package-user-dir'."
   (let* ((dir (expand-file-name (format "archives/%s" (car archive))
                                 package-user-dir)))
-    (package--with-work-buffer (cdr archive) file
+    (package--with-work-buffer archive file
       ;; Read the retrieved buffer to make sure it is valid (e.g. it
       ;; may fetch a URL redirect page).
       (when (listp (read buffer))
@@ -1187,7 +1257,11 @@
                                    'font-lock-face 'font-lock-builtin-face)
 		       "  Alternate version available")
 	     (insert "Available"))
-	   (insert " from " archive)
+	   (insert " from " (if (package-archive-signed-p
+                                 (assoc archive package-archives))
+                                "signed"
+                              "unsigned")
+                   " " archive)
 	   (insert " -- ")
 	   (let ((button-text (if (display-graphic-p) "Install" "[Install]"))
 		 (button-face (if (display-graphic-p)
@@ -1245,7 +1319,7 @@
 	;; For elpa packages, try downloading the commentary.  If that
 	;; fails, try an existing readme file in `package-user-dir'.
 	(cond ((condition-case nil
-		   (package--with-work-buffer (package-archive-base desc)
+		   (package--with-work-buffer (package-archive-for desc)
 					      (concat package-name "-readme.txt")
 		     (setq buffer-file-name
 			   (expand-file-name readme package-user-dir))

Re: ELPA security

[Stefan Monnier]

TZ> etc/elpa/ARCHIVE-NAME can contain the actual armored GPG signature but
TZ> it can also have more metadata about the archive.  So the format could
TZ> be:

TZ> url=ARCHIVE-URL
TZ> other-metadata=whatever
TZ> then-a-new-line=ends metadata

TZ> SIGNATURE

TZ> and if SIGNATURE is missing, the archive is not signed.

Hmm... I'm not sure I understand the issues here.  IIUC Debian
uses a GPG keyring.  What's the difference?Also, you talk about the
signature here, whereas I think "an archive has a key, each package has
a signature".

> For now I'm using the old format.  Archives are signed by default as
> requested.  I've rebased the patch against the changes to package.el.

I think the list of signed/unsigned archives should be managed
dynamically/automatically: if a signature is missing, ask the user if
she thinks it's normal, and if so, place the archive into a list of
"unsigned archives", so the question is not repeated.  But every time we
access the archive, we still try to get the a signature.  If we do find
a signature, then remove the archive from the "unsigned archives" list.

> Finally, for easier testing I think we should put a fake archive with 1
> package in test/elpa/packages.

Sure.

> I didn't do it because Stefan mentioned Daniel Hackney's changes
> included some testing code and I didn't want to confuse matters.

You could install Daniel's tests before adding your own.

TZ> Using EPG functions, however, I could not figure out how to verify with
TZ> an external public GPG key.  I don't see that option with any of the
TZ> context functions.  Perhaps someone knows?  Without that option, the
TZ> user has to explicitly load the maintainer's public GPG key, which is
TZ> very impractical around package.el.
> I need to know the above to make the patch usable, so I won't commit for
> now.

I don't understand the question, sadly.

> Also the signature has to be named .gpgsig because the extension .gpg
> (the default) makes EPA/EPG attempt to decrypt it.

".gpgsig" is fine, as is ".sig".  Are you talking about the packages's
signatures, or about some ~/.emacs.d/elpa/archive/key.gpgsig?


        Stefan

Re: ELPA security

[Ted Zlatanov]

On Sun, 23 Jun 2013 12:41:32 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

TZ> etc/elpa/ARCHIVE-NAME can contain the actual armored GPG signature but
TZ> it can also have more metadata about the archive.  So the format could
TZ> be:

TZ> url=ARCHIVE-URL
TZ> other-metadata=whatever
TZ> then-a-new-line=ends metadata

TZ> SIGNATURE

TZ> and if SIGNATURE is missing, the archive is not signed.

SM> Hmm... I'm not sure I understand the issues here.  IIUC Debian
SM> uses a GPG keyring.  What's the difference?Also, you talk about the
SM> signature here, whereas I think "an archive has a key, each package has
SM> a signature".

Sorry, I've been careless with the terminology.

Each file P has a detached signature P.gpgsig.

Each archive A has a public key A.key.

To verify that A signed P, the package.el user must import A.key into a
GPG keyring (either the default or, as I was suggesting to Daiki Ueno, a
special "elpa" keyring).  A GPG keyring is a storage space for keys,
essentially.

I propose `etc/elpa/A' to contain some metadata about the archive.  The
existence of that file should be noted in `package-archives-found' and
should be the only way to specify a signed archive.  The format of
`etc/elpa/A' would be:

url=ARCHIVE-URL
other-metadata=whatever
then-a-new-line=ends metadata

[after a final newline, append the contents of A.key]

This would let the user or site admin easily install or remove ELPA
archives without modifying Emacs Lisp code.  `package-archives' would
remain, but only as a way to specify unsigned archives.

>> For now I'm using the old format.  Archives are signed by default as
>> requested.  I've rebased the patch against the changes to package.el.

SM> I think the list of signed/unsigned archives should be managed
SM> dynamically/automatically: if a signature is missing, ask the user if
SM> she thinks it's normal, and if so, place the archive into a list of
SM> "unsigned archives", so the question is not repeated.  But every time we
SM> access the archive, we still try to get the a signature.  If we do find
SM> a signature, then remove the archive from the "unsigned archives" list.

I'd rather go with the `etc/elpa/A' scheme above.  Can you please
consider it?

>> Also the signature has to be named .gpgsig because the extension .gpg
>> (the default) makes EPA/EPG attempt to decrypt it.

SM> ".gpgsig" is fine, as is ".sig".  Are you talking about the packages's
SM> signatures, or about some ~/.emacs.d/elpa/archive/key.gpgsig?

P.gpgsig for every file P.

Ted

Re: ELPA security

[Nic Ferrier]

Ted Zlatanov <tzz@lifelogs.com> writes:

> SM> I think the list of signed/unsigned archives should be managed
> SM> dynamically/automatically: if a signature is missing, ask the user if
> SM> she thinks it's normal, and if so, place the archive into a list of
> SM> "unsigned archives", so the question is not repeated.  But every time we
> SM> access the archive, we still try to get the a signature.  If we do find
> SM> a signature, then remove the archive from the "unsigned archives" list.
>
> I'd rather go with the `etc/elpa/A' scheme above.  Can you please
> consider it?

FWIW I run marmalade-repo and I prefer Stefan's suggestion.



Nic Ferrier

Re: ELPA security

[Stefan Monnier]

> Sorry, I've been careless with the terminology.

Oh, OK, then I understand, thanks.

> This would let the user or site admin easily install or remove ELPA
> archives without modifying Emacs Lisp code.  `package-archives' would
> remain, but only as a way to specify unsigned archives.

I'd prefer to keep using Elisp for customization, and to handle the keys
in a more automated way.

> I'd rather go with the `etc/elpa/A' scheme above.  Can you please
> consider it?

I really want it to be as seamless as possible for the user, so the user
should not have to setup any key infrastructure herself.

SM> ".gpgsig" is fine, as is ".sig".  Are you talking about the packages's
SM> signatures, or about some ~/.emacs.d/elpa/archive/key.gpgsig?
> P.gpgsig for every file P.

As far as possible, I'd recommend to stick with "*ring.gpg" for the
keyrings, but if it's not possible, it's OK.  Also this should be mostly
transparent to the user since she shouldn't have to manage those files
by hand, so the name isn't that important.


        Stefan

Re: ELPA security

[Daiki Ueno]

Ted Zlatanov <tzz@lifelogs.com> writes:

> TZ> Using EPG functions, however, I could not figure out how to verify with
> TZ> an external public GPG key.  I don't see that option with any of the
> TZ> context functions.  Perhaps someone knows?  Without that option, the
> TZ> user has to explicitly load the maintainer's public GPG key, which is
> TZ> very impractical around package.el.

I guess you probably mean something like debian-keyring by "external
public GPG key", right?  If so, you can use an alternative ~/.gnupg
directory (e.g. ~/.emacs.d/elpa/gnupg/) set through
epg-gpg-home-directory, and import the keyring with
epg-import-keys-from-file on M-x package-list-packages, etc.

I'm not following the discussion nor the code, sorry if I'm missing the
point.

Regards,
-- 
Daiki Ueno

Re: ELPA security

[Ted Zlatanov]

On Mon, 24 Jun 2013 12:44:47 +0900 Daiki Ueno <ueno@gnu.org> wrote: 

DU> Ted Zlatanov <tzz@lifelogs.com> writes:
TZ> Using EPG functions, however, I could not figure out how to verify with
TZ> an external public GPG key.  I don't see that option with any of the
TZ> context functions.  Perhaps someone knows?  Without that option, the
TZ> user has to explicitly load the maintainer's public GPG key, which is
TZ> very impractical around package.el.

DU> I guess you probably mean something like debian-keyring by "external
DU> public GPG key", right?  If so, you can use an alternative ~/.gnupg
DU> directory (e.g. ~/.emacs.d/elpa/gnupg/) set through
DU> epg-gpg-home-directory, and import the keyring with
DU> epg-import-keys-from-file on M-x package-list-packages, etc.

Would it be better to follow the steps here than to have a separate
directory?  Or maybe we should do a separate key ring AND an alternative
directory?

http://stackoverflow.com/questions/9073288/decrypt-encrypted-gpg-file-using-external-secret-key

e.g.

gpg --import --no-default-keyring --secret-keyring elpa maintainer.key
gpg --verify file.gpgsig --secret-keyring elpa file
rm ~/.gnupg/elpa.gpg

DU> I'm not following the discussion nor the code, sorry if I'm missing the
DU> point.

Your help is appreciated in any way, of course, but this discussion in
particular will make EPG a fundamental tool for most ELPA interactions,
so your review would be most welcome.

Ted

Re: ELPA security

[Daiki Ueno]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Would it be better to follow the steps here than to have a separate
> directory?  Or maybe we should do a separate key ring AND an alternative
> directory?

I think using the separate directory only is a bit better here, because
of flexibility:

1. users could have separate preference for elpa keys, using gpg.conf or
   trustdb.gpg in the directory

2. package.el could display which keys are changed/imported in the ring,
   when the ring (on the web) is changed

It might look overkill to have a separate directory, but actually GPGME,
on which epg.el is modelled, only provides the directory option.  Also
some tools follow this way (e.g. caff in Debian signing-party package).

Regards,
-- 
Daiki Ueno