<div dir="ltr"><div>comments inline<br></div><div><br></div><div>On Mon, May 11, 2020 at 3:10 PM Brian Bouterse <<a href="mailto:bmbouter@redhat.com">bmbouter@redhat.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 11, 2020 at 3:21 AM Matthias Dellweg <<a href="mailto:mdellweg@redhat.com" target="_blank">mdellweg@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div>I agree</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>We could go one step further and provide the key ID as environment to the script called (to make that part reusable / packageable).</div></div></blockquote><div>+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?<br></div></div></div></blockquote><div>I'd say a script that calls gpg on the same machine can use the provided key ID to be reuseable. A script that invokes some arbitrary external service depends heavily on the service at hand. Either that service wants a key ID anyway in order to know which key to sign with, or the script can simply ignore that additional bit of information given. I think, this is about additional convenience (on the admin side).<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div> <br></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.<br></div></div></blockquote><div>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?</div></div></div></blockquote><div>I think, this signing service is meant to be used at publication time. A created publication is an immutable set of artifacts that are associated with certain relative paths. If the public key used while publishing should be part of the publication, then it can either be by referencing the SigningService on the Publication (in that case, it must be immutable, too) or the key can be turned into it's own published artifact. Then changing the singing service in any way by the admin is possible, but can lead to surprises of its users.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 8, 2020 at 8:03 PM Brian Bouterse <<a href="mailto:bmbouter@redhat.com" target="_blank">bmbouter@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div>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?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020 at 3:51 AM Matthias Dellweg <<a href="mailto:mdellweg@redhat.com" target="_blank">mdellweg@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>> 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.</div><div>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.<br></div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020 at 2:34 AM Dennis Kliban <<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 6, 2020 at 4:07 AM Matthias Dellweg <<a href="mailto:mdellweg@redhat.com" target="_blank">mdellweg@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div><div>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. <br></div><div><br></div><div>The implementation of the <span>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]? <br></span></div><div><br></div><div> [0] <a href="https://github.com/pulp/pulp_deb/blob/master/pulp_deb/app/models/signing_service.py#L12" target="_blank">https://github.com/pulp/pulp_deb/blob/master/pulp_deb/app/models/signing_service.py#L12</a></div><div>[1] <a href="https://github.com/pulp/pulpcore/blob/3.3/pulpcore/app/models/content.py#L447" target="_blank">https://github.com/pulp/pulpcore/blob/3.3/pulpcore/app/models/content.py#L447</a></div><div>[2] <a href="https://github.com/pulp/pulpcore/blob/3.3/pulpcore/app/models/content.py#L377" target="_blank">https://github.com/pulp/pulpcore/blob/3.3/pulpcore/app/models/content.py#L377</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 5, 2020 at 11:51 PM Dennis Kliban <<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 5, 2020 at 3:39 AM Quirin Pamp <<a href="mailto:pamp@atix.de" target="_blank">pamp@atix.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div id="gmail-m_-7219431365957042572gmail-m_-1679697976297522474gmail-m_2365325794050523688gmail-m_-4256182028666046316gmail-m_4389822627465218281gmail-m_-4037725761189694623gmail-m_2357888299075059144gmail-m_8353932931649697431m_-59539944953056316gmail-m_-5405251358577567675divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p style="margin-top:0px;margin-bottom:0px">Could you explain the reasoning for a 'public.key' file?</p></div></div></blockquote><div><br></div><div>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. <br></div><div></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="gmail-m_-7219431365957042572gmail-m_-1679697976297522474gmail-m_2365325794050523688gmail-m_-4256182028666046316gmail-m_4389822627465218281gmail-m_-4037725761189694623gmail-m_2357888299075059144gmail-m_8353932931649697431m_-59539944953056316gmail-m_-5405251358577567675divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><p style="margin-top:0px;margin-bottom:0px">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.</p>
<p style="margin-top:0px;margin-bottom:0px">(It would not be hard to add it just to satisfy the interface, it just would not serve any useful purpose.)</p></div></div></blockquote><div><br></div><div>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. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="gmail-m_-7219431365957042572gmail-m_-1679697976297522474gmail-m_2365325794050523688gmail-m_-4256182028666046316gmail-m_4389822627465218281gmail-m_-4037725761189694623gmail-m_2357888299075059144gmail-m_8353932931649697431m_-59539944953056316gmail-m_-5405251358577567675divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p style="margin-top:0px;margin-bottom:0px"><br>
</p>
<p style="margin-top:0px;margin-bottom:0px">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 ;-):<br>
<a href="https://github.com/pulp/pulpcore/pull/659" id="gmail-m_-7219431365957042572gmail-m_-1679697976297522474gmail-m_2365325794050523688gmail-m_-4256182028666046316gmail-m_4389822627465218281gmail-m_-4037725761189694623gmail-m_2357888299075059144gmail-m_8353932931649697431m_-59539944953056316gmail-m_-5405251358577567675LPlnk611168" target="_blank">https://github.com/pulp/pulpcore/pull/659<br>
</a></p>
<p style="margin-top:0px;margin-bottom:0px"><br>
</p>
<p style="margin-top:0px;margin-bottom:0px">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. <span>;-)</span></p></div></div></blockquote><div><br></div><div>I'll take a look at this PR. <br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="gmail-m_-7219431365957042572gmail-m_-1679697976297522474gmail-m_2365325794050523688gmail-m_-4256182028666046316gmail-m_4389822627465218281gmail-m_-4037725761189694623gmail-m_2357888299075059144gmail-m_8353932931649697431m_-59539944953056316gmail-m_-5405251358577567675divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p style="margin-top:0px;margin-bottom:0px"><span><br>
</span></p>
<p style="margin-top:0px;margin-bottom:0px"><span>Quirin</span><br>
</p>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-7219431365957042572gmail-m_-1679697976297522474gmail-m_2365325794050523688gmail-m_-4256182028666046316gmail-m_4389822627465218281gmail-m_-4037725761189694623gmail-m_2357888299075059144gmail-m_8353932931649697431m_-59539944953056316gmail-m_-5405251358577567675divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> <a href="mailto:pulp-dev-bounces@redhat.com" target="_blank">pulp-dev-bounces@redhat.com</a> <<a href="mailto:pulp-dev-bounces@redhat.com" target="_blank">pulp-dev-bounces@redhat.com</a>> on behalf of Dennis Kliban <<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>><br>
<b>Sent:</b> 04 May 2020 22:50:54<br>
<b>To:</b> Pulp-dev <<a href="mailto:pulp-dev@redhat.com" target="_blank">pulp-dev@redhat.com</a>><br>
<b>Subject:</b> [Pulp-dev] signing service interface</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>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]. <br>
</div>
<div><br>
</div>
<div>We should revisit the design of the signing service API to ensure that we enforce this naming convention.
<br>
</div>
<div></div>
<div><br>
</div>
<div>[0] <a rel="nofollow" href="https://pulp.plan.io/issues/5356" target="_blank">https://pulp.plan.io/issues/5356</a></div>
<div>[1] <a href="https://github.com/pulp/pulp_rpm/pull/1687/files#diff-c91893c1f4e7afe73e414d1a76162463R30" target="_blank">
https://github.com/pulp/pulp_rpm/pull/1687/files#diff-c91893c1f4e7afe73e414d1a76162463R30</a>
</div>
</div>
</div>
</div>
</blockquote></div></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div></div>