[Catalog-sig] RubyGems Threat Model and Requirements

[Nick Coghlan]

On Thu, Feb 14, 2013 at 6:46 PM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
> On 13 Feb, 2013, at 15:21, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>>
>> For now, though, we would probably start off with
>> release/target/timestamp roles sharing a key, all threshold values set
>> to 1, and just doing simple project based target delegation to user
>> keys. Given the existing GPG infrastructure, I'm also inclined to
>> stick with GPG based keys and work with the TUF folks to define that
>> format in their spec. We may also need to leave the protection against
>> replay attacks off by default, do to the problem with incorrect clocks
>> noted at the end of the TUF spec.
>
> On the other hand, AFAIK the GPG infrastructure of PyPI isn't used a lot and OpenSSL exposes PCKS#1 which means those can be used without adding new dependencies to CPython, and likely without installing new software on all unix-like systems (the openssl command-line tool is available on both osx and all linux boxes I checked).  For 3.4 the PCKS#1 support in openssl could be exposed through a new extension module.
>
> I don't have preferences either way,

I believe the main challenge in either case is Windows. For GPG, the
suggestion is for the pip folks to figure out a way to bundle GPG
(which has its own problems), but there's no current suggested Windows
approach for PCKS#1. I wonder if a way could be found to retrieve it
from CPython's bundled OpenSSL on Windows?

Currently, I expect we're going to have to rely on pip or distribute
to handle the signed upload side of things, since legacy distutils is
unlikely to be fully compatible with whatever new scheme we come up
with. *If* we can come up with an approach that integrates with the
legacy GPG signing capability in distutils, that would be a massive
point in favour of using GPG.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia