[Pulp-dev] signing service interface

Mon May 11 13:09:44 UTC 2020

On Mon, May 11, 2020 at 3:21 AM Matthias Dellweg <mdellweg at redhat.com>
wrote:

> What i like about this proposal is, that the yet unwritten rule, that one
> signing service is really meant to sign with one specific key would be very
> explicit.
>
I agree

We could go one step further and provide the key ID as environment to the
> script called (to make that part reusable / packageable).
>
+1 to packaging something reusable, but how do you imagine the key ID on
the data model relate to usages where the script is a gateway to an
external?

> Also we could state, that there is no reason to ever change a
> SigningService object, but to create a new one if you need to rekey or
> change the script behind it.
>
The implications of not being able to modify a SigningService is that after
an Administrator makes a change, pulp-API-users managing repositories that
would be pointing to that SigningService would have to
"switch-and-publish". If we can modify a SigningService then
pulp-repo-users with repositories would just need to republish. What do you
think about these outcomes?

>
> On Fri, May 8, 2020 at 8:03 PM Brian Bouterse <bmbouter at redhat.com> wrote:
>
>> From a goals perspective, we're trying to strengthen the interface
>> between Administrators configuring the signing service and plugin writers
>> using that signing service. One way to make that very explicit is to have
>> the contents of the public key live on the model itself (like we store keys
>> on Remote's as a TextField) for example.
>>
>> Plugin writers using the signing interface could access it directly
>> without having to "sign dummy data". Additionally, you could even search
>> SigningService's by it which would be more usable when figuring out "oh
>> which one of these is the one I need to update". I don't see any downsides
>> to this proposal, but what do you think? What are the benefits of returning
>> the key at runtime from the Admin's script over this approach?
>>
>> On Thu, May 7, 2020 at 3:51 AM Matthias Dellweg <mdellweg at redhat.com>
>> wrote:
>>
>>> > 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.
>>> This opens a new can of worms. But as far as i see it, metadata is
>>> signed when creating the publication. Along with the signature, the signing
>>> script provides the public key as a file. The publication task now turns
>>> the signature into a published artifact, and imho could do the same to the
>>> key. Why does the content handler need to retrieve the key again? It is not
>>> supposed to change.
>>> Even if the content handler needed to decide on the fly, where to
>>> publish the key, then we could reference the artifact containing the key as
>>> a field on the publication and serve that.
>>>
>>> On Thu, May 7, 2020 at 2:34 AM Dennis Kliban <dkliban at redhat.com> wrote:
>>>
>>>> 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
>>>>>>
>>>>> _______________________________________________
>>> 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/20200511/a6e2dd73/attachment.htm>