sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] Idea: dump should create keycount.txt


From: Phil Pennock
Subject: Re: [Sks-devel] Idea: dump should create keycount.txt
Date: Wed, 7 Nov 2012 20:07:50 -0500

On 2012-11-07 at 17:45 -0600, John Clizbe wrote:
> Rather than add a new file to the dump process, why not just improve the
> inadequate output that goes into dump.log?

Because that then needs to be parsed by a tool to extract only the most
recent dump's information, then put into the dump directory to make it
available via FTP, so creates more work for the people providing the
dumps, who are already being very generous by providing dumps.

IMO, it's better for those who want the feature and who benefit from it
to do the work.  I feel guilty that I made a proposal without a patch
and a vague hope that someone else would pick it up, so am grateful that
Kristian did.

A nice thing about the file with the metadata, including checksums, is
that _if_ the keyserver operators want to do more work and have a
qualify step before new dumps become available, then they could
PGP-sign the metadata-sks-dump.txt file; that way, folks downloading the
file-set could `gpg --verify metadata-sks-dump.txt.asc` before even
starting the build, and verify the checksums.

Kristian, one feature request: please emit a line stating the checksum
algorithm, so that it's easier to migrate in future?  Especially since
this is using MD5, which is leads to a second feature request.  ;-)

"#Checksum-Algorithm: MD5\n"

At least, I think it's MD5, based on use of Digest and
http://caml.inria.fr/pub/docs/manual-ocaml/libref/Digest.html saying
MD5.

Notably, because we already use CryptoKit, Hash.sha256() should be
available.  Doesn't have a filename-based method, but there's
hash_channel.

-Phil



reply via email to

[Prev in Thread] Current Thread [Next in Thread]