[
https://issues.apache.org/jira/browse/LUCENE-5143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16426794#comment-16426794
]
Jan Høydahl edited comment on LUCENE-5143 at 4/5/18 11:58 AM:
--------------------------------------------------------------
I put together a script verify.sh [^verify.sh] that :
* Lists all files in lucene and solr folder in archive
* Downloads all src artifacts (the smallest) with .asc files
* Downloads KEYS file from this JIRA and imports it in a clean gpg (Docker)
* Verify all sigs and produce a report
First run with my first KEYS file on this JIRA gave this result:
{noformat}
SUMMARY
=======
Number of artifacts to check: 158
Number of artifacts checked : 158
Number of artifacts SUCCESS : 150
Number of artifacts FAILED : 8
{noformat}
The 8 failed files were
* lucene-2.2.0-src.tar.gz
* lucene-2.3.0-src.tar.gz
* lucene-2.3.1-src.tar.gz
* lucene-2.3.2-src.tar.gz
* lucene-6.4.0-src.tgz
* lucene-7.3.0-src.tgz
* solr-6.4.0-src.tgz
* solr-7.3.0-src.tgz
There were three missing keys in my compiled KEYS file:
{noformat}
gpg: key 1F2123C36BD872A0: public key "Michael Busch (Lucene Committer)
<[email protected]>" imported
gpg: key 707B7D9F6FDB8105: public key "Jim Ferenczi (CODE SIGNING KEY)
<[email protected]>" imported
gpg: key 069E9741F3D97FD6: public key "Alan Woodward
<[email protected]>" imported
{noformat}
After adding them to the end of the KEYS file, all artifacts verify ok
{noformat}
SUMMARY
=======
Number of artifacts to check: 158
Number of artifacts checked : 158
Number of artifacts SUCCESS : 158
Number of artifacts FAILED : 0
{noformat}
See complete [^verify.log] in attachment, and new [^KEYS] file attached.
The important thing is that the KEYS file can verify all releases. It may not
contain all keys for the last added committers, but then they will get notified
once they become RM the first time that they have to update KEYS file with
their own PGP public key.
was (Author: janhoy):
I put together a script verify.sh [^verify.sh] that :
* Lists all files in lucene and solr folder in archive
* Downloads all src artifacts (the smallest) with .asc files
* Downloads KEYS file from this JIRA and imports it in a clean gpg (Docker)
* Verify all sigs and produce a report
First run with my first KEYS file on this JIRA gave this result:
{noformat}
SUMMARY
=======
Number of artifacts to check: 158
Number of artifacts checked : 158
Number of artifacts SUCCESS : 150
Number of artifacts FAILED : 8
{noformat}
The 8 failed files were
* lucene-2.2.0-src.tar.gz
* lucene-2.3.0-src.tar.gz
* lucene-2.3.1-src.tar.gz
* lucene-2.3.2-src.tar.gz
* lucene-6.4.0-src.tgz
* lucene-7.3.0-src.tgz
* solr-6.4.0-src.tgz
* solr-7.3.0-src.tgz
There were three missing keys in my compiled KEYS file:
{noformat}
gpg: key 1F2123C36BD872A0: public key "Michael Busch (Lucene Committer)
<[email protected]>" imported
gpg: key 707B7D9F6FDB8105: public key "Jim Ferenczi (CODE SIGNING KEY)
<[email protected]>" imported
gpg: key 069E9741F3D97FD6: public key "Alan Woodward
<[email protected]>" imported
{noformat}
After adding them to the end of the KEYS file, all artifacts verify ok
{noformat}
SUMMARY
=======
Number of artifacts to check: 158
Number of artifacts checked : 158
Number of artifacts SUCCESS : 158
Number of artifacts FAILED : 0
{noformat}
See complete [^verify.log] in attachment, and new [^KEYS] file attached.
The important thing is that the KEYS file can verify all releases. It may not
contain all keys for the last added committers, but then they will get notified
once they become RM the first time that they have to update KEYS file with
their own PGP public key.
> rm or formalize dealing with "general" KEYS files in our dist dir
> -----------------------------------------------------------------
>
> Key: LUCENE-5143
> URL: https://issues.apache.org/jira/browse/LUCENE-5143
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Hoss Man
> Assignee: Jan Høydahl
> Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: KEYS, KEYS, KEYS, LUCENE-5143.patch, LUCENE-5143.patch,
> LUCENE-5143.patch, LUCENE-5143_READMEs.patch, LUCENE-5143_READMEs.patch,
> LUCENE-5143_READMEs.patch, LUCENE_5143_KEYS.patch, verify.log, verify.sh,
> verify.sh
>
>
> At some point in the past, we started creating a snapshots of KEYS (taken
> from the auto-generated data from id.apache.org) in the release dir of each
> release...
> http://www.apache.org/dist/lucene/solr/4.4.0/KEYS
> http://www.apache.org/dist/lucene/java/4.4.0/KEYS
> http://archive.apache.org/dist/lucene/java/4.3.0/KEYS
> http://archive.apache.org/dist/lucene/solr/4.3.0/KEYS
> etc...
> But we also still have some "general" KEYS files...
> https://www.apache.org/dist/lucene/KEYS
> https://www.apache.org/dist/lucene/java/KEYS
> https://www.apache.org/dist/lucene/solr/KEYS
> ...which (as i discovered when i went to add my key to them today) are stale
> and don't seem to be getting updated.
> I vaguely remember someone (rmuir?) explaining to me at one point the reason
> we started creating a fresh copy of KEYS in each release dir, but i no longer
> remember what they said, and i can't find any mention of a reason in any of
> the release docs, or in any sort of comment in buildAndPushRelease.py
> we probably do one of the following:
> * remove these "general" KEYS files
> * add a disclaimer to the top of these files that they are legacy files for
> verifying old releases and are no longer used for new releases
> * ensure these files are up to date stop generating per-release KEYS file
> copies
> * update our release process to ensure that the general files get updated on
> each release as well
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
