lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Updated) (JIRA)" <>
Subject [jira] [Updated] (LUCENE-3945) we should include checksums for every jar ivy fetches in svn & src releases to verify the jars are the ones we expect
Date Wed, 04 Apr 2012 02:16:22 GMT


Hoss Man updated LUCENE-3945:

    Attachment: LUCENE-3945_trunk_jar_sha1.patch

previous patch with the addition of SHA1 files for all jars currently used on trunk.

SHA files were generated using...
ant clean resolve 
find -name \*.jar | xargs -L 1 sha1sum | awk '{ system("echo " $1 ">> " $2 ".SHA1")
find -name \*.SHA1 | xargs svn add

all tests pass these jars, but one thing i notice is that the classpath logic in most places
seems to be based on exclusion instead of inclusion (ie: 'excludes="*.txt,*.template"' instead
of 'includes="*.jar"') so with these SHA1 files added, we now get a metric shit ton of "ZipException:
error in opening zip file" warnints logged by junit because it's trying to parse these files
as jars

should we fix all these classpaths, or rename the files "*.SHA1.txt" ?

(note: i haven't even looked at the packaging yet to verify if the SHA1 files are being included
in the src builds and excluded from the bin builds)

> we should include checksums for every jar ivy fetches in svn & src releases to verify
the jars are the ones we expect
> ---------------------------------------------------------------------------------------------------------------------
>                 Key: LUCENE-3945
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Task
>            Reporter: Hoss Man
>             Fix For: 3.6, 4.0
>         Attachments: LUCENE-3945.patch, LUCENE-3945.patch, LUCENE-3945.patch, LUCENE-3945_trunk_jar_sha1.patch
> Conversation with rmuir last night got me thinking about the fact that one thing we lose
by using ivy is confidence that every user of a release is compiling against (and likely using
at run time) the same dependencies as every other user.
> Up to 3.5, users of src and binary releases could be confident that the jars included
in the release were the same jars the lucene devs vetted and tested against when voting on
the release candidate, but with ivy there is now the possibility that after the source release
is published, the owner of a domain where these dependencies are hosted might change the jars
in some way w/o anyone knowing.  Likewise: we as developers could commit an ivy.xml file pointing
to a specific URL which we then use for and test for months, and just prior to a release,
the contents of the remote URL could change such that a JAR included in the binary artifacts
might not match the ones we've vetted and tested leading up to that RC.
> So i propose that we include checksum files in svn and in our source releases that can
be used by users to verify that the jars they get from ivy match the jars we tested against.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message