Re: About a mass bug report not based on Sid or Jessie.
On Tue, Apr 22, 2014 at 01:14:57PM -0700, Russ Allbery wrote:
> > (a) Diffs are not made to be readable, they are made to update
> > things. As those diffs are the result of an automatic processs, you
> > should only need to look at the updated file, not at the diff.
> > Moreover, if they are unreadable, so are the file being diffed itself.
> > Being readable should not be a concern here.
>
> This is absolutely not true in Debian's processes. Both the release team
> and the security team use diffs as first-class artifacts for doing code
> review.
Sorry, I was referring only to the kind of diffs that would result
from running autoreconf, not to diffs in general. Either you trust
autoreconf or you do not. If you trust autoreconf, you will not have
to look at the diffs it creates, the same way you trust the compiler
and look at the source files, not at the binary files created by the
compiler.
> > (c) Security bugs are usually fixed in the actual source (.c, .h, etc)
> > and rarely in the build system (Makefiles, configure, etc).
>
> On several cases I have had to make changes to the build system as part of
> security fixes. [...]
Yes, sometimes we have to do that. Fine. Change things that have to be
changed in the build system first and make a patch for that. Then
regenerate the other files automatically and create another patch for
that. Security people will only have to review the first patch, which
will be small, not the second one, which is automatic.
The argument that "big patch makes auditing code a nightmare" should
not hold anymore now that we have a source format allowing individual
patches in debian/patches. If not, what did we gain by splitting diffs
in debian/patches, then?
Reply to: