Great article. Three broken links on the "Déjà vu, much?". Goes to support my opinion we should do away with tying any authority to domain names because this happens all the time and people cannot be trusted to have the want, prowess or funds to keep their domain active.
the most important component of the indieweb and content syndication is owning your own domain. As long as everything leads back to your own domain, it doesn't matter what IP it's pointing to
The issue's these groups abandoning their domains instantly.
Sounds quite dangerous that I may trust a Snap package when I download it today, but its domain name might be taken over by somebody else in the future and the Snap package updated to a malicious version. Is it possible to safely continue to use Snap with this knowledge? Maybe it's best to only use packages from the distro's own package manager?
Maybe it's best to only use packages from the distro's own package manager?
I mean ... it does seem like everyone else is slowly learning that in fact there is a reason Debian does it that way, and they're not just doing it to annoy you.
Indeed. Seems like open source & reviewing the software by distro package maintainers are the only solutions to more or less guarantee that malware doesn't slip in?
"Guarantee" is not the word I'd use here, (remember Jia Tan) but at least they are trying, and they appear to be the only ones making a serious effort.
It's not just snap. Any package manager that supports email password recovery is vulnerable too, eg. NPM.
Interestingly, I assumed Maven Central would be vulnerable because they also use domain for authentication, but at least this indicates they require manual review: https://central.sonatype.org/faq/verify-ownership/
Hmm, I wonder how many domains in total are involved? I started semi-automatically tracking domain expirations for a few domains of interest, with a script that uses Whois, and then that list just kept accumulating items. Covering hundreds of domains is not impossibly hard.
Yeah good idea. The number is on the order of thousands, not hundreds of thousands. It would cost a trivial amount of machine resources to monitor them all for sudden changes in DNS records and WHOIS records.
Are there any namespaces where this doesn't happen? I don't think it's reasonable to expect developers to maintain perfect opsec over their place in every public namespace. This seems to be causing a lot of software supply chain problems recently.
The top of the article mentions that snaps are cryptographically signed, but based on this article it seems like any key the server provides will be trusted. Why not just require the publisher of a package to cryptographically sign their builds with a consistent key?
Maybe there is a good reason, I’ve never used snaps.
They're signed by the store key. The key is checked when a snap is installed (or updated) and on boot, when the snap file is mounted. I believe it's possible for a developer to sign a package, but it's not required, and the onus is on the client (user) to check it. https://forum.snapcraft.io/t/verify-sign-build-snap-package-from-snapstore/27671
WilhelmVonWeiner | a month ago
Great article. Three broken links on the "Déjà vu, much?". Goes to support my opinion we should do away with tying any authority to domain names because this happens all the time and people cannot be trusted to have the want, prowess or funds to keep their domain active.
[OP] popey | a month ago
This is just a copy/paste error from me. I moved my blog from popey.com/blog to blog.popey.com. I have fixed it, and it will deploy soon.
mighmi | a month ago
elsewhere:
The issue's these groups abandoning their domains instantly.
DanOpcode | a month ago
Sounds quite dangerous that I may trust a Snap package when I download it today, but its domain name might be taken over by somebody else in the future and the Snap package updated to a malicious version. Is it possible to safely continue to use Snap with this knowledge? Maybe it's best to only use packages from the distro's own package manager?
technomancy | a month ago
I mean ... it does seem like everyone else is slowly learning that in fact there is a reason Debian does it that way, and they're not just doing it to annoy you.
DanOpcode | a month ago
Indeed. Seems like open source & reviewing the software by distro package maintainers are the only solutions to more or less guarantee that malware doesn't slip in?
technomancy | a month ago
"Guarantee" is not the word I'd use here, (remember Jia Tan) but at least they are trying, and they appear to be the only ones making a serious effort.
val | a month ago
It's not just snap. Any package manager that supports email password recovery is vulnerable too, eg. NPM.
Interestingly, I assumed Maven Central would be vulnerable because they also use domain for authentication, but at least this indicates they require manual review: https://central.sonatype.org/faq/verify-ownership/
jmtd | a month ago
“You know you’ve made it when” might apply, which is good for snaps I suppose.
pronoiac | a month ago
Hmm, I wonder how many domains in total are involved? I started semi-automatically tracking domain expirations for a few domains of interest, with a script that uses Whois, and then that list just kept accumulating items. Covering hundreds of domains is not impossibly hard.
0x2ba22e11 | a month ago
Yeah good idea. The number is on the order of thousands, not hundreds of thousands. It would cost a trivial amount of machine resources to monitor them all for sudden changes in DNS records and WHOIS records.
srtcd424 | a month ago
That was my thought when reading the article - whois info change triggers manual review?
landon | a month ago
Are there any namespaces where this doesn't happen? I don't think it's reasonable to expect developers to maintain perfect opsec over their place in every public namespace. This seems to be causing a lot of software supply chain problems recently.
finn | a month ago
The top of the article mentions that snaps are cryptographically signed, but based on this article it seems like any key the server provides will be trusted. Why not just require the publisher of a package to cryptographically sign their builds with a consistent key?
Maybe there is a good reason, I’ve never used snaps.
[OP] popey | a month ago
They're signed by the store key. The key is checked when a snap is installed (or updated) and on boot, when the snap file is mounted. I believe it's possible for a developer to sign a package, but it's not required, and the onus is on the client (user) to check it. https://forum.snapcraft.io/t/verify-sign-build-snap-package-from-snapstore/27671