[
https://issues.apache.org/jira/browse/CASSANDRA-12239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15428634#comment-15428634
]
Michael Shuler commented on CASSANDRA-12239:
--------------------------------------------
[~urandom] do you have any thoughts on this topic?
Up to now, the committers that have acted as Release Manager have been added to
{{KEYS}}, since these are the users building the release artifacts uploaded to
Nexus. These same committers have also signed the debian repository Release
file.
If multiple people share a common gpg secret key to sign artifacts and deb
repo, that key will also need to be added to KEYS and the deb repo installation
instructions need to be updated to import the key. A similar security issue
could be raised for a shared common key. OS vendors like Debian/Ubuntu/Red Hat
use system automation to sign package releases, automated by validating trusted
signatures by uploaders, so that users have a single or small number of keys to
maintain, updating a key package along the way, as needed.
I looked through a bunch of different Apache project {{KEYS}} and also found
some examples of installation artifact validation instructions those projects
provide. All the ones I looked at had {{KEYS}} files containing committer's
keys. I did not find one that had something that looked like a common shared
key. I did not exhaustively look at every Apache project, but enough to get a
general idea of how a lot of other projects use {{KEYS}}.
Example: https://archive.apache.org/dist/httpd/ - the readme section at the end
has a verification tidbit that instructs to use the KEYS file
https://archive.apache.org/dist/httpd/KEYS which contains committer's public
keys in the same manner as Cassandra does currently.
I did not find an Apache project best practices document on how to handle this
situation on packaging, but it appears that Cassandra has been following how
other projects proceed.
As for the "list of debian devs" Sylvain's seeing in my patch, as well as our
existing {{KEYS}} file, those are signatures on mine and Eric's keys.
We should work this out, prior to my publicly releasing any artifacts,
otherwise, one of the existing committers in KEYS should do the releases.
> Add mshuler's key FE4B2BDA to dist/cassandra/KEYS
> -------------------------------------------------
>
> Key: CASSANDRA-12239
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12239
> Project: Cassandra
> Issue Type: Task
> Components: Packaging
> Reporter: Michael Shuler
> Assignee: Michael Shuler
> Fix For: 3.x
>
> Attachments: KEYS+mshuler.diff.txt
>
>
> I've started working on packaging with the 3.8 release and signed the staging
> artifacts with FE4B2BDA. This key will need to be added for the debian
> repository signature to function correctly, if it's released as-is, or
> perhaps [~tjake] will need to re-sign the release. Users will need to also
> fetch this new key and add to {{apt-key}}.
> {{KEYS}} patch attached.
> Assigned to myself, but I am not sure exactly where {{KEYS}} lives - in svn
> somewhere or a direct upload? :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
