[Savannah-hackers] Re: about savannah reinstallation management

[Mathieu Roy]

(Cc: to savannah-hackers, not to savannah-root. This last mailing list
have never been created to hide from the public how savannah is
managed but specific sensitive information)

Paul Fisher <address@hidden> a tapoté :

> Mathieu Roy <address@hidden> writes:
>
>> For the kernel, ssh, and the usual packages, sure, it is
>> reasonable. For apache, savannah-hackers now best which exact
>> modules need to be activated, which version of apache should be
>> picked.
>
> Is there a particular reason why standard Debian packages and versions
> cannot be used for apache?

These packages have used. The point is not which package must be used
but who should decide that. From now, it was not the FSF admins and I
do not see any reason to change that.

savannah-hackers has always been opened to FSF admins
suggestions. However, we have also learn to avoid counting on FSF
admins because any trivial problem that was in FSF admins hands (like
mail server) was taking usually more than 15 days, more than 2 months
in some case, just to be acknowledge. 

And if Savannah is about to be managed that way, I guess that this
savannah will not be as the one we built over year: the one people
accept to rely on.

>
> We would like for there to be a clear separation between maintenance
>of the lower level of the system (debian packages/network
>configs/etc), and maintenance of upper level of the system
>(Savannah's php code and scripts).

I do not know what leads you to such request. Savannah was until the
5th december a great tool, with a nice reputation. It was nicely
working as we maintained it.

I'm not sure the same statement could be made with the FSF management
from the 5th december to now.

Please, explain why you would like to put limits on us.

>
> For instance, the old Savannah system used CVS to maintain all of
>the system config files (such as SSH) remotely, and these were
>accessible via anonymous CVS.  Those config files are an example of
>something that we think FSF staff should be maintaining.

This was unsensitive information stored in that files. However, even
if they shouldn't be available by anonymous CVS, it does not give any
reason for you to assume that you are the one that should handle that
files.



>> Until now, savannah-hackers maintain every part of Savannah, while
>> being totally opened to FSF sysadmin contributions. Do you want to
>> change that? Do you think there is a problem here?
>
> The people with root access on savannah should have set
> responsibilities for different parts of the system.

How the *** did you reached that conclusion?

> We'd like to have the FSF maintain the core parts of the system, and
> for the savannah-hackers to maintain the upper layers of the system.

Why? Please explain yourself, give reasons, do not just tell what you
want. 



> In other words, do you distrust us to maintain that server or part
>> of that server? In which case it would make sense to determine
>> limits.
>
> It's not that we distrust you.  The FSF employees staff to administer
> the systems at the Foundation.  In the past, we've understood how all
> of the systems here function, with the exception of Savannah.  It's in
> everyone's best interest that more people understand how Savannah is
> setup, and how changes to the running system will effect security and
> the rest of the system.

It is not in savannah-hackers interest to be forced to rely on
you. And that's your proposal, even if you describe it as the desire
to "understand how Savannah is setup"

In the past, you have never been reliable. In my archives, if I grep for
the string "busy", I'll find hundred of message sent to user
explaining why after 1 month their blocker problem, trivial to fix,
with a mailing list is still  not fixed. 



> I'm used to study carefully text, so I'm maybe to picky. But I would
>> like to be sure to correctly understand everything: you really mean
>> "We have no intention to exclude savannah-hackers on the
>> installation and maintenance of the whole savannah server", didn't
>> you?
>
> We would like to keep an open dialog between the system staff at the
> FSF and the savannah-hackers.
> We're paid to make sure that machines at the FSF stay up and
> running, and we'd like to include savannah in the list of machines
> that we're actively responsible for.
>
> We do not want the savannah-hackers to handle installation and
> maintenance of the _entire_ savannah server.  We want the maintenance
> and installation of the server to be a joint effort, with different
> people working on different parts of the system.

You talk about "joint effort" while you are telling that you will rule
the place. Well done, the server is yours. 


> The extra people looking at the savannah setup has already been
> useful.  There was a giant hole in the configuration and setup of the
> CVS pserver on the old savannah that would let anyone get root in a
> couple of minutes.

This is completely off-topic, unless you claim that savannah-hackers
should not be running this computer for effeciency issue.

>
>> I would like to be sure that everybody agree with what Nic Ferrier
>> replied:
>>          "once the hardware is up and running, the syadmins really
>>          _should_ be handing back responsibility for resolution of the
>>          crisis to savannah admins."
>
> We can't afford to go back to the situation that we were in before.
>
> The FSF admins had almost no knowledge as to the configuration or
> setup of Savannah.
>
> When savannah was cracked, it became the responsibility of the FSF to
> restore the system and work with the community to audit the existing
> software to get savannah back up in a trusted state.  The FSF staff as
> well as the savannah-hackers volunteers need to be sure that the new
> savannah is more secure than the old savannah, and that the effects of
> future exploits and buffer overflows in programs is limited.
>
> Simply putting the system back up in the state it was in before the
> compromise would have been irresponsible.

Is it the guy that forgot over several month to upgrade the kernel
with a well-known bug which is writing that? Is it a joke?

But I agree on one thing: this new savannah you are putting online
will have nothing to do with the previous one. Sure. 


>> About the reinstallation itself, I'm not proposing to rush, but it is
>> anyway never possible to be sure that no bug will ever be found on a
>> system.  
>
> It's true that we will not find all bugs, but we should do what we can
> to limit those future bugs from compromising the entire system.

You are not talking about limiting bugs but limiting
administrators. If we had behaved like you do, the rootkit would maybe
not even have been found by now (on that topic, I suggest you to avoid
any comment; the FSF admin reputation is not so great about that).



Since neither Bradley or RMS seems to disapprove Paul, I think that
the future of savannah.gnu.org seems to be set.

-- 
Mathieu Roy

  +---------------------------------------------------------------------+
  | General Homepage:           http://yeupou.coleumes.org/             |
  | Computing Homepage:         http://alberich.coleumes.org/           |
  | Not a native english speaker:                                       |
  |     http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english  |
  +---------------------------------------------------------------------+