Bug#540215: Introduce dh_checksums

2020-06-28 Thread Niels Thykier 
Control: tags -1 wontfix

Dimitri John Ledkov:
> On Wed, 10 Mar 2010 17:29:39 -0800 Ryan Niebur  wrote:
>> [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.
>>
> 
> Hello everyone.
> 
> I'd like to propose to move from md5sums to BLAKE2b-256 and BLAKE2s-256 for
> 64/32 bit architectures respectively, and arch:all packages providing both.
> 
> Mostly because it is faster than md5, sha1, sha2, sha3.
> 
> How do I get started to benchmark this, and start providing ability for
> packages to build these hash sums?
> 
> Regards,
> 
> Dimitri.
> 

Hi,

The conclusion on this bug is that Guillem is working on redesigning
some internal parts of the dpkg database and adding a "manifest" to deb
files. The manifest will replace many parts of the control.tar of the
.deb (at least both md5sums and conffiles).

I do not feel it makes sense to add a new file to the control.tar just
to deprecate it in a few years (not to mention a fictive dh_checksums tool).

Any progress in this area is therefore currently waiting for progress on
the dpkg front as well as a final specification of the manifest file.

~Niels

Bug#540215: Introduce dh_checksums

2020-06-12 Thread Dimitri John Ledkov 
On Wed, 10 Mar 2010 17:29:39 -0800 Ryan Niebur  wrote:
> [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.
>

Hello everyone.

I'd like to propose to move from md5sums to BLAKE2b-256 and BLAKE2s-256 for
64/32 bit architectures respectively, and arch:all packages providing both.

Mostly because it is faster than md5, sha1, sha2, sha3.

How do I get started to benchmark this, and start providing ability for
packages to build these hash sums?

Regards,

Dimitri.

Bug#540215: Introduce dh_checksums

2010-03-10 Thread Wouter Verhelst 
On Mon, Mar 08, 2010 at 12:59:00PM -0800, Russ Allbery wrote:
 Frank Lin PIAT fp...@klabs.be writes:
 
  Find a patch attached, for a smooth transition from DEBIAN/md5sums to a
  recent checksum.
 
  The way it is implemented, is that the dh_md5sums is a symlink to the
  new dh_checksums. The new helper computes both md5sum (for
  compatibility/transition) and a new checksum (SHA256, which was already
  chosen by FTP-masters as a remplacement for md5sum for signed files)
 
 If there's a general consensus that we should go this route, I'm okay with
 it, but I'm personally not sure this is the right approach.
 
 I think there are two possible directions we can take with this package
 feature:
 
 1. Strengthen the integrity check so that it could potentially be useful
for security purposes as well as for simple integrity checking.
 
 2. Declare such checksums only useful for corruption and local (benign)
modification checksumming.
 
 If we take option 1, going to a stronger hash is strictly less useful in
 every respect than going to embedded PGP signatures, which apparently only
 require active maintenance and a plan to be acceptable in the archive and
 which would need a different format anyway.

Maybe, but we're not there yet.

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.

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.
But changing to a more secure checksum algorithm could be done easily
with current infrastructure.

And since checksum files are generated at build time rather than at
install time, it is possible to download a known-good copy of the .deb
that is installed (using snapshot.debian.org, once it gets live, for
instance, or from a not-compromised host's apt cache), and verify the
files against that copy rather than the copy that is on the disk. Until
signed packages or signed checksums are available, this would of course
be a stopgap measure, but one that would actually work -- provided, of
course, that the used checksum algorithm is cryptographically secure,
which MD5 is no longer.

 If we take option 2, SHA256 offers no benefits over MD5 and just takes
 longer to compute.  There is essentially zero chance that random file
 corruption or typical local modification will result in a successful MD5
 preimage attack.

Of course, that much is 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



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#540215: Introduce dh_checksums

2010-03-10 Thread Frank Lin PIAT 
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 s...@debian.org
 License: GPL-2+
 
 Files: dh_md5sums
-Copyright: Charles Briscoe-Smith c...@ukc.ac.uk
+Copyright: Charles Briscoe-Smith c...@ukc.ac.uk, Frank Lin PIAT 
fp...@klabs.be
 License: GPL-2+
 
 Files: dh_bugfiles
diff --git a/debian/links b/debian/links
new file mode 100644
index 000..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::Debhelper::Dh_Lib;
 
 =head1 SYNOPSIS
 
+Bdh_checksums [SIdebhelper options] [B-x] [B-XIitem] 
[B--include-conffiles]
+
 Bdh_md5sums [SIdebhelper options] [B-x] [B-XIitem] 
[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-XIitem, B--exclude=Iitem
 
 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\\0' | xargs -r0 md5sum  DEBIAN/md5sums) 
/dev/null);
+   complex_doit((cd $tmp /dev/null ; find . -type f $exclude ! -regex 
'.*/DEBIAN/.*' -printf '%P\\0' | xargs -r0 sha256sum

Bug#540215: Introduce dh_checksums

2010-03-10 Thread Frank Lin PIAT 
On Wed, 2010-03-10 at 23:19 +0100, Frank Lin PIAT wrote:
 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...

The patch was incomplete... here it is.
(it also include a fix for and eq/== error in my code)

Franklin
From 719c77dd8531e3edc09471398a4f63e0fae29215 Mon Sep 17 00:00:00 2001
From: Frank Lin PIAT fp...@klabs.be
Date: Mon, 8 Mar 2010 16:35:39 +0100
Subject: [PATCH] Implement dh_checksums.

---
 debian/copyright |2 +-
 debian/links |3 +++
 dh   |2 +-
 dh_md5sums   |   41 +
 4 files changed, 38 insertions(+), 10 deletions(-)
 create mode 100644 debian/links

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 s...@debian.org
 License: GPL-2+
 
 Files: dh_md5sums
-Copyright: Charles Briscoe-Smith c...@ukc.ac.uk
+Copyright: Charles Briscoe-Smith c...@ukc.ac.uk, Frank Lin PIAT 
fp...@klabs.be
 License: GPL-2+
 
 Files: dh_bugfiles
diff --git a/debian/links b/debian/links
new file mode 100644
index 000..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..da0d568 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::Debhelper::Dh_Lib;
 
 =head1 SYNOPSIS
 
+Bdh_checksums [SIdebhelper options] [B-x] [B-XIitem] 
[B--include-conffiles]
+
 Bdh_md5sums [SIdebhelper options] [B-x] [B-XIitem] 
[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/shasums files, which respectively lists the
+md5sums and shasums 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-XIitem, B--exclude=Iitem
 
 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) eq '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/shasums) {
+   warning(Re-computing checksum file (even though md5sums and/or 
shasums 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\\0' | xargs -r0 md5sum  DEBIAN/md5sums) 
/dev/null);
+   complex_doit((cd $tmp

Bug#540215: Introduce dh_checksums

2010-03-10 Thread Ryan Niebur 
[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
ryanrya...@gmail.com


signature.asc
Description: Digital signature

Bug#540215: Introduce dh_checksums

2010-03-08 Thread Frank Lin PIAT 
retitle 540215 Introduce dh_checksums
tag 540215 +patch
thanks

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.

Hello,

Find a patch attached, for a smooth transition from DEBIAN/md5sums to a
recent checksum.

The way it is implemented, is that the dh_md5sums is a symlink to the
new dh_checksums. The new helper computes both md5sum (for
compatibility/transition) and a new checksum (SHA256, which was already
chosen by FTP-masters as a remplacement for md5sum for signed files)

Note regarding the patch:
  I have tried to make the patch so it isn't too intrusive (for
  instance, dh_checksums is a symlink to dh_md5sums even though it
  should be the other way around).
  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?

Franklin
From 69799a95b470c19cd395c532356eeaa64bc1bac8 Mon Sep 17 00:00:00 2001
From: Frank Lin PIAT fp...@klabs.be
Date: Mon, 8 Mar 2010 16:35:39 +0100
Subject: [PATCH] Implement dh_checksums.

---
 debian/copyright |2 +-
 debian/links |3 +++
 dh   |2 +-
 dh_md5sums   |   41 +
 4 files changed, 38 insertions(+), 10 deletions(-)
 create mode 100644 debian/links

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 s...@debian.org
 License: GPL-2+
 
 Files: dh_md5sums
-Copyright: Charles Briscoe-Smith c...@ukc.ac.uk
+Copyright: Charles Briscoe-Smith c...@ukc.ac.uk, Frank Lin PIAT 
fp...@klabs.be
 License: GPL-2+
 
 Files: dh_bugfiles
diff --git a/debian/links b/debian/links
new file mode 100644
index 000..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::Debhelper::Dh_Lib;
 
 =head1 SYNOPSIS
 
+Bdh_checksums [SIdebhelper options] [B-x] [B-XIitem] 
[B--include-conffiles]
+
 Bdh_md5sums [SIdebhelper options] [B-x] [B-XIitem] 
[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-XIitem, B--exclude=Iitem
 
 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

Bug#540215: Introduce dh_checksums

2010-03-08 Thread Joey Hess 
Frank Lin PIAT wrote:
 Note regarding the patch:
   I have tried to make the patch so it isn't too intrusive (for
   instance, dh_checksums is a symlink to dh_md5sums even though it
   should be the other way around).

Symlink direction seems irrelevant.

I'd probably just make dh_md5sums call dh_checksums, and later add
a deprecation warning message.

   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?

 +a DEBIAN/md5sums and DEBIAN/sha256sums files, which respectively lists the

So this doubles the amount of work that's done on build. Is there any
reason to generate md5sums files, aside from keeping old debsums
working?

 +my ($basename) = $0=~m:.*/(.+):;

Dh_Lib has a basename()

 + if (basename($0) == 'dh_md5sums') {
 + warning(This program should no longer be used. Please read the 
 dh_checksums(1) man page.);
 + }

It's probably too early for this warning, I prefer to give people some
time before starting to nag.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#540215: Introduce dh_checksums

2010-03-08 Thread Frank Lin PIAT 
On Mon, 2010-03-08 at 12:21 -0500, Joey Hess wrote:
 Frank Lin PIAT wrote:
  Note regarding the patch:
I have tried to make the patch so it isn't too intrusive (for
instance, dh_checksums is a symlink to dh_md5sums even though it
should be the other way around).
 
 Symlink direction seems irrelevant.
 
 I'd probably just make dh_md5sums call dh_checksums, and later add
 a deprecation warning message.
 
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?

Currently, debsums silently ignores sha256 checksums, so it won't break
if we start shipping those checksums.

I intend to submit a patch (see the TODO list[1])

  +a DEBIAN/md5sums and DEBIAN/sha256sums files, which respectively lists the
 
 So this doubles the amount of work that's done on build. Is there any
 reason to generate md5sums files, aside from keeping old debsums
 working?

Yes, this is for transition.
We still have to decide how long that transition would be.

  +   if (basename($0) == 'dh_md5sums') {
  +   warning(This program should no longer be used. Please read the 
  dh_checksums(1) man page.);
  +   }
 
 It's probably too early for this warning, I prefer to give people some
 time before starting to nag.

I agree,

Thank you for your quick review. I'll keep you informed about
lintian/debsums patch.

Franklin

[1] http://wiki.debian.org/Sha256sumsInPackages




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#540215: Introduce dh_checksums

2010-03-08 Thread Russ Allbery 
Frank Lin PIAT fp...@klabs.be writes:

 Find a patch attached, for a smooth transition from DEBIAN/md5sums to a
 recent checksum.

 The way it is implemented, is that the dh_md5sums is a symlink to the
 new dh_checksums. The new helper computes both md5sum (for
 compatibility/transition) and a new checksum (SHA256, which was already
 chosen by FTP-masters as a remplacement for md5sum for signed files)

If there's a general consensus that we should go this route, I'm okay with
it, but I'm personally not sure this is the right approach.

I think there are two possible directions we can take with this package
feature:

1. Strengthen the integrity check so that it could potentially be useful
   for security purposes as well as for simple integrity checking.

2. Declare such checksums only useful for corruption and local (benign)
   modification checksumming.

If we take option 1, going to a stronger hash is strictly less useful in
every respect than going to embedded PGP signatures, which apparently only
require active maintenance and a plan to be acceptable in the archive and
which would need a different format anyway.

If we take option 2, SHA256 offers no benefits over MD5 and just takes
longer to compute.  There is essentially zero chance that random file
corruption or typical local modification will result in a successful MD5
preimage attack.

I therefore have to question what utility there is in switching to SHA256.
It doesn't seem to achieve either possible goal, unless I'm missing some
way in which it's a step towards option 1?

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



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#540215: Introduce dh_checksums

2010-03-08 Thread Frank Lin PIAT 
On Mon, 2010-03-08 at 12:59 -0800, Russ Allbery wrote:
 Frank Lin PIAT fp...@klabs.be writes:
 
  Find a patch attached, for a smooth transition from DEBIAN/md5sums to a
  recent checksum.
 
  The way it is implemented, is that the dh_md5sums is a symlink to the
  new dh_checksums. The new helper computes both md5sum (for
  compatibility/transition) and a new checksum (SHA256, which was already
  chosen by FTP-masters as a remplacement for md5sum for signed files)
 
 1. Strengthen the integrity check so that it could potentially be useful
for security purposes as well as for simple integrity checking.

Yes, this is the intended goal. Imagine the following scenario:
1. You boot a trusted device with Debian Live or D-I
2. A helper mounts the root, usr and var partitions of the inspected
   system
3. It then fetches the list of installed package and version
4. It then fetches the list of signatures for the installed system, from
   your trusted mirror.
5. Then it validates the installed files on the inspected system.
6. You just have to trust one GPG key (per repository).

All that relies on the current infrastructure and chain of trust
(Repository's Releases.gpg-Packages.gpg-checksum). Alternatively, what
I am currently doing is to periodically export my md5sums to a trusted
system.

It would be much easier if a signed list of check-sums for current
packages in our archive were published (basically, when we create
Packages.gpg, we would need to extract the checksums contained in those
packages, then sign it. This list could also included the recently
updated packages, which is useful for point-releases, and unstable).

The benefit is that you can quickly audit if installed binaries are
pristine AND current.

 If we take option 1, going to a stronger hash is strictly less useful in
 every respect than going to embedded PGP signatures

Can you elaborate? checksums are currently signed, no?

 which apparently only require active maintenance and a plan to be
 acceptable in the archive and which would need a different format
 anyway.

I see some problems with signed packages:

1. Software developers and vendors will start distributing standalone
   binary packages, and pretend they are safe because they are signed.
   This is not safe: only an APT-like mechanism provides security
   updates.
2. You still need an infrastructure to publish valid packages version.
3. What do we do when we want to change a GPG key? we re-sign all
   the packages, probably breaking existing packages checksums?

Last but not least:

4. How long is it going to implement it? Does it seems realistic to
   implement your proposal before Squeeze +1 (or event Squeeze +2)?
   What do we do in-between?

 If we take option 2, SHA256 offers no benefits over MD5 and just takes
 longer to compute.

Why is that everyone seems to move away from MD5?

 There is essentially zero chance that random file corruption or
 typical local modification will result in a successful MD5 preimage
 attack.

An attacker has plenty of time to pre-compute a valid replacement for,
let say, a library in Debian Stable.

 I therefore have to question what utility there is in switching to SHA256.
 It doesn't seem to achieve either possible goal, unless I'm missing some
 way in which it's a step towards option 1?

As a bottom line:
1. A package is not safe because it is signed, but because it is
   up-to-date.
2. I am completely ok go for GPG packages, *if* it can be implemented 
   by squeeze.

Otherwise, let's move on to sha*** for squeeze, which can be quite
transparent, and move to GPG post squeeze.

Regards,

Franklin





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#540215: Introduce dh_checksums

2010-03-08 Thread Russ Allbery 
Frank Lin PIAT fp...@klabs.be writes:
 On Mon, 2010-03-08 at 12:59 -0800, Russ Allbery wrote:

 1. Strengthen the integrity check so that it could potentially be useful
for security purposes as well as for simple integrity checking.

 Yes, this is the intended goal. Imagine the following scenario:
 1. You boot a trusted device with Debian Live or D-I
 2. A helper mounts the root, usr and var partitions of the inspected
system
 3. It then fetches the list of installed package and version
 4. It then fetches the list of signatures for the installed system, from
your trusted mirror.
 5. Then it validates the installed files on the inspected system.
 6. You just have to trust one GPG key (per repository).

 All that relies on the current infrastructure and chain of trust
 (Repository's Releases.gpg-Packages.gpg-checksum). Alternatively, what
 I am currently doing is to periodically export my md5sums to a trusted
 system.

The missing link, in this validation scenario, is how to get a signed copy
of the MD5 checksums of the files in the package.  If that package is
still current, you can get this by downloading and extracting the copy of
that package from the Debian archive and examining the MD5 checksums in
it, but of course if the package is still current you don't even need MD5
checksums.  You can just compare the files directly with the files you
have.  Hence, adding a stronger checksum doesn't really help, except
possibly for some minor convenience.

 It would be much easier if a signed list of check-sums for current
 packages in our archive were published (basically, when we create
 Packages.gpg, we would need to extract the checksums contained in those
 packages, then sign it. This list could also included the recently
 updated packages, which is useful for point-releases, and unstable).

Yes, this plus a repository for older checksums for packages that are no
longer current would be required to let this work as an audit.  (It's
common in practice for not all packages on a system to be at the latest
version.)

But if you instead put a PGP signature directly in the package, then you
can always verify the package regardless of whether it's current or not
provided that you still have the original package (in /var/cache/apt, for
instance), which is why this is superior to using a hash.  Not to mention
that the infrastructure you describe for publishing signed hashes doesn't
really exist and you have to download the full package.

 If we take option 1, going to a stronger hash is strictly less useful
 in every respect than going to embedded PGP signatures

 Can you elaborate? checksums are currently signed, no?

No, the MD5 checksums currently included in packages aren't signed.

The package as a whole, which includes the checksum, is itself checksumed,
and that checksum is included in Packages, which in turn is signed.  So we
have validation of current packages at time of installation.  But as soon
as that's no longer the current package (which happens all the time in
unstable and testing, and happens in stable with new point releases), we
lose that signature because it depends on the current Packages list.

 I see some problems with signed packages:

 1. Software developers and vendors will start distributing standalone
binary packages, and pretend they are safe because they are signed.
This is not safe: only an APT-like mechanism provides security
updates.

Well, it depends on how you define safety.  The signed package is now
verified to come from the package signer, which is indeed more safe.
Having ongoing security support is a separate problem.

I see this as a feature.  It lets one distribute and install packages with
verified origins without needing to set up a full apt archive, which a lot
of people find tricky to do properly.

 2. You still need an infrastructure to publish valid packages version.

I don't think we do.

 3. What do we do when we want to change a GPG key? we re-sign all
the packages, probably breaking existing packages checksums?

Key change is a problem, yes, but note that an expired PGP signature is
still stronger in all respects than a SHA256 hash, given that you can
always ignore the signature part completely and just verify the hash.
(Assuming the signature uses a reasonable hash, of course.)  So while this
is a problem, it doesn't pose any worse of a problem than just having the
SHA256 hash does.

 Last but not least:

 4. How long is it going to implement it? Does it seems realistic to
implement your proposal before Squeeze +1 (or event Squeeze +2)?
What do we do in-between?

Use MD5.  My point is mostly that it's not clear to me SHA256 is any
better than what we have now for the problem that hashes are capable of
solving.

 If we take option 2, SHA256 offers no benefits over MD5 and just takes
 longer to compute.

 Why is that everyone seems to move away from MD5?

Because MD5 is not sufficient protection against an attacker.  It's