RPM Support

This should be broken up in two stories.

1) Pulling out the signature from RPM on upload and storing the signature as a searchable field.

2) Verifying the signature during a publish and only including correctly signed RPMs

What about other types like SRPM or DRPMs? This should be modeled on the right class which probably isn't RPM itself. This needs to be answered before continuing.

Probably "Yes" for all three. RPM and SRPM are practically the same thing, so we'll likely just put an attribute on RpmBase and put both models through the same code path to get the signature. DRPM might be a little different, but maybe not.

Also DRPM intherits through a different path so I had planned on not incorporating them in this way. What do you think?

Our RCM folks don't use DRPMs, so that's one factor. I suspect that it will be such little extra work to handle DRPMs while already doing SRPM and RPM, that it'll make sense to just get it all done at once. I found that to be the case with the checksum work recently. It could still be split out into a separate story if you prefer, but I'd lean toward adding a note to this issue to do DRPM as long as it's a no-brainer, and otherwise create a new story for it.

I do think that feature-wise, DRPMs should have the same gpg features as RPMs. Even if nobody is asking for it right now, the overall gpg story in pulp_rpm would be incomplete without it. So if we do defer that work, we should at least track it and try to prioritize it in the future.

To clarify, here's an example of a single result returned by a call to POST /{repository_href}/search/units/. Notice the obj['metadata']['signing_key'] attribute.

{'_id': {'$oid': '57acac7c189c7a1b5fa56e3c'},
 'created': '2016-08-11T16:49:00Z',
 'metadata': {'_content_type_id': 'srpm',
              '_id': 'b266b670-644c-4b43-b866-5843243e010a',
              '_last_updated': 1470934140,
              '_ns': 'units_srpm',
              '_storage_path': '/var/lib/pulp/content/units/srpm/01/d3b1d5e32fae6b044e0c07529c763bea083f387c245da1b106e96599197319/78459f5c-cb18-40e1-a912-ef8cdd6b67ea',
              'arch': 'src',
              'build_time': 1331302125,
              'buildhost': 'localhost',
              'changelog': [],
              'checksum': 'f9d40aa83892c5da05e5b94d8428ff744c27bfad363f31c18454ca797e8306cc',
              'checksums': {'md5': 'e5213cb8f1c75a638763f209324e72de',
                            'sha1': '6412b4b2113eb40c964dc3325d8e23bce853f8e7',
                            'sha256': 'f9d40aa83892c5da05e5b94d8428ff744c27bfad363f31c18454ca797e8306cc'},
              'checksumtype': 'sha256',
              'description': '\nThis is a test rpm',
              'downloaded': True,
              'epoch': '0',
              'filename': 'test-srpm02-1.0-1.src.rpm',
              'files': {},
              'header_range': {},
              'license': 'GPLv2',
              'name': 'test-srpm02',
              'provides': [],
              'pulp_user_metadata': {},
              'relativepath': 'test-srpm02-1.0-1.src.rpm',
              'release': '1',
              'release_sort_index': '01-1',
              'repodata': {'filelists': '…',
                           'other': '…',
                           'primary': '…'},
              'requires': [],
              'signing_key': '269d9d98',
              'time': 1470934139,
              'version': '1.0',
              'version_sort_index': '01-1.01-0'},
 'repo_id': '8546305a-45d4-4b9d-beef-d4fd6b70d639',
 'unit_id': 'b266b670-644c-4b43-b866-5843243e010a',
 'unit_type_id': 'srpm',
 'updated': '2016-08-11T16:49:00Z'}

Ichimonji10 wrote:

This feature seems to be implemented, except that Pulp names the attribute "signing_key," not "signature."

We renamed that to signing_key because we thought that this name would be more appropriate

I want to make sure there's an explicit acknowledgement from the dev side that the solution as implemented is different from what's asked for in the requirements, above. If y'all are OK with it, then I'm OK with it.