> Can I actually a publish <insert popular package> without any checks and, once I got half a million users by repackaging the deb file in snap, add some subtle malware? There is no review process or anything?
This is already possible with every other distribution method. If you host your own debs, then you can easily get them to do whatever you want. Even relying on the main archive isn't great - apt is typically delivered over HTTP to make mirroring easier, for example.
This is a large misunderstanding of how it works. You can't MITM millions of servers around the world just because they use HTTP for downloading their apt archives.
It verifies the cryptographic signatures. That's why you need to "apt-key add" when you add a custom repository. It doesn't rely on the transport method for integrity.
> [Typo-squatting] is already possible with every other distribution method.
No, the counterpoint we're talking about is apt. In apt, not anyone can just register any package name. My question was whether that's really a thing in snap.
> If you host your own debs, then you can easily get them to do whatever you want.
I'm not quite sure what you're trying to say here. Why would I host my own deb files (in the first place, but even if I did) only to hack myself? I could just install the modified deb files directly or modify the files on-disk, no hosting needed?
> This is a large misunderstanding of how it works. You can't MITM millions of servers around the world just because they use HTTP for downloading their apt archives.
If they used HTTPS then an attacker would have to control the mirror instead of being able to perform the attack as a MITM.
Also using HTTP allows someone in the middle to know what software is installed on a server, which while not critical if it is kept up to date it leaks some information.
I wasn't aware that plain http was what made that attack practical, that's good to know. And while not disagreeing with your point, I meant that it isn't supposed to be interceptable despite being plain text, due to the integrity check, so it isn't inherently insecure, just (significantly?) less hardened than if it would use https only.
For the 'which software is installed' argument (confidentiality in addition to integrity), I agreed but your first link actually argues this:
> the privacy gains [of using https] are minimal, because the sizes of packages are well-known
> In apt, not anyone can just register any package name.
Yes they can. Yes distributions maintain archives and are able to decide what to include. But there's nothing special about apt per se that prevents namesquatting.
If you create a well-used PPA, for example, you could easily add extra packages, e.g. "firefix", later on. The next time someone runs `apt update`, they'll be exposed to the new package.
> My question was whether that's really a thing in snap.
It looks like that from the outside, but in practice that's not possible. All snap package names are tightly managed by Canonical staff.
> I'm not quite sure what you're trying to say here.
Lots of software vendors host their own archives. It's very difficult to get new packages into distros, and they're often updated infrequently once they're there. For example, the OSGeo project distributes its suite of packages this way.
This is already possible with every other distribution method. If you host your own debs, then you can easily get them to do whatever you want. Even relying on the main archive isn't great - apt is typically delivered over HTTP to make mirroring easier, for example.