[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.