[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sv-migration] Re: savannah -> gforge migration
From: |
James E. Blair |
Subject: |
[Sv-migration] Re: savannah -> gforge migration |
Date: |
Mon, 29 Mar 2004 17:57:06 -0500 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
Tim Perdue <address@hidden> writes:
> Sure. The debian guys have a nice perl script that may help migrate
> from your older SF2.0 structure to the new structure.
>
> Just off the top of your head, how much did the schema change since
> you guys forked off of SF?
I've created the sv-migration list and initially subscribed the FSF
sysadmins and some of the more active Savannah hackers.
The development of the Savannah codebase (now called Savane) happened
without the involvement of Paul or myself. Maybe the Savannah hackers
can address your question about schema changes?
Here at the FSF we're trying to figure out what kind of staff
resources we're going to have to devote to the migration. Could you
help us understand more about these issues that we've (so far)
identified?
1) Most PHP exploits seem to derive from register_globals being on and
the meticulous care that needs to be taken with variables that
could be tainted. Savane requires that it be on and so does, I
believe, GForge. It seems to us to be worthwhile to modify GForge
to run with it off. I'm sure that's a big project; how much effort
do you think it would involve?
2) Group types: Savannah has the notion of group types which are used
to distinguish GNU/non-GNU/www.gnu.org/user-group projects. These
provide slightly different services (GNU projects use ftp.gnu.org
instead of the download area, and of course the banner that is
displayed at the top of the project page indicating its type).
Does GForge support this kind of behavior? If not, we could
probably do most of what we want with separate installs on one
machine, if that is supported, and we can easily import/export
projects between them.
3) Savannah has several private projects which do not allow anonymous
access to their resources. Can GForge support this?
4) We would like all file uploads to be GPG signed. For Savannah, we
have bolted the ftp-upload system for the GNU ftp servers in place,
but it's complicated and limiting. GForge seems to have a file
area, and I think we would like to use it for the non-gnu packages,
but we still want GPG signing. Would it be hard to require all
uploaded files to be GPG signed?
Thanks again for your help.
-Jim
- [Sv-migration] Re: savannah -> gforge migration,
James E. Blair <=