I usually include sha512 hashes in my release emails, but I try to remain overly paranoid about cryptography. As for whether or not sha1 is still useful for cryptographic signatures, the hash itself is encrypted in a signature, so you still need access to the private key to create the signature in the first place, so it's still as secure as the crypto algorithm itself.
On 5 December 2016 at 11:36, Stian Soiland-Reyes <st...@apache.org> wrote: > 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=cadb800f39946ec62ea2b1af9fe6a2 > b8> > >> > > >> > <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=31ecd1f6b6d1eaf8886ac902a24de4 > 18%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 > > -- Matt Sicker <boa...@gmail.com>
