Re: What to do with a kernel bug which lets my package work result look bad ?
Hi,
Rebecca N. Palmer wrote:
> Package: src:linux
There seems to be no such package name.
I got the source by
apt-get install linux-source
so i guess it would be ok to use that package name.
> 'affects' means it will appear in your package's bug list but be marked as
> linux's bug.
It does not keep xorriso (or cdrkit's genisoimage) from
working properly. It just fails to work properly with
flawless output from those programs.
Does that qualify for 'affects' ?
Henrique de Moraes Holschuh wrote:
> Ugh. Yeah, that code looks broken at first glance.
Two sins: It hits the innocent and it defaces its victims.
> Maybe it should instead drop the long name, and return the ISOFS name,
> instead.
This might reduce the probability of a name collision,
but can still collide with some short Rock Ridge name.
Better would probably be a hash text derived from all
available information about the file, which is not very
much at that level of code, i fear.
E.g. a SHA256 of the full really oversized name, plus
some constant salt, should reduce the probability to an
acceptable level and still show reproducible names.
But the actually needed fix is the protection of the
innocent.
> However, one has to check the code throughoutly to ensure it can deal with
> the 255-bytes size.
Will dive into the code and already began to read
http://kernel-handbook.alioth.debian.org
Maybe i can make experiments with s/254/256/ and/or
with truncation to exactly the assumed maximum size.
> Opening a bug report on bugzilla.kernel.org for 'isofs' would be the typical
> way to go about it, I guess.
Shall i do already now or better after i exhausted my code reading
skills and/or managed to get a kernel running with s/254/256/ ?
> OTOH, it is a >10-year old bug, so there are some kudos and credit to be
> proud of for anyone that fixes it :-)
Is there a find-the-oldest-bug contest ?
And is the list open for mere oddities, too ?
(I have some Linux timestamp peculiarities of which i really
don't know whether i shall replay them in libisofs.)
> The code in fs/isofs/rock.c looks like it has lots of cowebs and some
> bitrot, though.
The equivalents in FreeBSD, OpenSolaris, and NetBSD are
even more dusty. Solaris still calls it "High Sierra".
To our luck there are userland tools to read ISO 9660
independently of the kernels. Among them is my xorriso.
Have a nice day :)
Thomas
Reply to: