lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Updated) (JIRA)" <j...@apache.org>
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 Tue, 03 Apr 2012 19:04:24 GMT

     [ https://issues.apache.org/jira/browse/LUCENE-3945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Hoss Man updated LUCENE-3945:
-----------------------------

    Attachment: LUCENE-3945.patch

Here's a strawman suggestion for adding a SHA1 check to our custom LicenseCheckTask, it was
inspired by some of the code in ant's <checksum/> task, but it's not as configurable
(only supports one SHA1 and only the simplest file format)

I put this code in LicenseCheckTask because:
 * LicenseCheckTask already gets run when you use "ant validate" and that seems like the right
place for it from a user perspective
 * ant's built in support for verifying checksums in the <checksum/> task will only
set a property true/false if the checksum for a file doesn't match -- even with -verbose,
it won't tell you which file failed the checksum test, so it wasn't really suitable to adding
to our "ant validate" target.
 * if i added a new ShaCheckTast we would have to configure it to run over all the same files
LicenseCheckTask is already run over. 

If people want to pursue this, We can always refactor -- either to generalize the name/description
of of "LicenseCheckTask" or to refactor this out into it's own custom task (and do an extra
jar crawl).

(NOTE: current patch doesn't actually include the checksums themselves, so as is this will
fail the build.  If we trust what "ant resolve" is pulling down right now, the files would
be trivial for anyone to generate, but i would suggest being a little more diligent and and
generating the SHA1s against what was committed in svn up until last week -- except obviously
where we've actually changed which jar/version we use because of the ivy work)

Comments?

                
> 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: https://issues.apache.org/jira/browse/LUCENE-3945
>             Project: Lucene - Java
>          Issue Type: Task
>            Reporter: Hoss Man
>             Fix For: 3.6, 4.0
>
>         Attachments: LUCENE-3945.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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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


Mime
View raw message