$ 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.
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.
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.
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?
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.
> 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. A DCMA takedown is your lawyers contacting their lawyers and saying that you're invoking a law which forces them to immediately take something down or risk severe legal ramifications. Isn't it better to reach out without invoking a DCMA and see if the other party is willing to cooperate first?
>Isn't it better to reach out without invoking a DCMA and see if the other party is willing to cooperate first?
That would still be your lawyers talking to their lawyers. The channels for handling DMCA takedowns are much more efficient than channels for handling something custom.
Those channels are illegal to use outside of the copyright issues they're intended for. It's not just a free "hey take this down for me, will ya?" button.
If there was an icon, that could have be what was copyrighted. Perhaps it's from the usage of the deb package. The creator of a project that uses the GPL can actually have a download link to that software which is under a different license that is not freely distributable.
The icon is in the repo covered by the AGPLv3. Signal-Desktop does not have a CLA that would enable them to license the built binary anything but AGPLv3, as they do not have sole copyright over the code. They themselves are also bound by the AGPLv3.
If their explicit goal is having it taken down, and the law gives them explicit ability to do so, why would they waste the time? A DMCA isn't rude, it's just a strictly outlined process.
The law doesn't give them the ability, as the DMCA is for copyright and with an unrestricted free software license, there is no copyright issue. The takedown itself was illegal.
No, those lawyers are paid for by and directed by signal. Signal is responsible.