7 ms·

Why doesn't signal have a package in the official debian repo? I don't want to add random deb repositories for software like that.

michaelmrose 4y ago
Presumably for the same reason they don't want someone else packaging snap for them its another party to attack in order to attack their users in a way that would destroy trust in their product given its sensitive nature.
- turminal 4y ago
  I'm already trusting debian to provide the rest of the system without backdoors. Why would getting signal from somewhere else help in any way?
  - michaelmrose 4y ago
    It's presumably signal not trusting 97 different stores not Debian's in particular not to get compromised.
woodruffw 4y ago
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?
- progval 4y ago
  Trusting Signal to provide the source and host the servers.
  - woodruffw 4y ago
    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.
    - jdiff 4y ago
      The Snap's build instructions do nothing but download the .deb and repackage it into a Snap.
    - progval 4y ago
      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.
- codedokode 4y ago
  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 4y ago
    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 4y ago
      > 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.
- bostik 4y ago
  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 4y ago
    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 https://news.ycombinator.com/item?id=33455836
    - rlpb 4y ago
      Snaps run sandboxed. It's not perfect, but it's a whole lot better than debs.
hiq 4y ago
One potential reason is that their release cycle is too fast for the official Debian repositories, and they don't want to slow it down. Supporting old versions is a cost they don't want to bear.
- jdiff 4y ago
  All of their builds have shelf lives of 90 days. You must update at least that often or your app will stop working, so it's a non-starter for inclusion in the official Debian repos.

michaelmrose 4y ago

Presumably for the same reason they don't want someone else packaging snap for them its another party to attack in order to attack their users in a way that would destroy trust in their product given its sensitive nature.

turminal 4y ago
I'm already trusting debian to provide the rest of the system without backdoors. Why would getting signal from somewhere else help in any way?
- michaelmrose 4y ago
  It's presumably signal not trusting 97 different stores not Debian's in particular not to get compromised.

woodruffw 4y ago

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?

progval 4y ago
Trusting Signal to provide the source and host the servers.
- woodruffw 4y ago
  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.
  - jdiff 4y ago
    The Snap's build instructions do nothing but download the .deb and repackage it into a Snap.
  - progval 4y ago
    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.
codedokode 4y ago
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 4y ago
  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 4y ago
    > 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.
bostik 4y ago
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 4y ago
  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 https://news.ycombinator.com/item?id=33455836
  - rlpb 4y ago
    Snaps run sandboxed. It's not perfect, but it's a whole lot better than debs.

hiq 4y ago

One potential reason is that their release cycle is too fast for the official Debian repositories, and they don't want to slow it down. Supporting old versions is a cost they don't want to bear.

jdiff 4y ago
All of their builds have shelf lives of 90 days. You must update at least that often or your app will stop working, so it's a non-starter for inclusion in the official Debian repos.