[Python-Dev] [Infrastructure] Snakebite build slaves and developer SSH/GPG public keys

[Trent Nelson]

On Thu, Aug 23, 2012 at 12:24:33AM -0700, "Martin v. Löwis" wrote:
> On 23.08.2012 02:43, R. David Murray wrote:
> > On Thu, 23 Aug 2012 10:53:34 +1200, Noah Kantrowitz <noah at coderanger.net> wrote:
> >> For everyone with a record in the Chef server (read: everyone with SSH access to any of the PSF servers at OSL) I can easily give you automated access. Whats the easiest format? I can give you a Python script that will spit out files or JSON or more or less whatever else you want.
> > 
> > That isn't going to be the right set of keys for Trent's purposes
> > (though it is likely to be a subset).  The keyfile we use for the hg
> > repository is.
> 
> ... for which it would be easiest if we give Trent access to the
> repository storing these keys.
>
> I'm a bit hesitant to put "public" keys into the real world-wide
> public, given the past history of easily-breakable public keys.
> For PGP, this is less of a concern than for SSH, since the threats
> are smaller (plus users where aware that they might have to publish
> the key when they created it).

    Hmmm.  So, from my perspective, I have the following goals:

        - Commit access to ssh://hg.python.org implies access to
          `ssh cpython at snakebite` via the exact same key.

        - No extra administrative overhead/burden on infrastructure@
          (with regards to ssh key management, i.e. an entry in .ssh/
           authorized_keys should be sufficient for implicit snakebite
           access).

    Factoring in your (valid) security concerns, here's my altered
    proposal:

        - Let's just call the repo 'snakebite', and have it accessible
          only to ssh committers, no public http access.  Calling it
          something generic like 'keys' may invite phantom requirements
          like being able to store multiple identities/keys etc.  I
          don't need that for snakebite; one ssh key and one optional
          gpg key is all I want :-)

        - Same repo layout as before -- GPG keys not required unless
          I need to send you something encrypted via e-mail (RDP is
          the only use case I can think of for this).

        - I'll whip up the glue to take our current .ssh/authz and
          dump it into the 'snakebite' repo.  We can refine that process
          down the track (with automation and whatnot).

    If there are no objections I can take this offline with inf at .


        Trent.