On Tue, Mar 22, 2005 at 12:55:16AM -0800, Steve Langasek wrote:
> On Mon, Mar 21, 2005 at 08:08:57PM +0100, Wouter Verhelst wrote:
> > On Fri, Mar 18, 2005 at 06:44:46PM -0800, Steve Langasek wrote:
> > > - Architectures which need more than 2 buildds to keep up with package
> > > uploads on an ongoing basis are very slow indeed; while slower,
> > > low-powered chips are indeed useful in certain applications, they are
> > > a) unlikely to be able to usefully run much of the software we currently
> > > expect our ports to build,
>
> > Please leave it to our users to define what is useful.
>
> Does this mean "build it all and let the users decide for themselves what
> they want to use"?
That's our current approach, yes.
> Or does it mean "ask the users before getting rid of packages that
> aren't used on the architectures"?
Of all the other alternatives that have been proposed, I would think
this is the only valid one. It's hard to do that correctly, though,
because you can't be sure that you've contacted even a majority of
users.
> If the former, that doesn't seem to leave much room for ever improving
> the return porters to embedded/slow systems will ever get on their
> buildd investment, does it?
I don't see why not.
> > > and b) definitely too slow in terms of
> > > single-package build times to avoid inevitably delaying high-priority
> > > package fixes for RC bugs.
>
> > I would not have any problem with multi-staged security announcements,
> > for example.
>
> Well, I guess just as I can't speak on behalf of all users and say they
> won't use KDE on m68k, you can't speak on behalf of them and say they're ok
> with having delayed security support for m68k. :)
Good point. However, what I meant to say is that the multi-staged
security announcements could be an option for the security team in case
a build really takes an awful lot of time, such as in the KDE case, when
this isn't wanted (if there is no embargo set, or the embargo time is
about to pass). They'd be the exception; and in fact, this has happened
before, f.e. with the kernel builds, or with some other huge package
that was being delayed.
For regular, short-timed builds, multi-staged security announcements
wouldn't be required, and thus, they wouldn't be wanted.
> The security team seems historically unconvinced that staggered
> security announcements are worthwhile -- at least partly this is
> because staggered security announcements are more work, AIUI. In any
> case, you'd have to persuade them that this is a good idea before the
> release team could consider it.
Okay, that makes sense.
> > * Nobody has ever been offered to maintain a buildd host who was not at
> > least in NM. I did train Matthias Ulrichs and Goswin von Brederlow
> > when they were, but Goswin's machines were disconnected from w-b even
> > before he was rejected.
It was getting late when I wrote that, apparently. Goswin's machines
weren't even ever connected to w-b; what happened is that I discontinued
the manual support I had been putting in even before he was rejected.
> > I'm also quite sure today I won't do that
> > again, precisely because Goswin was rejected and I don't want to think
> > of what might've happened had he been able to upload trojanized
> > binaries (not that I think he would have done so).
>
> > I'm interested in what your base for the above assertion is.
>
> Merely a misunderstanding about the current state of affairs with the m68k
> port, it seems. Certainly with all the fuss Ingo has made over this issue
> in the past, I had the impression that it was actually a current issue --
> not a hypothetical.
Yes, Ingo's deliberate confusion hasn't really helped us a lot either.
> > > Whether or not these
> > > particular individuals should be trusted, the truth is that when you
> > > have
> > > to have 10 buildds running to keep up with unstable, it's very difficult
> > > to get a big-picture view of the security of your binary uploads.
> > > Security is only as strong as the weakest link.
>
> > True; but these concerns can be better addressed by spelling out some
> > security requirements (and somehow ensuring they are being followed)
> > rather than imposing some random, unrelated, limit to the number of
> > hosts in use.
>
> FSVO "better"; having explicit security standards is good, but increasing
> the number of people (and machines) involved still increases the chances
> that somewhere, they will fail to be met.
Well; this may be just me, but I have the feeling that using "no more
than X hosts" as a security precaution is based on "we don't have enough
time, so let's do this the easy way".
Having explicit security standards is a precondition to running a safe
network. If you have a safe network, then the number of hosts shouldn't
matter. Of course, the fact that Debian's network is widespread over the
globe doesn't really help, but trying to remedy that by reducing the
number of hosts smells like chickening out on what the real issues are,
to me. In any case, it isn't really a good measure -- the end result of
this proposal might be that some of the architectures currently not on
ftp.d.o will end up having some host that must be maintained by DSA,
thus that the number of hosts might increase. Then what?
A buildd host does not need much to work safely, so writing a security
standard should be possible. How about a security standard like the
following:
* A buildd host must not have any port open, except for one SSH port
(preferably port 22, but may be nonstandard).
* It must run OpenSSH of at least version <version without security
issues in stable> or <version without security issues in unstable>
* It must run a kernel from the list of <list of kernel packages in all
distributions that are safe>
* It must not have PermitRootLogin enabled
* It must not have PasswordAuthentication enabled
* It must not have any tunneling enabled, except for scp
* It must not have any enabled accounts except for root and the admin
user(s)
* ... possibly something more?
Then DSA could set up a cronjob that would run every x days, check
whether the requirements are being met, and would scream like hell if
one of the hosts was insecure?
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
