Skip to content

Generate non-encrypted license public key #34626

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 24, 2018
Merged

Generate non-encrypted license public key #34626

merged 1 commit into from
Oct 24, 2018

Conversation

hanbing0715
Copy link
Contributor

@hanbing0715 hanbing0715 commented Oct 19, 2018

After this commit(cca1a2a), Elasticsearch use fips-140 compliant key-pair to sign x-pack license , which public key is store in plain-text, but the key-pair-generator tool still generate old-style encrypted public key.
This patch edit the key-pair-generator to generate a key pair that public key is not encrypted.

@tvernum tvernum requested a review from jkakavas October 19, 2018 05:36
@tvernum tvernum added the :Security/Security Security issues without another label label Oct 19, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security

@jkakavas
Copy link
Member

Hi @hanbing0715 ! Thank you for your contribution. You are right that there is no need for key-pair-generator to generate an encrypted public key any more after the changes introduced in cca1a2a.
Taking the opportunity of you raising this, I believe key-pair-generator and KeyPairGenerator.java are not used anymore and we can safely remove them from the codebase. I will make sure this is true, but if not, I'll go ahead with running CI and merging this.

Would you mind changing the PR title and text to denote that the change has nothing to do with FIPS 140-2 compliance? What this PR changes, is that the public key that key-pair-generator generates is not stored on disk in an encrypted format.

@hanbing0715 hanbing0715 changed the title Generate FIPS-140 compliant key pair Generate non-encrypted public key public key Oct 22, 2018
@hanbing0715 hanbing0715 changed the title Generate non-encrypted public key public key Generate non-encrypted license public key Oct 22, 2018
@hanbing0715
Copy link
Contributor Author

Hi @hanbing0715 ! Thank you for your contribution. You are right that there is no need for key-pair-generator to generate an encrypted public key any more after the changes introduced in cca1a2a.
Taking the opportunity of you raising this, I believe key-pair-generator and KeyPairGenerator.java are not used anymore and we can safely remove them from the codebase. I will make sure this is true, but if not, I'll go ahead with running CI and merging this.

Would you mind changing the PR title and text to denote that the change has nothing to do with FIPS 140-2 compliance? What this PR changes, is that the public key that key-pair-generator generates is not stored on disk in an encrypted format.

I already edit the PR titile and text

@jkakavas
Copy link
Member

jkakavas commented Oct 22, 2018

@elasticmachine test this please

Copy link
Member

@jkakavas jkakavas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jkakavas jkakavas merged commit fe54f73 into elastic:master Oct 24, 2018
jkakavas pushed a commit that referenced this pull request Oct 24, 2018
The changes introduced in cca1a2a mean that we should
not encrypt the public keys that might be generated by
the key-pair-generator when storing the file, as the code 
that would consume them assumes that they are not encrypted
@hanbing0715 hanbing0715 deleted the gen-fips-140-license branch October 25, 2018 01:57
@jaymode
Copy link
Member

jaymode commented Oct 26, 2018

@jkakavas you have the backport pending label, are you planning to backport to 6.x? If so, please add the appropriate version label.

kcm pushed a commit that referenced this pull request Oct 30, 2018
The changes introduced in cca1a2a mean that we should
not encrypt the public keys that might be generated by
the key-pair-generator when storing the file, as the code 
that would consume them assumes that they are not encrypted
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants