417
Oh Snap! Canonical now doing manual reviews for new packages due to scam apps
(www.gamingonlinux.com)
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
Everything downloaded in snap is vulnerable because snap does not cryptographically verify all packages, unlike apt.
Also Ubuntu has newer packages in apt than Debian, which is more dangerous.
This isn't correct. Run
snap download htop
from your terminal and you'll receive two files: The actual squashfs image that gets mounted in/snap/htop/<revision number>
and a.assert
file that cryptographic signature data about this snap file. Modify the squashfs image and snap won't let you install it without passing--dangerous
to bypass that check, just like apt-get's--allow-unauthenticated
.The problem here exists at a different level: the level of what's getting signed. Conceptually speaking, running
sudo snap install htop
is a bit like runningsudo add-apt-repository ppa:maxiberta/htop && sudo apt install htop
. The package is built by the owner of the snap/ppa, and what Canonical is cryptographically verifying to you is that they got this from the owner of the (snap|ppa). This is roughly equivalent to domain verification for HTTPS (the type of HTTPS certificates Let's Encrypt uses).There are some different security considerations. For a snap, you need to be aware of the publisher each time you install something new. For PPAs, on the other hand, you only have to worry about this when you add a new PPA. However, the trade-off also works in the other direction. One snap can't just replace another snap on your system, whereas a malicious PPA could provide, for example, a malicious
libc6
update.These are both different (and lesser) assertions than what Ubuntu makes with its standard apt repositories. But they are still cryptographically backed.
Can you please link to the documentation that describes this?
I'm not sure if there's a single document explaining all of that, but this document talks about snap's assertions. I'm not entirely sure but I believe this file contains the main snapd business logic for actually checking these assertions.
On the PPA side I don't even know whether there is documentation for this - it's just the result of my understanding of how apt works and my own history creating PPAs.