Implement OpenPGP using librpm API #275
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jrohel
force-pushed
the
pgp_based_on_librpm
branch
from
06ff763
to
9ecfd9a
Compare
jrohel
force-pushed
the
pgp_based_on_librpm
branch
from
9ecfd9a
to
5fdbacc
Compare
jrohel
force-pushed
the
pgp_based_on_librpm
branch
from
5fdbacc
to
20fda1f
Compare
j-mracek
reviewed
Jun 27, 2023
jan-kolarik
reviewed
Jun 27, 2023
jan-kolarik
reviewed
Jun 27, 2023
jan-kolarik
reviewed
Jun 27, 2023
jan-kolarik
reviewed
Jun 27, 2023
jan-kolarik
reviewed
Jun 27, 2023
|
I think the CI should be fixed by a rebase. |
It implements the original librepo OpenPGP API using librpm API instead of GpgMe. It implements its own keyring for public keys. Each key with its subkeys is stored in its own file. The original GpgMe based implementation was moved to the "gpg_gpgme.c" file. So it is still present and can be activated by the USE_GPGME option in "CMakeList.txt". This commit will leave the original GpgMe implementation enabled by default in CMakeList.txt. In the .spec file it switches to the librpm API for Fedora >= 39. Requirement: A new rpm library is needed that supports OpenPGP ASCII Armored signature parsing. Tested with sequoia based rpm OpenPGP backend. Missing (requires support in the rpm library): - Setting the `can_sign` property. It now always returns TRUE. - Fingerprint for subkeys. An empty string is now returned. - Return all user IDs. Now only one returns Notes: In the Python tests, pgp tests that should succeed were disabled. This is because librepo lacks a Python API for working with OpenGPG keys. The Python tests manipulate the keyring directly using GpgMe. Of course, this only works if the librepo library uses the original GpgMe backend.
jrohel
force-pushed
the
pgp_based_on_librpm
branch
from
20fda1f
to
29ef387
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implements the original librepo OpenPGP API using librpm API instead of GpgMe. It implements its own keyring for public keys. Each key with its subkeys is stored in its own file.
The original GpgMe based implementation was moved to the "gpg_gpgme.c" file. So it is still present and can be activated by the USE_GPGME option in "CMakeList.txt".
This PR leaves the original GpgMe implementation enabled by default in CMakeList.txt. In the .spec file it switches to the librpm API for Fedora >= 39.
Requirement:
A new rpm library is needed that supports OpenPGP ASCII Armored signature parsing. Tested with sequoia based rpm OpenPGP backend.
Missing (requires support in the rpm library):
can_signproperty. It now always returns TRUE.Notes:
In the Python tests, pgp tests that should succeed were disabled. This is because librepo lacks a Python API for working with OpenGPG keys. The Python tests manipulate the keyring directly using GpgMe. Of course, this only works if the librepo library uses the original GpgMe backend.