Re: Crypto signing of packages
>
> Richard Jones <richard@a42.deep-thought.org> wrote:
> >I don't even think maintainer key compromise is the most likely route of
> >trojans, just as effective would be to compromise the maintainers machine,
> >modifying either the original source on which the maintainer depends on for
> >building the debian package or the patch to that source. If the maintainer
>
> How? The original source is md5sum'med, and that md5sum is stored on the
> Debian archive. (I'm assuming here that you're talking about second and
> subsequent releases). The dinstall program will reject uploads with
> incorrect md5sums (trust me, it's happened to me :-) in either the .dsc
> or the .changes file.
>
> In the Debian source, it would be seen in the patch.
>
> 'Course, this _would_ apply if you were uploading a trojan-ised -1
> release..
>
>
Ok I show my ignorance of current procedure ;), however incremental diffs
against a trusted by everyone original source still has the benefit of vetting
of changes between upstream releases, now if I get this one wrong I promise to
go back and read the docs properly ;), but say trojaned upstream release comes
down, maintainer doesnt have time to search all source so uploads the new
release a new md5sum is made for it. Now of course the maintainer
should/could diff the new upstream against the old one (which is what I am
suggesting should be done, with the diff distributed) and easily see any
"evil" changes, however I would guess not every maintainer has the time and/or
expertise to notice everything evil, but if a wider audience sees the b/w
upstream diffs it seems more likely to be found. Now do I have to do a proper
read of the docs or is this type of thing protected against?
Richard Jones
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: