RPM Support

I lean more toward preventing content from being associated to the repo, but it would be interesting to get RCM's opinion. Once a bunch of RPMs signed by the wrong key land in a repo, it could be a real pain to identify and remove each one.

The public key would be an importer config setting.

For the lazy case, that's a good question. A simple option is to just not enable this feature unless the download policy is immediate. That's the only way for us to prevent wrongly-signed content from getting added to a repo.

A different option, which I'm not crazy about but will describe anyway, would be to make this more of an advisory feature than an enforcement feature. We could show on each unit whether the signature is good, bad, or unknown, and let the user sort it out as they please. To me this sounds more cumbersome and less useful.

Have any other ideas?

Here is info about Red Hat's keys: https://access.redhat.com/security/team/key

And Fedora's: https://getfedora.org/keys/

It's important to note that some keys expire, but that is an optional feature of gpg keys. Looking at Red Hat's, it appears they do not expire. Same for Fedora.

None the less, they could get revoked and replaced at some point if compromised, or if they for some reason become unavailable for further use. For those reasons, we should support the ability to add additional keys to an importer at any time.

ipanova@redhat.com wrote:

The signature check will be implemented for upload as well as for sync. Due to the fact that signature check is incompatible with lazy sync, some restrictions will be applied, therefore signature check will work only with immediate download policy.

These conditions and restrictions are related just to the sync case:

1) it will not be possible to create repo with on_demand/background policy and with signature check

Do you mean s/repo/importer/ ? ^

2) once you created and synced the repository with immediate download policy and signature check, the policy cannot be switched
3) once you created repo with lazy download policy and synced it, you will not be able to change the policy to immediate with signature check
4) allow_keys can be updated with additional keys, allow_unsigned should be immutable

For clarity to ^, you could add a specific statement that allow_keys can not have keys removed after a sync occurs.

5) once you created repo with immediate download policy( with no signature check) and synced it, you cannot update repo to enable signature check

Do you mean s/repo/importer/ ? ^

Here is maybe a shorter set of rules for the restrictions:

1. If an importer has been used for a sync or upload and if the allow_keys allow_keys attribute is None, reject the setting of allow_keys
2. If an importer has been used for sync or upload, reject an update for the download policy attribute
3. If an importer has a download policy of not immediate (now or in this update) and allow_keys (now or in this update) is not None, reject the importer update
4. reject updates for allow_unsigned since it is immutable

I was thinking that 'signature_keys' could be a better name for the option than 'allow_keys'.

It seems like ipanova and bmbouter have clarified some questions about this feature. Can those clarifications be rolled back into the original issue description? That'd really help QE test the feature.

What values may go in allow_keys? Is it a list of PGP keys, or some other kind of key? Can I go to https://repos.fedorapeople.org/pulp/pulp/fixtures/, download an RPM, extract it, and find valid value that may be placed in allow_keys?

What happens if allow_keys is an empty list and allow_unsigned is true? Does that mean I can import unsigned RPMs into a repository, but not signed RPMs?

Are the same set of restrictions in place regardless of whether one is:

• importing units via direct upload,
• syncing in units via a feed, or
• copying units between repositories?

This feature appears to be implemented. However, the actual implementation uses keys named require_signature and allowed_keys, not allow_unsigned and allow_keys. Can I get an explicit confirmation from the developers that the implementation intentionally differs from the requirements?

Ichimonji10 wrote:

This feature appears to be implemented. However, the actual implementation uses keys named require_signature and allowed_keys, not allow_unsigned and allow_keys. Can I get an explicit confirmation from the developers that the implementation intentionally differs from the requirements?

Yes, this is also confirmed and described in docs and release notes.

I can verify that Pulp correctly checks key IDs for uploaded packages. I can't say anything about synced-in or copied packages.

I am not sure if the correct way would be to move the state to assigned or rather to open a new issue, because 1) i bet you tested against master, here the target release is 2.10. In 2.10-dev sync with signature filter works as expected( i just checked). so seems like it is a regression which was introduced on master.

first suspicious thing that comes to my attention is wrong unit count during download : downloading 6 rpms out of 3

 pulp-admin rpm repo sync run --repo-id test

+----------------------------------------------------------------------+
                    Synchronizing Repository [test]
+----------------------------------------------------------------------+

This command may be exited via ctrl+c without affecting the request.

Downloading metadata...
[|]
... completed

Downloading repository content...
[====================================================================================================] 200%
RPMs:       6/3 items
Delta RPMs: 0/0 items

... completed

Individual package errors encountered during sync:

3 packages failed signature filter and were not imported.

1) i bet you tested against master, here the target release is 2.10

I'm testing against the 2.10.1 nightly build.

$ ssh $hostname rpm -qa | sort | grep -i pulp
pulp-admin-client-2.10.1-0.1.alpha.git.7.da8dea2.fc24.noarch
pulp-docker-admin-extensions-2.1.1-0.1.alpha.git.9.e48c093.fc24.noarch
pulp-docker-plugins-2.1.1-0.1.alpha.git.9.e48c093.fc24.noarch
pulp-puppet-admin-extensions-2.10.1-0.1.alpha.git.25.b1e70b6.fc24.noarch
pulp-puppet-plugins-2.10.1-0.1.alpha.git.25.b1e70b6.fc24.noarch
pulp-python-admin-extensions-1.1.2-1.fc24.noarch
pulp-python-plugins-1.1.2-1.fc24.noarch
pulp-rpm-admin-extensions-2.10.1-0.1.alpha.git.11.83ec388.fc24.noarch
pulp-rpm-plugins-2.10.1-0.1.alpha.git.11.83ec388.fc24.noarch
pulp-selinux-2.10.1-0.1.alpha.git.7.da8dea2.fc24.noarch
pulp-server-2.10.1-0.1.alpha.git.7.da8dea2.fc24.noarch
python-kombu-3.0.33-6.pulp.fc24.noarch
python-pulp-bindings-2.10.1-0.1.alpha.git.7.da8dea2.fc24.noarch
python-pulp-client-lib-2.10.1-0.1.alpha.git.7.da8dea2.fc24.noarch
python-pulp-common-2.10.1-0.1.alpha.git.7.da8dea2.fc24.noarch
python-pulp-docker-common-2.1.1-0.1.alpha.git.9.e48c093.fc24.noarch
python-pulp-oid_validation-2.10.1-0.1.alpha.git.7.da8dea2.fc24.noarch
python-pulp-puppet-common-2.10.1-0.1.alpha.git.25.b1e70b6.fc24.noarch
python-pulp-python-common-1.1.2-1.fc24.noarch
python-pulp-repoauth-2.10.1-0.1.alpha.git.7.da8dea2.fc24.noarch
python-pulp-rpm-common-2.10.1-0.1.alpha.git.11.83ec388.fc24.noarch
python-pulp-streamer-2.10.1-0.1.alpha.git.7.da8dea2.fc24.noarch

oh i see you are right, i did not have pulled latest changes.
hm, these changes might have to do with wring unit count to download https://github.com/pulp/pulp_rpm/commit/8e2bfe7120654b65899c510108374212a33d3435