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

[bradwilson]

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:

• CI: https://github.com/xunit/visualstudio.xunit/actions/runs/7304662352/artifacts/1132054904 (it's embedded inside the ZIP file)
• NuGet: https://www.nuget.org/api/v2/package/xunit.runner.visualstudio/2.5.6

Expected Behavior

Date/time should be correct.

Screenshots

No response

Additional Context and logs

No response

[bradwilson]

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:

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]

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]

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

[bradwilson]

@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]

@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.