Re: leaks in our only-signed-software fortress
Henrique de Moraes Holschuh dijo [Sat, Feb 18, 2012 at 10:46:50AM -0200]:
> Good packaging developers go to great lengths to be sure they are not
> going to distribute anything trojaned. This takes a lot of work, and
> often requires very goot working relationship with upstream to the point
> of getting upstream to change his processes. This does include tracking
> deviations from VCS to upstream releases, going over upstream changes
> when possible, and using crypto properly to verify authenticity of
> upstream commits and tarballs (when available. When it is not
> available, educating upstream about it is required).
Sadly, I think this is more propaganda and wishful thinking than
reality. And if I'm going to badmouth somebody, I'll badmouth myself.
Depending on the project this is about, I'll check different
things. Some of my packages are quite big, and to be honest, more
complex than what I can understand (so it could be argued I was
irresponsible for packaging them to begin with). For those, I usually
look at upstream's changelog or announcement, and try to match them
with the open bugs in the BTS. If the upstream announcement includes
checksums, I'll (often, at least) verify the tarballs I get. But I
don't check the bits of diff between two revisions, surely not for
large changes.
In the case of smaller packages (most of what I maintain are libraries
I use for my systems), I often check if they are still offer a
coherent API, by trying my own stuff on them before
uploading. Whenever the code includes test suites, I include
them. However, I do _not_ audit the code itself.
So, either I am among Debian's biggest liabilities, or your paragraph
reflects what we want others to think about us. My packages tend not
to break, and I think they meet Debian's standards, but they are far
from audited by me.
Reply to: