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" <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