Proof-of-concept patch for 'make distsign'
Autrijus Tang
a 'make distsign' target that implements ANDK's suggestions about
including a signed MD5 fingerprinting of individual module files,
instead of detach-signing the distribution itself.
Crypt::OpenPGP was able to probe for my existing GnuPG settings
without problems; however, I had to use the old S2k algorithm
(--simple-sk-checksum) for it to recognize my secret keyrings.
Typing "perl Makefile.PL ; make distsign" in my Class-PseudoHash-1.02/
directory yields the following MANIFEST.digest:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MD5 (Changes) = 981c7a27b28f35e005fc081abdefc4fd
MD5 (MANIFEST) = bf994c9b35bd6f2106712b345ea5edab
MD5 (Makefile.PL) = 4da59ce0614b88622009c96d9a2521b4
MD5 (PseudoHash.pm) = 22932d85619066ca9f829391fa95aed5
MD5 (README) = 3a57b419468de2bb4f3a0518c31a7c9f
MD5 (t/PseudoHash.t) = 204878823cc80cf81b02faf9571158dc
-----BEGIN PGP SIGNATURE-----
Version: Crypt::OpenPGP 1.01
iD8DBQE9V6RYtLPdNzw1AaARAvtJAJwIXBJY84rf6Wx6egHnun4k2bvvpwCgsc7R
LaV9zh+ymEG70CK9a9Zz8yk=
=uXF8
-----END PGP SIGNATURE-----
This signature has been verified by both GnuPG and Crype::OpenPGP's
bin/pgplet utility. I hadn't tested it with PGP or other implementations.
My public key is at http://www.autrijus.org/pubkey.asc for people
interested in verifying it independently.
The reason for the plain-text format instead of YAML or XML is akin
to FreeBSD Port system's use of 'distinfo' file: It matches the
output format of the 'md5' utility, which makes hand-verification
of individual files much easier.
Also, "xargs md5 < MANIFEST" could be used to generate an identical
file without using perl.
Comments and opinions welcome. :-)
Thanks,
/Autrijus/
diff -dur lib/ExtUtils/MM_Unix.pm /usr/local/lib/perl5/5.8.0/ExtUtils/MM_Unix.pm
--- lib/ExtUtils/MM_Unix.pm Sun Jun 16 12:14:44 2002
+++ /usr/local/lib/perl5/5.8.0/ExtUtils/MM_Unix.pm Mon Aug 12 19:16:30 2002
@@ -735,7 +735,7 @@
=item dist_basics (o)
-Defines the targets distclean, distcheck, skipcheck, manifest, veryclean.
+Defines the targets distclean, distcheck, distsign, skipcheck, manifest, veryclean.
=cut
@@ -749,6 +749,9 @@
distcheck :
$(PERLRUN) "-MExtUtils::Manifest=fullcheck" -e fullcheck
+distsign :
+ $(PERLRUN) "-MExtUtils::Manifest=distsign" -e distsign
+
skipcheck :
$(PERLRUN) "-MExtUtils::Manifest=skipcheck" -e skipcheck
diff -dur lib/ExtUtils/MakeMaker.pm /usr/local/lib/perl5/5.8.0/ExtUtils/MakeMaker.pm
--- lib/ExtUtils/MakeMaker.pm Thu Jun 20 05:07:36 2002
+++ /usr/local/lib/perl5/5.8.0/ExtUtils/MakeMaker.pm Mon Aug 12 19:18:18 2002
@@ -2189,6 +2189,12 @@
MANIFEST file and vice versa. (See ExtUtils::Manifest::fullcheck() for
details)
+=item make distsign
+
+produce a OpenPGP-signed MANIFEST.digest file which contains MD5
+fingerprints for all files in MANIFEST. (See ExtUtils::Manifest::distsign()
+for details)
+
=item make skipcheck
reports which files are skipped due to the entries in the
diff -dur lib/ExtUtils/Manifest.pm /usr/local/lib/perl5/5.8.0/ExtUtils/Manifest.pm
--- lib/ExtUtils/Manifest.pm Sun May 26 05:17:51 2002
+++ /usr/local/lib/perl5/5.8.0/ExtUtils/Manifest.pm Mon Aug 12 20:06:36 2002
@@ -15,7 +15,7 @@
$VERSION = 1.38;
@ISA=('Exporter');
@EXPORT_OK = ('mkmanifest', 'manicheck', 'fullcheck', 'filecheck',
- 'skipcheck', 'maniread', 'manicopy');
+ 'skipcheck', 'maniread', 'manicopy', 'distsign');
$Is_MacOS = $^O eq 'MacOS';
$Is_VMS = $^O eq 'VMS';
@@ -110,6 +110,45 @@
return _check_manifest();
}
+sub distsign {
+ local *D;
+ open D, ">$MANIFEST.digest" or die "Could not open $MANIFEST: $!";
+
+ my $digest = _mkdigest_files();
+ my $plaintext = '';
+
+ foreach my $file (sort keys %$digest) {
+ next unless $file eq "$MANIFEST.digest";
+ $plaintext .= "MD5 ($file) = $digest->{$file}\n";
+ }
+
+ require Crypt::OpenPGP;
+ my $pgp = Crypt::OpenPGP->new;
+ my $ring = Crypt::OpenPGP::KeyRing->new(
+ Filename => $pgp->{cfg}->get('SecRing')
+ ) or die $pgp->error(Crypt::OpenPGP::KeyRing->errstr);
+ my $kb = $ring->find_keyblock_by_index(-1)
+ or die $pgp->error("Can't find last keyblock: " . $ring->errstr);
+
+ my $cert = $kb->signing_key;
+ my $uid = $cert->uid($kb->primary_uid);
+ warn "Debug: acquiring signature from $uid\n" if $Debug;
+
+ my $signature = $pgp->sign(
+ Data => $plaintext,
+ Detach => 0,
+ Clearsign => 1,
+ Armour => 1,
+ Key => $cert,
+ PassphraseCallback => \&Crypt::OpenPGP::_default_passphrase_cb,
+ ) or die $pgp->errstr;
+
+ print D $signature;
+ close D;
+
+ return $signature;
+}
+
sub skipcheck {
my($p) = @_;
my $found = manifind();
@@ -149,6 +188,39 @@
}
return @missfile;
+}
+
+
+sub _mkdigest_files {
+ my $p = shift;
+ my $dosnames=(defined(&Dos::UseLFN) && Dos::UseLFN()==0);
+ my $read = maniread() || {};
+ my $found = manifind($p);
+ my(%digest) = ();
+
+ require Digest::MD5;
+ my $md5 = Digest::MD5->new;
+
+ foreach my $file (sort keys %$read){
+ warn "Debug: collecting digest from $MANIFEST $file\n" if $Debug;
+ if ($dosnames){
+ $file = lc $file;
+ $file =~ s=(\.(\w|-)+)=substr ($1,0,4)=ge;
+ $file =~ s=((\w|-)+)=substr ($1,0,8)=ge;
+ }
+ unless ( exists $found->{$file} ) {
+ warn "No such file: $file\n" unless $Quiet;
+ }
+ else {
+ local *F;
+ open F, $file or die "Cannot open $file for reading: $!";
+ $md5->addfile(*F);
+ $digest{$file} = $md5->hexdigest;
+ $md5->reset;
+ }
+ }
+
+ return \%digest;
}
Autrijus Tang
> The attached proof-of-concept patch (requires Crypt::OpenPGP) adds
> a 'make distsign' target that implements ANDK's suggestions about
> including a signed MD5 fingerprinting of individual module files,
> instead of detach-signing the distribution itself.
> diff -dur lib/ExtUtils/Manifest.pm /usr/local/lib/perl5/5.8.0/ExtUtils/Manifest.pm
> --- lib/ExtUtils/Manifest.pm Sun May 26 05:17:51 2002
> +++ /usr/local/lib/perl5/5.8.0/ExtUtils/Manifest.pm Mon Aug 12 20:06:36 2002
> @@ -15,7 +15,7 @@
> $VERSION = 1.38;
> @ISA=('Exporter');
> @EXPORT_OK = ('mkmanifest', 'manicheck', 'fullcheck', 'filecheck',
> - 'skipcheck', 'maniread', 'manicopy');
> + 'skipcheck', 'maniread', 'manicopy', 'distsign');
>
> $Is_MacOS = $^O eq 'MacOS';
> $Is_VMS = $^O eq 'VMS';
> @@ -110,6 +110,45 @@
> return _check_manifest();
> }
>
> +sub distsign {
> + local *D;
> + open D, ">$MANIFEST.digest" or die "Could not open $MANIFEST: $!";
> +
> + my $digest = _mkdigest_files();
> + my $plaintext = '';
> +
> + foreach my $file (sort keys %$digest) {
> + next unless $file eq "$MANIFEST.digest";
The last line should read:
next if $file eq "$MANIFEST.digest";
A tab-expanded, fixed patch is available at:
http://www.autrijus.org/tmp/make_distsign.patch
Sorry and thanks,
/Autrijus/
Tels
Moin,
[Andreas, I am sorry that I just respond while you are away, I forgot and
was remined by the perl5porters weekly status and this mail :]
>The attached proof-of-concept patch (requires Crypt::OpenPGP) adds
>a 'make distsign' target that implements ANDK's suggestions about
>including a signed MD5 fingerprinting of individual module files,
>instead of detach-signing the distribution itself.
>
>Crypt::OpenPGP was able to probe for my existing GnuPG settings
>without problems; however, I had to use the old S2k algorithm
>(--simple-sk-checksum) for it to recognize my secret keyrings.
>
>Typing "perl Makefile.PL ; make distsign" in my Class-PseudoHash-1.02/
>directory yields the following MANIFEST.digest:
I still don't quite understand what the advantage over the detached-sig is.
Coud somebody please explain this to me in slow words again? Thanx! :)
Some comments:
Potential problems with the embedded signature-file:
* A deteched sig enables you to detect malicius tar.gz files. With the
signed-distfile you first unwrap the (potential dangerous file), and then
verify (some) of the contents. This opens up a potential hole. You also
never know whether a tar.gz file was changed afterwards, or not (you only
see additional or missing files, but see below).
Workaround: sign the tar.gz extra (or at least allow the author to do
this, and encourage the use of this)
* The very strong gpg/pgp signatures are replaced by rather weak md5
hashes. It is easier to replace a file in the tar.gz file, you just need
to find a collision for one file. Yes, I know, it is hard, but not
impossible, and easier than to fake a pgp/gpg signature without the
secring (if you have full access to the authors secring, anything is
open/broken anyway :).
To find a collision for a MD5, you only have to try 64 bits (birthday
paradoxon (sp?)). Actually, since the filesize is not stored extra (it is
only contained in the md5 hash), you could find a file with a different
size and the same md5, which makes this even easier. Also, if you don't
care which file you replace, you can make a malicious file, pad it
randomly, hash it, and compare it to several hashes. This is faster as
creating a padded file multiple times, speading up the attack (md5 for
lets say 10 files is slower than just comparing one to lets say 10
different md5 hashes from the tar.gz file).
Workaround: Use some stronger algorithmn, like SHA1, or even better sign
each file with gpg/pgp to avoid weak hashing.
Disadvantage of signing each file: time to sign, and bloat of the
signature/hash list. Disadvantage of SHA1: still only 160 bits per hash.
* See also something below to the format.
Some advantages I could think of:
* author needs to upload only one file (and Andreas doens't need to change
the upload formular) - supports our lazyness
* freebesd ports (for example) can break up the tar.gz and include the same
distfile with the hashes and signatures, only that their porting system
needs then to allow for missing files (without sec key they can't change
the signature of the list of hashes - so they can not create a new one)
Actually, I am still unsure whether this is an advantage, or not. As an
author I don't have control over the ports, so I am a bit wary of it
carrying my signature in it. YMMW ;)
Of course, FreeBSD ports are in general good, but I still dislike the fact
that they remove the additional doc and most important testcases. But
that's offtopic ;)
To the format:
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MD5 (Changes) = 981c7a27b28f35e005fc081abdefc4fd
Filenames with "()" might make problems. Why not use this:
md5 123456789abcdef Changes
Just nitpicking - but see below :)
>This signature has been verified by both GnuPG and Crype::OpenPGP's
>bin/pgplet utility. I hadn't tested it with PGP or other implementations.
>My public key is at http://www.autrijus.org/pubkey.asc for people
>interested in verifying it independently.
>
>The reason for the plain-text format instead of YAML or XML is akin
>to FreeBSD Port system's use of 'distinfo' file: It matches the
>output format of the 'md5' utility, which makes hand-verification
>of individual files much easier.
I prefer plaint-text, too, but I am unsure about the "md5" your refer to:
te@null:~> md5sum test.pl
999f793765762d9efc08638ffad09811 test.pl
>Also, "xargs md5 < MANIFEST" could be used to generate an identical
>file without using perl.
Which md5 utility do you mean? I don't have one at my system, obviously.
>Comments and opinions welcome. :-)
Hope this helps and is not to late ;)
Here are some general ideas/comments:
* The CPAN utility (or whatever is used to install a package) needs to allow
missing signatures for a while, but stringly suggest the user bug the
author to make one and double-check.
* But there is also the problem of a faked file with the hashes. We need
somehow make sure that the signer of that file is also the author of that
package. Uploading of the authors ublic key to CPAN or something?
This should still work with offline access, like you add first the
authors key to you local gpg keyring, and then do
perl Makefile.PL
make verify
to verify the package.
* Please note that the above step is actually a bad idea, because if
Makefile.PL was replaced with something bad, you already lost :)
No idea how to do this, maybe so:
Detached sig:
gpg --verify detached.sig
tar -xzf foo-0.01.tar.gz (good, because you verified first!)
sigfile:
tar -xzf foo-0.01.tar.gz
gpg --verify distsig (not so good, but still okay)
perl Makefile.PL
make verify (check everything)
Hope this helps.
Cheers,
Te"No, I am not Paranoid. I am his suspicous grandpa."ls
PS:
te@null:~> gpg --verify sig.txt
gpg: Signature made Mon 12 Aug 2002 14:04:40 CEST using DSA key ID 3C3501A0
gpg: Good signature from "Autrijus Tang (Tang Zong-Han)
<autr...@autrijus.org>"gpg: aka "Autrijus Tang (Tang
Zong-Han) <autr...@not.autrijus.org>"
gpg: aka "Autrijus Tang (Tang Zong-Han) <autr...@cpan.org>"
gpg: aka "Autrijus Tang (Tang Zong-Han)
<autr...@elixus.org>"
gpg: aka "Autrijus Tang (Tang Zong-Han)
<autr...@ourinet.com>"
Could not find a valid trust path to the key. Let's see whether we
can assign some missing owner trust values.
No path leading to one of our keys found.
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
gpg: Fingerprint: 66B2 B78E D1B7 7641 4861 D592 B4B3 DD37 3C35 01A0
te@null:~>
- --
perl -MDev::Bollocks -e'print Dev::Bollocks->rand(),"\n"'
continuously brand robust action-items
http://bloodgate.com/perl My current Perl projects
PGP key available on http://bloodgate.com/tels.asc or via email
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
iQEVAwUBPVfpIncLPEOTuEwVAQHGtgf+LtzLQ6njieSXpfNpyD+Zu+EY3nyoY26H
5CO8MhaRFUKipeYWO4hxujAdRjX/ywg4iBDifGJ57MGT/AdNc44t97RYi3cTBVHb
ouCBeZySIyKzns5qUXA3B8QBv3/fM5rhVLgVBYFAX5DpN/+5tQ7XTGoTl7s39ME+
sxWDSAjrA3CjzF6hYkvqOb7uHn3KpTp0hRDA9vSeCvmAKZqTb4VZ0qZUj0KCac+M
3ndQ9wOzRQ6LDVbJtYEK9FwSLp/OlwteTROKp1x0rcYdEBkT4lnShXt+YUG8mcO3
Cj0kfH3E5KgKO8x4gbeZYzL0Qv2QuWDWtEqUwSHguvQmyXrDachLnA==
=iipp
-----END PGP SIGNATURE-----
Autrijus Tang
On Mon, Aug 12, 2002 at 07:00:42PM +0200, Tels wrote:
> I still don't quite understand what the advantage over the detached-sig is.
> Coud somebody please explain this to me in slow words again? Thanx! :)
The only advantage to me is the ease of only have to upload/download one
file, which means we need only to patch Module::Build or ExtUtils::MakeMaker,
instead of all over the place (PAUSE, CPAN.pm, CPANPLUS.pm, BSDPAN,
search.cpan.org, lazy humans, etc.) However, this advantage is decisive,
imho.
> * A deteched sig enables you to detect malicius tar.gz files. With the
> signed-distfile you first unwrap the (potential dangerous file), and then
> verify (some) of the contents. This opens up a potential hole.
Unless gunzip, untar or Digest::MD5 had been exploited, I see little
possibilities for holes here. And if any of them is exploited, we're
in a very fatal state anyway. :-)
> You also never know whether a tar.gz file was changed afterwards,
> or not (you only see additional or missing files, but see below).
This theoretically has the protection of /authors/id/X/XX/XXX/CHECKSUM
on the main PAUSE site. Also, if a .tar.gz with signed MANIFEST was found
afterwards to contain additional or missing files, it should be considered
a provable security breach anyway.
> Workaround: sign the tar.gz extra (or at least allow the author to do
> this, and encourage the use of this)
I'm not opposed to this idea per se, but I'm not sure about what the
verification process should be (CPAN.pm or CPANPLUS.pm's automation
notwithstanding). If the user does not have bin/gpg or bin/pgp, do we
want to ship a utility that does the verification before untarring the
file?
> * The very strong gpg/pgp signatures are replaced by rather weak md5
> hashes. It is easier to replace a file in the tar.gz file, you just need
> to find a collision for one file. Yes, I know, it is hard, but not
> impossible, and easier than to fake a pgp/gpg signature without the
> secring (if you have full access to the authors secring, anything is
> open/broken anyway :).
The secring is protected by (essentially) a RIPEMD160 hash, and you'll
have to break that first, assuming a strong passphrase.
> Workaround: Use some stronger algorithmn, like SHA1, or even better sign
> each file with gpg/pgp to avoid weak hashing.
> Disadvantage of signing each file: time to sign, and bloat of the
> signature/hash list. Disadvantage of SHA1: still only 160 bits per hash.
I seriously dislike signing each file; it could be very troublesome to
verify on large distributions. Maybe switching to a Crypt::RIPEMD160
hash would be a better idea.
> MD5 (Changes) = 981c7a27b28f35e005fc081abdefc4fd
> Filenames with "()" might make problems. Why not use this:
> md5 123456789abcdef Changes
That works for me (although file may contain "\n", too). The first field
could be pluggable (prepended by 'Digest::' or 'Crypt::'), so it may say
SHA1 da39a3ee5e6b4b0d3255bfef95601890afd80709 Nullfile
> >Also, "xargs md5 < MANIFEST" could be used to generate an identical
> >file without using perl.
> Which md5 utility do you mean? I don't have one at my system, obviously.
BSDism here, sorry. Never mind that , then.
> Here are some general ideas/comments:
> * The CPAN utility (or whatever is used to install a package) needs to allow
> missing signatures for a while, but stringly suggest the user bug the
> author to make one and double-check.
I'd like this to be opt-in, though, because unlike adding a missing test
file, creating a keypair is much more a burden to the author.
> * But there is also the problem of a faked file with the hashes. We need
> somehow make sure that the signer of that file is also the author of that
> package. Uploading of the authors ublic key to CPAN or something?
Existing keyserver may be used, and/or adding a /PUBKEY file in addition to
/CHECKSUM in author's directory. The 01mailrc.txt.gz may be used to verify the
signing address -- either aut...@cpan.org or aut...@host.listed.in.mailrc.org
should be considered a valid identity.
The more robust way would be building a web of trust between the PAUSE
and each authors, as well as between authors. That would allow for NAPC
(distributed CPAN), too.
> Detached sig:
> gpg --verify detached.sig
> tar -xzf foo-0.01.tar.gz (good, because you verified first!)
>
> sigfile:
> tar -xzf foo-0.01.tar.gz
> gpg --verify distsig (not so good, but still okay)
How to incoporate a distsig of .tar.gz inside that .tar.gz escapes me,
unless you're talking about a separate Makefile.PL.sig or Build.PL.sig.
I'd like a special-purpose utility to be installed instead, maybe called
'perlchk', that does the checking of MANIFEST.digest. That way, the
'verify' target simply calls the utility.
Thanks,
/Autrijus/
Tels
Moin,
On 12-Aug-02 Autrijus Tang carved into stone:
> Thanks for your prompt comments. :-)
>
> On Mon, Aug 12, 2002 at 07:00:42PM +0200, Tels wrote:
>> I still don't quite understand what the advantage over the detached-sig
>> is.
>> Coud somebody please explain this to me in slow words again? Thanx! :)
>
> The only advantage to me is the ease of only have to upload/download one
> file, which means we need only to patch Module::Build or
> ExtUtils::MakeMaker,
> instead of all over the place (PAUSE, CPAN.pm, CPANPLUS.pm, BSDPAN,
> search.cpan.org, lazy humans, etc.) However, this advantage is decisive,
> imho.
>
>> * A deteched sig enables you to detect malicius tar.gz files. With the
>> signed-distfile you first unwrap the (potential dangerous file), and
>> then
>> verify (some) of the contents. This opens up a potential hole.
>
> Unless gunzip, untar or Digest::MD5 had been exploited, I see little
> possibilities for holes here. And if any of them is exploited, we're
> in a very fatal state anyway. :-)
You could wrap a couple of gigybytes of 1's and zip them up :-) I know I
would be *pissed* :-)
Or you could add a README.FIRST, or a Makefile.pl which an unwary user
could execute accidentily. Or add some other file that get's executed
automatically (like a malicius ExtUtils/MakeMaker.pm).
The potential ideas are endless to a crimin^Wcreative mind :)
>> You also never know whether a tar.gz file was changed afterwards,
>> or not (you only see additional or missing files, but see below).
>
> This theoretically has the protection of /authors/id/X/XX/XXX/CHECKSUM
> on the main PAUSE site.
The checksum can be easily faked. IF you can manipulate the tar.gz file
after uploading, so you can the checksum. That is why we want true signing
:)
> Also, if a .tar.gz with signed MANIFEST was
> found afterwards to contain additional or missing files, it should be
> considered a provable security breach anyway.
Yes, but we want to guard us so that this cannot happen without
noticing it *in any case*. Noticing it "afterwards" isn't good :) (Just
look at the manipulated source files that appeared (irc client, ssh I
believ and others). Finding it out "afterwards* is bad.
>> Workaround: sign the tar.gz extra (or at least allow the author to do
>> this, and encourage the use of this)
>
> I'm not opposed to this idea per se, but I'm not sure about what the
> verification process should be (CPAN.pm or CPANPLUS.pm's automation
> notwithstanding). If the user does not have bin/gpg or bin/pgp, do we
> want to ship a utility that does the verification before untarring the
> file?
Actually, you can not do SuSE Online Update without gpg, because it then
complains that you don't have gnupg (however this is now spelled, GNUpg,
GnuPG, gnupg or whatever :). So it is there always an requirement.
I think that we pretty much must require it for checking. The option for
the user is of course, not to check the file. I think that an embedded
distfile could server as a fallback check there.
OTOH, gpg/pgp are (becoming) very common for these checks, so it is not as
they aren't available or so.
I think building an extra utility that can do the check:
Hm, quite a lot of work, you can get it wrong etc. Could use Perl module
PGPSomething. Or use the GnuPG lib, but if you have this, you probably also
have gpg.
>> * The very strong gpg/pgp signatures are replaced by rather weak md5
>> hashes. It is easier to replace a file in the tar.gz file, you just
>> need
>> to find a collision for one file. Yes, I know, it is hard, but not
>> impossible, and easier than to fake a pgp/gpg signature without the
>> secring (if you have full access to the authors secring, anything is
>> open/broken anyway :).
>
> The secring is protected by (essentially) a RIPEMD160 hash, and you'll
> have to break that first, assuming a strong passphrase.
I assumed that you have "full" access, e.g. including the passphrase. Sorry
for not making this clear. (if you only have physical access, you need to
plant a keylogger, too. Hard, but not impossible). But let's assume the
authors key is secure.
(Of course, there are other problems. Author looses his key. Want's to make
a new one etc.)
>> Workaround: Use some stronger algorithmn, like SHA1, or even better
>> sign
>> each file with gpg/pgp to avoid weak hashing.
>> Disadvantage of signing each file: time to sign, and bloat of the
>> signature/hash list. Disadvantage of SHA1: still only 160 bits per
>> hash.
>
> I seriously dislike signing each file; it could be very troublesome to
> verify on large distributions. Maybe switching to a Crypt::RIPEMD160
> hash would be a better idea.
I agree, large distributions would carry a 2 Mb signature file :)
>> MD5 (Changes) = 981c7a27b28f35e005fc081abdefc4fd
>> Filenames with "()" might make problems. Why not use this:
>> md5 123456789abcdef Changes
>
> That works for me (although file may contain "\n", too). The first field
> could be pluggable (prepended by 'Digest::' or 'Crypt::'), so it may say
>
> SHA1 da39a3ee5e6b4b0d3255bfef95601890afd80709 Nullfile
Yes, that's why I think including the md5 is a good idea. If making it
optional, we should specify what the default is. (Okay, SHA1 and MD5 can be
distingished by the hash length).
Another idea:
MD5 {
123456789123456 null
1234827628282ab foo
}
SHA1 {
123848484u345830820842 Null
}
(Of course, makes it more complicated, and saves us only 4 or 5 bytes per
file and has the "problem" that it allows different hashes per file, which
is somewhat silly. Better stick with the simpler case)
>> >Also, "xargs md5 < MANIFEST" could be used to generate an identical
>> >file without using perl.
>> Which md5 utility do you mean? I don't have one at my system, obviously.
> BSDism here, sorry. Never mind that , then.
:o) Shame on me that I don't know that.
>> Here are some general ideas/comments:
>> * The CPAN utility (or whatever is used to install a package) needs to
>> allow
>> missing signatures for a while, but stringly suggest the user bug the
>> author to make one and double-check.
> I'd like this to be opt-in, though, because unlike adding a missing test
> file, creating a keypair is much more a burden to the author.
Yes. But then, nobody said it would be easy to be an Author :) (Curtesy of
Raven Software/ID Software).
We need to make it optional somehow, since a lot of authors are no longer
available to sign their old packages.
But maybe we can at this point also solve the old/outdated package issue,
anything without a signature is tagged as "old/unsecure". That would
probably bring some people to bug some authors to update their old stuff.
Or at least give the user an idea what is maintained and what not.
Oh well...
>> * But there is also the problem of a faked file with the hashes. We need
>> somehow make sure that the signer of that file is also the author of
>> that
>> package. Uploading of the authors ublic key to CPAN or something?
>
> Existing keyserver may be used, and/or adding a /PUBKEY file in addition
> to
> /CHECKSUM in author's directory. The 01mailrc.txt.gz may be used to
> verify the
> signing address -- either aut...@cpan.org or
> aut...@host.listed.in.mailrc.org
> should be considered a valid identity.
But that means I need to create an extra key just for CPAN signing?
(Not that I have arguments against it, except lazyness :)
> The more robust way would be building a web of trust between the PAUSE
> and each authors, as well as between authors. That would allow for NAPC
> (distributed CPAN), too.
>
>> Detached sig:
>> gpg --verify detached.sig
>> tar -xzf foo-0.01.tar.gz (good, because you verified first!)
>>
>> sigfile:
>> tar -xzf foo-0.01.tar.gz
>> gpg --verify distsig (not so good, but still okay)
>
> How to incoporate a distsig of .tar.gz inside that .tar.gz escapes me,
> unless you're talking about a separate Makefile.PL.sig or Build.PL.sig.
The second variant was the distsig file with the hashes inside the tar.gz
file, which only verifies that the list was signed ok, not that the files
are ok or that files were dropped or added.
> I'd like a special-purpose utility to be installed instead, maybe called
> 'perlchk', that does the checking of MANIFEST.digest. That way, the
> 'verify' target simply calls the utility.
This are implementation details, me thinks. But we need to make sure that
package is verified. I mean, someone could build a custom Makefile.PL and
have it skip the verification process by not calling the utility and nobody
would notice.
Relying on the package to test it self might be not a good idea.
Just throwing ideas around.
Best wishes,
Tels
- --
perl -MDev::Bollocks -e'print Dev::Bollocks->rand(),"\n"'
centrally network enterprise-class mindshares
http://bloodgate.com/perl My current Perl projects
PGP key available on http://bloodgate.com/tels.asc or via email
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
iQEVAwUBPVimd3cLPEOTuEwVAQGUugf9HEzzGh9PFSCwfFY4EWDoFhx5VMUJepjb
lLnc86Tw+0ctudIk6h/Pw25AnpTlcIkq89CLpmlEjZYQWlIz38tI01Vvol9Yw64w
zfeUzCgE1Q82mAWI+Wn7ebLdr2sRbKJP2YnbJDcJmVuI/4EnNo3zNK5xpK1YZq77
CyBjJ1lGN3S1Ntft7go2LOxzjD9yWRWBJeOscVF1gV2l4eKXRCxqyluO+YKAGGyQ
8HdfjpRPt3DWqQNvd+E+CaYg/8tZpSeg5sZ886Gl9BeXc/n+GuNEoiHRo1twjCKo
sUf7ypp4E53UBCOqy5AqD7zQhJCpUexjPswMM5LjNZLTCaZPAGehhw==
=jF7J
-----END PGP SIGNATURE-----
Autrijus Tang
> > This theoretically has the protection of /authors/id/X/XX/XXX/CHECKSUM
> > on the main PAUSE site.
> after uploading, so you can the checksum. That is why we want true signing
> :)
I'll be patching CPANPLUS to fetch checksum of another host; and the CHECKSUM
on the master PAUSE site should be authentic.
But I agree that multiple layers of small-cost security measures is nice.
> I think building an extra utility that can do the check:
> Hm, quite a lot of work, you can get it wrong etc. Could use Perl module
> PGPSomething. Or use the GnuPG lib, but if you have this, you probably also
> have gpg.
I was actually thinking about Crypt::OpenPGP. That requires a bunch
of Math::* modules to be reasonably portable, though.
> (Of course, there are other problems. Author looses his key. Want's to make
> a new one etc.)
That's why a PKI between PAUSE and authors would be neccessary.
> > SHA1 da39a3ee5e6b4b0d3255bfef95601890afd80709 Nullfile
> Yes, that's why I think including the md5 is a good idea. If making it
> optional, we should specify what the default is. (Okay, SHA1 and MD5 can be
> distingished by the hash length).
SHA1 should be relatively good already. There's nothing preventing using
different hashes in a given file:
MD5 123456789123456 File1
SHA1 123848484u345830820842 File2
> But maybe we can at this point also solve the old/outdated package issue,
> anything without a signature is tagged as "old/unsecure". That would
> probably bring some people to bug some authors to update their old stuff.
> Or at least give the user an idea what is maintained and what not.
> Oh well...
This is a good idea that ties in with CPANTS, although I'd like to finish
a working fundation first, leaving PAUSE-changing things for the later. :)
> > Existing keyserver may be used, and/or adding a /PUBKEY file in addition
> > /CHECKSUM in author's directory. The 01mailrc.txt.gz may be used to
> > signing address -- either aut...@cpan.org or
> > aut...@host.listed.in.mailrc.org
> > should be considered a valid identity.
> But that means I need to create an extra key just for CPAN signing?
Not really, as long as your own key already agrees with 01mailrc. Or you
may just add a new subkey.
> > How to incoporate a distsig of .tar.gz inside that .tar.gz escapes me,
> > unless you're talking about a separate Makefile.PL.sig or Build.PL.sig.
> The second variant was the distsig file with the hashes inside the tar.gz
> file, which only verifies that the list was signed ok, not that the files
> are ok or that files were dropped or added.
I'd like to think dropped/added files as security breaches, though.
> Relying on the package to test it self might be not a good idea.
Agreed.
Thanks,
/Autrijus/
Autrijus Tang
SIGNATURE file according to the format Tels suggested; also bundled
is a 'cpansign' utility, with the usage:
% cpansign # create SIGNATURE based on MANIFEST
% cpansign verify # verify a SIGNATURE
# -- better do this before running Makefile.PL
Currently it prefers the 'gpg' executable, and falls back to Crypt::OpenPGP
if it's not installed. Comments welcome. :-)
Thanks,
/Autrijus/
Tels
Moin,
On 13-Aug-02 Autrijus Tang carved into stone:
Cool :-)
I wanted to try it, but search.cpan.org didn't find it (yet).
So, Math::BigInt v1.61 will come without a signature ;)
Best wishes,
Tels
Btw, Autrijus, I see that you keep a lot of old versions around. They are
all stored on the backpan, too, so you can clean of your dir a bit and
delete the oldest ones. (Except if did this for a reason :)
- --
perl -MDev::Bollocks -e'print Dev::Bollocks->rand(),"\n"'
dramatically innovate transparent solutions
http://bloodgate.com/perl My current Perl projects
PGP key available on http://bloodgate.com/tels.asc or via email
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
iQEVAwUBPVlGt3cLPEOTuEwVAQEgDgf9Fz5ZYHwwv1/6Ue3gzDewxsvvLipw82l8
iQfGbU+qSCxJTJCSaJndLgGS0NJarZg9XFuGYWyL4yJFYBKcI5oGXq+yXJ6DQCMN
OkIrcPdAMR6+JHY1XCaNx/IQICUPTw406snODQT4BLxOATYVycGiOQYagk0xUX5e
2BpuvFMZFgda4G4DkuNJcRzPb/7miGnBex1PwgPFsJioaE7Wjl8zkWjXfCcmzHcc
jDwmrhwKijz0tHki1KEz4tgOVmRtdldD/prH+m1uI8Nq0UsNWGI8nVXlI/Ud18NZ
xGiqEa1wbFeKbrJf/cMagRXIIaSqVqDsr0l05CYEEhR+osHWPzkGhQ==
=nomH
-----END PGP SIGNATURE-----
Graham Barr
> I wanted to try it, but search.cpan.org didn't find it (yet).
search is currently on a once a day update. Rapid updates will
be restored soon.
Graham.
Benjamin Goldberg
>
> On Tue, Aug 13, 2002 at 11:17:24PM -0400, Benjamin Goldberg wrote:
> > My comment: Have 'cpansign' with no arguments print out help, and
> > 'cpansign create' create a signature, and 'cpansign verify' verify a
> > signature. It's *not*, imho, a good idea to have the no argument
> > version *create* (overwrite) a signature, it's too easy for someone
> > to accidently mess up.
>
> That's a valid point. However, what do you think about this:
>
> - if no existing SIGNATURE is found, create it.
> - if it's found, ask "Existing SIGNATURE file found.
> Overwrite? [y/N]":
> - (if it's _your_ signature, maybe default to 'Y'?)
Sounds fairly reasonable, to me.
--
tr/`4/ /d, print "@{[map --$| ? ucfirst lc : lc, split]},\n" for
pack 'u', pack 'H*', 'ab5cf4021bafd28972030972b00a218eb9720000';
Autrijus Tang
> > On Tue, Aug 13, 2002 at 11:17:24PM -0400, Benjamin Goldberg wrote:
> > That's a valid point. However, what do you think about this:
> > - if no existing SIGNATURE is found, create it.
> > - if it's found, ask "Existing SIGNATURE file found.
> > Overwrite? [y/N]":
> > - (if it's _your_ signature, maybe default to 'Y'?)
> Sounds fairly reasonable, to me.
Thanks; fixed in <http://www.autrijus.org/Module-Signature-0.04.tar.gz>.
/Autrijus/
Michael G Schwern
> I'll be patching CPANPLUS to fetch checksum of another host; and the CHECKSUM
> on the master PAUSE site should be authentic.
What if the two CPAN mirrors are out of sync? Foo-Bar-1.2.3.tar.gz has just
arrived on MirrorA which updates hourly (say, cpan.valueclick.com). MirrorB
only updates daily and doesn't have Foo-Bar-1.2.3.tar.gz yet and the
CHECKSUM file isn't updated.
CPANPLUS fetches the tarball from MirrorA, then the author's CHECKSUM from
MirrorB. It can't find a checksum for that tarball. What happens?
--
Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
Don't be a lover, girl, I'd like to shamelessly hump your inner child.
Autrijus Tang
> On Tue, Aug 13, 2002 at 06:34:41PM +0800, Autrijus Tang wrote:
> > I'll be patching CPANPLUS to fetch checksum of another host; and the CHECKSUM
> > on the master PAUSE site should be authentic.
> MirrorB. It can't find a checksum for that tarball. What happens?
The current plan is for it to try the list of hosts, looking for a CHECKSUM
that's newer than the module, and finally fetches from the canonical source,
funet.fi.
/Autrijus/
Kurt D. Starsinic
Newer how? All the CPAN sites around the world aren't running NTP.
- Kurt
Autrijus Tang
> > The current plan is for it to try the list of hosts, looking for a CHECKSUM
> > that's newer than the module, and finally fetches from the canonical source,
> > funet.fi.
> Newer how? All the CPAN sites around the world aren't running NTP.
It's "a CHECKSUM that's newer...", not "a host that's newer...".
All CHECKSUMs have this in its header:
# CHECKSUMS file written on Fri Aug 2 17:46:45 2002 by CPAN::Checksums (v1.008)
Which is parsable. But it wouldn't be required anyway, since a missing
module entry automatically means that the CHECKSUM is not new enough.
Thanks,
/Autrijus/
Autrijus Tang
> I just uploaded Module::Signature 0.02 to CPAN that implements the
> SIGNATURE file according to the format Tels suggested;
This is just a short follow-up about the current status of PGP-signed
module deployment:
- Module::Signature is on 0.06 currently, with a DWIM 'cpansign'
utility that checks a signature if it exists, or create one
otherwise. It also defaults the keyserver to pgp.mit.edu.
[ http://www.cpan.org/authors/id/A/AU/AUTRIJUS/Module-Signature-0.06.tar.gz ]
- Thanks to Graham Barr, http://search.cpan.org/ now lists
the special SIGNATURE file on the module information page.
[ http://search.cpan.org/author/ABERGMAN/Safe-2.09/ ]
- The development version of CPANPLUS project now features a
'signature' configuation option that, if enabled, validates
for the distribution's integrity before running Makefile.PL.
[ http://p4.elixus.org/snap/cpanplus-devel.tar.gz ]
- A number of CPAN authors begins to sign their new distributions,
e.g. Iain Truskett, Arthur Bergman, and yours truly. :-)
It is my sincere wish that CPAN authors can experiment with this
idea a bit, and/or audit the system to find possible deficiencies.
Suggestions and ideas for next step of deployments are most welcome.
Thanks,
/Autrijus/
Tels
Moin,
On 11-Oct-02 Autrijus Tang carved into stone:
> On Tue, Aug 13, 2002 at 10:13:00PM +0800, Autrijus Tang wrote:
>> I just uploaded Module::Signature 0.02 to CPAN that implements the
>> SIGNATURE file according to the format Tels suggested;
>
> This is just a short follow-up about the current status of PGP-signed
> module deployment:
>
> - Module::Signature is on 0.06 currently, with a DWIM 'cpansign'
> utility that checks a signature if it exists, or create one
> otherwise. It also defaults the keyserver to pgp.mit.edu.
Is it possible to not use a keyserver?
> - A number of CPAN authors begins to sign their new distributions,
> e.g. Iain Truskett, Arthur Bergman, and yours truly. :-)
v1.64 will definitely signed when it is ready :)
Cheers,
Tels
- --
perl -MDev::Bollocks -le'print Dev::Bollocks->rand()'
autoschediastically maximize back-end models
http://bloodgate.com/perl My current Perl projects
PGP key available on http://bloodgate.com/tels.asc or via email
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
iQEVAwUBPaZfwncLPEOTuEwVAQFTZgf+K2JOQvbXnbbe0QRT7jqkAGmW/W1U4FjN
W4ULI4QAkJITx4EwurhCq9f08xdjTYoMcuMnBXDC36RASlrr+eEXKEawX9lnM1mW
5iNQte1ljwR3T0Cnf140+WXHIBi1D84TljohVp9YHGUvqgWLA/+h0rG9PVXTtrhg
LxgnRjdAfwfYEGndizkMQ6Qvs0Y9PfJPEJsOte7+mTIo2fnBsEFtehAMdc6kYz8J
x1A+80n8aO++RcUs93TuzB8o4Hol22k5K2ofRcO7MEb6OyTpb3eVK42oBG6WjiWi
SvLZ7Ht9fXSSZBfP0RvYFaZqbpoANQDR+KGBTUKOq5EN/NYDuuA7/A==
=f7+g
-----END PGP SIGNATURE-----
Autrijus Tang
> > - Module::Signature is on 0.06 currently, with a DWIM 'cpansign'
> > utility that checks a signature if it exists, or create one
> > otherwise. It also defaults the keyserver to pgp.mit.edu.
Not yet. But that's a good suggestion; I'll make it to skip the
retrieval if $Module::Signature::KeyServer is false, in the next
version.
> > - A number of CPAN authors begins to sign their new distributions,
> > e.g. Iain Truskett, Arthur Bergman, and yours truly. :-)
> v1.64 will definitely signed when it is ready :)
That would rock. Thanks!
/Autrijus/