Re: [Pulp-dev] signing service interface
o 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 >>>>>> wrote: >>>>>> >>>>>>> On Tue, May 5, 2020 at 3:39 AM Quirin Pamp 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-boun...@redhat.com >>>>>>>> on behalf of Dennis Kliban >>>>>>>> *Sent:* 04 May 2020 22:50:54 >>>>>>>> *To:* Pulp-dev >>>>>>>> *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@redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>> >>>>>> ___ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>> ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] signing service interface
t;>> wrote: >>>>> >>>>>> On Tue, May 5, 2020 at 3:39 AM Quirin Pamp 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-boun...@redhat.com >>>>>>> on behalf of Dennis Kliban >>>>>>> *Sent:* 04 May 2020 22:50:54 >>>>>>> *To:* Pulp-dev >>>>>>> *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@redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>> >>>>> ___ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >> ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] signing service interface
gt;>>>> (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-boun...@redhat.com on >>>>>> behalf of Dennis Kliban >>>>>> *Sent:* 04 May 2020 22:50:54 >>>>>> *To:* Pulp-dev >>>>>> *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@redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>> ___ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] signing service interface
h 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-boun...@redhat.com on >>>>> behalf of Dennis Kliban >>>>> *Sent:* 04 May 2020 22:50:54 >>>>> *To:* Pulp-dev >>>>> *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@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>> ___ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] signing service interface
> 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 wrote: > On Wed, May 6, 2020 at 4:07 AM Matthias Dellweg > 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 wrote: >> >>> On Tue, May 5, 2020 at 3:39 AM Quirin Pamp 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-boun...@redhat.com on >>>> behalf of Dennis Kliban >>>> *Sent:* 04 May 2020 22:50:54 >>>> *To:* Pulp-dev >>>> *Subject:* [Pulp-dev] signing service interface >>>> >>
Re: [Pulp-dev] signing service interface
On Wed, May 6, 2020 at 4:07 AM Matthias Dellweg 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 wrote: > >> On Tue, May 5, 2020 at 3:39 AM Quirin Pamp 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-boun...@redhat.com on >>> behalf of Dennis Kliban >>> *Sent:* 04 May 2020 22:50:54 >>> *To:* Pulp-dev >>> *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@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] signing service interface
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. On Tue, May 5, 2020 at 11:51 PM Dennis Kliban wrote: > On Tue, May 5, 2020 at 3:39 AM Quirin Pamp 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-boun...@redhat.com on >> behalf of Dennis Kliban >> *Sent:* 04 May 2020 22:50:54 >> *To:* Pulp-dev >> *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@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] signing service interface
On Tue, May 5, 2020 at 3:39 AM Quirin Pamp 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-boun...@redhat.com on > behalf of Dennis Kliban > *Sent:* 04 May 2020 22:50:54 > *To:* Pulp-dev > *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@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] signing service interface
Could you explain the reasoning for a 'public.key' file? 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.) 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. ;-) Quirin From: pulp-dev-boun...@redhat.com on behalf of Dennis Kliban Sent: 04 May 2020 22:50:54 To: Pulp-dev 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@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
[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@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
