incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [VOTE] Apache Lucy (incubating) 0.2.0 RC 3
Date Wed, 10 Aug 2011 00:23:40 GMT
On Tue, Aug 09, 2011 at 04:48:19AM +0200, Stefan Bodewig wrote:
> You might want to use a different extension in the future (.sha512) to
> reduce the confusion in particular since most Java projects only provide
> sha1 hashes.

That makes sense to me, but it's contrary to the documentation on the
release-signing page, which A) states that when provided, an "SHA checksum"
file *must* be suffixed ".sha", B) recommends against using SHA1, and C)
provides sample code for using GPG to generate an SHA512 file with a ".sha"

  Note this is not normative

  Every artifact distributed by the Apache Software Foundation *should* and
  every new one *must* be accompanied by one file containing an OpenPGP
  compatible ASCII armored detached signature and another file containing an
  MD5 checksum. The names of these files *must* be formed by adding to the
  name of the artifact the following suffixes:

     * the signature by suffixing .asc

     * the checksum by suffixing .md5

  An SHA checksum *should* also be created and *must* be suffixed .sha.

  Using GnuPG, you can create a SHA1 signature as follows:

    $ gpg --print-md SHA1 [fileName] > [fileName].sha

  Please note that further use of SHA-1 should be avoided.

  SHA256 and SHA512 use the same SHA algorithm family with longer hash
  lengths (256 and 512 bits respectively). These longer variations are less
  vulnerable to the weaknesses found in the algorithm family than SHA1.
  SHA512 is recommended.

  To create a SHA512 checksum use:

    $ gpg --print-md SHA512 [fileName] > [fileName].sha

Though release-signing.html claims that it is "not normative", unless someone
presses the issue, I think it's best to leave the SHA-generating sections of
the Lucy file unchanged, so that our next release will
also have an SHA512 sum in a file with a ".sha" extension per the instructions

> > Unfortunately, one of the downsides of using GPG to produce the sums is that
> > the resulting file cannot be used with e.g. "sha512sum --check":
> The same is true for the mvn generated checksum files most Java projects
> use.  Those files only contain the hash with no file name of the file
> they apply to.  At least this is true for the Java artifacts I have
> reviewed in the past.

Ah, "XXXsum --check" must use the sum file's content to locate the file being
hashed, rather than stripping the extension from the file name and looking
there.  Oh well.

> > It would be nice if we could comment the rat-excludes file and have
> > the relevant comment show up next to each excluded file in the report,
> > as that would make auditing easier.
> Sounds like an enhancement request for RAT.

I guess it did sound that way... but I think RAT's pretty great as is!

I'm not sure RAT really needs that feature, which would be a bit of an
annoyance to implement.  (The rat-excludes file format would have to become
more complex.)  Instead, I've added comments to the rat-excludes file.  That
should aid future auditors examining the RAT report when run without the
excludes file.

> > I would be hesitant to insert copyright and licensing notices into those files
> > when the Snowball people have chosen to omit them.  We do include the relevant
> > information in NOTICE, though.
> Yes, that's OK.  Just from looking at the source files it wasn't clear
> to me that this was the case.  It wouldn't have helped in my case if you
> had a README inside the snowstem directory as I was only looking at the
> RAT report, but a small pointer there might help others.

Committed to Lucy trunk as r1155973, thanks!

> After your explanations (and pointing out that I'm unable to compare two
> numbers 8-) you now have my +1 as well.

On behalf of the Lucy community: Thank you for taking the time to audit our
work, and thank you for your +1 vote!


Marvin Humphrey

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message