> > There are DDP members that are not reading the list. Notably, a number of > > translators are probably not subscribed to this list. > > Everybody that need to access to the cvsroot can simply ask. Note that > Joey Hess did that for the d-i cvsroot, and everything is OK. Joey Hess gave advance notice, there was no advance notice on this DDP move. > > ¿? I'm not talking about they providing a tar, I'm talking about how is > > www.debian.org/doc going to get updated when the sources are up at Alioth. > > Since gluck had both the CVS and the the WWW repository it was trivial to > > have a cronjob to run the stuff, I'm not that sure admin's will like to run > > scripts in gluck that are extracted from Alioth in a cronjob, that has a > > lot of potential for abuse. > [...] > > I don't understand why you speak about abuse, since you can log in through > ssh. As Osamu point out, webwml is in the same situation. Log in through ssh where? > cvs hosted on gluck > > check out on klecker Yes, notice that gluck can only be accesed by DDs currently whileas klecker is now restricted. The cronjob in klecker runs 'make publish' from the checkout copy from gluck. Now consider the following, if you will: - full CVS hosted at alioth, translators, DDP writers and many people (even non-DD have access to it) - check out on klecker + run scripts from that CVS periodically (make publish) It turns out that _any_ account that has CVS rw access in alioth, or even a user who can access alioth itself and compromise its security (which is "lower" security from my PoV than gluck since its open to many more users). Somebody that wants to compromise klecker can just use shell script code in the DDP CVS and he's done. Notice that this is a very different situation from using Alioth as a, for example, source code repository for a package since an abuser is certain that his code will be run at least once if he times it right (makes the CVS change just before the cronjob) without giving a change for other CVS users to review the changes. I'm not against having the document data up at alioth, but any script/Makefile or whatever that is going to be run periodically at other system should be kept outside of Alioth and more tightly controlled. I'm arguing against moving the DDP to Alioth since that change will need time to be developed, lets first sort that out and then move to Alioth. Regards Javi
Attachment:
signature.asc
Description: Digital signature