Thanks for your explanation, Willem. 

Let me make it clear, my concern is that a public key ever signed for one 
release, and now this key is compromised, and although this key is in KEYS 
file, it could not work well. 
Therefore we could not use it for verify the integrity of old release in [1] 
anymore. 


On the one hand, we keep this key in KEY file, people would get the wrong 
information when verifying this legacy release, for it is a bad key; On the 
other hand, if we delete if from KEY file, people could not verify this release 
either.


So, if Liang could not use the old key for some reason anymore, he has to keep 
the old one well for previous release verification, and to create a new one for 
the coming release in the meantime. Is it right?


[1] https://www.apache.org/dyn/closer.cgi#verify


 Juan Pan (Trista) 
                         
Senior DBA & PPMC of Apache ShardingSphere(Incubating)
E-mail: panj...@apache.org




On 01/2/2020 12:08,Willem Jiang<willem.ji...@gmail.com> wrote:
No, I don't think using the KEYS file can keep good track of the
public key, it doesn't support the revoke operation.
It's better to use the public Key server to host the public key and we
can know if the key is revoked or not.


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Thu, Jan 2, 2020 at 12:04 PM Juan Pan <panj...@apache.org> wrote:

That means once one key was used for one release, it could not be deleted from 
KEYS files anymore no matter it is great on or not, right?


Juan Pan (Trista)

Senior DBA & PPMC of Apache ShardingSphere(Incubating)
E-mail: panj...@apache.org




On 01/2/2020 12:00,Willem Jiang<willem.ji...@gmail.com> wrote:
If someone use the compromised private to sign a new release, we
should be able to tell if the public key is revoked.
If we just delete the key from the KEY file, it's hard to tell if the
public key is valid or not.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Thu, Jan 2, 2020 at 11:55 AM Juan Pan <panj...@apache.org> wrote:

Hi Willem,


Just for curiosity, if the old key was used for one release and now is 
compromised, how about the release signed by this old and compromised key?
Since this release exists in our release list and if anyone downloads it from 
our website and intends to check it again with the bad key.


Thanks, trista


Juan Pan (Trista)

Senior DBA & PPMC of Apache ShardingSphere(Incubating)
E-mail: panj...@apache.org




On 01/2/2020 11:29,Willem Jiang<willem.ji...@gmail.com> wrote:
If the private key is compromised[1] or if we cannot find the private
key, we should revoke the public KEY[2].
Please keep your private key in a safe place.

[1]https://www.thesslstore.com/blog/heres-what-happens-when-your-private-key-gets-compromised/
[3]http://blog.chapagain.com.np/gpg-revoking-your-public-key-and-notifiying-key-server/

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Thu, Jan 2, 2020 at 10:21 AM Sheng Wu <wu.sheng.841...@gmail.com> wrote:

You can't simply delete the old one. Because ShardingSphere has existing
release based on that KEY :)
We could still continue in this way, but it should not be recommended if
your old key is still available.

Sheng Wu 吴晟
Twitter, wusheng1108


Juan Pan <panj...@apache.org> 于2020年1月2日周四 上午10:18写道:

Hi Liang,


If you plan not to use the old one any more, deleting is is an alternative
to avoid confusion. If so, it is necessary to delete it in KEYS file and
public key servers, IMO.


Juan Pan (Trista)

Senior DBA & PPMC of Apache ShardingSphere(Incubating)
E-mail: panj...@apache.org




On 01/1/2020 21:26,Sheng Wu<wu.sheng.841...@gmail.com> wrote:
My concern is making people confused. The PGP could export and import from
the old laptop. You don't need a new one.

Sheng Wu 吴晟
Twitter, wusheng1108


zhangli...@apache.org <zhangli...@apache.org> 于2020年1月1日周三 下午8:55写道:

A question, why you have two pgp keys in the KEYS file?

I change a computer, the 1st one is for the 4.0.0-RC1, the 4th one is for
this version.
Do you think we could remove the 1st one? because I will never use that gpp
key again, but do we need to keep it to make the 4.0.0-RC1 can be validate?

------------------

Liang Zhang (John)
Apache ShardingSphere & Dubbo


Sheng Wu <wu.sheng.841...@gmail.com> 于2020年1月1日周三 下午8:34写道:

Hi Liang Zhang

A question, why you have two pgp keys in the KEYS file?

Sheng Wu 吴晟
Twitter, wusheng1108


zhangli...@apache.org <zhangli...@apache.org> 于2019年12月30日周一 下午9:44写道:

Hello ShardingSphere Community,

This is a call for vote to release Apache ShardingSphere (Incubating)
version 4.0.0

Release notes:




https://github.com/apache/incubator-shardingsphere/blob/dev/RELEASE-NOTES.md

The release candidates:
https://dist.apache.org/repos/dist/dev/incubator/shardingsphere/4.0.0/

Maven 2 staging repository:




https://repository.apache.org/content/repositories/orgapacheshardingsphere-1029/org/apache/shardingsphere/

Git tag for the release:
https://github.com/apache/incubator-shardingsphere/tree/4.0.0/

Release Commit ID:




https://github.com/apache/incubator-shardingsphere/commit/f81f4f03b1dd4b426adf1f29ffe93f9540ce6fc9

Keys to verify the Release Candidate:
https://dist.apache.org/repos/dist/dev/incubator/shardingsphere/KEYS

Look at here for how to verify this release candidate:
https://shardingsphere.apache.org/community/en/contribute/release/

The vote will be open for at least 72 hours or until necessary number
of
votes are reached.

Please vote accordingly:

[ ] +1 approve

[ ] +0 no opinion

[ ] -1 disapprove with the reason

Checklist for reference:

[ ] Download links are valid.

[ ] Checksums and PGP signatures are valid.

[ ] DISCLAIMER is included.

[ ] Source code artifacts have correct names matching the current
release.

[ ] LICENSE and NOTICE files are correct for each ShardingSphere repo.

[ ] All files have license headers if necessary.

[ ] No compiled archives bundled in source archive.

------------------

Liang Zhang (John)
Apache ShardingSphere & Dubbo




Reply via email to