I think the hashes are important in the vote email as there can often be multiple release candidates (locally or announced on dev@) -- and it is not impossible to get it wrong as the files are all called the same. While hashes can be used to detect malicious tampering, it's more useful to detect accidental tampering. I find it useful as a way to "audit myself".
As Sebb points out, the .sha1 and .md5 files are intended for transport verification (CRC32 in TCP/IP is not reliable enough, and file might be incomplete) - after all they come from the same server - however the .asc files themselves may sometimes internally just contain a signed sha1 checksum and so don't offer any cryptographically stronger verification for tamper-proof-worried consumers (See https://www.apache.org/dev/openpgp.html#sha1 - I seem to be guilty here as well) . Checksums say that you got the right file and are small enough to include in emails/announcements, signatures says it's from the right source. To avoid man-in-the-middle attack (hi, Mallory!), you need to download the KEYS file with https://www.apache.org/dist/commons/KEYS (not http://!), trust the standard SSL CA's, your OS distro and your local government actors and ISPs. You can choose to verify that file is signed by one of the many keys imported (but maybe not cross-signed) into your ring (I count 151 @apache.org keys in my ring). On the other side, a copy-pastable sha1 checksum posted to a public mailing list with copies in archives across the world is a bit more work to circumvent (and more detectable). When building a Docker image it's also easier/better to use a hard-coded hash than a blind download of KEYS file and download - as the signature would match even if you download the wrong file/version. For instance: https://github.com/stain/jena-docker/blob/master/jena/Dockerfile#L23 Sometimes I see votes where the folder on dist.apache.org don't even have a "RC1" or similar in the folder name - then the votes can get quite confusing as to which RC has been reviewed. The existence of the hash files make it easy to check which file is meant to be there and cross-check with the email and/or the Maven staging repository (e.g. with curl or wget). I think it should be possible to move to a model where we only use the Nexus staging repository - which I think does self-checks of the .md5 and .sha1 files (and .asc against public PGP server?) -- perhaps extend the Commons Build Maven plugin to release from staging-repo to dist.apache.org -- it could ask for (or print out) the sha1 checksums and perhaps even make the VOTE email. Too ambitious? On 4 December 2016 at 20:51, Matt Sicker <boa...@gmail.com> wrote: > The .asc files should be used for verification. I don't even see the point > of adding md5 hashes anymore. Most software repositories rely on gpg > signatures instead nowadays. > > On 4 December 2016 at 07:44, sebb <seb...@gmail.com> wrote: > >> The hashes are not intended for authentication, only for checking that >> the download works OK. >> So the strength of the algorithm is not relevant here. >> >> On 3 December 2016 at 20:02, Gary Gregory <garydgreg...@gmail.com> wrote: >> > Well, getting SHA-1 hashes is not awesome either, we really need a plugin >> > updated to use SHA-2/SHA-256 >> > >> > Gary >> > >> > On Sat, Dec 3, 2016 at 11:57 AM, Matt Sicker <boa...@gmail.com> wrote: >> > >> >> The source jar does just include the .java/.scala/etc. files along with >> >> anything in src/main/resources/ (and anything else configured, though >> this >> >> is the default). I think that a source jar is required for distribution >> on >> >> maven central. Besides making releases on the /dist/ svn repo, there's >> >> repository.apache.org which can also technically be used to download >> maven >> >> artifacts besides MC (plus I think bintray/jcenter mirrors everything on >> >> MC). >> >> >> >> So basically, at the bare minimum, you need the source tarball/zip on >> dist >> >> which can be used by users to build usable artifacts from source using >> the >> >> relevant build tools and publicly available dependencies (which of >> course >> >> are licensed appropriately). All artifacts are signed along with at >> least >> >> an md5 hash, but I typically also see shaN hashes along with since md5 >> is >> >> so old and broken (maybe this policy should be updated?). And then the >> flow >> >> from repository.apache.org to MC and elsewhere only contains the >> compiled >> >> jars, source jars, poms, and sometimes accompanying xml artifacts or >> zips. >> >> >> >> On 3 December 2016 at 12:14, Gary Gregory <garydgreg...@gmail.com> >> wrote: >> >> >> >> > On Dec 3, 2016 9:34 AM, "Charles Honton" <c...@honton.org> wrote: >> >> > > >> >> > > To follow up the thread on releasing parent 42 and exactly what >> needs >> >> to >> >> > signed, etc. I’ve researched asf release policy. Here’s the gist: >> >> > > >> >> > > 1. Every ASF release must contain a source package, which must be >> >> > sufficient for a user to build and test the release provided they have >> >> > access to the appropriate platform and tools. < >> >> > http://www.apache.org/dev/release#what-must-every-release-contain> >> >> > > >> >> > > 2. A release isn't 'released' until the contents are in the >> project's >> >> > distribution directory, which is a subdirectory of >> www.apache.org/dist/ >> >> < >> >> > http://www.apache.org/dev/release#where-do-releases-go>. >> >> > > >> >> > > 3. Every artifact distributed to the public through Apache channels >> >> MUST >> >> > be accompanied by one file containing an OpenPGP compatible ASCII >> armored >> >> > detached signature and another file containing an MD5 checksum. < >> >> > https://www.apache.org/dev/release-distribution.html#sigs-and-sums> >> >> > > >> >> > > What do we consider the source package for our releases? >> >> > > Are the xxx-sources.jar, xxx-test-sources.jar, and pom sufficient >> to >> >> > build and test the release? >> >> > >> >> > Nope. A sources jar is a convenience for IDEs, it usually does not >> >> contain >> >> > build scripts and such. I am AFK so I am hoping someone can provide an >> >> > example. >> >> > >> >> > > Is the zip/gz just a convenience and is it still useful/required? >> >> > >> >> > That should contain almost everything that is in the repo except for >> >> things >> >> > like old files like proposal.html. >> >> > >> >> > > Or is it the reverse, the zip/gz is the release and the jars are the >> >> > convenience distributions? >> >> > >> >> > Yep. The release are the zip/gz sources. All binaries are >> conveniences. >> >> > Granted that without a Maven Central jar release, a component is not >> easy >> >> > to reuse. >> >> > >> >> > Gary >> >> > >> >> > > >> >> > > regards, >> >> > > chas >> >> > >> >> >> >> >> >> >> >> -- >> >> Matt Sicker <boa...@gmail.com> >> >> >> > >> > >> > >> > -- >> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> > Java Persistence with Hibernate, Second Edition >> > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ >> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& >> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> >> > >> > <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= >> 1617290459> >> > JUnit in Action, Second Edition >> > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ >> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& >> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22 >> > >> > >> > <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= >> 1935182021> >> > Spring Batch in Action >> > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ >> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& >> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% >> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> >> > <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= >> 1935182951> >> > Blog: http://garygregory.wordpress.com >> > Home: http://garygregory.com/ >> > Tweet! http://twitter.com/GaryGregory >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > -- > Matt Sicker <boa...@gmail.com> -- Stian Soiland-Reyes http://orcid.org/0000-0001-9842-9718 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
