Treat future date & timestamp in <release> as errors

[sidt4]

Some background on this issue: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2262

GNOME Software ( and possibly others ) rely a lot on the date / timestamp provided in the <release> tag. Values in the future are clearly wrong, and they have caused issues with GNOME Software.

• Future date / timestamps should fail appstreamcli validate checks.
• This check should possibly be added in appstream-generator as well.

[sidt4]

Example:

$ git diff data/metainfo/org.gnome.Software.metainfo.xml.in
diff --git a/data/metainfo/org.gnome.Software.metainfo.xml.in b/data/metainfo/org.gnome.Software.metainfo.xml.in
index 8cecc67ce..4f421b6db 100644
--- a/data/metainfo/org.gnome.Software.metainfo.xml.in
+++ b/data/metainfo/org.gnome.Software.metainfo.xml.in
@@ -66,7 +66,7 @@
    Validate with `appstreamcli validate *.metainfo.xml`
   -->
   <releases>
-    <release date="2023-08-04" version="44.4" type="stable">
+    <release date="2033-08-04" version="44.4" type="stable">
       <description>
         <p>This is a stable release with the following changes:</p>
         <ul>

$ appstreamcli validate --pedantic  data/metainfo/org.gnome.Software.metainfo.xml.in
P: org.gnome.Software.desktop:4: cid-contains-uppercase-letter org.gnome.Software.desktop
I: org.gnome.Software.desktop:2298: nonstandard-gnome-extension kudos

✔ Validation was successful: infos: 1, pedantic: 1

[ximion]

GNOME Software ( and possibly others ) rely a lot on the date / timestamp provided in the <release> tag. Values in the future are clearly wrong, and they have caused issues with GNOME Software.

You would think that, but when we validated that in the bast, we got tons of complaints by people who were staging future dates for later release and suddenly had invalid files. So we actually removed the date validation ages ago.

[sidt4]

Okay. Is it possible to add the validation in appstream-generator ?

We should have valid dates at that stage, right ?

[sidt4]

I think we can do the following:

1. Enable timestamp / date verification by default.
2. Add a --disable-time-checks option which should disable this.
3. In the current release, we can make this be reported as the highest error which doesn't fail validation ( should exit with zero exit code ). A message can be displayed that --disable-time-checks should be used to disable this check.
4. In the next releases, this should be upgraded to an error which fails validation ( should exit with non-zero exit code )

Folks who want to disable time checks due to the reasons mentioned above can use the --disable-time-checks option.

In contrast, downstream package maintainers who maintain SPEC files ( Fedora etc ), debian/rules ( Debian etc ) or the equivalent in other distros will not need the --disable-time-checks option, since the date / timestamp is expected to be in the past by that time. Anyone using --disable-time-checks option downstream will be accountable for that package, and the change will be visible publicly for review / comments.

I'm not sure how things work in the flatpak / flathub space, but I assume the above can be applied there as well.

[sidt4]

Does the above sound reasonable ?

[razzeee]

I'm not sure how things work in the flatpak / flathub space, but I assume the above can be applied there as well.

We've (Kodi) run into problems with checks like this before, cause we had a team member from australia (or the future) doing a release and flathub didn't like that. I guess the important fact is that everything would need to be utc/zulu time to work (obviously)

Still, kinda hard to make release managers think about utc dates and not their local date.