Re: Status of new packages in Incoming?
Raul Miller wrote: > Which implies that we should validate packages against developer's key > before install, and that we should have some kind of list indicating > which developers are working on which package for which architecture > which is maintained under tighter control than the mirrors. > > We probably don't want to forbid install if package is signed by the > wrong key -- but we want to do everything we can to help the sysadmin > examine the package under that circumstance. As I have already posted, the situtation you are talking about is the status quo. And as far as I know nobody has gotten a trojan package in to Incoming, so I'm confused why you are try to fix what's not broken. I hope we get signed packages RSN. We need them badly, for completly unrelated reasons. However, I am firmly opposed to any system that makes it harder to do NMU's, and what you're proposing seems to do that. -- see shy jo
Re: Status of new packages in Incoming?
On Mon, Sep 27, 1999 at 11:22:32AM -0500, Steve Greenland wrote: > I think the key difference is that if some one screws with the BTS or > the Debian web site, it's not going to *me* any harm during the time > it takes to discover and undo the damage. If someone installs a bad or > malicious libc6 in the archive, a buncha people could get seriously > screwed. Depending on mirror cycles and timing, I suspect it could take > *days* to completely correct the damage in the archive and its mirrors, > and who tells how long for the victims to correct their local situation. Which implies that we should validate packages against developer's key before install, and that we should have some kind of list indicating which developers are working on which package for which architecture which is maintained under tighter control than the mirrors. We probably don't want to forbid install if package is signed by the wrong key -- but we want to do everything we can to help the sysadmin examine the package under that circumstance. Also, we don't want to lock people in to just the Debian keyring. If they're getting packages from somewhere else they should be able to start trusting that source, if that's what they want. That, and people should be able to build up reputations. -- Raul
Re: Status of new packages in Incoming?
Joey Hess wrote: > I think it should be possible to come up with a structure where ftp site > maintainers need not be trusted. The key to doing so is making it possible > for any change such a person makes to be logged, and reversable. > > Anyone can manipulate bugs in the BTS, and that's > generally ok, because the changes they make are reversable. > > I think we should consider writing a developers' interface to the ftp site. > This would allow developers to move files from one section to another, edit > override files, delete files, and replace files with new files from > Incoming. I think it would be _great_ if we could move files directly into the archive instead of to incoming. The installer program would log everything, and the ftpmasters could just oversee the logs instead of doing it themselves. New packages stay for too long in incoming. I currently never get kernels frm the stanadrd Debian place because they are obsolete (almost) by the time they get installed. Peter
Re: Status of new packages in Incoming?
Steve Greenland wrote: > I think the key difference is that if some one screws with the BTS or > the Debian web site, it's not going to *me* any harm during the time > it takes to discover and undo the damage. If someone installs a bad or > malicious libc6 in the archive, a buncha people could get seriously > screwed. Yes, but we have nothing in place right now to prevent anyone installing a bad or malicious package into the archive. Upgrades to packages that already exist are already installed automatically -- as far as I know this applies to NMU's as well; any developer can slip a bad or malicious package in and it will not be caught until it hits the mirrors. So I think your concern is orthagonal to what I am proposing. -- see shy jo
Re: Status of new packages in Incoming?
On 27-Sep-99, 00:44 (CDT), Joey Hess <[EMAIL PROTECTED]> wrote: > I think it should be possible to come up with a structure where ftp site > maintainers need not be trusted. The key to doing so is making it possible > for any change such a person makes to be logged, and reversable. > > The reason I think this is possible is because of things like the Bug > Tracking System, and CVS. Anyone can manipulate bugs in the BTS, and that's > generally ok, because the changes they make are reversable. People routinely > give other write access to CVS repositiories without strenuous background > checks on them. For example, anyone who expresses the willingness to > translate can get CVS commit access to the debian web site. With CVS, this > isn't a problem, because if someone does something bad, it's possible to > revert their changes. It's also possible to identify who did it and deal > with them if they're a repeat offender. I think the key difference is that if some one screws with the BTS or the Debian web site, it's not going to *me* any harm during the time it takes to discover and undo the damage. If someone installs a bad or malicious libc6 in the archive, a buncha people could get seriously screwed. Depending on mirror cycles and timing, I suspect it could take *days* to completely correct the damage in the archive and its mirrors, and who tells how long for the victims to correct their local situation. Note that this doesn't argue against the idea of having a reversible and logging interface to the archive, which might be a good thing anyway; just against allowing widespread access to the archive. -- Steve Greenland <[EMAIL PROTECTED]> (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
