Re: Mirror layout proposal

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============74674872279190097==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig563415F20A294D4B3C192601"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig563415F20A294D4B3C192601
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

 > * No comments on where gpg signatures should go - Security guys, we
 > actually need a whole new approach at this, not only for distfiles,
 > but also for build scripts.


I always imagined that those signatures are kept within the ebuild 
directory. I would propose a sepparate file containing the signatures 
and using a file type extention of the for gna-1.0.ebuild.gpg or 
something along this line. This will allow us to use another files named 
gna-1.0.ebuild.XXX for different sorts of signatures, eg: x509.

Naturally those signature files could also be placed to arbitrary 
different places. I'm not sure we would want this. Shouldn't ebuild and 
signatures share a common directory?

 > ... that have not been gpg signed by X number of trusted devs ...

I would propose to implement this in an abstract way so that _different_ 
types of trust can be applied! I can imagine multiple form of trust as 
for example:

GPG:
- Trust in a keyring of Zynot developers
- Trust in a top level signature of one or multiple Zynot GPG 
Certificate Authority Certificates, created specially for this purpose. 
This maps a hirarchical trust schema like the x509 schema to GPG. Trust 
would essentially be provided by giving the End-User a keyring of 
trusted GPG CA Certificates, and not individual developers. By defining 
apropriate certificate verification depths these special signature 
certificates could be checked.
- Trust in a simple web of trust given by a arbitrary keyring (user 
supplied)

x509:
- Trust in the Zynot Certificate Authority's trust chain
- Trust in a foreign Certificate Authority's trust chain

Last but not lest:
- Trust in any combination of the above. This will allow the checking of 
the GPG signatures by x509 signatures and vice versa. It will also allow 
to use a web of trust and hirarchical trust chain in combination giving 
the system a independency of arbitrary bugs in one or the other form of 
signatures and trust schemas...

Please share your thoughts!
- Amir

-- 
Amir Guindehi, [email protected]
DataCore GmbH, Witikonerstrasse 289, 8053 Zurich, Switzerland


--------------enig563415F20A294D4B3C192601
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-nr1 (Windows 2000)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/K7O+bycOjskSVCwRAiCcAJsFquPsl7aq+AWEBTVFp+VN9jNW4ACfS/hb
07GG3PQU3+CSsIxAuQijVbc=
=bTgQ
-----END PGP SIGNATURE-----

--------------enig563415F20A294D4B3C192601--


--===============74674872279190097==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Zynaut mailing list
[email protected]
http://lists.zynot.org/mailman/listinfo/zynaut

--===============74674872279190097==--