from devil's_advocate import * (should really have been on the top of the last message too :) and i've been awake for about 17hours, and am moving offices. I may talk shit. (TM)) * Matt Zimmerman (mdz@debian.org) wrote : > On Mon, Jan 29, 2001 at 10:59:14PM +0000, Thom May wrote: > > > The BSDs use CVS for their core system. Ie kernel, basic system requirements, > > that sort of thing. you'll see the package tree is (a) fairly separate (b) > > not full of packages anyway, just Makefiles and patches. > > The base system is where the auditing is concentrated, and for good reason. Definitely. >I > am just suggesting ways in which Debian could benefit from similar tools and > methodology. > I think the idea is more suited to - in the form being discussed - to one of the BSDs. After all, they have "control" of the entire operæting system. <snip> > I imagine that each area of the tree would be subject to its own access control > policy. Notification of changes is easy, as I noted later, as it can be > automated. A lot of coordination would be necessary to avoid conflicting > changes and other such messes, though. The scalable solution would be for each > maintainer to determine the access control policy for his/her packages. It would be a fairly massive investment of resources to get working right. It would also be - relatively - a lot tougher to add a new package - a new module would have to be added, decisions on access control made, set up of who to mail changes too - a list, a group of maintainers, just the developer, etc. While it would be easy to automate this, it's another layer in front of a developer wishing to add a new package. > > > - Maintainers adopting orphaned packages would have access to the complete > > > history of the package, to help avoid repeating old mistakes, and to help > > > understand why changes were made. > > That's what the changelog is for. > > The changelog is too granular, and has no mapping to actual changes in the > source code. CVS supplies that mapping with log messages and diffs for each > revision. Yes, you're right. I didn't consider that well enough. > > > > - A hypothetical security auditing team could easily and methodically audit > > > the entire source tree. > > *falls off his chair* Debian has ~600 developers. if each of them only > > maintains 4 packages, each of around a megabyte of source code ( a gross > > simplification, and doesn't take into account things like X, emacs, gnome, > > kde etc). This is 2.4 gig of source code. Not to mention documentation. > > I didn't claim that it would be quick or easy. Such a project (as has already > been suggested here) would probably start with the (relatively manageable) base > system. > True, but what is the analogue to cvs diff -rrev1 -rrev2? cvs log <file>? > These are powerful tools for keeping aware of what is going on with a source > tree. Sure. I was really voicing my overarching conecerns, rather than granularily going through point to point. I should have taken more time to write my first email. > I subscribe to debian-bugs-dist, and sometimes to try to help investigate a > bug, I'll download and extract the source package and poke around. But if > something broke between the previous revision and this one, I have to guess > (based on the package changelog and my knowledge of the software) where to look > for the problem. Even knowing exactly which files changed between two > revisions would be a huge help. Members of the QA team would likely agree. > > > Tricky with CVS, i think. > > Impossible in the current implementation. One needs write access to the > _directories_ in the repository in order to make any changes at all. Yep. is subversion worth a look? - subversion.tigris.org, license appears to be based on APL - it's still fairly new. > > The answer may be that Debian is simply too big to be manageable using such a > system. One could also argue that Debian is simply too large and complex to be > secure. In that case, we should focus on doing what we can for a subset of > Debian. Sure. but at that point, how do we define the subset? Is it just the base system? Important packages? Daemons and services only? I guess my major concern is that this idea - while highly laudible - could easily eat up a major amount of infrastructure and developer time. > I have a 9gb disk looking for a use; I may just extract a useable subset of > Debian into a CVS tree there and see what happens. The components for > importing new versions should be relatively simple. I'll be very interested in the results :-) Cheers, -Thom
Attachment:
pgpKj2FC1SgFm.pgp
Description: PGP signature