On Mon, May 11, 2020 at 3:21 AM Matthias Dellweg <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> wrote: >>> >>>> On Wed, May 6, 2020 at 4:07 AM Matthias Dellweg <[email protected]> >>>> 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 <[email protected]> >>>>> wrote: >>>>> >>>>>> On Tue, May 5, 2020 at 3:39 AM Quirin Pamp <[email protected]> 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:* [email protected] <[email protected]> >>>>>>> on behalf of Dennis Kliban <[email protected]> >>>>>>> *Sent:* 04 May 2020 22:50:54 >>>>>>> *To:* Pulp-dev <[email protected]> >>>>>>> *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 >>>>>> [email protected] >>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>> >>>>> _______________________________________________ >>> Pulp-dev mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
