[Pulp-dev] signing service interface

[Dennis Kliban]

On Wed, May 6, 2020 at 4:07 AM Matthias Dellweg <mdellweg at redhat.com> wrote:

> As i see it, it is up to the subclass (e.g. AptReleaseSigningService,
> YumMetadataSigninigService, ...) to provide a stable interface. And the way
> it is implemented, the script for an AptReleaseSigninigService is required
> to report the filenames of both created signatures. And that is verified by
> the service before saving to the database.
>

In case of the RPM plugin, the content handler needs to be able to know
what the public key file is named without actually executing the sign() or
validate() method. I don't see anything in the AptReleaseSigninigService[0]
that provides that functionality.

The implementation of the AsciiArmoredDetachedSigningService[1] could
provide a method for retrieving the public key file name and the validate()
method would have to enforce it. Would this be more valuable to implement
at the base class (SigningService) level[2]?

[0]
https://github.com/pulp/pulp_deb/blob/master/pulp_deb/app/models/signing_service.py#L12
[1]
https://github.com/pulp/pulpcore/blob/3.3/pulpcore/app/models/content.py#L447
[2]
https://github.com/pulp/pulpcore/blob/3.3/pulpcore/app/models/content.py#L377


>
> On Tue, May 5, 2020 at 11:51 PM Dennis Kliban <dkliban at redhat.com> wrote:
>
>> On Tue, May 5, 2020 at 3:39 AM Quirin Pamp <pamp at atix.de> wrote:
>>
>>> Could you explain the reasoning for a 'public.key' file?
>>>
>>
>> The public.key file is the file that a yum/dnf client can use to verify
>> that the metadata in an RPM repository was signed by the signing service
>> associated with the repository. The name of the file can be anything - the
>> path to it needs to be specified in the repository config on the client.
>>
>>
>>> In the case of the AptReleaseSigningService we built for pulp_deb we saw
>>> zero need for this file and consequently did not add it in.
>>>
>>> (It would not be hard to add it just to satisfy the interface, it just
>>> would not serve any useful purpose.)
>>>
>>
>> It is definitely up to each plugin if it wants to provide the public key
>> as part of the publication. It is currently impossible for the plugin to
>> know exactly what files are produced by the signing service. This is where
>> I would like to see an improvement in the API. Pupcore should provide a
>> guarantee to plugin writers that a signing service configured by an
>> administrator is functioning in a predictable way. One possible way to do
>> that is with an interface that lets a plugin writer inspect a signing
>> service without executing it. Though I am looking for other ideas in this
>> area.
>>
>>
>>>
>>> Since we are on the topic of signing services, a colleague has had a PR
>>> relating to them just sitting their waiting for a review for quite a while
>>> now ;-):
>>> https://github.com/pulp/pulpcore/pull/659
>>>
>>>
>>> It would be great if you (or somebody else) could have a look at it. I
>>> believe it is mostly ready, but probably needs the eyes of an experienced
>>> pulp core developer to look over it and suggest style consistency changes
>>> and where and whether to add documentation. ;-)
>>>
>>
>> I'll take a look at this PR.
>>
>>
>>
>>>
>>> Quirin
>>> ------------------------------
>>> *From:* pulp-dev-bounces at redhat.com <pulp-dev-bounces at redhat.com> on
>>> behalf of Dennis Kliban <dkliban at redhat.com>
>>> *Sent:* 04 May 2020 22:50:54
>>> *To:* Pulp-dev <pulp-dev at redhat.com>
>>> *Subject:* [Pulp-dev] signing service interface
>>>
>>> The Plugin API of Signing Services in Pulp 3 is too vague. I came to
>>> this conclusion while working with @lieter on an RPM plugin feature that
>>> allows users to download a repo config file from a distribution[0]. As a
>>> result, we decided to document that the signing service needs to produce a
>>> public key file named 'public.key'[1].
>>>
>>> We should revisit the design of the signing service API to ensure that
>>> we enforce this naming convention.
>>>
>>> [0] https://pulp.plan.io/issues/5356
>>> [1]
>>> https://github.com/pulp/pulp_rpm/pull/1687/files#diff-c91893c1f4e7afe73e414d1a76162463R30
>>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200506/f459b059/attachment.htm>