search

NuGet / NuGetGallery

NuGet Gallery is a package repository that powers https://www.nuget.org. Use this repo for reporting NuGet.org issues.
https://www.nuget.org/
Apache License 2.0
1.52k stars 643 forks source link

[NuGet.org Bug]: Package counter-signature uses incorrect time (time zone bug?) #9780

Closed bradwilson closed 5 months ago

bradwilson commented 5 months ago

Impact

Other

Describe the bug

While investigating some packaging related issues, I discovered that NuGet has what appears to be a time zone related bug with the counter-signing process. The updated signature appears to be in the past.

Here is the date/time of the .signature.p7s file in a NuGet package that I uploaded:

2023-12-22 23:30:14   11832   .signature.p7s

And here is the date/time of the .signature.p7s file in the version NuGet offers for download:

2023-12-22 15:38:00   23226   .signature.p7s

I'm not aware of any impact this has other than correctness (i.e., I am unaware of this causing any problems with the NuGet client), thus I marked the Impact as "Other".

Repro Steps

  1. Create a NuGet package that is signed
  2. Upload it to NuGet
  3. Download the resulting package from NuGet
  4. Compare the signed times

For my package in question, here are my two versions:

Expected Behavior

Date/time should be correct.

Screenshots

No response

Additional Context and logs

No response

bradwilson commented 5 months ago

The NuGet package is made on a standard GitHub Actions runner, which I assume has its time zone set to UTC. When I look at the build time in local time (PST), it's 3:27pm:

image

The NuGet counter-signature happened at 3:38pm PST, and I assume it's recorded in PST and not UTC. It's possible that ZIP files don't store time zone, in which case this isn't a bug at all, just an unavoidable inconsistency.

bradwilson commented 5 months ago

https://en.wikipedia.org/wiki/ZIP_(file_format)

The FAT filesystem of DOS has a timestamp resolution of only two seconds; ZIP file records mimic this. As a result, the built-in timestamp resolution of files in a ZIP archive is only two seconds, though extra fields can be used to store more precise timestamps. The ZIP format has no notion of time zone, so timestamps are only meaningful if it is known what time zone they were created in.

Alright then, issue closed. 😂

akoeplinger commented 5 months ago

FYI since https://github.com/NuGet/NuGet.Client/pull/3793 nuget explicitly stores these timestamps in UTC inside the .zip and converts back and forth to local timezone during pack/unpack.

bradwilson commented 5 months ago

@akoeplinger That does not appear to be related to my bug, since that's a NuGet client issue, and my issue is related to the counter-signing process on the NuGet server.

akoeplinger commented 5 months ago

@bradwilson yeah but I'd assume all NuGet code creating/modifying packages should obey the same rule i.e. treat the zip file timestamp as UTC.