[woodruffw]

It's not a "random" repository, it's their official repository. They seem to be doing everything right (or as right as possible), including providing a signing key (which you can independently verify) and using an HTTPS host.

What's your threat model here? Trusting Signal to provide the binary and host the servers, but not distribute the binary that connects to the servers?

[bostik]

This threat model was at the heart of Maemo's and later Meego's app store criteria. Both APT and RPM repository trust model is flat: all repositories have the same privileges to make packages available for upload, and can declare any dependencies they choose in their packages. This allows a third party to override any package in the system.

Doesn't matter who provides the repository, because ownership can change. Even if you trust the current owner to be diligent and fair you have no control over what a future owner does. (Incidentally, buying widely used but badly maintained browser extensions and using them to distribute malware is a real thing.)

For example: the software everyone cares about is in a repo. The company uploads a version of a core library, such as glibc or libstdc++ in their repo and set it up with a very specific version number. Then they wait a bit, and upload a version of the much-cared software that declares a dependency against the specific library version. When the end users upgrade their packages, they also get a compromised core system library and all of a sudden ALL the software on their system is affected. The software you added the repo for has not been tampered with. But a backdoor from the core library is now present everywhere.

I worked with Nokia and Intel before and during the Maemo/Meego fusion. Back in 2010/2011 I had an early draft patch against libzypper that would have allowed to set certain package priority levels behind a fixed signing key, and made the above attack impossible. (Others were looking at how to confine the install scripts.) I went to a holiday in January 2011 and during that time, Elopcalypse happened. When I came back, the project no longer existed and my RFC patch never saw the light of the day.

[woodruffw]

I think I addressed this in the adjacent reply[1].

Yes, there's a legitimate risk (and accompanying threat model) when trusting package repositories. But I don't understand the specific threat model that involves not trusting Signal's package repository while (1) trusting a random third-party package that (2) just redistributes (in the best case) the official binary.

[1]: https://news.ycombinator.com/item?id=33455836

[bostik]

The threat model here isn't about trusting one third-party repo and distrusting another. It's about trusting any third-party repository without exceptionally good reasons.

I trust Signal, the company, as an author of specific type of communications software. I hesitate to trust them with root on my systems. The company and their intentions are, for the best of my knowledge, benign - but I have seen far too many well-meaning packaging snafus over the past 25 years to add even them to my sources.list.d; and in fact, I believe that with the actions of the company over the past ~three years they have squandered lot of the goodwill they had built up. I'm sorry to say, but the theme to me has felt like one of miscommunication combined with a lack of foresight.

I do trust they have had good reasons for everything. But optics are important, and for stewards of such a critical piece of software Signal have come up with questionably announced surprises. In a domain where boring is the characteristic everyone looks for.[ß]

A bit more context. As of now, there are only two third-party APT repositories that I can stomach. The official Postgres repo, and the Deadsnakes PPA. Both are maintained by the actual package maintainers, so they benefit from the assumed baseline and robustness.

ß: btw, I understand the SMS stuff. From an engineering effort perspective it makes sense, given what shitshow the SMS/MMS protocol stacks are. And with RCS, future integration would not be guaranteed at all. But it still came as a surprise.

[rlpb]

Snaps run sandboxed. It's not perfect, but it's a whole lot better than debs.

[codedokode]

Adding third-party repositories is actually dangerous because they can replace packages on your system (for example, bash) and run scripts with root privileges during installation.

Sadly many Linux distributions do not have user-friendly ways to install third-party applications and as a result we see instructions on running curl via sudo bash.

[woodruffw]

Yes, I suppose Signal could replace other packages on your system by updating their package lists with versions newer than those on the official index.

But again: what's the threat model here? If you're worried about someone stealing your messages, then they don't need root access -- they just need to give you a malicious build of Signal. That's way easier in an unofficial ecosystem like Snap than it is with a third-party package repository that Signal's developers are signing for.

(My understanding is that you can also configure apt to limit packages on a per-source basis, but I won't recommend that since I don't think anybody bothers to do that.)

[codedokode]

> what's the threat model here?

By installing signal-desktop you give Signal not only access to your messages (which is fine), but root access to the whole system which allows reading and modifying any file. Even if Signal doesn't have malicious intents, they might have vulnerabilities in their installation or configuration scripts.

[progval]

Trusting Signal to provide the source and host the servers.

[woodruffw]

Okay, but that's not what any of the parties in this current case are doing: the Snap in question is a third-party build, not a source distribution.

My understanding (as an outsider) is that Signal doesn't object to you building yourself a copy of Signal Desktop for source, but they do object to anybody building it for others, especially when they brand it as "Signal." That doesn't seem especially unreasonable to me: E2EE is a domain where trust is established exactingly; a proliferation of unreviewed third-party builds compromises environmental trust.

[progval]

I already trust Debian's repositories with my system; so getting Signal from Debian's repositories would not make my system or Signal more vulnerable. By adding Signal's deb repositories, I need to also trust Signal not to mess with the rest of my system.

[jdiff]

The Snap's build instructions do nothing but download the .deb and repackage it into a Snap.