$ 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
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?
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
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.
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?
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
I’m a developer too. Currently job title “senior enterprise systems engineer”. It would take me much longer than that to ensure the code is ok. Additionally without modelling the code (and proving it correct) in something like COQ, you will never understand the calculus of inductive constructions behind the code and have no guarantees as to its correctness.
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.
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.
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.
>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.
The difference is that the stream coming out of curl and entering sh is ephemeral. With this device, there is no checksum or signature (as with apt). If you pipe curl into sh, you also leave no trail of what you've run. A malicious actor can also hinder analysis by serving different payloads per user-agent, per time of day, per subnet; or only serving the malicious payload intermittently.
With .deb-files you're expected to verify the checksum. Maybe you don't, and even if you don't, you can theoretically go back and verify after as part of a forensic process. This checksum is also typically distributed across different mirrors, making bait-and-switch attacks difficult. It means that if you're going to do a supply chain attack, you must do it in the open.
Compiling from sources is a bit sketchy, but it is also the vector that is easiest to analyze, so I think they cancel out.
>Compiling from sources is a bit sketchy, but it is also the vector that is easiest to analyze, so I think they cancel out.
Is it really meaningfully easier to analyse? I get that it feels better, but I'd bet that the people saying this would fail to catch the backdoor every time.
Yeah, it's possible for a web server to detect and change the returned data maliciously. Even with user agent and all other factors changed to match, it's possible to detect even the difference between being piped into another command vs being redirected to a file.
It helps that Signal uses an HTTPS apt repo and includes "signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg" in the apt list entry. If their download server were compromised, (and assuming the hacker didn't also get the private gpg key) the attacker would have to provide malicious archives selectively to avoid detection. Anyone who installed the old key (e.g., me) would notice the key validation errors.
So what? I can inspect downloaded code and find the backdoor, or a trojan, or an error. I did it few times already in last 30 years. If you cannot do that doesn't mean that nobody can. But I cannot do that with `curl | bash`.
I cam do that on MY machine. I cannot do that on your. I can download code, inspect it, install, and then create a RPM package, which can be installed in a safe way by DNF package manager, but I cannot do that with `curl | bash` method of installation.
>I can download code, inspect it, install, and then create a RPM package, which can be installed in a safe way by DNF package manager, but I cannot do that with `curl | bash` method of installation.
Sounds great as long as they get proper permission to distribute the software they’re distributing. Otherwise it’s just another untrusted party in the supply chain
> 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.
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.
No, those lawyers are paid for by and directed by signal. Signal is responsible.