Re: kernel/d-i/security/release meeting at DebConf6
On Tue, May 23, 2006 at 10:16:37PM -0500, dann frazier wrote:
> On Sun, May 21, 2006 at 10:46:44PM +0200, Sven Luther wrote:
> > On Sun, May 21, 2006 at 01:09:45PM -0500, dann frazier wrote:
> > > Kernel udeb creation process (possibly using k-p?)
> > > -------------------------------------------------
> > > If we build all of the *existing* udebs from a single source, we outgrow
> > > the limit of the Binary: field in the control file.
> >
> > Huh ? This problem is known since over 2 years now, and i thought it was one
> > of the things that where fixed earlier this year or late last year ?
>
> Immediately after I sent out the notes from this meeting, aba said
> he'd followed up with an ftp master (neuro, iirc). From what he was
> told, it sounds like the information we had during this meeting was
> stale/inaccurate. Hopefully someone will update this thread with the
> accurate information so that we can revisit this discussion. Many of
> the attendees are still travelling (in fact, I'm replying to this
> without a net connection, so it may be moot once it actually goes
> out). It'll probably be a few days before everyone makes it home, but
> then we can continue with a more well-informed discussion.
Notice that this issue was mentioned in a thread on debian-boot at least some
weeks ago, i am not sure, but it may even have been Joeyh who mentioned it. I
also mentioned it earlier, altough i was not 100% sure.
> > > dannf suggested that maybe k-p can be configured to allow simple unapcking of
> > > debs vs. all the postinst configuratin to allow autobuilders to deal with udebs
> > > better; manoj thinks that this will be possible but further out in the current
> > > k-p transition that allows for users to do more "overriding" of
> > > postinstallations by default.
> >
> > Mmm. But i don't see how this will play nice with the auto-builders. There is
> > no way we can get this behaviour into the current set of deps/build-deps.
> > Should we add another new kind (Source-dep: ?) ?
>
> Well, the only problem (aiui) is that kernel installs want to do bad
> things like run bootloaders, etc. If we had a chroot parameter we
> could tweak to turn this off, then wouldn't that solve this problem?
Ah, that would indeed be a solution, we could easily implement something such,
together with Manoj, since i believe it involves kernel-package, and how the
/etc/kernel/*.d/ scripts are run.
Not sure if this is enough, as we would also obviously need support from the
buildd software.
> > > The consensus was that the current udeb approach is suboptimal, but
> > > solving it cleanly won't be possible until etch+1. None of the
> > > attendees considered this issue to be critical for etch, so the
> > > current plan is to status quo and wait till etch so that we can come
> > > up with a good solution.
> >
> > I strongly disagree with this. The non-solution of this issue means that we
> > have a limited power to handle abi-breaking security and bug-fix patches, and
> > impose unreasonable earliness on the kernel freeze for etch, as well as
> > endangers security support during etch's lifetime after that. This was and is
> > a problem with sarge, and we should not repeat that. We should have tackled
> > this issue last fall though.
>
> I sympathize with your concerns but, speaking as a person that does
> security work and udeb maintenance for one architecture, I don't think
> this is *that* big of a problem. ABI changes are more painful, but
> d-i work can be ignored when releasing a security update (in fact, we
> did so last time) - its just point release that suffer, and those
> schedules are more flexible (as far as our users are concerned).
Well, as a proof of my claims, the sarge d-i released with a known remote
security hole, and there has been no (or maybe 1 by now ?) d-i update since
then.
> Where this would help solve time critical issues is *before* the
> release of etch, where a late change could cause us to miss a release
> deadline. However, the d-i team seemed to believe this was low-risk.
Yeah, well, i disagree on this. Taking the last time as example, all
development on the kernel was frozen by the d-i team, and we released with
a known remote exploit in d-i. And again this time, d-i freeze is scheduled
first week of august, and this means we need to have the kernels frozen a week
or so before that. This is something like 5 month before the actual release
date of etch.
So, given these, i am dubious of any claim on the subject made by the d-i
team.
> I do believe that our consensus was correct based on what we knew at
> the time - however, it now sounds like this information may have been
> incorrect so we should re-discuss.
I have some trouble with this too, i believe that at least some in the meeting
must have known about this new information, and either forgot about it, or
chose to ignore it, or whatever.
Friendly,
Sven Luther
>
> --
> dann frazier
>
> ---------------------------------------------------------------------------------------
> Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
Reply to: