Invalid APT repository metadata after uploading new deb package

[wwuck]

Nexus version: 3.67.1 and 3.68.0

After uploading a new deb package component to a hosted APT repository, I am seeing an error when running apt update.

W: Invalid 'Date' entry in Release file /var/lib/apt/lists/partial/nexus.example.com_repository_prod-bookworm_dists_bookworm_InRelease

I reviewed the InRelease files of two hosted repositories, one with a new component uploaded and one unmodified since a long time ago.

The unmodified repository has a Date field:
Date: Tue, 13 Jun 2023 04:57:12 GMT

The modified repository has a Date field:
Date: Thu., 09 May 2024 06:03:43 GMT

It looks like the extra . in the day name may be causing the issue here.

Correct formatting of the Date field can be found at https://wiki.debian.org/DebianRepository/Format#Date.2C_Valid-Until and also by running /bin/date -R -u.

EDIT: removed reference to latest nexus version upgrade.

[wwuck]

I have downgraded to 3.67.1-01 and I still get the same error. I'm now not sure what previous version it was working as I haven't uploaded any new deb packages since January 2024. This would probably have been on Nexus 3.63.0 or 3.64.0.

[nblair]

Thanks for opening this @wwuck. That's curious, is there a specific example deb package that causes the behavior? Or any?
We'll try to replicate.

[wwuck]

@nblair I created a new test repository on my nexus instance. Created a test empty deb package and uploaded to the repository. Still get the same error.

The date field of the InRelease for the new test repository is also showing the extra ..

Date: Tue., 28 May 2024 00:39:42 GMT

It looks like any deb package is causing the problem. Were there any recent changes to the APT repository metadata date string formatting code in Nexus?

[EmporioHanzo]

same error here with version 3.70.0-03. the InRelease file gets recreated on every component upload and uses the system date instead of RFC5333. I tried "timedatectl set-timezone Etc/UTC" on debian, the timezone changes in file but the error stays.
Any updates on apt-plugin?

[EmporioHanzo]

we fixed it by setting /etc/timezone manually to "ETC/UTC" and system language to english
the date field is now correct without dots, apt update is working without warning.

[wwuck]

This appears to be the same as reported a long time ago at https://community.sonatype.com/t/apt-repository-inrelease-date-field-sometimes-gets-invalid-timezone-must-be-0000-utc-gmt-or-z/4752/2 but that issue tracker no longer exists.

[wwuck]

@nblair was there any resolution or workaround for that issue ticket?

[wwuck]

The problem seems to have disappeared here after migrating from OrientDB to H2 and upgrading to Nexus 3.71 and Temurin 17 JRE.

[lalmeras]

I confirm the issue with nexus 3.70.1-02.

Bug is here :

nexus-public/plugins/nexus-repository-apt/src/main/java/org/sonatype/nexus/repository/apt/datastore/internal/hosted/metadata/AptHostedMetadataFacet.java

Line 308 in e4622a7

String date = DateFormatUtils.format(new Date(), PATTERN_RFC1123, TimeZone.getTimeZone("GMT"));

; if I run this line with java 8, 11 or 17, result depends on user.language system property. user.language=fr results in broken values ; user.language=en results in correct values.

I fix this issue, as by @EmporioHanzo by adding -Duser.timezone=Etc/UTC -Duser.language=en-US, dropping my metadata, and rebuild.

I don't think java 17 fixes the issue ; I think it only changes the way locale is determined from the host system, and maybe it chooses a locale that allow correct metadata generation.

I think the following code may solves this issue :

String date = DateFormatUtils.format(new Date(), PATTERN_RFC1123, TimeZone.getTimeZone("GMT"), Locale.ROOT);

[saturnjct]

Based on my poking around in the code, I think date should be set with DateTimeUtils.formatDateTime from components/nexus-repository-view/src/main/java/org/sonatype/nexus/repository/date/DateTimeUtils.java which explicitly sets the timezone and locale.

A co-worker and I have tracked down the cause of this issue to changes in locale data between Java 8 and Java 17 (in our case) causing the PATTERN_RFC1123 ("EEE, dd MMM yyyy HH:mm:ss zzz") to have different results in different versions of Java.