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
