Live data from Hacker News

Snap Store administrators removed signal-desktop from Ubuntu Snap

forum.snapcraft.io

361–370 of 443 posts

Re: Snap Store administrators removed signal-desktop from Ubuntu Snap

#361
post #119

Earlier quoted context omitted.

What do you recommend as an alternative?

XMPP with OMEMO e2ee. Fallback to jitsi meet for video calling, although several xmpp clients support video calling to each other.

Jitsi Meet is pretty good for video, and relatively easy to self-host, though you'll need some decent resources for it. The docker-jitsi-meet project[0] can get you started quickly

Signal's "source available" infra can be self-hosted but it's huge effort and relies on a bunch of cloud-specific services which need to be replaced with self-hostslable alternatives. It's also extremely poorly documented and the code quality is fairly mediocre. I wouldn't recommend trying to host Signal infra yourself; it can be done; I've done it at work and it took some months of effort, and maintaining it is a nightmare (or was, then at least) because they'd only push one huge update to GitHub quarterly or less often.

[0]https://github.com/jitsi/docker-jitsi-meet

Re: Snap Store administrators removed signal-desktop from Ubuntu Snap

#362
post #258

Earlier quoted context omitted.

My grandma uses WhatsApp Web and Facebook hasn't taken down the WhatsApp Web snap yet. Both are end to end encrypted and based on the same transport but one of them used copyright law to take down a redistribution of their application. Looks to me like Signal is the interior app here.

If you look at anything through a narrow enough lens you can make it look good.

Ignoring UX for non-technical users is a narrow lens.

Re: Snap Store administrators removed signal-desktop from Ubuntu Snap

#363

Earlier quoted context omitted.

There's also just as many reasons to not give Signal root on my PC by installing their .deb package.

Signal is secure communications used not only by nerds but in situations in which privacy is a requirement for safety. In this singular case do you think its a greater security risk that someone may compromise signal and ergo your computer or that one or more of 97 different stores/repos with a multitude of different maintainers get attacked and used to first compromise your communications and then probably your comp…

I agree that policing a bunch of third party rebundling of apps is problematic but the entire idea of just giving up and letting user applications splat all over my system because that's how linux always has been doesn't work.

Re: Snap Store administrators removed signal-desktop from Ubuntu Snap

#364
post #287
post #262

Earlier quoted context omitted.

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

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

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

Re: Snap Store administrators removed signal-desktop from Ubuntu Snap

#365

Earlier quoted context omitted.

While this incident isn't good, I still think the setup is a ton better than Flathub, where you have flatpaks being maintained by third parties with no relationship to the software vendors. For example, all of the Jetbrains snaps are managed by a volunteer, as is Zoom (!) Compromise one of those devs' personal computers, and you've now got a path to getting a backdoor out to everybody using those. I trust Canonical's…

Is the third party maintainer relationship a policy choice by flatpak? or is that just the case because the maintainer built the flatpak first?

Flatpak is more like Docker than Snap. Flathub, an unaffiliated 3rd party that uses the Flatpak format and provides a Flatpak repo -- Flathub, allows people to publish packages to their repo that aren't the official developers.

Re: Snap Store administrators removed signal-desktop from Ubuntu Snap

#366
post #50

Earlier quoted context omitted.

I haven't used Ubuntu recently, hadn't heard of snaps, and this entire thread has been a horrifying introduction.

The whole snap thing is clearly doomed anyway. It's got no chance of "winning" the new wave of app distribution on Linux, being easily the most-hated of the three taking any kind of similar approach (AppImage, Flatpack). Canonical just hasn't thrown in the towel yet, for whatever reason.

In my brief introduction to it, there seems to be an impedance mismatch between snaps and the entire philosophy of Linux (and Unix more generally).

When a program tries to build it's own little world without consideration for the conventions of the operating system it creates all sorts of problems and doesn't allow the user to leverage its functions as part of a complete system like they can with programs that follow the decades old Unix patterns.

What I'm saying is if Canonical wants to be in the Snaps business, perhaps they should make SnapOS.

Re: Snap Store administrators removed signal-desktop from Ubuntu Snap

#367

Earlier quoted context omitted.

Why doesn't signal have a package in the official debian repo? I don't want to add random deb repositories for software like that.

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.

I'm already trusting debian to provide the rest of the system without backdoors. Why would getting signal from somewhere else help in any way?

Re: Snap Store administrators removed signal-desktop from Ubuntu Snap

#368

Earlier quoted context omitted.

Why doesn't signal have a package in the official debian repo? I don't want to add random deb repositories for software like that.

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.

Re: Snap Store administrators removed signal-desktop from Ubuntu Snap

#369

Earlier quoted context omitted.

At a naive level, this sounds like the sort of supply chain attack we've all been taught to fear. Asking seriously: has this build been replicated? is the source different from mainline? if so, what changed and who changed it?

Yes, this is a supply chain attack. That’s how Snap works. As far as I know, no one is alleging they actually changed anything, just that they could.

That’s also how free software distros work, and have always worked, in general: their job is[1] to prioritize the interests of the users as they see them over the vision of the developers, so that the users can choose the distro that reflects their interests most and still be able to use the software.

[1] https://drewdevault.com/2021/09/27/Let-distros-do-their-job....

Re: Snap Store administrators removed signal-desktop from Ubuntu Snap

#370
post #368

Earlier quoted context omitted.

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

I think I addressed this in the adjacent reply[1].

Yes, there's a legitimate risk (and accompanying threat model) when trusting package repositories. But I don't understand the specific threat model that involves not trusting Signal's package repository while (1) trusting a random third-party package that (2) just redistributes (in the best case) the official binary.

[1]: https://news.ycombinator.com/item?id=33455836

Post reply on HN