New RPM packages are not available

[mssucksalot]

It is latest available package at https://repo.sonatype.com/service/rest/repository/browse/community-yum-hosted/

nexus-repository-manager-3.69.0_02-1.el7.noarch.rpm  Tue Jun 04 20:25:41 Z 2024 	226606804

No 72-74 builds are available even if such tag as build_new_version_3.74.0-05 is created.

[bhamail]

Thanks for taking the time to create this issue. There are a "few" problems to work through, mostly related to database upgrades, some of which are covered here: Issue #40

[mssucksalot]

I see... I experienced the issue on upgrade, so I did migration manually and then switched back to 3.71 rpm package from this repository. I think currently it is revoked, but it works on my server.

The reason why I want to get 3.72, 3.73 and 3.74 is the CVE fixed in 3.73: https://support.sonatype.com/hc/en-us/articles/34496708991507-CVE-2024-5764-Nexus-Repository-Manager-3-Static-hard-coded-encryption-passphrase-used-by-default-2024-10-17

For me it is not critical issue. But it's better to update in any case. And I expect further releases can fix something and that will not be available this repo.

I think 3.71 and further releases can have some confirmation or notice like for example MariaDB has when it upgrades to new major version. No reason to disallow updates for all users who already have 3.71 version or later.

[TomJampen]

Any update on more recent deb/rpm packages?

I've performed a fresh install with 3.71 when it was still available (what a coincidence). I feel lucky that I didn't get 3.69 (and got stuck with the old db format).

I would very much appreciate to hear about the plans for those already using the new db format.

[bhamail]

Hi Tom, I'm sorry to say I haven't had any cycles to spare to work on this issue, and it appears nobody in the community has either. The problems are somewhat documented in Issue #40 if anyone wants to take a stab at it. It boils down to needing a smooth upgrade path over a very large bump in the road involving both JVM and Database upgrade requirements, which if mishandled, could leave you in an unpleasant(tm) state.

[mssucksalot]

Hi Tom, I'm sorry to say I haven't had any cycles to spare to work on this issue, and it appears nobody in the community has either. The problems are somewhat documented in Issue #40 if anyone wants to take a stab at it. It boils down to needing a smooth upgrade path over a very large bump in the road involving both JVM and Database upgrade requirements, which if mishandled, could leave you in an unpleasant(tm) state.

We are trying to tell you to forget about updating of old versions. And continue to support for users who has new database and new environment. So you can add check which version you update and if it is less then minimal supported just show message to update manually and reject automatic updating.

Users can migrate on their own side. Or just make new installation. And many new users will start via new installation.

[bhamail]

Hi Tom, I'm sorry to say I haven't had any cycles to spare to work on this issue, and it appears nobody in the community has either. The problems are somewhat documented in Issue #40 if anyone wants to take a stab at it. It boils down to needing a smooth upgrade path over a very large bump in the road involving both JVM and Database upgrade requirements, which if mishandled, could leave you in an unpleasant(tm) state.

We are trying to tell you to forget about updating of old versions. And continue to support for users who has new database and new environment. So you can add check which version you update and if it is less then minimal supported just show message to update manually and reject automatic updating.

Users can migrate on their own side. Or just make new installation. And many new users will start via new installation.

Cool. That is a valid path forward too. Anybody want to take a stab at a PR?