Re: debian services and responsibility
On Fri, 1 Mar 2002, Branden Robinson wrote:
> On Fri, Mar 01, 2002 at 11:25:15AM +0100, David N. Welton wrote:
> > I would like to know the opinions of the DPL candidates on
> > responsibility for Debian machines and services.
> >
> > As it stands now, we have outages, and no one seems to really have a
> > firm handle on the situation. For instance, master has been
> > unavailable for almost 48 hours, and the few people who have physical
> > access to it seem to be saying "sorry, don't have time". That is not
> > an ideal situation for Debian services.
>
> No, in fact I'd venture to say it's unacceptable.
It's perfectly fine. You don't announce to the world when some incident has
occured, esp. when that incident may be nothing at all.
> If I were DPL, I'd have been on the phone to brainfood within minutes of
> hearing that there was a possible incident.
Well, that's all well and good, but we wouldn't have to respond to you. You
don't maintain the machines. You have no idea of their history. The
provider/sponsor, and DSA, do.
> Hopefully Brainfood has been in touch with Ben to apprise him of the
> situation. I can understand Brainfood's unwillingness to speculate to
> the entire developer community about what's going on, especially given
> the possibility that the security incident could have been caused by a
> Debian developer. At least for the first several hours following the
> port lockdown, I'd say it's reasonable to guess that Brainfood didn't
> have a complete picture of the compromise yet. It can take quite a bit
> of time to diagnose these things.
Local admins should never talk to the debian populace, ever. They should only
talk to DSA(thru -admin), and DSA should filter than on to everyone else.
> But the DPL -- at the very least -- should be in the loop. Sponsoring
> sites provide resources of tremendous value to Debian, but it is
> unacceptable for a vendor to unilaterally terminate services for an
> indefinite period without adequate explanation. Hopefully, Ben is in
> the loop on this issue and it's being handled in a way that I'd be
> comfortable with were I in his shoes.
No, this shows a severe lack of how things work in the real world.
We have not terminated services. We have blocked ssh access. Mail, web, and
dns are still working. Has the BTS gone down? Has list mail stopped flowing?
Stop spreading FUD.
> As far as the volunteer nature of our Project goes, I'd say that simply
> means that people and organizations who are part of -- or affiliated
> with -- the Debian Project need to be cognizant of their
> resposibilities. Part of my platform talked about this with respect to
> individual developers, but it holds true generally. Volunteering for
> Debian means a lot of things; one thing it means is acceptance of
> responsibility. Just as we expect package maintainers to keep their
> packages up-to-date, policy-compliant, and bug-free (as much as
> possible), we expect the providers of colocation facilities and our
> volunteer sysadmins to be able to fulfill their responsibilities as
> well.
Why don't you say what you really mean here, instead of burying it in legal
gobledy(sp) gook.
> Perhaps the DMUP could be revised to establish acceptable standards of
> behavior and incident response procedures that are binding upon the
> sponsors and DSA team as well as our developers. After all, problems
> can originate from anywhere, not just from plebe developers who get a
> spanking from DSA every now and then.
What does the DMUP have to do with this? In fact, how can you know anything
about this situation? No information has been given. Any type of inference
you try to make is pure conjecture on your part, with no basis in fact
whatsoever. So back off.
> A status report containing as much information as possible should be
> posted to debian-private by the DPL or DPL delegate within 24 hours of
> any incident like the one that has happened to us this week.
I informed -admin. That's all you need to know.
Reply to: