[ For the full context, see the -devel thread starting at
http://lists.debian.org/debian-devel/2010/03/msg00038.html ]
On Thu, Mar 04, 2010 at 01:12:26PM -0800, Russ Allbery wrote:
> > Russ, while we are at it, would you mind a bug report on the policy to
> > suggest (starting at SHOULD?) to store md5sums in packages?
>
> Not that I've had any time to work on Policy (or Lintian) in the last
> month, but that does seem reasonable to me. It seems to be a widespread
> best practice already, and a lot of people are turning up in this thread
> to say that they find it useful.
Here we go.
Currently, packages ships file checksums which are computed at package
build time by the means of dh_md5sums (usually), and stored under
/var/lib/dpkg/info/*md5sums. Several people find those checksums
useful, mostly for file corruption detection a-la CRC.
Empirical tests show that the archive coverage is pretty good, most
packages seem to ship those checksums.
Hence, there is a desire to turn a similar feature into, for start, a
SHOULD requirement, meant to become a MUST later on.
However, a few generality shortcomings should probably be addressed,
such as the usage of different checksumming mechanisms. Even though the
intented purpose of those checksums is not intrusion detection, it would
be nice to use stronger checksums such as sha1 and, more generally, to
not have the specific kind of checksum used carved in stone.
Thanks for considering,
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Stefano Zacchiroli <za...@debian.org> (04/03/2010):
> Empirical tests show that the archive coverage is pretty good, most
> packages seem to ship those checksums.
That can be seen this way:
| $ wget -q http://lintian.debian.org/tags/no-md5sums-control-file.html -O -|grep -c '<h2 class="tag">'
| 249
Mraw,
KiBi.
If we are moving that way, maybe it would make sense for the checksums
to be generated by dpkg-buildpackage.
Cheers,
--
Bill. <ball...@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
>> Currently, packages ships file checksums which are computed at package
>> build time by the means of dh_md5sums (usually), and stored under
>> /var/lib/dpkg/info/*md5sums. Several people find those checksums
>> useful, mostly for file corruption detection a-la CRC.
>> Empirical tests show that the archive coverage is pretty good, most
>> packages seem to ship those checksums.
>> Hence, there is a desire to turn a similar feature into, for start, a
>> SHOULD requirement, meant to become a MUST later on.
> If we are moving that way, maybe it would make sense for the checksums
> to be generated by dpkg-buildpackage.
One does have to be able to exclude some things on a per-package basis
since there are some weird cases in the archives. (Files in
/var/lib/[ai]spell are the one case that Lintian knows about at present.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Repeating myself and expaning my thoughts for the sake of having it in
the BTS.
Are you sure this is something that policy must spell out? Couldn't that
be tucked into the dpkg specs, which are outside of policy?
In many packages the binary targets end with these 3 commands (or the
lowlevel equivalents):
dh_gencontrol (dpkg-gencontrol)
dh_md5sums (find | xargs md5sum)
dh_builddeb (dpkg-deb)
If checksum files are to become a MUST directive then they should be
generated by dpkg as part of the lowlevel build process. Requiring every
package to build the checksum file itself is rather pointles. This could
be done as part of building the actual deb file in dpkg-deb.
I would like to propose a different mechanism though, one that also
improves the usefullness. I would propose to generate the checksum file
as part of dpkg-gencontrol. The reason for this is so that
dpkg-gencontrol can include a digest of the the checksum file
(e.g. sha256sum of the file itself) in DEBIAN/control. dpkg-genchanges
could then include that in the changes file. The end goal would be to
include the digest of the checksum file in the Packages.gz files and
therefore in the trust path. The local checksum files could then be
verified and trusted for a security check.
Either way this would be a change in dpkg and not policy directly.
MfG
Goswin
PS: This will only work though if the filename of the checksum file is
changed so packages that call dh_md5sums after dh_gencontrol do not
overwrite the file. But that goes nicely together wih changing the
checksum algorithm to something crypographically strong.
> Bill Allombert <Bill.Al...@math.u-bordeaux1.fr> writes:
>> On Thu, Mar 04, 2010 at 11:00:45PM +0100, Stefano Zacchiroli wrote:
>
>>> Currently, packages ships file checksums which are computed at package
>>> build time by the means of dh_md5sums (usually), and stored under
>>> /var/lib/dpkg/info/*md5sums. Several people find those checksums
>>> useful, mostly for file corruption detection a-la CRC.
>
>>> Empirical tests show that the archive coverage is pretty good, most
>>> packages seem to ship those checksums.
>
>>> Hence, there is a desire to turn a similar feature into, for start, a
>>> SHOULD requirement, meant to become a MUST later on.
>
>> If we are moving that way, maybe it would make sense for the checksums
>> to be generated by dpkg-buildpackage.
>
> One does have to be able to exclude some things on a per-package basis
> since there are some weird cases in the archives. (Files in
> /var/lib/[ai]spell are the one case that Lintian knows about at present.)
Why?
A use case for the md5sum file is to show all files that are modified in
respect to what the deb contains. The files are modified and should show
up as not matching the md5sum. I think it is a bug of [ai]spell to ship
the files if they modify them.
MfG
Goswin