From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20100927/000299.html | 132 ++++++++++++++++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100644 zarb-ml/mageia-dev/20100927/000299.html (limited to 'zarb-ml/mageia-dev/20100927/000299.html') diff --git a/zarb-ml/mageia-dev/20100927/000299.html b/zarb-ml/mageia-dev/20100927/000299.html new file mode 100644 index 000000000..e219c60d8 --- /dev/null +++ b/zarb-ml/mageia-dev/20100927/000299.html @@ -0,0 +1,132 @@ + + + + [Mageia-dev] Will this work for a build system? + + + + + + + + + +

[Mageia-dev] Will this work for a build system?

+ Buchan Milne + bgmilne at multilinks.com +
+ Mon Sep 27 12:31:18 CEST 2010 +

+
+ +
On Monday, 27 September 2010 10:51:19 Giuseppe Ghibò wrote:
+> 2010/9/27 Michael Scherer <misc at zarb.org>
+> 
+> > Le lundi 27 septembre 2010 à 03:19 +0200, vfmBOFH a écrit :
+> > > What about virtualization?
+> > > 
+> > > Maybe we could set-up some kind of cluster of remote and dedicated
+> > > vm's as a
+> > > unique build system.
+
+Are you familiar with how the Mandriva build cluster worked? If not, you 
+should try and familiarise yourself with it first. While there are areas for 
+improvement, most of the time it worked very effectively.
+
+> > > Could be a good workaround over security and
+> > > integrity issues, 'cause we are using a "single" build system.
+
+You need to explain further how "remote" VMs can be used to workaround 
+security issues ...
+
+> > Well, how do you garantee that the person who have physical access do
+> > not mess with the vm image ?
+
+Again, as I said earlier, you need to be able to maintain the entire integrity 
+of the build environment/tool chain, not just the source of software being 
+compiled (to avoid trojaned compiler, possibly injected by trojan hypervisor 
+etc.).
+
+> > Look at libvirt developers blog ( http://rwmj.wordpress.com/ ) to see
+> > how easy it can be to externally mess with a virtual instance if you are
+> > root on the host computer.
+
+> The only way of doing this is NOT letting anyone packaging or uploading a
+> tarball.
+
+This is not the only requirement.
+
+> Just have two different building system. One "secure" and the
+> other of contributors (not unsecure, but with less checking). The secure
+> one would download the tarball automatically from the original
+> repositories:
+> 
+> e.g.: suppose there is a package SPEC file containing:
+> 
+> Source: http://blabla.com/openssh-5.5-1.tar.xz
+> Source1: http://blabla.com/openssh-5.5.1.tar.sig
+> 
+> An automatic system would try to retrieve from the http://blabla.com/ site
+> the packages
+> http://blabla.com/openssh-5.5-1.tar.xz, or if not exists
+> http://blabla.com/openssh-5.5-1.tar.bz2 or
+> http://blabla.com/openssh-5.5-1.tar.gz or
+> http://blabla.com/openssh-5.5-1.tar. Then would retrieve the signature
+> http://blabla.com/openssh-5.5.1.tar.sig and would check with the one from
+> the Database of signatures which has been already populated on the secure
+> system. If the signatures checking would match, then tarball would be
+> uploaded to the "secure" system svn and used for building instead of the
+> one from the contributor/package maintainer.
+> 
+> [Of course the system would fail if the package maintainer has downloaded
+> the source tarball from the svn and not from a canonical repository, and to
+> be further secure this system would require also signing of Patches].
+
+IMHO, you should also keep the public keys of tarball signers. Please have a 
+look at the samba SPEC file, which does verification of the tarball signature 
+during %prep. In conjunction with the existing build tools (repsys/mdvsys 
+etc.), a single command ('mdvsys update samba xxx') currently (usually) 
+updates and submits the package, and building it at any time validates the 
+source tarball.
+
+Actually, I still need to petition other security-sensitive packages which 
+have previously said that tarball signing is irrelevant (due to the problem of 
+first establishing trust of public keys etc.).
+
+Regards,
+Buchan
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1