FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 03-10-2010, 05:52 PM
Russ Allbery
 
Default Bug#540215: Introduce dh_checksums

Peter Samuelson <peter@p12n.org> writes:
> [Wouter Verhelst]

>> At any rate, a PGP signature takes a lot of data; much more so than
>> a checksum. It's therefore more economical to produce a signed
>> package.checksums file than it is to produce a package.pgpsigs.

> Huh? Since asymmetric cryptography is so computationally expensive,
> PGP never signs the payload directly. Instead, the payload is hashed
> and then the hash is signed. So it is not (noticeably) more economical
> to sign foo.md5sums than to sign the whole data.tar.gz.

However, since the most common verification action is probably going to be
to check whether a specific file installed on the system has been
modified, Wouter's approach is probably the best implementation strategy.
It's more efficient to compute the checksum of a file, check that it
matches the checksum in the signed file, and verify the signature on that
file than it is to verify the data.tar.gz signature and then extract the
relevant file from it and compare it to the file on disk. Among other
things, you can use the first algorithm with nothing but the signed
checksum files, which are a lot smaller than keeping the whole package
around.

> If you're going to the trouble to download a .deb, why bother with
> signatures at all? Why not just compare the full text directly?

Indeed. It's an efficiency gain for much the same reasons as above, but
not really a security gain.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87y6i0ggal.fsf@windlord.stanford.edu">http://lists.debian.org/87y6i0ggal.fsf@windlord.stanford.edu
 
Old 03-10-2010, 09:19 PM
Frank Lin PIAT
 
Default Bug#540215: Introduce dh_checksums

Hello,

On Mon, 2010-03-08 at 17:36 +0100, Frank Lin PIAT wrote:
> On Thu, 2010-03-04 at 20:08 +0100, Tollef Fog Heen wrote:
> > Frank Lin PIAT wrote:
> > > What about a transitional dh_md5sums that would produce md5sum AND
> > > invoke dh_sha ?
> >
> > Or call it dh_checksums or something so we don't have to change the tool
> > name each time we decide to change the algorithm.
>
> Find a patch attached, for a smooth transition from DEBIAN/md5sums to a
> recent checksum.


Since SHA algorithms is a family, tools and API usually implement
multiple variants. Wouter's initial email suggested to use the name
shasums. I must admit I find this quite sensible for future
improvements. People should be encourage to detect and support SHA-224
and better hash, even though we should only accept sha256 in the archive
for now.

I have still named the helper "dh_checksums", because it we ever want to
ship a different algorithm, we would probably still use the same
(updated) helper to generate that file.

Find an updated patch attached.

Regards,
diff --git a/debian/copyright b/debian/copyright
index a9f950d..162bfc0 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -48,7 +48,7 @@ Copyright: Steve Robbins <smr@debian.org>
License: GPL-2+

Files: dh_md5sums
-Copyright: Charles Briscoe-Smith <cpb4@ukc.ac.uk>
+Copyright: Charles Briscoe-Smith <cpb4@ukc.ac.uk>, Frank Lin PIAT <fpiat@klabs.be>
License: GPL-2+

Files: dh_bugfiles
diff --git a/debian/links b/debian/links
new file mode 100644
index 0000000..3e7d603
--- /dev/null
+++ b/debian/links
@@ -0,0 +1,3 @@
+usr/share/man/man1/dh_md5sums.1.gz usr/share/man/man1/dh_checksums.1.gz
+usr/bin/dh_md5sums usr/bin/dh_checksums
+
diff --git a/dh b/dh
index bcac8da..0aa9bc3 100755
--- a/dh
+++ b/dh
@@ -322,7 +322,7 @@ $sequences{install} = [@{$sequences{build}}, qw{
my @b=qw{
dh_installdeb
dh_gencontrol
- dh_md5sums
+ dh_checksums
dh_builddeb
};
$sequences{'binary-indep'} = [@{$sequences{install}}, @b];
diff --git a/dh_md5sums b/dh_md5sums
index da00090..33bf561 100755
--- a/dh_md5sums
+++ b/dh_md5sums
@@ -2,7 +2,7 @@

=head1 NAME

-dh_md5sums - generate DEBIAN/md5sums file
+dh_checksums - generate DEBIAN/*sums files (md5, sha256)

=cut

@@ -12,18 +12,24 @@ use Debian:ebhelper:h_Lib;

=head1 SYNOPSIS

+B<dh_checksums> [S<I<debhelper options>>] [B<-x>] [B<-X>I<item>] [B<--include-conffiles>]
+
B<dh_md5sums> [S<I<debhelper options>>] [B<-x>] [B<-X>I<item>] [B<--include-conffiles>]

=head1 DESCRIPTION

-dh_md5sums is a debhelper program that is responsible for generating
-a DEBIAN/md5sums file, which lists the md5sums of each file in the package.
-These files are used by the debsums package.
+dh_checksums is a debhelper program that is responsible for generating
+a DEBIAN/md5sums and DEBIAN/sha256sums files, which respectively lists the
+md5sums and sha256sums of each file in the package. These files are used
+by the debsums package.

-All files in DEBIAN/ are omitted from the md5sums file, as are all
+All files in DEBIAN/ are omitted from the checksums files, as are all
conffiles (unless you use the --include-conffiles switch).

-The md5sums file is installed with proper permissions and ownerships.
+The checksums files are installed with proper permissions and ownerships.
+
+dh_md5sums is deprecated, you should use dh_checksums instead, which generates the
+type of checksums files recommended by the Debian policy.

=head1 OPTIONS

@@ -37,7 +43,7 @@ redundant since it is included elsewhere in debian packages.
=item B<-X>I<item>, B<--exclude=>I<item>

Exclude files that contain "item" anywhere in their filename from
-being listed in the md5sums file.
+being listed in the checkums file.

=back

@@ -48,15 +54,26 @@ init(options => {
"include-conffiles" => $dh{INCLUDE_CONFFILES},
});

+my ($basename) = $0=~m:.*/(.+):;
+
foreach my $package (@{$dh{DOPACKAGES}}) {
next if is_udeb($package);
-
+
+ if (basename($0) == 'dh_md5sums') {
+ warning("This program should no longer be used. Please read the dh_checksums(1) man page.");
+ }
+
my $tmp=tmpdir($package);

if (! -d "$tmp/DEBIAN") {
doit("install","-d","$tmp/DEBIAN");
}

+ # Detect if this is run multiple times (calling both dh_md5sums and dh_checksums?)
+ if (-f "$tmp/DEBIAN/md5sums" or -f "$tmp/DEBIAN/sha256sums") {
+ warning("Re-computing checksum file (even though md5sums and/or sha256sums exists)");
+ }
+
# Check if we should exclude conffiles.
my $exclude="";
if (! $dh{INCLUDE_CONFFILES} && -r "$tmp/DEBIAN/conffiles") {
@@ -76,6 +93,7 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
}

complex_doit("(cd $tmp >/dev/null ; find . -type f $exclude ! -regex '.*/DEBIAN/.*' -printf '%P' | xargs -r0 md5sum > DEBIAN/md5sums) >/dev/null");
+ complex_doit("(cd $tmp >/dev/null ; find . -type f $exclude ! -regex '.*/DEBIAN/.*' -printf '%P' | xargs -r0 sha256sum > DEBIAN/sha256sums) >/dev/null");
# If the file's empty, no reason to waste inodes on it.
if (-z "$tmp/DEBIAN/md5sums") {
doit("rm","-f","$tmp/DEBIAN/md5sums");
@@ -84,6 +102,13 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
doit("chmod",644,"$tmp/DEBIAN/md5sums");
doit("chown","0:0","$tmp/DEBIAN/md5sums");
}
+ if (-z "$tmp/DEBIAN/sha256sums") {
+ doit("rm","-f","$tmp/DEBIAN/sha256sums");
+ }
+ else {
+ doit("chmod",644,"$tmp/DEBIAN/sha256sums");
+ doit("chown","0:0","$tmp/DEBIAN/sha256sums");
+ }
}

=head1 SEE ALSO
--
1.7.0
 
Old 03-11-2010, 12:29 AM
Ryan Niebur
 
Default Bug#540215: Introduce dh_checksums

[despite having not yet replied to this thread, I am watching it...I
just don't have the desire to add to yet another giant, silly thread on
-devel. anyways...]

On Mon, Mar 08, 2010 at 12:21:42PM -0500, Joey Hess wrote:
>
> > Your comments on the patch are obviously welcome (feel free to hack
> > it your self if you want)
> >
> > Any chance to merge it before squeeze Freeze?
>
> Is debsums ready to handle other checksums types?
>

no. I will happily add support for it if there is consensus that a
switch to sha256sums (or any other checksum algorithm, for that
matter) should happen, and once packages begin to migrate to it.

Cheers,
Ryan

--
_________________________
Ryan Niebur
ryanryan52@gmail.com
 
Old 03-11-2010, 09:31 AM
Wouter Verhelst
 
Default Bug#540215: Introduce dh_checksums

On Wed, Mar 10, 2010 at 11:13:31AM -0600, Peter Samuelson wrote:
>
> [Wouter Verhelst]
> > At any rate, a PGP signature takes a lot of data; much more so than
> > a checksum. It's therefore more economical to produce a signed
> > package.checksums file than it is to produce a package.pgpsigs.
>
> Huh? Since asymmetric cryptography is so computationally expensive,
> PGP never signs the payload directly.

I am aware of that.

> Instead, the payload is hashed
> and then the hash is signed. So it is not (noticeably) more economical
> to sign foo.md5sums than to sign the whole data.tar.gz.

I was not suggesting to sign the data.tar.gz, because that is not useful
anymore once the package is installed (you do not have the data.tar.gz
anymore to verify). Instead, I was suggesting to sign individual files,
which would require several signatures per package (one per file).

Just check the length of any PGP signature, and compare it against the
lenght of a random checksum. You'll agree that a signed file with
checksums takes less data than a file with several signatures.

[...]
> Or is this not what you meant? I'm confused.

Hope that explains,

[...]
> If you have a .deb on a different host and don't want to transfer the
> entire thing over the network, well, no reason you can't do your
> SHA16384 on both ends, and transfer only the hashes at that time.

True.

--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html
 
Old 03-11-2010, 04:37 PM
Harald Braumann
 
Default Bug#540215: Introduce dh_checksums

On Wed, Mar 10, 2010 at 03:32:14PM +0100, Wouter Verhelst wrote:
>
> Having package.checksums be GPG-signed will take a significant change in
> our infrastructure (buildd hosts, for instance, would need to have a way
> to sign checksums files as well), so it's not going to happen
> tomorrow.

I was wondering about that. Unfortunately I'm quite ignorant of the
details of the whole upload and build process.
- Are all packages that end up in the archive built by the autobuilders, or can maintainers
upload binary packages directly?
- How are the Release files signed? Is it done automatically or
manually? By whom?

Cheers,
harry


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100311173710.GC25679@nn.nn">http://lists.debian.org/20100311173710.GC25679@nn.nn
 
Old 03-12-2010, 03:16 AM
Goswin von Brederlow
 
Default Bug#540215: Introduce dh_checksums

Harald Braumann <harry@unheit.net> writes:

> On Wed, Mar 10, 2010 at 03:32:14PM +0100, Wouter Verhelst wrote:
>>
>> Having package.checksums be GPG-signed will take a significant change in
>> our infrastructure (buildd hosts, for instance, would need to have a way
>> to sign checksums files as well), so it's not going to happen
>> tomorrow.

That can be avoided by including a hash of the checksum file in the
Packages files. That would be a relatively minor change in
apt-ftparchive.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87aaue898o.fsf@frosties.localdomain">http://lists.debian.org/87aaue898o.fsf@frosties.localdomain
 
Old 03-12-2010, 03:33 AM
Russ Allbery
 
Default Bug#540215: Introduce dh_checksums

Goswin von Brederlow <goswin-v-b@web.de> writes:
>> On Wed, Mar 10, 2010 at 03:32:14PM +0100, Wouter Verhelst wrote:

>>> Having package.checksums be GPG-signed will take a significant change
>>> in our infrastructure (buildd hosts, for instance, would need to have
>>> a way to sign checksums files as well), so it's not going to happen
>>> tomorrow.

> That can be avoided by including a hash of the checksum file in the
> Packages files. That would be a relatively minor change in
> apt-ftparchive.

Having the signature only in the Packages file only solves a part of the
problem. It's going to be very common to want to verify the integrity of
a package that's no longer current and hence no longer listed in the
Packages file. I'd really rather see us pursue solutions that solve the
entire problem instead, including verification of the signature on
isolated *.deb files.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87wrxi6tw4.fsf@windlord.stanford.edu">http://lists.debian.org/87wrxi6tw4.fsf@windlord.stanford.edu
 
Old 03-12-2010, 09:13 PM
Wouter Verhelst
 
Default Bug#540215: Introduce dh_checksums

On Fri, Mar 12, 2010 at 05:16:55AM +0100, Goswin von Brederlow wrote:
> Harald Braumann <harry@unheit.net> writes:
>
> > On Wed, Mar 10, 2010 at 03:32:14PM +0100, Wouter Verhelst wrote:
> >>
> >> Having package.checksums be GPG-signed will take a significant change in
> >> our infrastructure (buildd hosts, for instance, would need to have a way
> >> to sign checksums files as well), so it's not going to happen
> >> tomorrow.
>
> That can be avoided by including a hash of the checksum file in the
> Packages files.

That doesn't help for the problem we're trying to fix here: having a
path to a GPG signature from an individual binary on the hard disk,
months or years after the package was installed.

With your proposal, you lose the signatures once the package is out of
the archive and you run 'apt-get update'.

--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100312221356.GJ3902@celtic.nixsys.be">http://lists.debian.org/20100312221356.GJ3902@celtic.nixsys.be
 
Old 03-17-2010, 06:58 AM
Goswin von Brederlow
 
Default Bug#540215: Introduce dh_checksums

Wouter Verhelst <wouter@debian.org> writes:

> On Fri, Mar 12, 2010 at 05:16:55AM +0100, Goswin von Brederlow wrote:
>> Harald Braumann <harry@unheit.net> writes:
>>
>> > On Wed, Mar 10, 2010 at 03:32:14PM +0100, Wouter Verhelst wrote:
>> >>
>> >> Having package.checksums be GPG-signed will take a significant change in
>> >> our infrastructure (buildd hosts, for instance, would need to have a way
>> >> to sign checksums files as well), so it's not going to happen
>> >> tomorrow.
>>
>> That can be avoided by including a hash of the checksum file in the
>> Packages files.
>
> That doesn't help for the problem we're trying to fix here: having a
> path to a GPG signature from an individual binary on the hard disk,
> months or years after the package was installed.
>
> With your proposal, you lose the signatures once the package is out of
> the archive and you run 'apt-get update'.

Then don't do that.

I don't think signing the checksum file itself will be feasable as that
would alter the contents of the deb and change the checksums in the
changes files autobuilders send the admin for signing. It would break
the existing signing infrastructure for autobuilders. It would also
require running dpkg-genchanges again during signing or otherwise adjust
the checksums in the changes file.

But for packages no longer in the archive there is snapshot.debian.net
(or the official replacement).

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87eijj7523.fsf@frosties.localdomain">http://lists.debian.org/87eijj7523.fsf@frosties.localdomain
 
Old 03-17-2010, 09:31 AM
Wouter Verhelst
 
Default Bug#540215: Introduce dh_checksums

On Wed, Mar 17, 2010 at 08:58:28AM +0100, Goswin von Brederlow wrote:
> Wouter Verhelst <wouter@debian.org> writes:
>
> > On Fri, Mar 12, 2010 at 05:16:55AM +0100, Goswin von Brederlow wrote:
> >> Harald Braumann <harry@unheit.net> writes:
> >>
> >> > On Wed, Mar 10, 2010 at 03:32:14PM +0100, Wouter Verhelst wrote:
> >> >>
> >> >> Having package.checksums be GPG-signed will take a significant change in
> >> >> our infrastructure (buildd hosts, for instance, would need to have a way
> >> >> to sign checksums files as well), so it's not going to happen
> >> >> tomorrow.
> >>
> >> That can be avoided by including a hash of the checksum file in the
> >> Packages files.
> >
> > That doesn't help for the problem we're trying to fix here: having a
> > path to a GPG signature from an individual binary on the hard disk,
> > months or years after the package was installed.
> >
> > With your proposal, you lose the signatures once the package is out of
> > the archive and you run 'apt-get update'.
>
> Then don't do that.

We can hardly say to our users "if you want to be able to check
signatures, never run run apt-get update"...

> I don't think signing the checksum file itself will be feasable as that
> would alter the contents of the deb and change the checksums in the
> changes files autobuilders send the admin for signing.

Yes, it would be a problem for autobuilders. However, I don't think it's
completely unfeasible.

> It would break the existing signing infrastructure for autobuilders.
> It would also require running dpkg-genchanges again during signing or
> otherwise adjust the checksums in the changes file.
>
> But for packages no longer in the archive there is snapshot.debian.net
> (or the official replacement).

Which are both not very useful at the moment.

--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html
 

Thread Tools




All times are GMT. The time now is 08:34 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org