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" extension. http://www.apache.org/dev/release-signing.html#reading 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. http://www.apache.org/dev/release-signing#sha-checksum 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 release_commands.pl file unchanged, so that our next release will also have an SHA512 sum in a file with a ".sha" extension per the instructions above. > > 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. http://svn.apache.org/repos/asf/incubator/lucy/trunk/devel/conf/rat-excludes > > 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! http://svn.apache.org/repos/asf/incubator/lucy/trunk/modules/analysis/snowstem/source/README > 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! Cheers, Marvin Humphrey --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
