Bug#610712: [devscripts] Allow to check cryptographic signatures
On 06/05/2013 09:24 PM, James McCoy wrote: I took a quick look at the patch and found to things: 1) Please update README in addition to d/control and 2) please check the indentation. A little clarification on this. uscan uses (as most of the shell/Perl scripts in devscripts do) the following indent style: - Each indent level is 4 columns - Use tabs when the indent is a multiple of 8 - Use spaces for the rest There are some hunks in your patch that should be updated accordingly. thanks, i've just pushed two commits: one that includes some emacs localvars so that future emacs-using contributors should have the right whitespace, and a patch with cleaned-up whitespace that also updates the README, as recommended by Benjamin. I did not add a test to uscan because i don't have a place that i want to commit to storing an example package and signature, and i'm generally distrustful of tests that run against external network services. if anyone wants to make such a test i'd be happy to walk through the signature creation part. As a DD, I'm a member of collab-maint -- should i just go ahead and commit it to the devscripts repo? It works for me, and i would like to start using it for debian packages that have an upstream that signs releases. I vote for go ahead. Welcome in the devscripts devel team! Agreed. thanks for the vote of confidence! I look forward to seeing this feature in uscan. Feel free to ping me if there are any problems. --dkg signature.asc Description: OpenPGP digital signature
Bug#610712: [devscripts] Allow to check cryptographic signatures
[i'm not on the devscripts-devel list, please cc me or 610...@bugs.debian.org] On Sat 2013-05-04 05:26:55 -0400, Daniel Kahn Gillmor wrote: On Sat 2013-05-04 05:03:36 -0400, Daniel Kahn Gillmor wrote: The attached patch implements the above proposal, using (e.g.) opts=pgpsigurlmangle=s/$/.asc/ and debian/upstream-signing-key.pgp. This time with the patch actually attached :/ Any thoughts on this patch? As a DD, I'm a member of collab-maint -- should i just go ahead and commit it to the devscripts repo? It works for me, and i would like to start using it for debian packages that have an upstream that signs releases. If i don't hear any objections, i'll probably commit it (plus a an update to debian/changelog) in a day or two. Regards, --dkg pgpi0Hxf81JJh.pgp Description: PGP signature
Bug#610712: [devscripts] Allow to check cryptographic signatures
Am Mittwoch, den 05.06.2013, 15:15 -0400 schrieb Daniel Kahn Gillmor: [i'm not on the devscripts-devel list, please cc me or 610...@bugs.debian.org] On Sat 2013-05-04 05:26:55 -0400, Daniel Kahn Gillmor wrote: On Sat 2013-05-04 05:03:36 -0400, Daniel Kahn Gillmor wrote: The attached patch implements the above proposal, using (e.g.) opts=pgpsigurlmangle=s/$/.asc/ and debian/upstream-signing-key.pgp. This time with the patch actually attached :/ Any thoughts on this patch? I took a quick look at the patch and found to things: 1) Please update README in addition to d/control and 2) please check the indentation. The script uses a obscure mixture of tabs and spaces as indentation. You might want to add a test to test/test_uscan. As a DD, I'm a member of collab-maint -- should i just go ahead and commit it to the devscripts repo? It works for me, and i would like to start using it for debian packages that have an upstream that signs releases. I vote for go ahead. Welcome in the devscripts devel team! If i don't hear any objections, i'll probably commit it (plus a an update to debian/changelog) in a day or two. Nice way to trigger a quick response. :) -- Benjamin Drung Debian Ubuntu Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610712: [devscripts] Allow to check cryptographic signatures
On Wed, Jun 05, 2013 at 11:42:19PM +0200, Benjamin Drung wrote: Am Mittwoch, den 05.06.2013, 15:15 -0400 schrieb Daniel Kahn Gillmor: [i'm not on the devscripts-devel list, please cc me or 610...@bugs.debian.org] On Sat 2013-05-04 05:26:55 -0400, Daniel Kahn Gillmor wrote: On Sat 2013-05-04 05:03:36 -0400, Daniel Kahn Gillmor wrote: The attached patch implements the above proposal, using (e.g.) opts=pgpsigurlmangle=s/$/.asc/ and debian/upstream-signing-key.pgp. This time with the patch actually attached :/ Any thoughts on this patch? I took a quick look at the patch and found to things: 1) Please update README in addition to d/control and 2) please check the indentation. A little clarification on this. uscan uses (as most of the shell/Perl scripts in devscripts do) the following indent style: - Each indent level is 4 columns - Use tabs when the indent is a multiple of 8 - Use spaces for the rest There are some hunks in your patch that should be updated accordingly. As a DD, I'm a member of collab-maint -- should i just go ahead and commit it to the devscripts repo? It works for me, and i would like to start using it for debian packages that have an upstream that signs releases. I vote for go ahead. Welcome in the devscripts devel team! Agreed. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org signature.asc Description: Digital signature
Bug#610712: [devscripts] Allow to check cryptographic signatures
Control: tags 610712 + patch On Fri 2011-01-21 11:25:27 -0500, Emil Langrock wrote: A more interesting approach is to make it possible to download the source tarball and a pgp/gnupg signature which is used to verify the the file. This is i think the approach we want to pursue. having a standard way to do this would also help to encourage best practices from upstream. So we need to ensure that only a single (or multiple) predefined keys are accepted. yep, agreed. I don't expect uscan to implement all that in the framework in a heavily configurable manner, but to allow to add some kind of verify hook that calls an external script. This script has to receive the url which was used to download the file and the location of the downloaded file. The return value can be used to in uscan to decide if the file is ok or was modified. I think i actually disagree here. I would prefer if uscan implemented this directly, so that the maintainer only has to specify the bare minimum: * where to find the matching signature (perhaps as a new opts= option in debian/watch, based on a set of mangling rules that apply subsequently to the upstream URL) * the key that should make the signature (perhaps in a keyring file like debian/upstream-signing-key.pgp) The attached patch implements the above proposal, using (e.g.) opts=pgpsigurlmangle=s/$/.asc/ and debian/upstream-signing-key.pgp. One possible gotcha: since debian/upstream-signing-key.pgp is not likely to be a plain text file, packages which use this will probably need to be source format 3.0 (quilt) instead of using a diff.gz. This doesn't bother me (i think we should be transitioning packages to 3.0 (quilt) anyway). If this could be integrated into devscripts, then we could improve the ability to check the cryptographic integrity of upstream files. another possible gotcha: this approach doesn't prevent against replay attacks that target the version string alone. That is, if alice releases FooSoft 0.7 (fixing a critical vulnerability in earlier versions of FooSoft), and Eve can MITM the connection between the debian developer and the FooSoft distribution server, there's nothing stopping Eve from renaming FooSoft_0.6.tgz to FooSoft_0.8.tgz and FooSoft_0.6.tgz.asc to FooSoft_0.8.tgz.asc. In this case, uscan will accept the package as a new version (because the signature checks out OK). So we're still relying on the debian package maintainer to at least do a sanity check based on the version of the filename, which hopefully isn't too unreasonable. We could mitigate this threat by requiring the user to store the timestamp of the last signed version someplace like debian/upstream-last-signed-time, assume that time is monotonically increasing, and reject any signature older than debian/upstream-last-signed-time. I don't know that this is necessary (and i'm not sure how to implement it with gpgv, the tool this patch uses for signature verification). Regards, --dkg pgpNKO6JLDSK6.pgp Description: PGP signature
Bug#610712: [devscripts] Allow to check cryptographic signatures
On Saturday 04 May 2013 05:03:36 Daniel Kahn Gillmor wrote: The attached patch implements the above proposal, using (e.g.) opts=pgpsigurlmangle=s/$/.asc/ and debian/upstream-signing-key.pgp. The file seems to be empty. At least I cannot download the content from bugs.debian.org http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=22;filename=610712.patch;att=1;bug=610712 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610712: [devscripts] Allow to check cryptographic signatures
On Sat 2013-05-04 05:03:36 -0400, Daniel Kahn Gillmor wrote:
The attached patch implements the above proposal, using (e.g.)
opts=pgpsigurlmangle=s/$/.asc/ and debian/upstream-signing-key.pgp.
This time with the patch actually attached :/
--dkg
commit 13667a098a23d6c4a522322672f79d88eea6452a
Author: Daniel Kahn Gillmor d...@fifthhorseman.net
Date: Sat May 4 04:46:34 2013 -0400
Enable OpenPGP signature verification (Closes: #610712)
add a new opts= option for debian/watch files: pgpsigurlmangle.
if this option is present and the file debian/upstream-signing-key.pgp
exists (as an OpenPGP keyring) uscan will try to fetch the detached
signature based on the mangled URL, and verify it against the key(s)
stored in the keyring.
diff --git a/debian/control b/debian/control
index 742dc3a..59fc856 100644
--- a/debian/control
+++ b/debian/control
@@ -68,6 +68,7 @@ Suggests: bsd-mailx | mailx,
cvs-buildpackage,
devscripts-el,
gnuplot,
+ gpgv,
libauthen-sasl-perl,
libfile-desktopentry-perl,
libnet-smtp-ssl-perl,
@@ -184,7 +185,7 @@ Description: scripts to make the life of a Debian Package maintainer easier
transitions for which uploads to unstable are currently blocked
[libwww-perl, libyaml-syck-perl]
- uscan: scan upstream sites for new releases of packages
-[libcrypt-ssleay-perl, libwww-perl, unzip, lzma, xz-utils]
+[libcrypt-ssleay-perl, gpgv, libwww-perl, unzip, lzma, xz-utils]
- uupdate: integrate upstream changes into a source package [patch]
- what-patch: determine what patch system, if any, a source package is using
[patchutils]
diff --git a/scripts/uscan.1 b/scripts/uscan.1
index 99ee64c..f3b3be3 100644
--- a/scripts/uscan.1
+++ b/scripts/uscan.1
@@ -282,6 +282,16 @@ matched, then the version number is determined from this URL.
Finally, any rules given by this option are applied before the actual
download attempt is made. An example of its use is given in the
examples section above.
+.TP
+\fBpgpsigurlmangle=\fIrules\fR
+If present, the supplied rules will be applied to the downloaded URL
+(after any downloadurlmangle rules, if present) to craft a new URL
+that will be used to fetch the detached OpenPGP signature file for the
+upstream tarball. Some common rules might be `\fBs/$/.asc/\fR' or
+`\fBs/$/.pgp/\fR' or `\fBs/$/.gpg/\fR'. This signature must be made
+by a key found in the keyring \fBdebian/upstream-signing-key.pgp\fR.
+If it is not valid, or not made by one of the listed keys, uscan will
+report an error.
.SH Directory name checking
Similarly to several other scripts in the \fBdevscripts\fR package,
\fBuscan\fR explores the requested directory trees looking for
diff --git a/scripts/uscan.pl b/scripts/uscan.pl
index 177f3f0..cafa5e8 100755
--- a/scripts/uscan.pl
+++ b/scripts/uscan.pl
@@ -56,6 +56,7 @@ eval { require Crypt::SSLeay; };
if ($@) {
$haveSSL = 0;
}
+my $havegpgv = (-x '/usr/bin/gpgv');
# Did we find any new upstream versions on our wanderings?
our $found = 0;
@@ -761,6 +762,9 @@ sub process_watchline ($$)
elsif ($opt =~ /^downloadurlmangle\s*=\s*(.+)/) {
@{$options{'downloadurlmangle'}} = split /;/, $1;
}
+ elsif ($opt =~ /^pgpsigurlmangle\s*=\s*(.+)/) {
+ @{$options{'pgpsigurlmangle'}} = split /;/, $1;
+ }
else {
uscan_warn $progname warning: unrecognised option $opt\n;
}
@@ -793,6 +797,17 @@ sub process_watchline ($$)
uscan_warn $progname warning: downloadurlmangle option invalid for ftp sites,\n ignoring in $watchfile:\n $line\n;
}
+ # Check validity of options
+ if (exists $options{'pgpsigurlmangle'}) {
+ if (not (-r 'debian/upstream-signing-key.pgp')) {
+uscan_warn $progname warning: pgpsigurlmangle option exists, but debian/upstream-signing-key.pgp does not exist,\n ignoring in $watchfile:\n $line\n;
+delete $options{'pgpsigurlmangle'};
+ } elsif (! $havegpgv) {
+ uscan_warn $progname warning: pgpsignurlmangle option exists, but you must have gpgv installed to verify\n in $watchfile, skipping:\n $line\n;
+ return 1;
+ }
+ }
+
# Handle sf.net addresses specially
if ($base =~ m%^http://sf\.net/%) {
$base =~ s%^http://sf\.net/%http://qa.debian.org/watch/sf.php/%;
@@ -1123,6 +1138,7 @@ EOF
# So what have we got to report now?
my $upstream_url;
+my $pgpsig_url;
# Upstream URL? Copying code from below - ugh.
if ($site =~ m%^https?://%) {
# absolute URL?
@@ -1202,6 +1218,20 @@ EOF
$upstream_url = $base$newfile;
}
+if (exists $options{'pgpsigurlmangle'}) {
+ $pgpsig_url = $upstream_url;
+ foreach my $pat (@{$options{'pgpsigurlmangle'}}) {
+if (! safe_replace(\$pgpsig_url, $pat)) {
+ uscan_warn $progname: In $watchfile, potentially
+. unsafe or malformed pgpsigurlmangle
+. pattern:\n '$pat'
+
Bug#610712: [devscripts] Allow to check cryptographic signatures
http://www.phpmyadmin.net/home_page/security/PMASA-2012-5.php clearly shows the problematic situation of not having cryptographic signatures or tools to check it offline. This could easily break the trust chain and therefore introduce backdoors in Debian even when upstream and Debian packagers didn't do anything wrong. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610712: [devscripts] Allow to check cryptographic signatures
Package: devscripts Version: 2.10.69 Severity: wishlist It happened in the past and will happen in the future that a mirror or even the original download server for a project is hacked and minimal modified sources gets uploaded. The packager using uscan will trust usually that the sources are untouched and can be trusted. This may be a wrong assumption and some projects provide different ways to check the integrity of downloaded files. The usual way is a *.sha1 or *.md5 file next to the actual download file. This file can easily modified by an attacker (and are currently too weak for serious security applications). This makes it unsuitable for our tests. There is still the possibility that this file is downloaded from a trusted site which is different from the site we downloaded the file from. I will not follow this path any longer due to the complexity for uscan. A more interesting approach is to make it possible to download the source tarball and a pgp/gnupg signature which is used to verify the the file. The attacker could now modify this signature too, but has not the possibility to do that with the same private key (usually - there is still the possibility that the attacker kidnapped the release manager and forced him to sign the modified tarball). So we need to ensure that only a single (or multiple) predefined keys are accepted. I don't expect uscan to implement all that in the framework in a heavily configurable manner, but to allow to add some kind of verify hook that calls an external script. This script has to receive the url which was used to download the file and the location of the downloaded file. The return value can be used to in uscan to decide if the file is ok or was modified. Here is an easy example what a maintainer defined script has to do (beside the first download which is done by uscan): $ set -e $ DOWNLOAD_URL=http://mirror.synyx.de/apache//httpd/mod_ftp/mod_ftp-0.9.6-beta.tar.gz; $ DOWNLOADED_FILE=mod_ftp-0.9.6-beta.tar.gz $ TMP=`mktemp -d` $ trap 'rm -rf $TMP' 0 $ wget -q $DOWNLOAD_URL -O $DOWNLOADED_FILE # this should not be done by us $ wget -q $DOWNLOAD_URL.asc -O $TMP/sign $ rm -f $TMP/keys $ gpg --batch --no-default-keyring --keyring $TMP/keys --recv-keys B1B96F45DFBDCCF974019235193F180AB55D9977 || true $ gpg --batch --no-default-keyring --keyring $TMP/keys --keyserver-options no-auto-key-retrieve --verify $TMP/sign $DOWNLOADED_FILE --- System information. --- Architecture: i386 Kernel: Linux 2.6.37-trunk-686 Debian Release: 6.0 500 testing www.debian-multimedia.org 500 testing ftp.debian.org 500 testing eeepc.debian.net 1 experimentalftp.debian.org --- Package information. --- Depends (Version) | Installed ==-+-== dpkg-dev (= 1.15.4.1) | 1.15.8.8 perl | 5.10.1-17 libc6 (= 2.1.3) | 2.11.2-7 Recommends(Version) | Installed ===-+-=== at | curl| 7.21.0-1 OR wget| 1.12-2.1 dctrl-tools | 2.14.5 debian-keyring | 2010.12.29 debian-maintainers | dput| 0.9.6.1 OR dupload | equivs | 2.0.8 fakeroot| 1.14.4-1 gnupg | 1.4.10-4 libauthen-sasl-perl | 2.1500-1 libcrypt-ssleay-perl| 0.57-2 libparse-debcontrol-perl| 2.005-2 libsoap-lite-perl | 0.712-2 libterm-size-perl | 0.2-4+b1 libtimedate-perl| 1.2000-1 liburi-perl | 1.54-2 libwww-perl | 5.836-1 libyaml-syck-perl | 1.12-1 lintian | 2.4.3 lsb-release | 3.2-23.2squeeze1 bsd-mailx | 8.1.2-0.20100314cvs-1 OR mailx | man-db | 2.5.7-8 patch | 2.6-2 patchutils | 0.3.1-2 ssh-client | strace | 4.5.20-2 unzip | 6.0-4 wdiff | 0.6.3-1 www-browser | subversion | 1.6.12dfsg-4 OR cvs | 1:1.12.13-12 OR darcs | OR tla | OR bzr | OR git-core| 1:1.7.2.3-2.2 OR mercurial | 1.6.4-1 lzma|
