On Tue, Jun 24, 2008 at 07:35:00PM -0500, Shawn Walker wrote: > 2008/6/24 Guido Berhoerster <[EMAIL PROTECTED]>: > > Shawn Walker wrote: > >> > >> 2008/6/24 Chris Ridd <[EMAIL PROTECTED]>: > >>> > >>> On 19 Jun 2008, at 08:32, Venky wrote: > >>> > >>>> I find third-party contributors directly submitting binaries a scary > >>>> prospect. The best option, IMO, would be to have them submit > >>>> patches and build recipes (which are much more easily vetted) and > >>>> have the actual build carried out by the /contrib project. Going > >>>> the SFE way would seem to be the best option for this. > >>> > >>> Would requiring that all ELF binaries be signed (noting the recent > >>> elfsign thread) mitigate your concerns? Obviously they only tell you > >>> who provided the bad binaries in the first place, and it wouldn't help > >>> at all with dangerous scripts. > >>> > >>> Having a build recipe seems safer though. This would make the contrib > >>> repository a bit like the ports systems on other OSes (eg FreeBSD, > >>> MacPorts, Gentoo, etc.) > >> > >> As long as there is an audit trail, I think it is perfectly acceptable > >> to allow direct third-party contributions. > >> > >> Whether published packages should get "approved" by a contrib project > >> member before being available is another story. > >> > >> I do not believe that contrib project members should have to be > >> responsible for building everything (again). > > > > Firstly, it generates transparency, nothing beats taking a quick look at > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/ or > > http://pkgbuild.svn.sourceforge.net/viewvc/pkgbuild/spec-files-extra/trunk/ > > etc. how a package is built and with what patches. > > You can still have transparency without making so that one group of > people has to rebuild everything.
How? By the way, I was not suggesting that one group of people rebuild everything. It was more on the lines of the automated build infrastructure suggested by Moinak. The /contrib project members have a look at the build recipe, certify it, throw a switch and the package gets built and published. This is perfectly automatable if we have a standardized build setup (like pkgbuild-pkg and the SFE repository), which again is the reason why I have argued time and again for a standardized build setup which allows for bulk builds. > > Secondly, it allows for easy customization by modifying a build recipe. > > Again, you don't have to operating things that way to achieve the same > results. Again, how? How does a published binary-only package allow someone apart from the publisher to modify the build recipe? > And in some cases, no source code may be available. A build recipe would still be useful in this case since we would need to do stuff like unpacking the binary package and republishing it to a pkg repository. Also, there is the question of responsibility. If a backdoor is discovered in a binary package of Apache, the Apache project is not responsible, it is the distributor of the package -- in this case, OpenSolaris. (I guess some small-print will absolve the project of direct legal responsibility, however.) On the other hand, if a vulnerability is discovered in a binary-only package by Nvidia, it will be Nvidia's responsibility. An audit-trail won't help because it is trivial to create a new online identity and in any case, does not help the people who have installed the trojan'ed package. On the other hand, if with a little bit more effort (setting up an automated build system based on pkgbuild and SFE) we can assure a much greater degree of security, I'd think it is worth it. > >> I don't believe such a model will scale very well. > > > > Look at the mentioned FreeBSD Ports (18700) or NetBSD Pkgsrc (7500), in fact > > it does scale very well. > > Sorry, but I just don't agree. You don't agree that the FreeBSD ports model scales?! Venky. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
