Re: rc3 timeline
Hi Joey,
I am looking for some advice on releasing 2.4.27-9, or not as
the case may be.
There are a few security bugs that have been found recently
that are patched. Everything else is pretty minor. The changelog
is below for your reference. And have been checking, and there
do not seem to be any ABI changes so far.
Part of this is due to Micah Anderson looking through some old
CAN entries that we thought were fixed but were not, or otherwise
slipped through the cracks somehow. All good.
There is also a problem (my fault) with some stray files
in kernel-patch-deabian that mean unapply and apply don't always
work. Actually, I think that is pretty bad. Though most people
would probably never notice as they probably don't use patch and
unpatch enough for it to fall over - I only just noticed this week myself.
The unfortunate problem is that the rc3 timeline meens if
a new 2.4.27 is to go in, it needs to be uploaded ASAP.
This in itself is a problem, because all the different arches
will need to update to the new kernel-source package, and
that typically takes a while.
Then there is also the problem that this kernel hasn't been released -
most of these changes were added in the past week or so - and thus
hasn't been tested much. Actually, it probably hasn't even been
compiled on a buch of architectures.
And to make matters just that little bit worse, tomorrow (i.e. the
next 24 hours) is the last day I can work on it for a full week
as I am attending a Debian Mini-Conf in China and am not sure
of my schedule or my connectivity. But I am pretty sure I won't
be able to sit down for hours at a strech to fix kernel packages,
which is typially what is required.
Josh Kwan is the other person who releases 2.4.27 kernel-source.
There are others on the kernel-team who could also do it.
But I feel kind of bad putting everything on other's shoulders.
In a nutshell, I am concerned about making a release that turns
out to be bad and not being around to fix it. The current 2.4.27
seems quite stable, and I am hesitent to risk that. However, I also
realise that it might be better to get these fixes in now,
else they might never get in for Sarge. So I would really like
Joey, or someone else to advise me on what they would like me to do.
I am putting this in this email as I have to go to sleep now.
No slight to anyone who is involved in maintaining 2.4.27 intended.
--
Horms
kernel-source-2.4.27 (2.4.27-9) UNRELEASED; urgency=low
* There was a stray file in 2.4.27-8. Don't include it this time.
(Simon Horman) (closes: Bug#291536)
* Updated kernel-tree description from Martin F Krafft
(Simon Horman)
* Updated apply script so it can handle point versions
(Simon Horman)
* 134_skb_reset_ip_summed.diff: resolve checksumming exploit in
fragmented packet forwarding (Joshua Kwan)
* 135_fix_ip_options_leak.diff: [CAN-2004-1335] fix leak of IP options
data. (Joshua Kwan)
* 136_vc_resizing_overflow.diff: [CAN-2004-1333] make sure VC resizing
fits in 16 bits. (Joshua Kwan)
* 137_io_edgeport_overflow.diff: [CAN-2004-1017] fix buffer overflow
(underflow, really) that opens multiple attack vectors. (Joshua Kwan)
* 138_amd64_syscall_vuln.diff: [CAN-2004--1144] fix the "int 0x80 hole"
that allowed overflow of the system call table. (Joshua Kwan)
* 139_sparc_context_switch.diff: fix FPU context switching dirtiness on
sparc32 SMP. (Joshua Kwan)
* 140_VM_IO.diff: [CAN-2004-1057] fix possible DoS from accessing freed
kernel pages by flagging VM_IO where necessary.
* 141_acpi_noirq.patch:
[ACPI] Enhanced PCI probe, CONFIG_HPET_TIMER build warning fix
(Simon Horman)
* 142_acpi_skip_timer_override.diff:
[ACPI] skip_timer_override backport from 2.6
including early PCI bridge detection. (Simon Horman)
* 121_drm-locking-checks-3.diff: LOCK_TEST_WITH_RETURN build cleanup
(Simon Horman)
* [CAN-2005-0204]: AMD64, allows local users to
write to privileged IO ports via OUTS instruction
(Simon Horman)
Reply to: