Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reuse spdx time value not valid per SPDX spec or validator #918

Closed
KlfJoat opened this issue Feb 22, 2024 · 2 comments · Fixed by #952
Closed

reuse spdx time value not valid per SPDX spec or validator #918

KlfJoat opened this issue Feb 22, 2024 · 2 comments · Fixed by #952
Labels
bug Something isn't working

Comments

@KlfJoat
Copy link

KlfJoat commented Feb 22, 2024

The time value output by reuse spdx is wrong.

reuse --version = reuse 3.0.1

Steps to reproduce

  1. Have a repo that reuse lint passes as okay.
  2. Run reuse spdx > myfile
  3. You may skip this, but you might want to edit myfile to have the same time value as me: Created: 2024-02-22T01:21:17+00:00Z
  4. Browse to https://tools.spdx.org/app/validate/
  5. Select "Tag/Value" for the file type
  6. Select myfile
  7. Click Validate

Expected result

A pop-up saying...

Success!
This SPDX Document is valid.

Actual result

An error pop-up with the following message...

Analysis exception processing SPDX file: Invalid date format: Text '2024-02-22T01:21:17+00:00Z' could not be parsed at index 19

ISO 8601 conformance

For one, I'm pretty sure that using +00:00Z is not allowed in ISO 8601. IIRC either +00:00 (or acceptable variants like +0000 & +00) is allowed OR Z is allowed, but not both. So that's one bug for sure.

Spec conformance

Per the spec, only Z is allowed, not a timeshift offset.

Format
YYYY-MM-DDThh:mm:ssZ
where:
YYYY is year
MM is month with leading zero
DD is day with leading zero
T is delimiter for time
hh is hours with leading zero in 24-hour time
mm is minutes with leading zero
ss is seconds with leading zero
Z is universal time indicator

@KlfJoat
Copy link
Author

KlfJoat commented Mar 26, 2024

Is it possible to bump this?

Your SPDX tool is outputting non-conformant SPDX files. Seems an important bug to fix.

smortex added a commit to smortex/reuse-tool that referenced this issue Mar 29, 2024
When generating a Bill Of Materials, the SPDX specification for the
[Created field] expect the date with format `YYYY-MM-DDThh:mm:ssZ`.

The current implementation does the transformation to express the
current time in UTC, but this has the side effect to add `+00:00` at the
end of the date when formatting it.  The resulting date
`YYYY-MM-DDThh:mm:ss+00:00Z` does not match the SPDX specification and
validation using the SPDX online tools fail because of this invalid
format.

Make sure to remove `tzinfo` from the date so that time zone information
is not output when formatting the date, so that we can safely append a
`Z` at the end to indicate UTC time-zone.

Other formats for the time-zone (e.g. `+00:00`) is not allowed by the
SPDX specification.

Fixes: fsfe#918

[Created field]: https://spdx.github.io/spdx-spec/v2.3/document-creation-information/#69-created-field
smortex added a commit to smortex/reuse-tool that referenced this issue Mar 29, 2024
When generating a Bill Of Materials, the SPDX specification for the
[Created field] expect the date with format `YYYY-MM-DDThh:mm:ssZ`.

The current implementation does the transformation to express the
current time in UTC, but this has the side effect to add `+00:00` at the
end of the date when formatting it.  The resulting date
`YYYY-MM-DDThh:mm:ss+00:00Z` does not match the SPDX specification and
validation using the SPDX online tools fail because of this invalid
format.

Make sure to remove `tzinfo` from the date so that time zone information
is not output when formatting the date, so that we can safely append a
`Z` at the end to indicate UTC time-zone.

Other formats for the time-zone (e.g. `+00:00`) is not allowed by the
SPDX specification.

Fixes: fsfe#918

[Created field]: https://spdx.github.io/spdx-spec/v2.3/document-creation-information/#69-created-field

Signed-off-by: Romain Tartière <romain@blogreen.org>
@carmenbianca carmenbianca added the bug Something isn't working label Apr 8, 2024
@carmenbianca
Copy link
Member

Found the cause of this bug. Thanks for reporting @KlfJoat

With utcnow() deprecated, I changed to now(tz=...utc) in bc49936, but this is ever subtly different, because utcnow() didn't create a datetime object with UTC tzinfo, but the latter does. And a datetime object with tzinfo has a different output for isoformat().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
2 participants