On Mon, Oct 20, 2003 at 07:57:20AM +0100, Andrew Suffield wrote: > On Mon, Oct 20, 2003 at 09:39:54AM +1000, Brian May wrote: > > On Sun, Oct 19, 2003 at 08:08:11PM +0100, Andrew Suffield wrote: > > > > And you also volunteer to replace the autobuilders and build _every_ > > > > package out there by hand on _every_ architecture ? > > > > > > > > Have you seriously thought about what you are proposing here ? > > > > > > What are you talking about? I'm not the one proposing anything. > > > > > > The proposal was "All packages should be built in an artificial > > > environment of this form". I have pointed out that this is a > > > braindamaged idea. > > > > Autobuilders already build packages "in an artificial" > > environment" for every architecture except the one the > > maintainer used for uploading. > > > > Surely making every package consistant on every architecture > > should be a goal for Debian? > > > > Sure, ideally the package should build exactly the same way where > > ever it is built, but differences can emerge with out being obvious, > > for instance if a package detects an extra library > > is installed on the maintainers machine and automatically uses it > > without the maintainer being aware of what is happening > > (this happened with early versions of Heimdal and libhesiod0 in fact). > > So, we have two scenarios. Let the package be broken in such a way > that it builds differently on different platforms. > > a) All packages uploaded to the archive are built in an artifical > environment. All packages in the archive function as expected.
This is the good think to do. > b) The package is uploaded from real-world environments. Sometimes it > breaks; when this happens the bug is noticed and corrected, so that > the package always builds the same way. A Malicious maintainer has installed a version of libc or whatever on his system that opens the way to a security hole. He builds a package on his system which links this libc statically and uploads it. Conclusion, there is a security hole in the uploaded packages that there is no way to trace given the sources only. Furthermore, it may even violate the GPL in some cases, where a maintainer uses a patch on his system, which is linked into a packages he uploads, and there is no trace of the source code for this patch anywhere. > I say that (b) is vastly superior to (a). The tradeoff is temporary > bugs in sid versus unnoticed bugs in a release. We'll never trap all > the bugs, but going out of your way to _not look_ cannot be a good > idea. And you think than building the package in an environment corresponding to what _1_ maintainer use is better than building it in an environment that will be the same for every installed system once it is rebuilt. Friendly, Sven Luther
