You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we write down SHA of signed packages with the signature file which is different than the original SHA of the same package when it's not signed when we extract a package on disk either as part of install or restore. This will potentially break our SHA validation as part of post restore operation with repeatable build (project lock file) feature because then if a lock file already has a unsgined package SHA and later that package is repo signed by nuget.org, then any further restore validation will fail which will also fail the restore operation.
So there are multiple suggestions to solve this issue, such as:
Write the original SHA of the package avoiding Signature file so that it's consistent with unsigned package. That way we won't need to change at multiple places but the down side is it will break existing 4.6 to 4.8 clients so we'd need to ask customers to clean their NuGet global packages folder before opting into project lock fle.
Another option is to create a new SHAFile to keep track of original SHA of the package and use that to validate post restore. This will have the advantage to not break existing clients and not needed to clean global packages folder but the downside is that we'd need to change at multiple places starting the way we figure out if package is coming from global packages folder or not, then extraction of the package, and finally the validation.
3rd option is to continue with the existing code of writing SHA, but change the way we validate SHA of signed packages. So for signed packages, instead of using SHA from the assets file, we use SignUtility apis to get the original SHA and compare that wrt lock file. This will work with existing clients as well as won't need to change at too many places but the downside is to retrieve original SHA of the package specially when package is Author + Repo signed.
After our discussion, we decided another option (4) which was a slight variation of option (2). With this option, instead of changing anything with existing file (which has real hash for signed packages), we'll have a new file for original hash but that file will be a json file so that we can add more metadata into it in future instead of coming up more additional files.
rrelyea
changed the title
Handle signed packages SHA for post restore validation with project lock file
.nupkg.metadata file will now be created during package extraction - contains "content-hash"
Nov 26, 2018
Currently we write down SHA of signed packages with the signature file which is different than the original SHA of the same package when it's not signed when we extract a package on disk either as part of install or restore. This will potentially break our SHA validation as part of post restore operation with repeatable build (project lock file) feature because then if a lock file already has a unsgined package SHA and later that package is repo signed by nuget.org, then any further restore validation will fail which will also fail the restore operation.
So there are multiple suggestions to solve this issue, such as:
Write the original SHA of the package avoiding Signature file so that it's consistent with unsigned package. That way we won't need to change at multiple places but the down side is it will break existing 4.6 to 4.8 clients so we'd need to ask customers to clean their NuGet global packages folder before opting into project lock fle.
Another option is to create a new SHAFile to keep track of original SHA of the package and use that to validate post restore. This will have the advantage to not break existing clients and not needed to clean global packages folder but the downside is that we'd need to change at multiple places starting the way we figure out if package is coming from global packages folder or not, then extraction of the package, and finally the validation.
3rd option is to continue with the existing code of writing SHA, but change the way we validate SHA of signed packages. So for signed packages, instead of using SHA from the assets file, we use SignUtility apis to get the original SHA and compare that wrt lock file. This will work with existing clients as well as won't need to change at too many places but the downside is to retrieve original SHA of the package specially when package is Author + Repo signed.
more options.....
Spec - https://github.com/NuGet/Home/wiki/Nupkg-Metadata-File
@anangaur @rrelyea @PatoBeltran @dtivel
The text was updated successfully, but these errors were encountered: