Bill Davidsen <davidsen@tmr.com> wrote:
It seems that you missd the fact that it has been introduced 2 weeks before
cdrtools-2.01-final came out and people on LKML did complain that I did not
cause cdrtools to become unstable from introducing untested code.
Announced (in case of an incompatible change) means:
- prominent developers of code that uses the interface that is to
be changed need to be informed a sufficent time _before_ the
incompatible change is applied.
In general, it would make Linux a mature project if such changes would be
discussed for being reasonable with other people ( e.g. with experienced
programmers like me).
This was not a change made because it would be nice, it was made because
it became public information that anyone who could burn could change the
firmware. Security fixes sometime do have to be done quickly, evil
people do tend to jump on any opening in the time between a
vulnerability becoming public and being fixed.
This is unfortunately nonsense.
If you have a security problem, you usually fix the problem and to not
change the interfaces. In special when it was posible to fix the security
problem _whithout_ breaking the interface as in our case:
The Security problem was that the Linux kernel did not check for write
permission in order to allow SCSI generic commands to be send.
The onvious fix wouild have been to change the kernel to correctly require
write permission on a fd for the SD_IO ioctl.
You are an experienced programmer, you are aware that sometimes a quick
fix needs to be made and tuned after the fact.
And as I am an experienced programmer, I know that a clean fix that
would just require write access would be even much simpler to write than
what actually has been done.