security projects thoughts

Bayard Bell buffer.g.overflow at googlemail.com
Mon Apr 18 08:14:27 PDT 2011


On 18 Apr 2011, at 15:55, Jeff Johnson wrote:

> Note no "key management" or "delegated trust" through signing by
> developers or other "central authority" other than what the build system
> chooses to use, thereby simplifying the needed deployment.
> 
> And its the "build system" not the upstream sources nor the "branding"
> that is the appropriate place to "trust". The build system isn't
> responsible for other factors such as tampered upstream sources or
> anything that happens prior to the build starting. The added non-repudiable
> signature secures the contents going "forward", not "backward", in time.

There's already been some references to having some kind of automated build service/sausage factory. Could you provide more info about how this is done with rpm at Red Hat? Is the source provided with build instructions as a source rpm that's then built and signed automatically to produce the distribution rpm? There's clearly a split in horizon between what the build system signs, but what checks does it do to decide what to build, package, and sign, meaning who does it trust "backward", if I might attempt to adopt your terminology at the risk of losing your meaning?
-------------- 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/47236ffd/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/47236ffd/attachment-0001.bin>


More information about the macports-dev mailing list