[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [buildd] Implications of DSA-1571-1



Hi,

Might as well collect an up-to-date listing for all the buildds. I'm
hoping we'll have the opportunity to update keys at buildd.d.o. So I'd
like to update all the questions we normally get asked.

The question is, should we maintain this on a wiki where it can be
updated? We've potentially got 25 buildds if all of them were up and
running. I can keep that in a spreadsheet, but it'll bit rot as soon as
something changes and I don't notice. (Look a shiny thing, I must chase
it. :)

Even if it's not much information, having it on a wiki would be nice.

The only downside I see is spam harvesting and frankly I've got a nice
procmail filter that keeps spam from making it to my buildds (buildd
mail only knows six messages, everything else must be spam). If I was
really clever, I could probably drop such messages earlier. Hmmmm.

If we route all buildd mail via debian (or other) mail servers, that kind of procmail fitering could happen there.

What other questions should we ask/track?

Thanks,

Stephen


builddname: buildd_m68k-foo
hostname: foo.debian.org
dynamic/static ip: static
ssh connection info: ssh -p2145 foo.debian.org
buildd email: buildd@foo.debian.org
buildd admin(s): John Doe <bar@debian.org>
local admin: Jane Baz <baz@foobar.com>

Who else has access (posibly sudo) and can unjam things, or take over logs for this machine?

configured suites: experimental, unstable, testing, testing-security

host key:
ssh-rsa blahblahblah root@foo

buildd ssh key:
ssh-rsa blahblahblah buildd@foo

kernel: 2.6.25-2
distro: etch-m68k
has patched ssl and ssh (yes,no,n/a): yes

I'd classify information like ssh connection info and backup admins as sensitive, and would suggest to keep them out of public view. As the wiki will need some sort of account management, that should not be too hard to do.

While we're on the topic of renewing buildd.d.o ssh keys - is there any way to tell the SSH server to accept dynamic DNS addresses, in the sense that they may not resolve to the dyndns host name on a reverse query? Otherwise, the buildd.d.o admins would have to accept a rather broad wildcarding on my part (*.jetstream....), or set up a system to securely register the current buildd IP address (like dyndns update).

Lastly: I'm cleaning up kullervo's vast backlog of 370 failed build trees, because it makes buildd-watcher spend way too much time looking for outdatest files. I'm currently keeping two months' worth of build trees. Feel free to shoot me :-)

	Michael



Reply to: