On 2025-10-23 14:56, Quantum Mirror wrote:
>> Anyone on this?
>
> Yes, in my opinion, since ISO files for some distributions are already
> approaching 3-7+ GB in size, it would be better to outsource the whole
> thing to torrent.

Devuan already provides torrents:
https://files.devuan.org/devuan_daedalus.torrent

Also, (in my experience) users usually download the smaller netinst
ISOs, because they will install with an internet connection anyways.

> This would have three advantages.
>
> First, the mirrors would not be unnecessarily overloaded and used as
> speed tests, so we could focus on distributing the packages. (Those
> who want to participate in torrent-based distribution can still do so
> as webseeds.)
>
> Users with lower bandwidth would not have a problem if the download
> were interrupted.

Does your webserver not support the HTTP Range header? Download
continuations (both in wget and Firefox) have been working just fine for
15+ years, I don't really get your point here.

> The other advantage is security. Also in 2016, the Linux Mint incident
> highlighted the vulnerability https://blog.linuxmint.com/?p=2994 .
> On the one hand, ordinary users do not check the integrity or
> authenticity of ISOs, and even if they did, it would be pointless if
> these files were located on the same server as the ISOs...

How does torrent guard you from this attack? If an attacker can replace
the magnet file (on the central server), they can serve whatever files
they want without anyone knowing the difference. As far as I can tell,
this was the scenario that happened to Mint.

> With torrents, however, the situation is different. If an attacker had
> manipulated with the source ISO or the tracker, the hash would have
> changed and the system would have thrown an error in every seeder
> client at that moment, which would certainly have been noticed, so the
> attack would have been discovered much sooner.

There's no way for an attacker to change the contents of a torrent after
they've been fetched by the client. I doubt any errors would be thrown,
clients just wouldn't seed from that peer. That being said, *replacing
the magnet / .torrent* on the site pwns all new users until someone
notices.

> Of course, the direct download method could remain with https, which
> can also be useful in certain circumstances.
>
> In the case of packages, the lack of https does not pose a significant
> security problem, as many have mentioned that packages are
> authenticated in a different way, but this traffic is unencrypted
> between the client and the mirror, so an attacker will know exactly
> what operating system and version the user is using, as well as which
> packages and versions are installed, which can be analyzed to identify
> the user, at least partially, and prepare a targeted attack against
> them in the future, which could indeed be a problem. -> VPN/Tor or, if
> available on the selected mirror, the use of https is recommended.
>
> Cheers

In my opinion, the solution is to provide additional signature files for
the ISOs. And we already do that: there's a SHA256SUMS file in every
directory with install media, and a SHA256SUMS.asc signature on it.
Users can check the checksum after a finished download, and check the
signature on the SHASUMS file to verify its authenticity. Whether anyone
does that is another question ;)

It would be beneficial if we came up with a specific threat model
instead of throwing weird ideas around.

- files.devuan.org already uses HTTPS
- the list of mirrors on https://www.devuan.org/get-devuan shows HTTPS
hosts first
- deb.devuan.org doesn't use HTTPS due to round-robin, but APT verifies
the signatures already.

Where is the problem again?

~domi