On Tue, 21 Feb 2012, Gunnar Wolf wrote:
> 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.
Well, for all the stuff I've been downstream of, I think I've managed to do
it for everything but hplip. It really means you have to track upstream VCS
and look at the changes very often, because when they pile up... for hplip,
I had to do it by skimming the changes and looking for obvious crap, as the
volume was too big and it came as a code dump instead of incremental
changes. And even just skimming the changes took a few hours, and I had to
just plain ignore any changes to the PPD files or I'd go insane.
Closed development and code dumps are nasty.
Tracking deviations is a matter of instrumenting things properly, and it
adds barely an hour per release after you've got things set up. Basically,
it requires a good VCS, tracking upstream VCS, and tracking upstream
tarball/whatever releases, and using the VCS diff :p When there is no
upstream VCS, there are no deviations to track, and likely the most you can
do is to pester upstream to do proper release signatures.
It can get worse. The worst upstream I have about it so far is Intel's
processor microcode people. Unsigned releases, absolutely impossible to
contact upstream except indirectly by asking favours of some Intel employees
that can be found on LKML, what looks from the outside to be an absolute
nutjob of a microcode release management... The best I could do there was
to expose the weirdness as a commented changelog of the timeline of each
microcode[1], track deviations in each microcode (hash every opaque blob
inside the metadata container and track it across every public microcode
release since 2008 -- no deviations found to date), and add some guard time
between upstream releases and Debian releases.
[1] The package has the full changelog, but the relevant portions for each
new release are also in the Debian changelog:
http://packages.debian.org/changelogs/pool/non-free/i/intel-microcode/current/changelog
> 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.
You should not limit yourself to just that paragraph when reading what I
wrote. It is far less about auditing, and far more about doing what is
possible to try to shield the users from trojans added by a third-party to
the release distribution points and public VCS (and not by a rogue upstream
-- that one can be avoided only if you audit everything, and that's often
downright impossible).
Only you can judge whether you could/should/need to do better.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120222135808.ga21...@khazad-dum.debian.net
