commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject Re: Commons release policy
Date Mon, 05 Dec 2016 17:36:46 GMT
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 <boards@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 <sebbaz@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 <garydgregory@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 <boards@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 <garydgregory@gmail.com>
>> wrote:
>> >>
>> >> > On Dec 3, 2016 9:34 AM, "Charles Honton" <chas@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 <boards@gmail.com>
>> >>
>> >
>> >
>> >
>> > --
>> > E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> Matt Sicker <boards@gmail.com>



-- 
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message