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