security projects thoughts

[Bayard Bell]

On 19 Apr 2011, at 14:12, Rainer Müller wrote:

> On 04/18/2011 04:04 PM, Jeff Johnson wrote:
>> 
>> On Apr 18, 2011, at 9:40 AM, Arno Hautala wrote:
>> 
>>> On Mon, Apr 18, 2011 at 06:12, Bayard Bell
>>> <buffer.g.overflow at googlemail.com> wrote:
>>>> 
>>>> I've read back on the threads from March about binary packaging and
>>>> appreciate better what constraints were accepted to simplify deployment. The
>>>> signed Macports releases in distfiles that Anders pointed me to is signed
>>>> with GPG. Given that we're talking about developer tools rather than
>>>> packaging, is it reasonable to add this to the base requirements for
>>>> macports? Are people fine with the idea of using PGP with macports and
>>>> openssl with the packaging system?
>>> 
>>> I'm all for more GPG adoption, but it might be a good idea to be
>>> consistent and stick with OpenSSL.
>>> 
>> 
>> These are opinions only, without any supplied reason to prefer OpenPGP
>> over OpenSSL. DOes DSA from OpenSSL taste better to you somehow than
>> OpenPGP? Perhaps the random big numbers are "fresher" if wrapped in
>> OpenSSL than OpenPGP?
> 
> OpenSSL with .pem wasn't choosen for technical but pragmatical reasons.
> Mac OS X does not ship with any PGP implementation while OpenSSL is part
> of the base install.
> 
> Releases have been signed by our own GPG keys but without any master key
> to verify the signing key. All we did prove there was that a developer
> signed this binary and other people had signed his key to prove the
> developer exists as a human being ;-)

So, let's take packaging and porting as different problem domains and try to express this as a threat model. With packaging, you want to make sure people are only getting their sausage from a known factory. Furthermore, the preference is already to use OpenSSL to verify that the package came from that factory, although Jeff suggests a non-PKI solution using notarised timestamps. Are there further scenarios to this that should be considered (at least as a threat modelling question), such as compromise of the factory (someone may well break in, so how would you pick up the pieces from such an incident)?

As far as porting, what we're talking seems to be a number of separate things: preventing porters from being compromised, both for their own protection and to reduce downstream risk. The solution constraints may also be different from that of packaging: in order to get individual accountability in moving porting material, adding a requirement like GPG may be a more reasonable compromise, rather than limiting yourself to elements of the base build, as you'd do for packaging. What are the concrete elements of that that might need to be addressed? Porter leaves the project (not sure that, with a loose FOSS collective that that's clear, except in the extraordinary case of a vitriolic falling out)? Porter finds out his development system's been compromised, so the minimum precaution is to stop taking updates until further notice?

Following Jeff's comments, if you've got an automated build system that's providing a factory signature for consumers, what measures are appropriate looking the other direction in the submission system? Presumably this would be the same thing used generally in the port tools, as distinct from the packaging system. And speaking of the porter side of things, presumably what you're trying to do is signature checking on update delivery, rather than when a Portfile is being consumed? We're treating the update mechanism as what's under threat, so does anyone see some really serious risks with local tampering that require signature-type controls (as opposed to something simpler, like ownership and permissions checks)?

> Rainer
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1515 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110419/07e58586/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 841 bytes
Desc: This is a digitally signed message part
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110419/07e58586/attachment-0001.bin>