Home: Repository Signatures

[rido-min]

Status: Reviewing

Use this issue to discuss the Repository Signatures spec.

[maartenba]

That looks like a solid spec! One remark: the matrix at the end has Secure as the mode for most entries, where I suspect a couple (near the end of the table) need Strict instead.

Also:

Repository signing certificates will have some requirements which be detailed in the technical specification (TBD).

Any pointers as to what type of certificate would be needed?

[rido-min]

@maartenba I omitted the Strict mode intentionally. It will be covered in more detail with the Client Policies spec.

The certificate requirements will be the same as for author signatures. Code Signing, RSA 2048, SHA256 and so on.

[rrelyea]

We are now feature complete in 15.7. Closing this issue.
We'll open more for follow on issues, like Client Policies.

[maartenba]

Are packages released for working with these?

[loic-sharma]

@maartenba Yes, latest NuGet.Packaging package has the necessary APIs. For an example, see: https://github.com/NuGet/NuGet.Client/blob/095d2d9563bac6b6bb3269e6996dd4e5af690f20/src/NuGet.Clients/NuGet.MSSigning.Extensions/RepoSignCommand.cs#L34

[maartenba]

Seems these aren't in the latest stable 4.6.2?

[dtivel]

Correct.

[maartenba]

Ok found it all in 4.7 prereleases.

One thing I did not immediately find in the spec. Imagine a MyGet feed proxies NuGet.org (essentially a read from www.myget.org that just streams the package from www.nuget.org). Will we have to strip the repo signature, or can www.myget.org serve a NuGet.org repo-signed package?

In other words, is this supported?
client <- MyGet (with NuGet repo signature from NuGet.org) <- NuGet.org

Or is this the only way?
client <- MyGet (strip off repo signature) <- NuGet.org

[clairernovotny]

I don't think there's any reason you'd need to strip the repo sig. It tells you where it came from.

[maartenba]

True. But then the question is: is the NuGet client going to like MyGet serving a package that has a NuGet.org repo signature?

[maartenba]

(also NuGet.org will remove other repo signature of available, hence the question)

[dtivel]

MyGet or any other feed can serve NuGet.org repository signed/countersigned packages without having to strip the NuGet.org signature/countersignature. However, if the serving feed goes out of its way to claim that it repository signs/countersigns packages with a different certificate, the NuGet client will block NuGet.org-signed/-countersigned packages from that feed. It'll appear as though the feed might have been compromised, serving a package signed with one signer while the feed tells the client to expect a different signer. The way a feed tells a client to expect packages signed with specific repository signing certificates is roughly described here. CC @rido-min

[maartenba]

Hmmmz... So what would be the best way of including the NuGet signature in our feed? Ideally there would be a way to delegate signature info, we'd rather not have to update the list of certificates on our side with those on NuGet.org side.

[maartenba]

After going through repository signatures a bit deeper, here are a few thoughts that I think could use some clarification.

Change package owners

• Do package owners in the package metadata have to match with the package owners in the repository signature?
• And consequently: when package owners are changed, does the repository signature have to be updated as well?

Proxy scenario

• If repo A serves packages from repo B, can repo A include the repo B signature info in its own?
• Can repo A perhaps delegate pat of the signature info to repo B? (so that A does not have to include the metadata from B, just a reference to it)

Virtual feeds scenario

MyGet has "pre-authenticated" feeds, where the repo is essentially the same, but the URL may look different per user.

VSTS has virtual feeds with "views" that are part of the repository URL (where each view is a virtual feed that holds a subset of packages on the base feed).

Since repo signatures contain a signed V3 index URL, can a package from a virtual feed be signed with the URL of the base feed? IF yes, awesome! If no, would this mean a package has to be re-repo signed on download, instead of once on ingestion?

(also can we re-open this issue? the spec is still in "Status: Reviewing" so the discussion should stay open imo :-))

[rido-min]

@maartenba, thanks for your feedback, I'm reopening this issue while the spec is "in review"

Change Package owners

The purpose of the package owners field is to capture who were the package owners at the time of submission. NuGet.org is not going to resign the package if the owners change but other repositories can re-sign those packages if they want.

Proxy Scenario

Repo A can publish signed packages from repo B without including those certificates in the announcement. But before making any recommendation I'd like to understand your scenario.
For services like MyGet.org I'd suggest to evaluate how to implement ingestion policies to allow signed packages from other repositories.

Virtual Feeds

Yes, the design decouples the current location of the package from the repository that originaly signed it.

[maartenba]

Thanks! That helps.

[maartenba]

Note to self on proxy/virtual feeds -> #6880

[vuplea]

Not sure if the page is just historical specification, or it must match the implemented behavior, but:

The spec is outdated with regards to Author Trust:

Author Trust. The author will be considered trusted if it chains to a trusted root but users can explicitely trust one author by adding the certificate to the configuration file.

As I understand the implemented feature, trusted author candidates are the configuration trustedSigners. Authors not in trustedSigners but chaining to a trusted root of the local machine are not trusted authors.

Also, some Client Validation Matrix lines are incorrect:

• Repo-only-signed packages without repo trust and with undetermined author trust must be rejected, but the matrix indicates OK
• Same for Repo-only-signed without repo trust and without author trust.

[rido-min]

Hi @vuplea,

Certainly the spec was written before the implementation and could be some minor differences.

Regarding Author Trust: In "accept mode" NuGet clients will install any package, and will produce a warning if signed with an untrusted cert. In require mode, the author/repo must be explicitly trusted.

The Client Validation Matrix for require mode shows how repo-signed packages with untrusted certs are rejected.

If you see a different behavior, please file an issue.

Thanks for your feedback,
Rido