Uploaded image for project: 'Lucene - Core'
  1. Lucene - Core
  2. LUCENE-3945

we should include checksums for every jar ivy fetches in svn & src releases to verify the jars are the ones we expect

Details

    • Task
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • 3.6, 4.0-ALPHA
    • None
    • None
    • New

    Description

      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.

      Attachments

        1. LUCENE-3945_trunk_jar_sha1.patch
          40 kB
          Chris M. Hostetter
        2. LUCENE-3945_trunk_jar_sha1.patch
          38 kB
          Chris M. Hostetter
        3. LUCENE-3945_trunk_jar_sha1.patch
          34 kB
          Chris M. Hostetter
        4. LUCENE-3945.patch
          5 kB
          Chris M. Hostetter
        5. LUCENE-3945.patch
          5 kB
          Chris M. Hostetter
        6. LUCENE-3945.patch
          4 kB
          Chris M. Hostetter

        Activity

          People

            Unassigned Unassigned
            hossman Chris M. Hostetter
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: