commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: Commons release policy
Date Mon, 05 Dec 2016 17:57:50 GMT
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 <stain@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 <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=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-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
>
>


-- 
Matt Sicker <boards@gmail.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message