security projects thoughts

Bayard Bell buffer.g.overflow at googlemail.com
Mon Apr 18 10:02:49 PDT 2011


On 18 Apr 2011, at 17:45, Jeff Johnson wrote:

>> Sorry, there's a gap in explicitness here. What's done to prevent the robo-signer and/or build system from accepting arbitrary content? This isn't relying on a trusted network, presumably there's some idea of who's allowed to request a build and specify its content, even if the source is redistributed under the robo-signer's signature, no?
>> 
> 
> You are best off controlling the submission channel, not muck-a-bout with
> the non-repudiable signature, which guranatees no tampering after, not before,
> the build occurs.

I think our gap here is semantic: I'm considering the submission system integral to the build system (which the split horizons and backwards/forwards language probably didn't clarify), whereas you view it as something distinct. It's the submission system, which decides whose arbitrary instructions to mint as a branded package, that I'm trying to ask after at this point because I like what you've already described and sense that it would fit.

> You better believe that I don't put my credit
> card numbers in RPM (even though you can find my phone number if you look carefully ;-)

We're still getting to know each other via an mailing list format, so I'm not asking for your number at this stage. ;->

-------------- 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/20110418/b725d50c/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/20110418/b725d50c/attachment-0001.bin>


More information about the macports-dev mailing list