Re: kernel/d-i/security/release meeting at DebConf6
* Sven Luther ([EMAIL PROTECTED]) [060526 10:20]: Well, it was my understanding that both those packages where living in a differnt section, namely etch and etch-whatever, which would take care of the problem. Failing that, it is easy enough to handle the problem in the same way as we want to handle the sid/etch kernel dichotomy, in case we froze on a 2.6.16 kernel. Both packages will have to live in etch. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
On Thu, May 25, 2006 at 05:10:57PM -0700, Steve Langasek wrote: On Tue, May 23, 2006 at 07:08:41PM +0200, Sven Luther wrote: On Tue, May 23, 2006 at 09:47:08AM -0700, Steve Langasek wrote: On Mon, May 22, 2006 at 11:38:46PM +0200, Sven Luther wrote: On Mon, May 22, 2006 at 01:52:47PM -0700, Steve Langasek wrote: Perhaps we disable new kernel features for etch 1/2? e.g., limit new feature to new hardware support. For example, we wouldn't want to turn on something as drastic as preempt in a stable update. So how do you structure this? I would expect that updates limited to new hardware support shouldn't normally change the kernel ABI at all, which makes it hard to make both the old and new kernel versions available for installation. If it is a new kernel ABI (either because the version number has simply been changed on it, or for other reasons), what gets done with out-of-tree module packages? If ever the new out-of-tree module and d-i kernel reunification is in place, it will be easy enough to rebuild all packages which depend on the abi-changed kernel. rebuilding them doesn't address the question of making them available for both old and new kernels. Since the assumption seems to be that etch 1/2 Well, they will obviously have the abi number embedded in their package name, and a virtual package / provides who will handle the transition, so this should be no real problem. It is a technology that is well proven and mastered since years in debian. See the ocaml example. Er, the problem is that you're talking about keeping *two* sets of packages around. That implies two source packages; at least some members of the ftp Well, it was my understanding that both those packages where living in a differnt section, namely etch and etch-whatever, which would take care of the problem. Failing that, it is easy enough to handle the problem in the same way as we want to handle the sid/etch kernel dichotomy, in case we froze on a 2.6.16 kernel. team don't like having source packages building binaries that aren't mentioned in debian/control of the source package, and keeping one source I fail to see the problem here. package for two kernel versions, one of them added at a later date and for an undetermined version, pretty definitely means that one set of these binaries aren't mentioned in debian/control of the current source package. No, see above. The ftp team might be ok with making an exception here, I'm just saying that's a conversation to have *before* release instead of when it comes time to do etch 1/2 and people suddenly realize there's no infrastructure to fully support both kernels. Ah, yes, i fully agree with you about that. Like most of the discussions we are having now should have been handled last fall :) uses a different upstream kernel version than etch, to be able to continue providing security support for the etch versions it seems that you need a separate source package (or a whole new suite in dak complete with w-b support!) for any packages being rebuilt against the etch 1/2 kernel. You need a source package, which will be able to generate its debian/control semi-automatically, to adjust to the kernel abi change, yes. This is also something we have done in the ocaml case recently. Needs some coordination and policy for the out of tree modules, and maybe binNMUs who are able to regenerate the debian/control in this way, but nothing otherwordly. Changing the list of packages in debian/control in the standard debian/rules targets is almost always something we treat as an RC bug; so binNMUs are definitely out. Indeed. But why be so inflexible ? Why not see that there are some limited cases where this is useful, and this is one of them. What is so definitively wrong in this case ? Also, the problem is not as you think, the idea is only to modify the debian/control in an automated way in the source upload, so no, it would not be binNMUs, but some kind of automated sourceNMUs. We have the same problem in the ocaml case, and see what happened, despite our care, some of the m68k packages where rebuilt with the older ocaml, the same problem can happen here if we are not carefull and will cause a mess. Which means sourceful uploads, which means the binaries for the old kernel no longer correspond to the current source package, which means rene tags them as candidates for removal... We can simply append some random tag to the new source-upload, or upload them to a separate archive, and the problem goes away by itself. There are always solution if there is the will to implement them :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
On Fri, May 26, 2006 at 11:39:30AM +0200, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [060526 10:20]: Well, it was my understanding that both those packages where living in a differnt section, namely etch and etch-whatever, which would take care of the problem. Failing that, it is easy enough to handle the problem in the same way as we want to handle the sid/etch kernel dichotomy, in case we froze on a 2.6.16 kernel. Both packages will have to live in etch. Ok, so we need to find a scheme which appends some tag or something to the module names. Ideally, this would be the full kernel version (2.6.16-2-flavour), which i believe would be enough for our purpose. kernel-package already does this for binary package, we only need to transpose this to the source package too, and everyone is happy. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
* dann frazier ([EMAIL PROTECTED]) [060524 05:33]: 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. Actually, if I understood everything correct, the issue with the long lines used to be that on the way from the buildd to the buildd maintainer, the long line in the changes-file could be broken by MTAs, and this has been fixed. The best way to test if this is all would be to upload one source package producing all udebs to experimental, and see what happens. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
On Wed, May 24, 2006 at 10:27:14AM +0200, Andreas Barth wrote: * dann frazier ([EMAIL PROTECTED]) [060524 05:33]: 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. Actually, if I understood everything correct, the issue with the long lines used to be that on the way from the buildd to the buildd maintainer, the long line in the changes-file could be broken by MTAs, and this has been fixed. The best way to test if this is all would be to upload one source package producing all udebs to experimental, and see what happens. A, good thinking. Who volunteers for doing so ? I don't think i am the right person, as i would again be seen as over-stepping my place, and stuff. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
On Wed, May 24, 2006 at 10:31:08AM +0200, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [060524 06:33]: 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. You mean, a remote root exploitable hole? If so, which bug, and why wasn't that information sent to debian-release? Or is it just a remote DoS-issue? Ah, i don't remember the details exactly. It was indeed a remote security issue, but i don't remember if it was an exploit or a DoS kind of thingy. The issue was well known by the release managers of the time, and the decision to ship with it was taken in conjunction between the release managers and the d-i team. The rationale was that d-i was going to install a newer kernel anyway, and the system would be vulnerable only during the time of the install, which still seemed unacceptable to me back then, altough a bit less so if it was just a DoS, but my understanding of back then was that it was a hole. I may have been wrong though. The issue is widely documented on the lists, debian-boot, probably debian-kernel, and maybe even debian-release in april 2005, as well as the subsequent kernel changelog entry of the sarge kernel. The problem back then was that the poor kernel state meant a 30+ days upgrade path, which was partly caused by the kernel, but partly by the d-i folk too. 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. You are ignoring that we have scheduled a time to update the kernel again before release of etch. Ah, nice. But would this include an abi-changing kernel upgrade ? I fear not, given the trouble of abi changes for security upgrades. In any case, it doesn't include an upstream kernel version bump in the planes i have read, right ? We should be able to rebuild all those packages on all release arches within a couple of days, a week at most, if we do it right. This doesn't seem to be worth the effort to many in this discussion though, who prefer the status-quo. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
* Sven Luther ([EMAIL PROTECTED]) [060524 11:23]: On Wed, May 24, 2006 at 10:31:08AM +0200, Andreas Barth wrote: You are ignoring that we have scheduled a time to update the kernel again before release of etch. Ah, nice. But would this include an abi-changing kernel upgrade ? I fear not, given the trouble of abi changes for security upgrades. In any case, it doesn't include an upstream kernel version bump in the planes i have read, right ? It would even allow a newer minor kernel version, so an abi-change should be possible as well. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
On Wed, May 24, 2006 at 11:35:00AM +0200, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [060524 11:23]: On Wed, May 24, 2006 at 10:31:08AM +0200, Andreas Barth wrote: You are ignoring that we have scheduled a time to update the kernel again before release of etch. Ah, nice. But would this include an abi-changing kernel upgrade ? I fear not, given the trouble of abi changes for security upgrades. In any case, it doesn't include an upstream kernel version bump in the planes i have read, right ? It would even allow a newer minor kernel version, so an abi-change should be possible as well. Nice then, the question remains of how often and in what timeframe we can do such. Imagine there is a security issue shortly before the release, will we say like last time, let's ship with it, because we have not put into place the procedure to handle it in a timely fashion ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
* Sven Luther ([EMAIL PROTECTED]) [060524 11:52]: On Wed, May 24, 2006 at 11:35:00AM +0200, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [060524 11:23]: On Wed, May 24, 2006 at 10:31:08AM +0200, Andreas Barth wrote: You are ignoring that we have scheduled a time to update the kernel again before release of etch. Ah, nice. But would this include an abi-changing kernel upgrade ? I fear not, given the trouble of abi changes for security upgrades. In any case, it doesn't include an upstream kernel version bump in the planes i have read, right ? It would even allow a newer minor kernel version, so an abi-change should be possible as well. Nice then, the question remains of how often and in what timeframe we can do such. Imagine there is a security issue shortly before the release, will we say like last time, let's ship with it, because we have not put into place the procedure to handle it in a timely fashion ? There will definitly be a time when it is too late to replace the kernel without delaying the release (just consider that we e.g. notice after starting the CD build that there is some issue). Also, we need a minimum testing periode for the final kernel and the final installer. If we set that minimum testing periode to something like 6 weeks (which seems sane to me), we cannot update the installer later than mid of October, and the kernel needs to be a little bit earlier, which is like the beginning of October. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
On Wed, May 24, 2006 at 12:04:59PM +0200, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [060524 11:52]: On Wed, May 24, 2006 at 11:35:00AM +0200, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [060524 11:23]: On Wed, May 24, 2006 at 10:31:08AM +0200, Andreas Barth wrote: You are ignoring that we have scheduled a time to update the kernel again before release of etch. Ah, nice. But would this include an abi-changing kernel upgrade ? I fear not, given the trouble of abi changes for security upgrades. In any case, it doesn't include an upstream kernel version bump in the planes i have read, right ? It would even allow a newer minor kernel version, so an abi-change should be possible as well. Nice then, the question remains of how often and in what timeframe we can do such. Imagine there is a security issue shortly before the release, will we say like last time, let's ship with it, because we have not put into place the procedure to handle it in a timely fashion ? There will definitly be a time when it is too late to replace the kernel without delaying the release (just consider that we e.g. notice after starting the CD build that there is some issue). Also, we need a minimum testing periode for the final kernel and the final installer. If we set that minimum testing periode to something like 6 weeks (which seems sane to me), we cannot update the installer later than mid of October, and the kernel needs to be a little bit earlier, which is like the beginning of October. Err, do you really need to retest everything when a kernel change only includes a small set of security fixes ? I think 6 weeks may be overkill there, unless naturally you are speaking of a version bump with a huge load of changes. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
* Sven Luther ([EMAIL PROTECTED]) [060524 12:14]: On Wed, May 24, 2006 at 12:04:59PM +0200, Andreas Barth wrote: There will definitly be a time when it is too late to replace the kernel without delaying the release (just consider that we e.g. notice after starting the CD build that there is some issue). Also, we need a minimum testing periode for the final kernel and the final installer. If we set that minimum testing periode to something like 6 weeks (which seems sane to me), we cannot update the installer later than mid of October, and the kernel needs to be a little bit earlier, which is like the beginning of October. Err, do you really need to retest everything when a kernel change only includes a small set of security fixes ? I think 6 weeks may be overkill there, unless naturally you are speaking of a version bump with a huge load of changes. If it is a minimal patch, we will see. However, I don't think it's usefull to discuss that now in theory. We need to see the patchset (and also what amount of open issues there still is elsewhere) to decide what to do. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
[ keeping the cross-post and please keep it cross-posted ] On Sun, May 21, 2006 at 01:09:45PM -0500, dann frazier wrote: hey, Frans Pop assembled an informal BoF at DebConf to discuss cross-team issues related to the kernel[1]. We discussed the following topics: snip/ * Non-free modules + firmware * External module packages Non-free modules + firmware --- It was noted that Bastian Blank is working on splitting non-free modules out of main into their own source package. frans It should happen pretty soon; we need the modules in non-free before we do the d-i work; d-i will probably ask for an exception so that d-i can install them as though they were in main because frans thinks we won't have time for that (modules really won't be in main) This means that non-free modules will be on installer cds. The needed exception would be to allow etch to be used as a transition period. manoj this isn't a release management decision, we don't want another GR aba a GR would be time consuming manoj what about a free and a non-free installer image, where the non-free installer is in the non-free section What work is done to get the Linux kernel completely libre? Who is talking with hardware manufactures to GPL their code? aba 2-3 different options * images like today w/ non-free udebs * only put the modules on non-free, make users pick them up * dropping support for devices that require non-free fw completely manoj only option (for permitting non-free modules on the etch installer) is a gr to once again modify our social contract suggestion was made to have users click-through to opt-in to use non-free firmware. manoj believes this is still a violation of the social contract and will require a GR (because the non-free modules would still be on the media) manoj you can ask for an official interpretation of the social contract from the project secretary. manoj suggests two different installers, but joeyh is concerned over additional maintenance/support The deliver modules/users opt-in approach would give us enough time, but requires a GR. joeyh maybe keep it as a separate image that can be combined by the user, problem is that the solution varies with each installation method floppy install needs another floppy; netboot needs another layered initramfs joeyh multi-sessions could be used for cd installs In conclusion, we believe the following options exist: a) debian doesn't support this hardware b) GR to allow combining c) make users combine External module packages Its believed that if we solve the non-free external module package issue, we will also have solved this one. Beside non-free will the external module package help hardware manufactures to get their libre driver in Debian - divergence between official kernel packaging and kernel-package (k-p) The /lib/modules/$(uname -r)/build symlink issue was introduced by Manoj. The attendees agreed to move this to a discussion thread on debian-kernel, in probably a week's time. Please post the outcome also to debian-boot Cheers Geert Stappers [1] http://lists.debconf.org/lurker/message/20060517.065113.4f39d60e.en.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
On Tue, May 23, 2006 at 09:10:54AM +0200, Geert Stappers wrote: [ keeping the cross-post and please keep it cross-posted ] On Sun, May 21, 2006 at 01:09:45PM -0500, dann frazier wrote: hey, Frans Pop assembled an informal BoF at DebConf to discuss cross-team issues related to the kernel[1]. We discussed the following topics: snip/ * Non-free modules + firmware * External module packages Non-free modules + firmware --- It was noted that Bastian Blank is working on splitting non-free modules out of main into their own source package. frans It should happen pretty soon; we need the modules in non-free before we do the d-i work; d-i will probably ask for an exception so that d-i can install them as though they were in main because frans thinks we won't have time for that (modules really won't be in main) This means that non-free modules will be on installer cds. The needed exception would be to allow etch to be used as a transition period. manoj this isn't a release management decision, we don't want another GR aba a GR would be time consuming manoj what about a free and a non-free installer image, where the non-free installer is in the non-free section What work is done to get the Linux kernel completely libre? Who is talking with hardware manufactures to GPL their code? We did some work to make the drivers with non-free firmware at least be distributable (many of them originally came with GPLed binary-only blobs), and the manufacturers where rather open about this. That said, asking them to free their actual firmware is something rather doubtful to work, especially given the current situation of upstream linux deciding to ignore the issue. By moving those drivers to non-free, we raise the user awareness of the issue, and we should even document it during the install (a dialog saying this driver is non-free because of blah-blah-blah maybe), and this should in the mid-to-long term help out convince the manufacturers to go the free route. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
On Tue, May 23, 2006 at 09:47:08AM -0700, Steve Langasek wrote: On Mon, May 22, 2006 at 11:38:46PM +0200, Sven Luther wrote: On Mon, May 22, 2006 at 01:52:47PM -0700, Steve Langasek wrote: Perhaps we disable new kernel features for etch 1/2? e.g., limit new feature to new hardware support. For example, we wouldn't want to turn on something as drastic as preempt in a stable update. So how do you structure this? I would expect that updates limited to new hardware support shouldn't normally change the kernel ABI at all, which makes it hard to make both the old and new kernel versions available for installation. If it is a new kernel ABI (either because the version number has simply been changed on it, or for other reasons), what gets done with out-of-tree module packages? If ever the new out-of-tree module and d-i kernel reunification is in place, it will be easy enough to rebuild all packages which depend on the abi-changed kernel. rebuilding them doesn't address the question of making them available for both old and new kernels. Since the assumption seems to be that etch 1/2 Well, they will obviously have the abi number embedded in their package name, and a virtual package / provides who will handle the transition, so this should be no real problem. It is a technology that is well proven and mastered since years in debian. See the ocaml example. uses a different upstream kernel version than etch, to be able to continue providing security support for the etch versions it seems that you need a separate source package (or a whole new suite in dak complete with w-b support!) for any packages being rebuilt against the etch 1/2 kernel. You need a source package, which will be able to generate its debian/control semi-automatically, to adjust to the kernel abi change, yes. This is also something we have done in the ocaml case recently. Needs some coordination and policy for the out of tree modules, and maybe binNMUs who are able to regenerate the debian/control in this way, but nothing otherwordly. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
On Mon, May 22, 2006 at 11:38:46PM +0200, Sven Luther wrote: On Mon, May 22, 2006 at 01:52:47PM -0700, Steve Langasek wrote: Perhaps we disable new kernel features for etch 1/2? e.g., limit new feature to new hardware support. For example, we wouldn't want to turn on something as drastic as preempt in a stable update. So how do you structure this? I would expect that updates limited to new hardware support shouldn't normally change the kernel ABI at all, which makes it hard to make both the old and new kernel versions available for installation. If it is a new kernel ABI (either because the version number has simply been changed on it, or for other reasons), what gets done with out-of-tree module packages? If ever the new out-of-tree module and d-i kernel reunification is in place, it will be easy enough to rebuild all packages which depend on the abi-changed kernel. rebuilding them doesn't address the question of making them available for both old and new kernels. Since the assumption seems to be that etch 1/2 uses a different upstream kernel version than etch, to be able to continue providing security support for the etch versions it seems that you need a separate source package (or a whole new suite in dak complete with w-b support!) for any packages being rebuilt against the etch 1/2 kernel. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: kernel/d-i/security/release meeting at DebConf6
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. buildd issue - it'd be nice if we could be from an unpacked kernel, but you can't build-dep on that so its a FTBFS. Which is why it makes the most sense to build them from linux-2.6, but i won't argue this point here. I think that the decision of whether or not to build them from linux-2.6 is a separate issue. If doing so is the right thing, let's do it, if its not, let's fix the build issue. 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? manoj new kernel package will have some new features the kernel team might like - versioning is messed up, manoj is integrating abi number, etc, into k-p dannf what if we split up centralized udeb source packages to manage a certain set of archs 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). 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. 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. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
Re: kernel/d-i/security/release meeting at DebConf6
On Sun, May 21, 2006 at 01:09:45PM -0500, dann frazier wrote: hey, Frans Pop assembled an informal BoF at DebConf to discuss cross-team issues related to the kernel[1]. Attendees included: Sorry I wasn't able to make this meeting, guys. Random thoughts: Kernel Updates During Etch Lifetime --- This discussion is based upon the idea of providing an updated kernel with new hardware support during the etch *stable* release. We've been referring to this update as etch and a half. Would we keep both the etch and etch 1/2 kernels? Yes - we would not drop support for a stable kernel in a stable release. 2 months was suggested for user testing of a kernel prior to including it in a point release. To enable this possibility, d-i will require some work. fjp said that, for d-i, the critical udeb is base-install which builds a list of available kernels and selects a default from that. If a good default can be found, it will be installed. If no default is found, it will just show the list of kernels it did find. (With medium priority it will always show the list, but with the default selected). base-install selects this default by taking the stem name of the kernel and the major version (kernel-image-2.4, linux-image-2.6). How the kernel is named will be very important. What will also be important is what we expect to run after the kernel has been released. We want to use the same install kernel as the target, to avoid hitting bugs late in the install. We would want to add the etch 1/2 kernel to the installer, and not drop the etch kernel from the installer. A blocker for d-i would be 2.6.12 - 2.6.14 style changes (devfs drop). Frans suggested talking with Marco D'itri (or perhaps GregKH) about planned udev stability. Moritz is fairly sure that GregKH is planning to keep a stable interface. Frans says Linus has also mentioned that he doesn't plan to accept breakages to this interface. This isn't a blocker *just* for d-i. Consider how painful the upgrade path is from sarge to etch on account of the circular dependencies between the kernel, udev, and initramfs generators. This may be something we just have to cope with for sarge-etch, but do you really want to compound the problem by adding etch - etch 1/2 and/or etch 1/2 - etch+1 to the mix? Perhaps we disable new kernel features for etch 1/2? e.g., limit new feature to new hardware support. For example, we wouldn't want to turn on something as drastic as preempt in a stable update. So how do you structure this? I would expect that updates limited to new hardware support shouldn't normally change the kernel ABI at all, which makes it hard to make both the old and new kernel versions available for installation. If it is a new kernel ABI (either because the version number has simply been changed on it, or for other reasons), what gets done with out-of-tree module packages? Dropping 2.4 from Etch -- aba noted that Holger had spoken with him earlier, and asked if it would be ok to do stable/2.4 maintenance by tracking the latest 2.4 upstream instead of individual security issues. dannf noted that 2.4 has poor upstream security support. Rough consensus was that we cannot support 2.4 in debian for security reasons. If we drop it for etch, Frans would like to drop 2.4 support from the installer as well. d-i will become easier w/o 2.4 support, but only if we drop sarge support in the etch installer. Frans is ok with dropping this sarge support. I agree with all of this, and had a similar discussion with Holger. With no one stepping up to provide the needed security support for 2.4 in etch, are there any further objections to beginning the process of removing the 2.4 kernel packages from unstable? Will someone on the kernel team be willing to drive this? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: kernel/d-i/security/release meeting at DebConf6
On Mon, May 22, 2006 at 01:52:47PM -0700, Steve Langasek wrote: Perhaps we disable new kernel features for etch 1/2? e.g., limit new feature to new hardware support. For example, we wouldn't want to turn on something as drastic as preempt in a stable update. So how do you structure this? I would expect that updates limited to new hardware support shouldn't normally change the kernel ABI at all, which makes it hard to make both the old and new kernel versions available for installation. If it is a new kernel ABI (either because the version number has simply been changed on it, or for other reasons), what gets done with out-of-tree module packages? If ever the new out-of-tree module and d-i kernel reunification is in place, it will be easy enough to rebuild all packages which depend on the abi-changed kernel. This means that all those out-of-tree modules need rebuilding, and maybe a source change if they are hit by the abi breakage. They should thus be included in the original etch 1/2 process, the same as with abi breaking security upgrades. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
kernel/d-i/security/release meeting at DebConf6
hey, Frans Pop assembled an informal BoF at DebConf to discuss cross-team issues related to the kernel[1]. Attendees included: Micah Anderson (micah) Andreas Barth (aba) dann frazier (dannf) Joey Hess (joeyh) Moritz Muehlenhoff (jmm) Frans Pop (fjp) Manoj Srivastava (manoj) ...and a few other folks whose names I don't recall We discussed the following topics: * Which kernel to release with Etch (2.6.16 from AB or current upstream) * Kernel Updates during Etch Lifetime * Dropping 2.4 from Etch * Non-free modules + firmware * External module packages * Divergence Between linux-2.6 packaging and kernel-package behavior * Kernel udeb creation process (possibly using k-p?) This report is based upon notes I took during the meeting, and my recollection. Neither will be completely accurate; and no statements attributed to an individual should be taken as a direct quote. Which kernel to release with Etch - This discussion is related to a thread[2] on debian-kernel about which kernel we will choose for etch. Attendees expressed concern over choosing to move to a new 2.6.x release shortly before etch releases - a kernel that has has a few 2.6.x.y releases would be preferred. With respect to using the Adrian Bunk tree, attendees expressed concern that this tree is unproven. It is possible that Adrian has underestimated the amount of energy it will take to maintain such a branch. Success of this tree may depend upon the assistance of its consumers (such as Debian). It was noted that even if we stick with 2.6.16.x, the kernel team will still need to limit ourselves to cherry picking patches once we freeze, otherwise we may pull in new features/ABI breakages after the freeze. The current release schedule[3] has us freezing the kernel by July 30th. However, aba noted that the kernel freeze is really just a dependency of the d-i schedule. According to Frans, a kernel freeze of October 1 is necessary for d-i's final release candidate to remain on schedule. Andi noted that if we change the kernel later than mid/end July we'll need to do more extensive testing of the sarge-etch upgrade than usual. Kernel Updates During Etch Lifetime --- This discussion is based upon the idea of providing an updated kernel with new hardware support during the etch *stable* release. We've been referring to this update as etch and a half. Would we keep both the etch and etch 1/2 kernels? Yes - we would not drop support for a stable kernel in a stable release. 2 months was suggested for user testing of a kernel prior to including it in a point release. To enable this possibility, d-i will require some work. fjp said that, for d-i, the critical udeb is base-install which builds a list of available kernels and selects a default from that. If a good default can be found, it will be installed. If no default is found, it will just show the list of kernels it did find. (With medium priority it will always show the list, but with the default selected). base-install selects this default by taking the stem name of the kernel and the major version (kernel-image-2.4, linux-image-2.6). How the kernel is named will be very important. What will also be important is what we expect to run after the kernel has been released. We want to use the same install kernel as the target, to avoid hitting bugs late in the install. We would want to add the etch 1/2 kernel to the installer, and not drop the etch kernel from the installer. A blocker for d-i would be 2.6.12 - 2.6.14 style changes (devfs drop). Frans suggested talking with Marco D'itri (or perhaps GregKH) about planned udev stability. Moritz is fairly sure that GregKH is planning to keep a stable interface. Frans says Linus has also mentioned that he doesn't plan to accept breakages to this interface. Perhaps we disable new kernel features for etch 1/2? e.g., limit new feature to new hardware support. For example, we wouldn't want to turn on something as drastic as preempt in a stable update. We wouldn't want an etch 1/2 kernel that requires a large number of changes to userspace packages. Questions about X update issues were brought up; but Frans doesn't think that will affect d-i. What about alsa? We should have a formal agreement about how we *would* do an etch a half ahead of time so we can make sure d-i has any features it should need. This should probably be discussed on -devel to get project-wide buyoff. Frans thinks d-i can make necessary changes in a max of 2 months, but it depends upon what other things may be going on at the time (etch+1 betas, etc) We could make test d-i images available for stable like we currently do for testing. We probably don't need the extreme testing as for the first release. jmm, dannf frans all seem to agree that we should use the etch kernel as the default boot kernel, even after a etch 1/2 kernel is added. jmm wondered if there ways we can
Re: kernel/d-i/security/release meeting at DebConf6
[ drop debian-release from CC ] 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. Which limit? The policy don't specify one and linux-2.6 already broke the 10KiB. A second limitation exists in sarge's version of apt, which is what we might be running on ftp-master. Not an issue if we start this with etch + 1 this will create an upgrade problem for users. Which problem? udebs/deb creation is currently separate - is that a feature? The decision was done before the kernel team was founded. So it is a feature. manoj wonders if maybe kernel-package can do this work. he wouldn't want to build the per-arch mapping into k-p, but might take these from lists on the file system As not all of the images are currently built with k-p and the number will decrease in the future, this is not appropriate. Frans points out that his preference is to continue to keep udeb generation separate from the mainline kernel, to avoid having to do a full kernel release each time we shuffle udeb contents. Currently we have the problem the other way around. We can't rebuild the udebs for every update of the debs. Frans believes that sepearate source packages are more feasible for allowing this type of shuffling If someone goes crazy, it may see this as GPL violation. Bastian -- Punishment becomes ineffective after a certain point. Men become insensitive. -- Eneg, Patterns of Force, stardate 2534.7 signature.asc Description: Digital signature
Re: kernel/d-i/security/release meeting at DebConf6
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 ? A second limitation exists in sarge's version of apt, which is what we might be running on ftp-master. Not an issue if we start this with etch + 1 this will create an upgrade problem for users. Why is this an issue ? The longer Binary: field will only be used in the source package file, right, and as such, it should be no major problem if sarge's apt has a problem with it. The pure binary package file should be mostly ok, so sarge's apt should be happy with this issue. What am i missing here ? buildd issue - it'd be nice if we could be from an unpacked kernel, but you can't build-dep on that so its a FTBFS. Which is why it makes the most sense to build them from linux-2.6, but i won't argue this point here. udebs/deb creation is currently separate - is that a feature? svenl has noted that a porter has to select modules twice - during the kernel build and during the udeb creation manoj wonders if maybe kernel-package can do this work. he wouldn't want to build the per-arch mapping into k-p, but might take these from lists on the file system joeyh notes that kernel-wedge could also support this additional functionality Frans points out that his preference is to continue to keep udeb generation separate from the mainline kernel, to avoid having to do a full kernel release each time we shuffle udeb contents. Yep. Altough these days we upload .deb kernels more often than the d-i team uploads .udeb packages of the same :) Frans believes that sepearate source packages are more feasible for allowing this type of shuffling Indeed. but there is the FTBFS issue mentioned above and which needs solving. 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: ?) ? manoj new kernel package will have some new features the kernel team might like - versioning is messed up, manoj is integrating abi number, etc, into k-p dannf what if we split up centralized udeb source packages to manage a certain set of archs 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. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
On Sun, May 21, 2006 at 10:10:51PM +0200, Bastian Blank wrote: Frans believes that sepearate source packages are more feasible for allowing this type of shuffling If someone goes crazy, it may see this as GPL violation. Ah, excellent point. The source producing some of the .udeb kernel packages are indeed missing in the archive, at least in a temporarily way, but it may be longer for the less-actively-updated arches. Bastian, i wonder what this 'it' is that you mention above :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
