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

Mon Sep 27 00:49:31 CEST 2010

On Sunday, 26 September 2010 18:14:15 Giuseppe Ghibò wrote:
+> IMHO the idea of the cloud is not that bad
+
+It has obviously already been thought about to some extent.
+
+> but need to be rethinked. I
+> don't see so much flaws for security. If you inspire to what repsys is
+> right now, the cloud would be like having several svn repositories
+> mirrored around the world each one with a local iurt/repsys building
+> system (it might be even partial, e.g. there could be BIG ones holding the
+> whole svn|git tree, and smaller one holding just the latest release or the
+> latest two releases, etc.). Each building system around the world will
+> sign packages they build with their own signing keys and you know where
+> they come from. And packages won't be resigned by a supposed master. Of
+> course you have to trust their administrators, exactly like you right now
+> have to trust single users submitting sources to the svn and bulding
+> packages.
+
+No, at present we trust users to submit source code, that can in theory be 
+audited quite easily.
+
+Changing a distributed model means you need to trust all users who have any 
+way to affect any of the toolchain on any of the hosts (taking into account 
+e.g. compiler trojans), or you need mechanisms to be able to validate it the 
+toolchain. While this could be done with a slow-moving distro, with a fast-
+moving one, where parts of the toolchain and integral libraries change on a 
+more-frequent-than-weekly basis, the manual overhead to update signed 
+filesystem images or similar would probably be excessive.
+
+Changing to a distributed, virtualised model brings in more issues (how about 
+trojaned hypervisor?), while possibly allowing to mitigate some ...
+
+What we could do in a more distributed fashion (e.g. on EC2 or similar), is 
+providing instances on which developers test/develop builds (such as the 
+interactive use of n*, chroot* etc. on Mandriva).
+
+> The most difficult things IMHO would be building from the same syncronized
+> data. In that case you might choose a master server and several mirrors.
+> The master might have multiple internet access points (e.g. from two
+> providers) and will be the only one who might receive svn commits. Or a
+> model without a master, I guess inspiring to a model what UseNET is (was),
+> I think a lot more complicate. But in that case you have two direction of
+> feeding and if two libraries are submitted in different user in nearest
+> time, you need a system to check for coerency and set alarms in some
+> cases.
+> 
+> IMHO one of the building problems was not massive automatic rebuilding but
+> avoid bottenlecks to the users when building goes wrong.
+
+But, there aren't usually very many cases like this which can be solved by 
+distributing outside the control of the foundation. A standby build 
+environment to go with a standby authoritative mirror host would be nice, but 
+it would need to same security as the production authoritative mirror host.
+
+Regards,
+Buchan
+