On Sat, Dec 13, 2003 at 03:56:02PM -0700, Kevin Rosenberg wrote: > I certainly miss the varied and up-to-date information that I was able > to get from auric. Taking James Troup's advice from his announcement > of discussing information we'd like from auric, what's on my mind > today is the ability to check the NEW queue. > > I frequently add new packages to Debian and, at the moment, I'm not > sure of what new packages I've uploaded before the recent breech and > what versions they were. > > Thus, if the ftpmasters are planning on a long-term restriction on > auric, mirroring the data in the new queue [at least filenames and > upload dates] would be of significant help to me. > > Thanks for considering the request, > > Kevin I myself do not consider restricting access to auric to be of any sense. For one, auric was not affected by the recent attack to Debian machines, so there really isn't any provocation that would give restricting auric a sense. As we could see, it obviously was easy to check the files on auric for integrity (some hours after compromise we were sure that nothing bad happened). Additionally, we would be able to track changes to the archive quickly as rsync logs on remote machines will show conspicuous entries (if the atacker started a mirror push; if he didn't, checking against a "known-to-be-good-source" would be enough). I generally see the following problems with the proposal made by James Troup: 1) A "mirror" of auric would certainly be good; however, for one, you would need to find a sponsor for yet another (probably quite expensive) box (and housing for it, somebody who pays the monthly bill, someone who administers the new box, somebody who controls it for security related things ...). Additionally, mirroring auric probably could not be done "simultaneously" so that people who have to rely on the data from the "mirror"-auric would have outdated data all the time. 2 (very subjective, though)) I have no idea why, but the speed i get when uploading to auric is significantly lower than the speed I get when uploading to gluck. This made me end up with uploading packages to gluck and downloading them from auric locally to get them into the archive (as this was the much faster solution) -- that just wouldn't be possible anymore once auric is restricted on the long term. 3) Mirroring auric on a box that is accessible by all developers will somehow rule out the possibility to use the mirror as "fallback" if auric has problems itself (as then we're down to exactly the same problem we have if we just have the unrestricted auric itself all the time -- the possibility of breakins into a very critical point of the Debian infrastructure) I understand the ongoing efforts to make the Debian development boxes more secure and I appreciate them as they will probably help to save our users better from security issues related to the Debian machines. However, I think that we should not burden our own work that hard in the name of security. -- .''`. Martin Loschwitz Debian GNU/Linux developer : :' : madkiss@madkiss.org madkiss@debian.org `. `'` http://www.madkiss.org/ people.debian.org/~madkiss/ `- Use Debian GNU/Linux 3.0! See http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature