On Linux you require your users to add your Apt repository to their system configuration.
This allows you to execute code with root privileges during package installation, e.g. in the most simple case through maintainer scripts which always execute as root.
You could also replace all other packages on user systems by providing alternatives of them on your repository.
It may also happen that law enforcement agencies force you to add a trojan horse to your packages. Then not only Signal is compromised but everything else on the users' machines.
I'm thankful for the existence of Signal but I don't think it qualifies for root privileges at all. It's bleeding edge software built from a large zoo of bleeding edge experimental web frameworks, each of which executing who knows how much code during installation or compilation or downloading stuff from all over the Internet in an unsigned fashion during their build.
The privilege of being installed from a repository should be reserved to packages which have passed my distribution's review procedure and became part of the official repositories.
Thus please provide a plain tarball which contains the Signal binaries and can be "installed" merely by unzipping as any low privileged user.
Thank you! :)
I agree that this is an important issue, but in the meantime:
~~~
wget https://updates.signal.org/desktop/apt/pool/main/s/signal-desktop/signal-desktop_1.0.35_amd64.deb
ar x signal-desktop_1.0.35_amd64.deb
tar xfJ data.tar.xz
./opt/Signal/signal-desktop
~
Would be nice to have rpm package as well.
As a separate mitigation, you can use software like firejail to constrain which files a program can access as well as what other permissions it has. I use this to constrain almost all of my often-used programs. Just a thought.
@chiraag-nataraj
As a separate mitigation, you can use software like firejail to constrain which files a program can access as well as what other permissions it has. I use this to constrain almost all of my often-used programs. Just a thought.
Thank you but once root privileges have been granted to something the system has to be regarded as compromised. Putting it into a sandbox afterwards does not revert that.
Thank you but once root privileges have been granted to something the system has to be regarded as compromised.
The only time you're granting root privileges is to the package manager though, not Signal itself (Signal doesn't run any post-install scripts beyond doing a simple ln (which you can verify by opening up the deb in e.g. emacs and examining control.tar.gz/postinst)). And you can set it up so that Signal never has root access when running (that's one of the features of firejail, among many others).
I agree with the goal of this issue, to provide a way to install Signal without needing root. But I think you're wrong on some of the specific claims you're making.
It is _technically_ true that the package manager could spawn Signal itself (i.e. if Signal launched itself through the postinst script). But that's an easy thing to verify before installing (as I just did). Worst case, you could probably even run aptitude itself in a sandbox, only granting it access to certain directories (that would probably be a pain to deal with though). And once you've installed it, you can constrain it on all runs using firejail or other similar technology/software. So no, I don't think you're ever _giving_ Signal root anymore than _any other application has access to root while it's running outside of a sandbox_. Hell, your _browser_ could technically get root, since it has access to the sudo binary. As could your office suite.
Just another note as well. The whole point of the repository system is that you trust the third-party repositories you add. That is _implicit_. This is one of the main reasons virtually all advice dealing with third-party repositories is "Don't be an idiot".
There is, of course, another way around this: get Signal into the main repositories. That would require a maintainer and whatnot - I'm not quite sure about the details, but this should have some more info. I'm fairly certain the process would be similar for other apt-based distributions.
@tribut
I agree that this is an important issue, but in the meantime:
wget https://updates.signal.org/desktop/apt/pool/main/s/signal-desktop/signal-desktop_1.0.35_amd64.deb
ar x signal-desktop_1.0.35_amd64.deb
tar xfJ data.tar.xz
./opt/Signal/signal-desktop
Thank you. How can I validate that this is indeed the URL of the latest, stable package?
The webserver on https://updates.signal.org does not serve directory listings.
Can someone make it do that?
@tribut
wget https://updates.signal.org/desktop/apt/pool/main/s/signal-desktop/signal-desktop_1.0.35_amd64.deb
That URL doesn't work anymore anyway :(
So where's the official source where I can obtain the latest package URL?
This will always tell you the latest production version: https://updates.signal.org/desktop/latest.yml
This will always tell you the latest beta version: https://updates.signal.org/desktop/beta.yml
@scottnonnenberg
This will always tell you the latest production version: https://updates.signal.org/desktop/latest.yml
This will always tell you the latest beta version: https://updates.signal.org/desktop/beta.yml
Thank you.
Now if I manually unzip the package as @tribut suggested, am I correct with the assumption that I will have to keep manually updating it whenever there is a new version, for ever?
@leo-bogert Yep. The auto-update mechanism built into the product is only enabled for OSX and Windows. If you really want to be on the latest all the time, you might consider installing the development version and just pulling down the latest changes via git periodically. Dev version install instructions are here: https://github.com/signalapp/Signal-Desktop/blob/development/CONTRIBUTING.md
Most helpful comment
I agree that this is an important issue, but in the meantime:
~~~wget https://updates.signal.org/desktop/apt/pool/main/s/signal-desktop/signal-desktop_1.0.35_amd64.deb
ar x signal-desktop_1.0.35_amd64.deb
tar xfJ data.tar.xz
./opt/Signal/signal-desktop
~