Finding and Downloading the iso is too complicated

[jmbadu]

Thank You for the tip!

[toorsq]

@ben79

IMO the links should be https anyway.

I was wondering about what was causing this. I managed to figure out right click > save link as, but got a little worried when I saw it was blocked and flagged as insecure, especially when I didn’t see any signed checksum files. Am I just too paranoid?

Anyways, it’s a cakewalk compared to Debian. But I suppose that’s not saying much lol.

[ben79 (Ben Bullard)]

If you have trouble downloading OMLx iso

We have had a number of reports recently of people having difficulty downloading isos. This is an attempt to provide help with that. Some browser downloaders will not download OMLx isos. Namely Chrome based browsers. In my testing there is not problem in downloading the isos in Firefox or Ungoogled Chromium. There are to many browsers for us to test all of them. Do not know why the isos won’t download in Chrome or Brave but they won’t. There is an easy workaround below. The Cooker isos are ou…

[richp (rich)]

I must have got luky on my fist try because i hit download now and was taken to souceforge and the download started automatically. However things did get complicatded when i needed to try other isos. Can anyone point me to a server iso i’m having problems with rome plasma and want to try installing manually from a server iso to see if that reproduces the problem.

[ben79 (Ben Bullard)]

Try installing Plasma6 slim iso instead. I do not believe the latest server installers for ROME are ready yet. They weren’t a high priority because they weren’t used much. Seems we may be changing in that regard.

If there were server installers they would be here.

[WilsonPhillips]

Brave here as well. I had to right click on the iso file and click “save link as” and then it just stopped.
HOWEVER, click on the Dowload button at the top right of the browser and it says “insecure download blocked.”
Click on the download file and then click “download insecure file.”

[Axemark38]

@ben79

I think the likely problem is that the links in ABF are http instead of https and that does not work in Chrome browsers. I have asked devs if this is the problem and if it can be fixed. I think the better fix is to correct whatever the cause of our files not downloading in Chrome based browsers.

It explains a lot. I checked all distro ISOs downloaded and can confirm they’re from HTTPS links. OpenMandriva was the only one that refused to download on Brave. I was forced to go to your SourceForge page and had no issue downloading there since it’s HTTPS-hosted.

So I 100% agree that HTTP is likely the issue. Configuring ISO links with HTTPS should solve this. It should’ve been set up like this from the start but hey at least we know now

[Mordechai (Morris)]

One suggestion - have more torrent options available. This will save enormous bandwidth.

[LeeTalbert]

If I get the torrents I will seed endlessly

[WilsonPhillips]

The only torrents I saw were old. I could have been in the wrong place. It wasn’t straight forward.

[encw]

The bigger problem is perhaps that the process is not complicated enough. There doesn’t seem to be any signatures to verify, and so users cannot ensure the provenance of the files. Please correct me if I am wrong.

[Mordechai (Morris)]

Found the same one and downloaded it at first not realizing at first it was from 2023.

[rugyada]

@encw

There doesn’t seem to be any signatures to verify, and so users cannot ensure the provenance of the files

If from sourceforge (example)
OpenMandriva Lx - Browse /release/ROME/24.12 at SourceForge.net

If from abf containers (example)
Show - Product ROME plasma6.x11 x86_64 - Platform - Openmandriva ABF

right click, Save file with name - or what your browser shows.

[encw]

I wasn’t actually talking about checksums, but PGP signatures. A matching SHA proves that the file downloaded properly, but it doesn’t prove that it is the right file, as it is possible that the iso and the SHA file were compromised on the file server. This has happened to distros before, Mint being a famous example. Linux Mint Hacked Briefly – Bad ISOs, Compromised Forum | Hackaday

Here is Debian’s answer to the problem: Verifying authenticity of Debian images

Are you making the argument that a user should check multiple download sources to ensure that they all have the same checksum? That would work, even if it isn’t optimal, but you definitely need to detail that process very clearly as it is not expected.

Here is a blog post (not mine) by a fellow who explains the problem with using checksums for verification. Backdoored Linux Mint, and the Perils of Checksums | Micah Lee

One way to fix the problem properly would be to sign your sha256sum file with a key that you have email verified (with an email address from the openmandriva domain, say “security or release @ openmandriva.org”) with keys(dot)openpgp(dot)org. Then a user who downloads your sha256sum file would be able to download your email verified public key from openpgp and verify the sha256sum file, and thereby verify that the iso file is legitimate. The email verification on openpgp.org helps because while you can spoof a sending address, openpgp.org sends out an email with a verification code, and having received it strongly implies ownership of the domain.

[rugyada]

@encw ok I misunderstood your question. Sorry.

[encw]

No problem! While we’re on the topic; does OpenMandriva host its own repositories? And is dnf configured properly to check package signatures? The fact that the download iso itself is not signed leads me to believe that the repository system might also be unsigned, and therefore be a security weakness.

Please take a look at the “Important” section highlighted with purple. DNF :: Fedora Docs

[ben79 (Ben Bullard)]

You need to ask a developer.

Edit: Excuse me, developers may see this post but no guarantee. OM-Chat may be quicker. Edit some more: You may have a valid point.