411–420 of 443 posts
Signal Snap Maintainer here, this is because of a DMCA takedown request from lawyers representing Signal. Canonical is currently working with them to clear things up. Canonical's communication to me was initially lacking due to issues in their process, the process has been amended and I'm back in the loop again.
Earlier quoted context omitted.
Systemd was a child of Redhat. Debian had to support it, mostly because at the time Gnome, another Redhat controlled project, decided to depend upon systemd.
1. Supporting it is not the same as mandating it (which it effectively has) 2. You're saying that Debian made this choice because of a choice by GNOME. But - was GNOME strong-armed by commercial interests? 3. AFAIK, The dependence of GNOME on systemd was broken quite easily (IIANM mostly by using a forked elogind).
Regardless of now, at the time, there was no alternative such as elogind.
Earlier quoted context omitted.
Most of what runs on any computer is built by volunteers. Most open source softwares relies on volunteers.
Yes, but distributions provide a security layer, as well as source repositories. With flathub, binaries with no source code are being packaged up (albeit with scripts), and the process of pushing updates is quite easy.
Earlier quoted context omitted.
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…
Sadly debian-based distributions do not respect the principle of least privileges and grant unnecessary permissions to installation scripts.
Earlier quoted context omitted.
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-…
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.
Earlier quoted context omitted.
Yes, but distributions provide a security layer, as well as source repositories. With flathub, binaries with no source code are being packaged up (albeit with scripts), and the process of pushing updates is quite easy.
Not really, distributions do not check every piece of code that is packaged and distributed. I just meant that centralising distribution does not make thing specifically safe neither. Some form of audit over flathub would be nice though, but I personally much prefer projects open to community contributions.
Check out the processes involved in getting software accepted by a distribution:
https://packaging.ubuntu.com/html/fixing-a-bug.html https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
It looks a lot like they are auditing what gets included very tightly. On the other hand, Flathub is all about convenience, and while I get where they're coming from, they've already shot themselves in the foot when it comes to credibility by allowing third parties to package binaries. If the sandboxes that flatpaks run in were really impenetrable, that'd matter much less, but they're not.
Earlier quoted context omitted.
> Also certbot, shame on you for removing the Debian repository in favor of snap. Yes, this deserves shaming. > https://certbot.eff.org/instructions > The Certbot snap supports the x86_64, ARMv7, and ARMv8 architectures. While we strongly recommend that most users install Certbot through the snap, you can find alternate installation instructions here. Shame on you, certbot and EFF. Of all people, I expected better fr…
certbot won't be missed. The code quality is pretty poor. https://github.com/certbot/certbot/issues 5000 bugs and it most of it can be replaced by much smaller tools
Earlier quoted context omitted.
You didn't realize what you were doing was against the license?
How terrible of them, packaging open source software for their distribution like so many package managers do.
Putting my tinfoil hat on, all it takes is one unofficial Snap maintainer to be approached by one Glow-In-The-Dark with an offer they can't refuse to infect a hundred thousand users with key material compromise.
I hate to say it, but Signal is doing the right thing, here.
Earlier quoted context omitted.
It's also possible for a web server to selectively serve you a backdoored .deb or git repo
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`.