[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: package.el + DVCS for security and convenience
From: |
Stephen J. Turnbull |
Subject: |
Re: package.el + DVCS for security and convenience |
Date: |
Tue, 08 Jan 2013 11:20:16 +0900 |
Ted Zlatanov writes:
> On Mon, 07 Jan 2013 11:03:07 +0900 "Stephen J. Turnbull" <address@hidden>
> 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, (continued)
- Re: package.el + DVCS for security and convenience, Stephen J. Turnbull, 2013/01/04
- Re: package.el + DVCS for security and convenience, Ted Zlatanov, 2013/01/06
- Re: package.el + DVCS for security and convenience, Stephen J. Turnbull, 2013/01/06
- Re: package.el + DVCS for security and convenience, Ted Zlatanov, 2013/01/07
- Re: package.el + DVCS for security and convenience, Stephen J. Turnbull, 2013/01/07
- Re: package.el + DVCS for security and convenience, Ted Zlatanov, 2013/01/08
- Re: package.el + DVCS for security and convenience, Stephen J. Turnbull, 2013/01/08
- Re: package.el + DVCS for security and convenience, Ted Zlatanov, 2013/01/08
- Re: package.el + DVCS for security and convenience, Stefan Monnier, 2013/01/08
- Re: package.el + DVCS for security and convenience, Stephen J. Turnbull, 2013/01/08
- Re: package.el + DVCS for security and convenience,
Stephen J. Turnbull <=
- Re: package.el + DVCS for security and convenience, Xue Fuqiao, 2013/01/08
Re: package.el + DVCS for security and convenience, Xue Fuqiao, 2013/01/04