From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: emacs-devel@gnu.org
Subject: Re: package.el + DVCS for security and convenience
Date: Tue, 08 Jan 2013 11:20:16 +0900 [thread overview]
Message-ID: <87wqvoa00v.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <877gnpkq1u.fsf@lifelogs.com>
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
next prev parent reply other threads:[~2013-01-08 2:20 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-09 14:41 ELPA security George Kadianakis
2012-12-09 21:00 ` Nic Ferrier
2012-12-21 14:32 ` Ted Zlatanov
2012-12-21 22:12 ` Xue Fuqiao
2012-12-22 5:07 ` Bastien
2012-12-22 6:17 ` Xue Fuqiao
2012-12-22 12:34 ` Stephen J. Turnbull
2012-12-22 13:03 ` Bastien
2012-12-22 13:24 ` Bastien
2012-12-22 19:37 ` package.el + DVCS for security and convenience (was: ELPA security) Ted Zlatanov
2012-12-24 12:53 ` package.el + DVCS for security and convenience Nic Ferrier
2012-12-24 12:55 ` Bastien
2012-12-24 13:38 ` Ted Zlatanov
2012-12-24 13:39 ` Xue Fuqiao
2012-12-24 16:17 ` Stefan Monnier
2012-12-24 17:46 ` Ted Zlatanov
2012-12-25 1:03 ` Stephen J. Turnbull
2012-12-26 14:22 ` Ted Zlatanov
2012-12-27 3:06 ` Stephen J. Turnbull
2012-12-27 8:56 ` Xue Fuqiao
2012-12-31 11:18 ` Ted Zlatanov
2012-12-31 12:32 ` Stephen J. Turnbull
2012-12-31 13:50 ` Ted Zlatanov
2012-12-31 16:47 ` Stephen J. Turnbull
2012-12-31 21:41 ` Ted Zlatanov
2012-12-29 6:19 ` Stefan Monnier
2012-12-31 11:22 ` Ted Zlatanov
2013-01-03 16:41 ` Stefan Monnier
2013-01-04 16:05 ` Ted Zlatanov
2013-01-04 18:11 ` Stefan Monnier
2013-01-04 19:06 ` Ted Zlatanov
2013-01-05 3:25 ` Stephen J. Turnbull
2013-01-06 19:20 ` Ted Zlatanov
2013-01-07 2:03 ` Stephen J. Turnbull
2013-01-07 14:47 ` Ted Zlatanov
2013-01-08 1:44 ` Stephen J. Turnbull
2013-01-08 15:15 ` Ted Zlatanov
2013-01-08 17:53 ` Stephen J. Turnbull
2013-01-08 18:46 ` Ted Zlatanov
2013-01-08 21:20 ` Stefan Monnier
2013-01-09 2:37 ` Stephen J. Turnbull
2013-01-08 2:20 ` Stephen J. Turnbull [this message]
2013-01-08 14:05 ` Xue Fuqiao
2013-01-04 22:21 ` Xue Fuqiao
2012-12-31 20:06 ` Re:package.el + DVCS for security and convenience (was: ELPA security) Phil Hagelberg
2012-12-31 22:50 ` package.el + DVCS for security and convenience Ted Zlatanov
2012-12-22 16:20 ` ELPA security Stefan Monnier
2012-12-26 17:32 ` Paul Nathan
2012-12-31 11:50 ` Ted Zlatanov
2012-12-31 12:34 ` Stephen J. Turnbull
2012-12-31 13:39 ` Package signing infrastructure suggestion (was Re: ELPA security) Nic Ferrier
2012-12-31 22:32 ` Ted Zlatanov
2012-12-31 23:01 ` Xue Fuqiao
2012-12-31 19:48 ` ELPA security Tom Tromey
2012-12-31 19:57 ` Drew Adams
2012-12-31 22:19 ` Ted Zlatanov
2012-12-31 22:15 ` Ted Zlatanov
2013-01-05 16:46 ` Achim Gratz
2013-01-06 19:12 ` Ted Zlatanov
2013-01-07 5:32 ` Paul Nathan
2013-01-07 5:47 ` Jambunathan K
2013-01-07 5:53 ` Paul Nathan
2013-01-07 6:09 ` Jambunathan K
2013-01-07 6:20 ` Paul Nathan
2013-01-07 7:12 ` Stephen J. Turnbull
2013-01-07 7:18 ` chad
2013-01-07 14:34 ` Ted Zlatanov
2013-01-07 6:57 ` Stephen J. Turnbull
2013-01-07 14:35 ` Ted Zlatanov
2013-01-07 15:01 ` Ted Zlatanov
2013-01-08 3:07 ` Stefan Monnier
2013-01-08 14:47 ` Ted Zlatanov
2013-01-08 16:57 ` Stefan Monnier
2013-01-08 17:30 ` Ted Zlatanov
2013-01-08 20:50 ` Stefan Monnier
2013-01-08 21:30 ` Ted Zlatanov
2013-01-08 22:46 ` Stefan Monnier
2013-01-08 23:30 ` Ted Zlatanov
2013-03-12 18:29 ` Ted Zlatanov
2013-01-08 17:00 ` Stefan Monnier
2013-01-08 17:59 ` Achim Gratz
2013-01-08 18:37 ` Ted Zlatanov
2013-01-08 20:59 ` Stefan Monnier
2013-06-16 11:18 ` Ted Zlatanov
2013-06-16 23:12 ` Stefan Monnier
2013-06-17 1:56 ` Stephen J. Turnbull
2013-06-17 7:23 ` Ted Zlatanov
2013-06-17 15:54 ` Stephen J. Turnbull
2013-06-28 15:34 ` Ted Zlatanov
2013-06-17 14:34 ` Stefan Monnier
2013-06-17 7:20 ` Ted Zlatanov
2013-06-19 5:02 ` Ted Zlatanov
2013-06-19 12:38 ` Stefan Monnier
2013-06-23 11:58 ` Ted Zlatanov
2013-06-23 16:41 ` Stefan Monnier
2013-06-28 15:47 ` Ted Zlatanov
2013-06-28 16:28 ` Nic Ferrier
2013-06-28 22:49 ` Stefan Monnier
2013-06-24 3:44 ` Daiki Ueno
2013-06-28 15:32 ` Ted Zlatanov
2013-06-28 16:15 ` Daiki Ueno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wqvoa00v.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).