Hacker News new | ask | show | jobs
by dheera 1327 days ago
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".

5 comments

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?
You're already trusting debian/ubuntu maintainers with your entire system. Why would trusting them with one particular app make any difference?
> 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.

Lol, like you audit the thousands of lines of code when you compile from source.
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

Yes, I look at code. I'm professional developer. I will spend 1-2 minutes at scanning per thousand of lines.
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.
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

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

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.
Is it meaningfully sketchier than downloading a .deb and calling dpkg -i on it?

Or cloning a git repo and building it?

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.

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.
Unless you audit every line of code the one liner executed, reviewing that one line doesn’t add much value.
What alternative do you propose?
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.
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
All that time you've gained on the installation will be lost during the lethargic start of snapped application :P
> 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.