Package Immutability

[karann-msft]

Status: Implemented

Spec for this feature is available here: https://github.com/NuGet/Home/wiki/Package-Immutability

Discussion should happen on this issue. Please link other issues with similar asks to this one

[maartenba]

Big fan of this! 🎉

[karann-msft]

Also, the spec is not ready for feedback just yet (hence the incubation status). I am making final edits and once done, I'll update the status to reviewing and also announce on the announcement repo.

[clairernovotny]

I mentioned this idea to @unniravindranathan, but I believe there's a way to allow package metadata editing, if so desired, and package signing together.

This functionality is essentially the same as what will be needed for changing package owners anyway.

Basically, the feed source signature can contain an updated set of metadata (delta's). In the case of a package owner change, the owners metadata element would be contained in the new feed source signature. This could apply to any metadata change. Meta-data changes are reflected in an updated feed source signature.

The clients would do a base nuspec + deltas from the feed source to build the displayed value.

[xavierdecoster]

@onovotny what you're saying has the side-effect of requiring compute at restore time, which is very costly and a performance hit (not to mention another dependency that may break restores, or reduce combined SLA of the infrastructure this runs on). A technical solution that avoids compute at restore time (e.g. pre-calculating at publish time, or at edit-package time), has impact on the time required to make the package/the edited metadata available for restore, and will result in additional HTTP requests client-side (chattier protocol).

In fact, making packages immutable has positive side-effects:

• no tampering with packages or metadata is possible, makes caching a lot easier
• no compute required/less chatty protocol
• reduced operational cost (no background processing for edits, no pre-calculating delta's, no additional bandwidth for delta's which cannot be cached client-side/CDN)
• reduced complexity (which also simplifies design and effort for other functionality, such as lock files)
• improved trust: what the author pushes, is what you get. No differences possible between restores on different machines over time.
• mirrors, proxies, downstream sources and other nuget servers don't need to bother about any changes to the package metadata (if edits are allowed, I can see the desire to also have some webhook or other notification system to subscribe to package changes... this is why many are crawling the v2 feed)
• in my opinion, package ownership changes only transfer the right to publish future versions of these packages, and maybe list/unlist previous versions (which is a package state on the feed and not package metadata)

IMHO, once a package is committed to the central nuget.org repository, it should be immutable. I can see value in the ability to update metadata in a verification step BEFORE the package is committed, but as package authors will sign packages client-side, that's likely just some review screen with a final "go/no-go" decision to commit the package, or go back and change + reupload it.

You can compare nuget.org with a git remote that does not allow push --force: stage your packages as much as you want, but once pushed to the remote, we should not allow you to change the commit.

[tomkerkhove]

I agree with @xavierdecoster here. Certainly on this:

in my opinion, package ownership changes only transfer the right to publish future versions of these packages, and maybe list/unlist previous versions (which is a package state on the feed and not package metadata)

If a package is transfered, the owner of the old packages is still the previous owner, not you. All new packages however, will have a new owner instead.

[clairernovotny]

@xavierdecoster @tomkerkhove All good points, I was just pointing out a potential way to handle this in the package signing world, if the behavior is so desirable.

[karann-msft]

This feature has been now been implemented and is live.