Allow GnuPG 2 users to export keys with and without passphrase#59376
Conversation
|
All unit tests for gpg execution module are skipped. Some are marked as slow and the others as destructive. I'll try to update the tests soon. But in a clean environment, the "destructive" looks scary. |
|
If you can get this working on centos/rhel 8, that would be great, they seem to have tried to remove all methods of programmatically entering passphrases. It would be great for this to work in conjunction with the pkgbuild.make_repo as well in centos 8. Another issue I've seen is requiring a tty to work, if this could take care of that too, that would be pretty cool. |
Let's see what I can do. I still need to write the tests (which usually take a lot of time). Then I will test in other platforms, including CentOS 8. |
|
@bryceml , Ok, now I have the Can you check if this covers your usecases? Still need to update the unit tests. |
ed2bc06 to
cfc1ce1
Compare
df68e19 to
a2d8b08
Compare
|
Ok first the tests fails in all Debian derived platforms, then I re-write two tests to fix this but forgot to test one of them, so a new commit to fix the broked test, after that it seems all tests run Ok, except for ubuntu1804/pytest, but it did break in what I guess is an unrelated test in salt-proxy. Did a merge with master and finally it pass all tests. Please @xeacott, can you take a look if this PR is Ok while it's all green? |
2cb6c38 to
78c82aa
Compare
ea74504 to
812c486
Compare
s0undt3ch
left a comment
There was a problem hiding this comment.
All the tests that were decorated as destructive, if they change temp files or paths, they are not destructive, temp resources are meant to be "destroyable".
The slow decorator. why are these unit tests marked as slow?
s0undt3ch
left a comment
There was a problem hiding this comment.
I think this way the docs will build properly
|
And lets also remove the destructive decorator |
Ok, by night I can do the changes, test locally and then update this feature branch. |
- Calls gpg.export_keys with expect_passphrase = False to allow the export of keys without passphrase - Added support to export keys with a passphrase. - Behaviour controlled by parameter use_passphrase, defaulted to False
- Added parameter use_passphrase to delete_key - Added _gen_key_input to send %no-protection command to gen_key
- Added tests for new _gen_key_input function, used by create_key - Added tests for export_key - Updated tests for delete_key
- Removed the _gen_key_input function - Added code to add '%no-protection' independent of python-gnupg version - Updated the tests to test directly the gpg.create_key
The create_key tests are entropy dependent and can wait for a long time to have enough of it in the automated tests environment.
- Added versionadded information to use_passphrase argument in delete_key and export_key - Unmarked the tests that only writes at temporary files as destructive
3111633 to
3d9d3ca
Compare
|
@s0undt3ch , just did the required changes. I hope it's now Ok. |
What does this PR do?
Added the
use_passphraseparameter. This allows to export keys with a passphrase. The passphrase itself comes from pillargpg_passphrase.Added the
expect_passphrase = Falseto Python GnuPG'sexport_keyscall when theuse_passphraseis False (default). That allows the export of passwordless keys.What issues does this PR fix or reference?
Fixes: #58980
Previous Behavior
An error when calling
gpg.export_key, see the issue #58980Also, there was no support to use a passphrase.
New Behavior
It's now possible to export a key with and without a passphrase.
Merge requirements satisfied?
Commits signed with GPG?
No