From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23909 invoked by uid 1002); 7 Sep 2003 23:27:17 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 31441 invoked from network); 7 Sep 2003 23:27:17 -0000 From: Jan Krueger Organization: microgalaxy.net To: Jon Portnoy Date: Mon, 8 Sep 2003 01:32:45 +0000 User-Agent: KMail/1.5.2 Cc: azarah@gentoo.org, Gentoo-Dev , Thomas de Grenier de Latour References: <200309072234.06470.jk@microgalaxy.net> <20030907203546.GA6996@cerberus.oppresses.us> In-Reply-To: <20030907203546.GA6996@cerberus.oppresses.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309080132.45709.jk@microgalaxy.net> Subject: Re: [gentoo-dev] suggestion portage ebuild system file modification rights and protection X-Archives-Salt: 3cbe895d-ea84-4ea2-8e1f-42d87214ec2f X-Archives-Hash: f4ccd7055964bc07ffe3430a7a5b153c On Sunday 07 September 2003 20:35, Jon Portnoy wrote: > What, that any situation involving installing software is going to have > security holes? That's the nature of software installation. The gift of portage is a new quality of automated software installation system, easy to use, never seen before. This is good. However by being a full automated software installation system portage has a very high responsibilty for the integrity of the system it is run on. The discussion should have shown you, that the current portage can not bear this responsibility. This thread showed and will continue to show: ebuilds can overwrite any system file ebuilds can wipe your box ebuilds are affecting system integrity ebuilds lack quality Some of you think this can be addressed by: qa signing ebuilds and files I say: this is not sufficient. Again examples from the actual tree, so you can try yourself: 1. emerge ezmlm and emerge ezmlm-idx providing slightly different funtionality they will overwrite each other (instead of blocking each other) 2. emerge heartbeat (sys-cluster/heartbeat-1.0.3-r1, marked x86, so considered stable) If your emerge was successfull (it will be as long as you dont have snmp installed), try to get it running! You wont! Then take a look at bugs.gentoo.org since when important fixes are available. This two examples clearly show what the current qa is worth. (Well i respect it very much, but its not perfect and never will be, thats qa, qa you for sure know from other software/hardware products you use and used before, you know the deficencies of qa then) I am pretty sure you can post examples from the tree yourself. And to me its clear why it is like that (at least on reason): If you compare the number of ebuilds to the number of CVS committers than you will see, that it is impossible for each CVS-commiter to make a valuable statement of the quality of the software and/or ebuild he/she is going to commit. There are to many ebuilds. (i see this as an organizational deficiency of gentoo) So it is probable that faulty ebuilds hit the tree. They are there actually. Conclusion for me: I expect faulty ebuilds. they are there. (you will never wipe them out until you change the organization of gentoo development to a more apropriate model, and even then, you can only reduce the amount of faulty ebuilds. ebuilds are software, software has bugs.) and therefore: i hold portage responsible to protect my system from faulty ebuilds as much as it can. if not portage, who else? there is just me left, but then, i dont need portage. I made several suggestions how portage can be improved to protect the system it is run on. -prevent ebuilds from modifying the life filesystem -allow the actual package install process only to add files to the filesystem or to only modify/remove files that belong to an revision of the same ebuild (qa would benefit from this suggestions too.) This would result in: -enforced package integrity -wiping my box from within the ebuild is no longer possible Please implement the suggestions. Do you understand me? If still not, i will remind you of former times, when bootblock virii have been very successfull. Why do you think they have been successfull and are no longer? Answer: Because it was possible to modify the bootblock. It is possible for an ebuild to wipe your box. So doesnt this scare you now? Jan -- gentoo-dev@gentoo.org mailing list