[dheera]

Hey signal, maybe fix this

    $ sudo apt-get install signal
    Reading package lists... Done
    Building dependency tree... Done
    Reading state information... Done
    E: Unable to locate package signal

and we don't need to resort to unofficial snap packages

[tssva]

The name for the Signal Desktop package is signal-desktop and Signal provides instructions on their website on how to add their deb repository.

[turminal]

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.

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

[michaelmrose]

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]

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]

It's presumably signal not trusting 97 different stores not Debian's in particular not to get compromised.

[hiq]

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]

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.

[galgalesh]

I don't think there is any reason for publishers to force users to download their software from the internet now that the Snap Store and Flathub exists.

I've had so many bad experiences with broken third party packages or worse, "installers".

[irthomasthomas]

I just expunged the snap system entirely from my ubuntu. It feels much snapier without it. I've never tried flatpacks, my preference is to AppImages, they seem to perform much better than other systems I've tried.

[tssva]

I can think of a lot of reasons why publishers of privacy and security related software would want to direct distribute their software rather than relying on 3rd parties if it is avoidable.

[jcastro]

There's also just as many reasons to not give Signal root on my PC by installing their .deb package.

[michaelmrose]

Signal is secure communications used not only by nerds but in situations in which privacy is a requirement for safety. In this singular case do you think its a greater security risk that someone may compromise signal and ergo your computer or that one or more of 97 different stores/repos with a multitude of different maintainers get attacked and used to first compromise your communications and then probably your computer as well?

Remember you are expecting the maintainer to not only be honest you are expecting them to secure his own machine as well.

[jcastro]

I agree that policing a bunch of third party rebundling of apps is problematic but the entire idea of just giving up and letting user applications splat all over my system because that's how linux always has been doesn't work.

[cyberphobe]

No one is forcing you to use their deb

[dheera]

Too difficult. Their install instructions are also too complicated and involve reading about 5 lines of comments and 4 shell commands.

It should NEVER be more than 1 line of shell or 2 mouse clicks to install anything. This is 2022, not 1995.

It's faster to just search for "signal" in the snap store and hit "Install".

[tssva]

Unfortunately, this is the world Signal lives in. For binary debian packages to be installed securely directly from a vendor requires the installation of gpg keys which is what 2 of the 3 commands are regarding. If Ubuntu had spent resources to develop a convenient way for developers to directly provide binaries to the users of their OS instead of developing a system where they are gatekeepers and distribute all packages Signal would now be able to provide an easier secure method of installation. If you were providing a privacy focused product which in some uses that privacy can be the difference between life and death, would you want to turn over supply chain protection of that product to a 3rd party?

[turminal]

You're already trusting debian/ubuntu maintainers with your entire system. Why would trusting them with one particular app make any difference?

[drran]

> If Ubuntu had spent resources to develop a convenient way for developers to directly provide binaries to the users of their OS

No way. I will never trust your binary.

[mechanical_bear]

Lol, like you audit the thousands of lines of code when you compile from source.

[411111111111111]

What made you think they'd be willing to compile from untrusted sources?

There are a lot of users that prefer the established trust model of a Linux distribution. They're willing to trust the mostly unpaid debian maintainers for example... but not John Doe, the temporarily set back billionaire who's just about to make it big

[drran]

Yes, I look at code. I'm professional developer. I will spend 1-2 minutes at scanning per thousand of lines.

[irthomasthomas]

It's 5 lines. Took me 30 seconds. Well worth it for the performance gains.

wget -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg && cat signal-desktop-keyring.gpg | sudo tee -a /usr/share/keyrings/signal-desktop-keyring.gpg > /dev/null && echo 'deb [arch=amd64 signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg] https://updates.signal.org/desktop/apt xenial main' |\ sudo tee -a /etc/apt/sources.list.d/signal-xenial.list && sudo apt update && sudo apt install signal-desktop

[codedokode]

This is not secure at all because you just gave Signal root access to your system. By adding their keys you also have granted a permission for Signal to replace any packages on your system.

I would instead manually download and unpack the app, create separate user for it, and run it in chroot. Much safer than your method.

[electromech]

Respectfully, I don't think that's correct, or possibly I am misreading your comment. IIUC, placing a key in /usr/share/keyrings does not allow those keys to sign any package, only the packages designated with "signed-by" in the apt list.

Sadly, plenty of applications still take the old "apt-key" approach of adding the keys globally (e.g., installing keys to /etc/apt/trusted.gpg.d), but I think Signal's installation process is the correct/recommended approach for distributing apt packages securely.

[codedokode]

Yes, I made a mistake about the key. Adding a key is safe by itself. However by adding third-party repository you are granting Signal a permission to replace packages on your system (unless you manually whitelist package names in apt preferences), and by installing a package from Signal repository you grant it root access to your system.

Sadly debian-based distributions do not respect the principle of least privileges and grant unnecessary permissions to installation scripts.

[marginalia_nu]

Yeah, let's teach users to paste sudo commands into the terminal. That's great.

[ChuckNorris89]

>Yeah, let's teach users to paste sudo commands into the terminal. That's great.

This is also one of my fears with pushing non tech savvy people away from Apple/Windows and onto Linux without the Snap, Flathub, or other such curated stores that ship with the distro, without which they would need to touch the terminal and run commands found on the internet.

GNU/Geeks will keep shouting religiously how insecure Windows is because "grandma can download a dodgy .exe pretending to be a game and get viruses", but on Linux it's the same shit or worse, all you have to do is to convince a user new to Linux to paste and run a sudo command in the terminal as instructed by some scammy tutorial he found on Youtube when searching for "how to install Fortnite on Linux" and it's game over for him, since Youtube removed the downvote counter and the user had no idea he was running into a trap.

After all, for most Average Joes, copying some text feels far less dangerous than downloading and opening a strange file.

At least Windows Defender will most likely catch that malware you downloaded and warn you about it being harmful, but on Linux you have no such guardian nanny to save you. With sudo, it will do whatever self-destructive thing you tell it to do and not complain.

[marginalia_nu]

I've seen this extremely sketchy variant a few times

  curl -sfL www.marginalia.nu/install.sh | sudo sh -

Even without sudo, this is extremely sketchy.

[hsbauauvhabzb]

Unless you audit every line of code the one liner executed, reviewing that one line doesn’t add much value.

[rosnd]

What alternative do you propose?

[marginalia_nu]

What if there was some sort of a store of snaps where you could download vetted packages with a graphical interface. A snap store, if you will.

[iakov]

All that time you've gained on the installation will be lost during the lethargic start of snapped application :P

[politelemon]

> It should NEVER be more than 1 line of shell or 2 mouse clicks to install anything.

If it is critical or has the potential to compromise security, it should take however many lines that are required to ensure a safe installation. The landscape today is far too complex to expect simple deployments (one liners) to be safe. A few extra lines is a small tradeoff in that case. I shudder when I see curl|bash type installations being normalized.

[cyberphobe]

It’s true, they should distribute a .deb that ensures the repo and key are installed so it gets updates. However, your suggestion that they should just capitulate and allow 3rd parties to violate trademark seems like a pretty bad take.

[nsxwolf]

Oh, snap!