Snap Store administrators removed signal-desktop from Ubuntu Snap
forum.snapcraft.io
forum.snapcraft.io
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.
- Still need a phone number
- They refuse to post the app on f-droid (directly)
- No 3rd party clients allowed on their servers.
- Crypto thing they attempted
- I don't trust Moxie, he rubs me the wrong way.Signal is not without flaws as you say, but if you have a phone number and can access a binary, there's every reason to believe it will securely and privately transmit your messages. You are also, ofc, free to fork their client and run your own service (as others have done).
Edit: to be clearer - signal both publishes a protocol (that is thought to be secure) and provides a public service (that claims to use the signal protocol). Signal has claimed that the binary blobs they add to their public client (and the other restrictions) are required to run a public service (anti-abuse, etc). You are free to believe them or not - I do.
At the protocol level, which you are free to use, none of the problems you or the ancestors have pointed to apply. All of the alternatives people are pointing to here are at the "protocol" level - accessible only if you or someone you trust has setup a node. There's nothing wrong with that - it's a good idea - but it's no reason to attack signal's service for not being a protocol (which they also provide).
[1] https://community.signalusers.org/t/overview-of-third-party-...
I've heard WhatsApp recommended from people I trust, but I have never personally used it so can't speak from experience.
Your suggested alternatives are owned by Zoom and Facebook. I'll stick with Signal.
All of them being tied to a phone number is bad form.
> Crypto thing they attempted
well...
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://www.theverge.com/2022/1/10/22876891/signal-ceo-steps...
- No easy way to do and restore backups on Android and impossible to do backups on their PC client
- Does not support Android tablets at all (my mom loves hers)
- Fails to ring on Android when you call someone or someone calls you, later serving you a missed call notification (disabled Doze/battery optimization feature on Android and tested on 3 different phones with no cigar)
- No way to share your live location to friends
- Using its built in photo snapping and sharing function takes horrible pictures on Android (I suspect they're using the wrong API). If I want to send someone I'm currently texting a good looking picture I need to switch to my phone's camera APP, then back to the chat and use the photo upload function, instead of the in-app photo snapping and sharing function
Some of these bugs have been reported 3+ years ago, while these things work flawlessly on WhatsApp since nearly forever, meanwhile Signal is busy implementing crypto payment features.
I don't know about iOS, but at least for Android and PC, it still feels like an app in alpha that's not yet released to the public compared to how polished and feature rich WhatsApp and Telegram are.
The rest are all feature requests.
That said, it’s interesting to see what people think are basic requirement for a messaging app these days.
Uncontroversial example: a calculator app that doesn't have a divide key. Technically, yes, it's a separate feature from the multiply key, but it's so basic, so expected, that its absence is a bug.
From the above list, I consider "No easy way to do and restore backups on Android and impossible to do backups on their PC client" a bug, or at least a frustrating omission by design.
More like missing basic features. I never said all are bugs, I said some are bugs and that all these things exist and work on the other alternatives like WhatsApp or Telegram
If you climb in the ring with Ali, then you'd better be able to box.
And it's also the criteria of millions of other users who have not switched to Signal because of the bugs, quirks, and lack of basic features for a modern messaging app.
Just being able to send encrypted ASCII characters to someone is not enough to make a good messaging app these days.
> And it's also the criteria of millions of other users who have not switched to Signal because of the bugs, quirks, and lack of basic features for a modern messaging app.
You have absolutely no knowledge that this is why people haven’t switched, indeed it’s highly unlikely that it would have been as successful as it has if this were the case. People move to Signal because they distrust Facebook and telegram.
The more logical explanation is simply network effects and inertia. Occam’s razor.
This is mostly Androids fault... For me, even Whatsapp's built in camera is terrible. When you press the button to take a photo, it starts focussing, then takes a photo before the focussing is done. So every photo taken is reliably blurry. There isn't any way to take a non-blurry photo with the main (back) camera.
The main OS camera app works fine.
I think they have per-device logic for this sort of thing, and mine is an uncommon chinaphone, so presumably they haven't tuned the logic for it.
Also no problems with it not ringing, Signal is actually the primary way that my family calls each other now and no one has experienced it not ringing when expected.
The rest I admittedly dont use or arent impacted by.
While its not perfect in all ways, I disagree with the "alpha" quality sentiment. Especially when you are comparing it to apps that dont have the same security goals or standards.
I generally agree with gp, it's not a bad app but certainly not one id ever use if I could contact someone another way. I find the lack of interpretability with my computer especially annoying. I'm constantly left feeling like a second class citizen.
Especially when it comes to seeing my history, I linked the accounts ages ago, I barely use my phone yet I'm consistently losing messages on my pc
As for the "security" I'm pretty sure it doesn't have reproducible builds, so it's basically just "trust me bro". rather trust moxie than zuck but still don't really trust either.
I never said backups don't work, I said they're not easy to do and restore compared to other apps where it's much more seamless and hands-off. No average user knows what Syncthing is and how to set it up. People expect the messaging app to have its own backup-restore system compatible with the cloud storage provider setup in the phone's OS.
>Also no problems with it not ringing, Signal is actually the primary way that my family calls each other now and no one has experienced it not ringing when expected.
Can't concur, I've personally seen this issue across 3 different android phones form 3 different brands and there are countless people online complaining about the same issue. You were lucky.
>Especially when you are comparing it to apps that dont have the same security goals or standards.
Which security goals and standards exactly? Signal's sales pitch is that it's end-to-end encrypted, but so does WhatsApp, and until we have an independent security audit of all of Signal's code and infrastructure, the claim for "better" security goals is as valid as "trust me bro". The only thing going for it is that it's not owned by Zuck's advertising empire or owned by Russian/CCP tech magnates, and that's it, but that's a very low bar to clear.
And also, how does having "better" security goals impact the issues with picture quality the app takes or the app failing to ring when someone calls you? "Security" is not an excuse for major bugs and lack of basic features. If security is done right then it should work transparently for the bytes going down the internet pipe and not have an impact on any other features.
As to ringing, it seems that the six people with six different phones (mostly Pixels, one iPhone) in my circle mean that it isn't good luck on my part...
It's end to end by default vs Telegram which is well known to be end to end maybeish if it's explicitly setup, for private chats only. WhatsApp is WhatsApp. Maybe it's a low bar, but Signal beats those others pretty easily. And refusing to use Signal over those two due to lack of a security audit is a bit absurd... All you're getting from Telegram and WhatsApp is "trust us bro" as well.
It's not an excuse. But considering it IS transparent for many users, me included.... Not everyone is having the issues you are.
It also has some questionable decisions in it like cropping to close to the screen's aspect ratio rather than using the native aspect ratio of the sensor. I never want that behavior.
Are we sure that Signal didn't contact the maintainer? I haven't seen any statements either way about that.
> I was just linked to this thread from our issue tracker
> As a maintainer for this snap package, it’s mind-boggling to me that, even after almost two weeks, the store team did not contact me at all. I had to find this out myself from users reporting it on our bug tracker.
> After almost two weeks, the maintainer of the snap has not received any official communication about this, but @roadmr was able to provide this tiny sliver of info in a thread on this forum.
From the original comment of this particular thread, also from galgalesh:
> 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.
Seems pretty clear that he was neither aware of it being taken down nor the reason, so I think it's safe to assume that Signal didn't contact the maintainer directly.
You could be right, but I think another possibility is that the maintainer did get contacted earlier by Signal, and just didn't mentally connect the dots between that and his Snap package being pulled.
Note that I don't know how realistic this is, I'm just trying to be fair in my assumptions.
> 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.
Had they contacted the maintainer, then the maintainer would not have been wondering what the deal was.
So far Signal is a centralized encrypted messaging app that includes its own cryptocurrency and wallet no one asked for, shills me for donations every other release, and begs me to invite new users despite deprecating regular SMS message support.
if youre a threat-actor the most malevolent thing you could do at this point is just watch Moxie and the team drive this project into the ground.
He’s not blameless for the fact it’s not federated, for example. Even if he’s not involved anymore.
I see you want federation, that's fine. I want private metadata. Don't use Signal if it doesn't do what you want, but maybe try to accept that not every project should do what you want. They have their preferences too.
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
Ironically, from his website:
> In general, I hope to contribute to a world where we value skills and relationships over careers and money, where we know better than to trust cops or politicians, and where we're passionate about building and creating things in a self-motivated and self-directed way.
>>Some time ago you federated with CyanogenMod. What has changed since then?
>What changed was going through that experience. It seriously degraded the UX for our users and held us back in the development process at many times. I'd estimate that all told, we lost about 6 months to a year of progress. It's something we'll probably never do again, and has fully convinced me that federated protocols are a thing of the past in this world of ours.
That's a pretty reasonable take: we tried it and it hurt velocity too much.
I'm not convinced that's still the case in 2022. There are a couple issues I'd like to see polished in the Android client, but I have not noticed bugs or missing features that seem likely to require breaking changes.
Moxie is no longer active in signal afaik. This is the new leadership.
Is it? How do you measure that? It seems like WhatsApp is a better default choice for most people probably.
There are so many scandals that come to mind, like not updating the FOSS code for years.
I’m no fan of Meta, and they have incentive to hoover up data.
But I don’t have a good reason to trust signal other than that everyone on hackernews seems to love them.
Meta is a publicly traded company. Signal is a 501c3, it's a completely different kind of organization.
There is credibility to the notion that signal is designed to ensure that people who are paranoid would prefer it.
The fact that it exists and is convenient prevents more secure messengers from existing as the lions share simply goes to signal, and this is what I mean by marketing. It is conventional wisdom that signal is the bees knees and looking further or scrutinising it is folly.
A lot of funding comes from the government to signal too; and since it’s an American company it must comply to the best of its ability with US law. They tell us that they can only comply in small ways, but given that there is no independent verification of the server (that it even runs the FOSS code) and the hostility in having unofficial clients on the network I am left pondering.
So you can actually audit the client code and make sure it is e2ee, which you cannot do with WhatsApp. In other words, for e2ee you must trust WhatsApp, not Signal.
I presume that for the outdated code, you think about the server code. That's different and would imply metadata, not message content.
Signal is e2ee, and you don't have to trust them for that.
Only if both sides are using clients that are self-compiled, independently-compiled (and audited), deterministic/reproducible or third-party.
The problem is that the network and the app are the same people, and worse than that; they send binaries and expect you to trust them.
I know lip service is paid to reproducibility but afaik the instructions for doing that are 404ing.
I just get a greasy feeling from the lock-in, the heavy marketing, the fact that everyone refuses to speak critically of them unless it’s about anonymous usernames.
A truly good secure client would have worked on any network, it wouldn’t rely on transporting your data over their servers, it would be a protocol that was open to third parties to implement, it would also be reproducible or independently compiled by trusted third parties (like OS maintainers, who already audit a lot of the code that gets built and signed).
There are two things: First, say the Android apk they distribute has a backdoor, and someone realizes that (it's distributed to millions of people, could be that someone checks). Then that's the end of Signal, right? So that's a big risk for them. That's for the "mass surveillance" scenario. Not perfect, but that's something. Second, if you fear a targeted attack, then self-compile Signal. It's not that difficult if you care about it.
The list goes on (and on), but the point is that Facebook gets to be the good guy and claim E2EE, while gathering all that metadata.
As for web/desktop one can use also Telegram.
Looks to me like Signal is the interior app here.
Signal had one feature it did better than its competitors and that's allowing integration of SMS. That feature is now getting killed because of RCS issues. With all my contacts on similar chat apps, I don't see why I should keep Signal installed once they remove the SMS feature, let alone why I should convince my grandma to make the switch.
"But Facebook is evil and wants to control you and wants to suck your blood" yes and so do the companies that made our phones and mobile operating systems. What's the point of Signal's openness (well, "open", they did stop uploading the source code for a while when they were adding in their crypto scheme) if you still use it on a proprietary phone.
And no, Linux on neither mobile devices nor the desktop is grandma-ready.
It isn't owned by a data leech.
My parents use that. I use that.
And years before that sms was cheaper than data.
Also sms is cheaper when roaming in Europe (in my case it has zero cost besides the monthly subscription price).
Sure IM are etter if you need group chat or communication abroad. But that is not the case for majority of population where 1 to 1 communication is used inside a single country.
Isn't their client open source? If I compiled it myself, is that a third party client?
If they don't let me compile it myself, how can I trust their official version is using the source they published?
This is a multi-level failure.
1. Signal-Desktop is AGPLv3: https://github.com/signalapp/Signal-Desktop
2. The snap package metadata is AGPLv3: https://github.com/snapcrafters/signal-desktop
So, this looks like a fraudulent DMCA claim by Signal, as the snap package maintainers and Canonicial have an open source license! This shows malice by Signal.
3. No-one from Canonical contacted the package maintainer(s) about the DMCA, so they have no opportunity to counterclaim or defend.
This is an open sign Snap should not be used. Because utterly unjustified DMCA claims will result in the removal of a package without any way to contest. This is compounded by Canoncial's controlling methodology with Snap where it is ostensibly open-source but Canonical controls what is permitted with snap through a closed-source server.
Signal's license on the other hand, does permit use of trademark. If nothing else this means that using the DMCA for this is wildly inappropriate.
As far as I understood the argument, you're free to distribute binaries, you just can't call them "Signal", since it's a trademarked name (?).
* I'm sure Signal would object to you redistributing binaries under their name, even if you claim they are unmodified, but they can't verify that fact. And honestly such an objection seem pretty reasonable.
They are, yes. Well, former maintainer.
And if it were, it still wouldn't matter because the AGPLv3 source would have granted you a license to that too being a copyright license.
You need a copyright license to use the binary. You need a trademark license to use the trademark. See the firefox -> iceweasel kerfuffle
It sounds like people are saying that a company can have their trademarks used by downstream distributors of AGPLv3 software, if the license doesn't explicitly prevent that, which just seems wrong. The codebase license is not a license to other company IP
I also don't understand why an entity couldn't do a DCMA takedown based on a trademark violation.
But that's not what's going on here. If the source is unchanged, it's perfectly valid (and often done) to just point people upstream. That is providing the source. And the code used to build their snap is available*, and you can see all it does is repackage upstream's official package.
* https://github.com/snapcrafters/signal-desktop/blob/master/s...
AGPL v3 specifically allows authors to add trademark restrictions that become violating.
Don't follow the trademark clauses, lose your copyright license, that becomes a copyright violation, actionable under DMCA.
https://github.com/signalapp/Signal-Desktop/blob/main/LICENS...
[1] https://drewdevault.com/2021/09/27/Let-distros-do-their-job....
If unmodified binaries are redistributed, there is no trademark violation. It's nominative use, and simply not misleading the public because it's the genuine article. Any obstacle to redistribution must therefore come from the copyright licensing terms (if the binaries are available to the general public), or from an individual agreement with the original recipient of the binaries (so no direct free, public downloads even if the binaries are technically under an open-source license, and export compliance is a bit more difficult). Not sure which applies here, but it's not a trademark issue.
Can you post this update on the Snapcraft (https://forum.snapcraft.io/t/what-happened-to-signal-desktop...) and GitHub threads (https://github.com/snapcrafters/signal-desktop/issues/70) too?
I was going to just now and cross link back here to your comment and figured it would be better coming from you directly!
Will they do the same if some vulnerability is found in Signal? Lawyer up instead of fix the problem?
No, those lawyers are paid for by and directed by signal. Signal is responsible.
$ sudo apt-get install signal
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package signal
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".
No way. I will never trust your binary.
There are a lot of users that prefer the established trust model of a Linux distribution. They're willing to trust the mostly unpaid debian maintainers for example... but not John Doe, the temporarily set back billionaire who's just about to make it big
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
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.
curl -sfL www.marginalia.nu/install.sh | sudo sh -
Or cloning a git repo and building it?
But you can?
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.
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.
I would instead manually download and unpack the app, create separate user for it, and run it in chroot. Much safer than your method.
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.
Sadly debian-based distributions do not respect the principle of least privileges and grant unnecessary permissions to installation scripts.
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.
I've had so many bad experiences with broken third party packages or worse, "installers".
Remember you are expecting the maintainer to not only be honest you are expecting them to secure his own machine as well.
I don't want to add random deb repositories for software like that.
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?
My understanding (as an outsider) is that Signal doesn't object to you building yourself a copy of Signal Desktop for source, but they do object to anybody building it for others, especially when they brand it as "Signal." That doesn't seem especially unreasonable to me: E2EE is a domain where trust is established exactingly; a proliferation of unreviewed third-party builds compromises environmental trust.
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.
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-party package repository that Signal's developers are signing for.
(My understanding is that you can also configure apt to limit packages on a per-source basis, but I won't recommend that since I don't think anybody bothers to do that.)
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.
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.
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.
I trust Signal, the company, as an author of specific type of communications software. I hesitate to trust them with root on my systems. The company and their intentions are, for the best of my knowledge, benign - but I have seen far too many well-meaning packaging snafus over the past 25 years to add even them to my sources.list.d; and in fact, I believe that with the actions of the company over the past ~three years they have squandered lot of the goodwill they had built up. I'm sorry to say, but the theme to me has felt like one of miscommunication combined with a lack of foresight.
I do trust they have had good reasons for everything. But optics are important, and for stewards of such a critical piece of software Signal have come up with questionably announced surprises. In a domain where boring is the characteristic everyone looks for.[ß]
A bit more context. As of now, there are only two third-party APT repositories that I can stomach. The official Postgres repo, and the Deadsnakes PPA. Both are maintained by the actual package maintainers, so they benefit from the assumed baseline and robustness.
ß: btw, I understand the SMS stuff. From an engineering effort perspective it makes sense, given what shitshow the SMS/MMS protocol stacks are. And with RCS, future integration would not be guaranteed at all. But it still came as a surprise.
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.
goodpoint's answer is probably the best longer term answer: someone needs to fork Signal and manage it properly. But it's not as simple as just rebranding the software, it needs lots of difficult technical work to fix its many problems.
Why is that?
It is not like most of my social groups are me-centric, which forces me to pick battles carefully. Now that I moved people to signal, I need to do what I can to try moving signal to my ideal space ( no phone requirement being one of them, 3rd party clients and so on ).
That list is still short. I would love to be able to return to pidgin days, where all I had to connect my various accounts >.>
I do not know if the issue is that some the features are just incompatible with standards?
Sadly, the biggest problem is inertia.
Threema is liked for security. I haven't used it, but my mother's tennis group is using it, and they're all 65+.
I used this snap package thinking it was an official one, if I had known that it isn't I wouldn't have installed it.
Whoa. That's unexpected.
You could argue that it's a trademark issue, except that if it was, this makes a DMCA request illegal as it's not a tool to enforce trademark issues. And in addition, while the AGPLv3 has allowances for trademark carve-outs, Signal makes none.
It's not a good look for the lawyers to be completely in the dark on an issue so core to their company's business.
> ... a company that prides itself on being tech-centric ...
I can't see why this matters. Wouldn't it also be a worthy question for $NOT_TECH_COMPANY if their lawyers send a DMCA takedown request in such a manner?
It's bad in any case, it's worse when you're uninformed on an issue core to your entire mission. This is an area their lawyers should be exceptionally experienced and informed in, where it'd be potentially easier to forgive a lawyer completely green on FOSS making a mistake on something they thought was straightforward.
To clarify, any lawyer working for any company with a publicly available, physical (read: non-software or computer hardware) product or service that I've heard of should never make this mistake. That's why I wouldn't think it's especially weird that the company in question is one who offers a software product.
Anyway, you do otherwise make a good point. I can understand that someone sees it that way. (And thanks for explaining your perspective!)
Trying to prevent legal from being overzealous while not chilling their ability to do their job seems like a very challenging problem.
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.
e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
Signal’s Rights. We own all copyrights, trademarks, domains, logos, trade dress, trade secrets, patents, and other intellectual property rights associated with our Services. You may not use our copyrights, trademarks, domains, logos, trade dress, patents, and other intellectual property rights unless you have our written permission. To report copyright, trademark, or other intellectual property infringement, please contact abuse@signal.org.
https://github.com/signalapp/Signal-Desktop/blob/main/LICENS...
I think what Signal is objecting to is that the snap looked like it was packaged and distributed by Signal when the files included could have been modified with a backdoor or whatever.
This is the sort of reason why people are concerned about an ecosystem where Canonical has 100% of the control of the only distribution mechanism. I suppose this is just a confirmation of the legitimacy of those fears.
[1]: https://www.yoctoproject.org/
[2]: https://rauc.io/
Of course, take my opinion with a grain of salt. I am currently developing a tool at my day job to significantly lower the developer time required to produce and regularly release our Yocto-based distributions. I hope to be able to release that package as open source at some point.
In any case, Yocto is infinitely better than Ubuntu's Snap Crap.
In fact, I am poised at the starting line of that sprint, but I'm still trying to decide what my next distribution will be that provides similar quality and cadence. It's a somewhat sad day, as my servers have been running Ubuntu for almost two decades. A switch will be immensely painful, but the state of their snap crap is pushing me to switch all of my systems once and for all. Worse for Canonical, I then will be taking all of the systems in my engineering division to those greener pastures.
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 security team over random volunteers.
The biggest problem IMO is that Flatpak coupled itself too closely with Bubblewrap. Flatpak is missing many key features because of this (support for running services???), and it makes zero sense in the context of a modern desktop. Apps like Flatseal should focus on sandboxing regular applications with Bubblewrap rather than trying to manage all of the software on it's own. As-is, Flatpak is the last resort of packaging methods for all of my systems, even behind Snap.
There is nothing stopping Canonical from offering a Flatpak based App Store that only contains approved and vetted apps.
I agree consolidation on a single format would be great. They have no incentive to make this switch though - most of the flak they're taking is about them being in control of their app store, rather than snap as a technology.
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.
How is a user supposed to decide whether they want to trust a flatpak published mainly by "flathubbot" (according to the page linked by FlatHub) and a bit by various other contributors with names like "TheEvilSkeleton" and "barthalion"? I have no idea.
Due to how the Snapcrafters publisher works, Canonical was communicating with the "wrong" person about this takedown. They've since amended their process to make sure this doesn't happen anymore. (Snapcrafters is a team of community volunteers maintaining unofficial packages)
Due to how lawyers and legal threats work, Canonical is very hesitant to publicly talk about what is going on. You can expect a thorough post-mortem after the legal issues are cleared up.
Snaps response [2] seems to be:
> I understand the sudden move of signal-desktop can be disruptive for people wishing to install this package. Just to confirm the reason for the absence - Snap Store administrators had to remove the snap in accordance with our policies. We hope to have it back shortly.
1. https://github.com/snapcrafters/signal-desktop/issues/70#iss...
2. https://forum.snapcraft.io/t/what-happened-to-signal-desktop...
Would I use Ubuntu as a desktop, oh hell no -- nothing is ever going to beat Fedora.
Good to hear you enjoy Fedora, I do as well! I use the server variant for my stuff, unless you compile kernel modules you might find it a decent fit
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.
Don't forget a --purge for extra wantonness.
And then engineers started installing snaps on their dev instances, I think mostly by accident...
Why fix what ain't broke?
Basically the same thing, but not only does it not have snap, it's also systemd-free :-)
I think the long term solution will be to just hop distros anyway (Ubuntu is doing their thing and it works for lots of people, they don't have to be everything for everybody, there are various other little pain-points for me that make it not really worthwhile).
I went back to Debian in the end. Absolutely nothing wrong with good old apt. Nice to have a clean and predictable system that respects my choices.
Once I realised they were not for me I started distro hopping and ended learning far more day to day system administration skills than ever.
To this day, I've never once found myself remotely tempted to use anything like a Snap or Flatpak.
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 from you.
For my Fedora people, looks like we can directly install with `dnf`. Debian aptitude people should prefer the same.
Available Packages
Name : certbot
Version : 1.30.0
Release : 1.fc36
Architecture : noarch
Size : 44 k
Source : certbot-1.30.0-1.fc36.src.rpm
Repository : updates
Summary : A free, automated certificate authority client
URL : https://pypi.python.org/pypi/certbot
License : Apache-2.0
Description : certbot is a free, automated certificate authority that aims
: to lower the barriers to entry for encrypting all HTTP traffic on the internet.And even Ubuntu: https://packages.ubuntu.com/kinetic/certbot
Though I guess there's a risk that eventually the Ubuntu package becomes a facade package like Chrome is, that has no content but uses a postinstall script to grab you the snap instead.
https://github.com/certbot/certbot/issues 5000 bugs and it most of it can be replaced by much smaller tools
The snap identifies itself as an unofficial snap package of signal-desktop so my assumption is this is third-party volunteers repackaging it for snap users (and possibly non-deb systems).
A centralized service being the only option for software distribution is too large of a failure point, no matter who's running it.
I have plenty of gripes with Snap but this time the Signal team is to blame.
As a side note, "Signal" is a generic English word. The logo is a generic speech bubble. Copyright and trademark law should not be piecing up language and handing it out to tech companies that decided that all app names should be no longer than two syllables. I'm sure legally speaking there's a trademark case to be made here, but ethically speaking I think it's wrong.
Your saving grace here is that Ubuntu as a Debian derivative still supports apt repos, but if snaps were to really gain traction that might not always be the case. A desktop version of Ubuntu Core (akin to Fedora Silverblue for flatpak) would not have this luxury.
And finding out now that it's possible that snaps are part of a walled garden, just like app/play stores are is really bumming me out.
I'm rather new to linux and Ubuntu is the distro I'm most familiar with and I also really like using KDE. So I'm wondering if it's feasible to continue using a Ubuntu based distribution while completely avoiding Snaps or should I just switch distros (maybe to another one that runs KDE).
I’m a big fan of Fedora. I primarily work on RHEL systems, though, so I’m biased because it’s what I’m used to using.
I've never run the KDE spin of Fedora, but from what I understand it's popular and well maintained so shouldn't be an issue.
Ubuntu has a lot to answer for, and planting the idea that you have to completely reinstall your OS to switch to a different window manager is right up there at the top. Kubuntu, Xubuntu, god those were terrible ideas.
They are openly hostile towards their own users.
Yes, and it's deeply ingrained in their culture so unlikely (IMHO) to change. My eyes first opened to this in April of 2011 when I was (horribly) surprised by Gnome being removed in favor of Unity, when I saw how they treated their users and community on forums and such. It was the same condescending attitude we see today where the user are complete idiots who want to do things the "wrong" way and the canonical employees (especially the "community managers") know the "right" way to do everything.
If you're writing software, the switch will be a great way to see that your code is robust and not too closely coupled to the peculiarities of Ubuntu. Portability may not be an explicit goal but it turns out to have some benefits.
Or maybe there is something totally different that is becoming popular that I don't know about yet?
Sorry I wasn't clear enough about the Ubuntu connection. Pop!_OS is based on Ubuntu, but Pop!_OS provides non-snap packages for (AFAIK) everything. So for me, Pop!_OS is like Ubuntu, minus the user-hostility.
If you want a paradigm shift, try NixOS + home-manager.
Manjaro or mint too.
On the desktop side, Debian is also a stable choice, but you might prefer to go downstream from Ubuntu to get newer features sooner. Snap-free distros based on Ubuntu include Pop!_OS, Linux Mint, and elementary OS. There are also popular distros not based on Debian or Ubuntu, including Arch Linux (and its derivatives) and Fedora.
sudo apt update
sudo apt upgrade
sudo sed -i 's/bullseye/sid/g' /etc/apt/sources.list
sudo apt dist-upgradeImagine if I asked police to give me my neighbor's car, as I'm claiming it as mine, and they would have to immediately comply before investigating if my claim has merit?
If Signal is willing to leverage the DMCA to take down the Snap package, they could just as easily take down any other unofficial repository.
If you wish to solve this problem, write a letter to your favourite American legislator to protest the stupid way the DMCA is set up or contact Signal legal and tell them their use of the DMCA is bad for the open ecosystem that they operate in.
Someone freely choosing to grab an unofficial version of Signal from the store of their preference isn't the problem here.
Linux and OSS software became what it is, became the stable, secure powerhouse it is, literally dominating every aspect of computing, because profit was originally less important.
Look at Debian, which only ships when ready, and never ever to a fixed deadline.
Yet today, almost all private corps take and take and take, without every contributiong code and workers back.
Look at Ubuntu, a distro which literally could not even remotely exist without Debian, from which most of it is derived, and rebased to constantly.
To Ubuntu, a great leech of the OSS world, it is more important to give a crappy experience(snaps), than use Firefox LTS, for example.
Good grief.
I'm not being facetious, it's just that this aspect has not been described to me so far, IIRC.
Debian had to support it, mostly because at the time Gnome, another Redhat controlled project, decided to depend upon systemd.
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.
1. https://github.com/signalapp/Signal-Desktop/issues/1639
2. https://www.reddit.com/r/signal/comments/tiidh8/comment/i1em...
Why can't a publishers website be their store front, then from that site, you can run (or "download"/"install" if you must) the app?
Technically it looks like that would actually work [1]. They could host the `.snap` file. Although I'm sure snap will add friction to this (as in, not simple let you open and click "Install") from a downloaded snap file, as they probably want you to use their app store.
1. https://github.com/snapcrafters/signal-desktop/issues/70#iss...
The Year of the Linux Desktop isn't now, and it may never happen. Even if it does, I don't think any of the hypothetical "normie" Linux users would really care for it all that much. Trying to be the devil's advocate for things like the Snap store benefits a group of users that doesn't exist in any timeline at the expense of current users in this timeline.
When searching on Google, I have to look through a bunch of crappy results from SEO optimized crap. Then when I find something that looks interesting, I have to see if it's packaged for Fedora or not. If not, then I have to hunt down either a GitHub page or look for a RPM file or a flat pack or app image. I won't use a snap even if it's the only distribution method.
There's also a very convenient way of checking for popularity, which doesn't necessarily mean it's a bad pic, but if the package is popular enough that somebody has packaged it for Fedora and maintains the package, there's a very high chance that it will work as needed.
If you don't currently check the apt or DNF repos first, I would definitely recommend doing so.
Don't get me wrong. I hate Snap much more than the next guy, but the idea of keeping a repository so you can go look for, and discover, stuff that is supposedly also vetted by someone is nice.
The issue is, when an app store is a monopoly and not standardized.
APT repositories is, in my eyes, an example of "the good" type of app store.
I think the rub here is that the maintainers of the signal snap can't reuse the work they’ve already put in to this and offer it elsewhere in another snap repository as there’s no other snap repository possible
Flatpak allows this, but, in the other hand, despite I exclusively use Flatpak these days, I dislike the fact that is not focused in CLI apps but desktop ones instead.
This hasn't been the case on Windows for years now.
I want a centralized "update" feature, that will do all that for me.
This can be done by signal adding its own repo, but it's a pain to add a per-app repo, if the app can be on the central (distribution-managed) one, especially if it's a popular app.
> I really despise the idea/existence of app stores.
> Why can't a publishers website be their store front, then from that site, you can run (or "download"/"install" if you must) the app?
- Links resolve, and data can be fetched, as long as anyone is hosting it (regardless of who) - Anyone (including big orgs/corps) can provide a curated lists/search for links they vouch for - Removing something from a list doesn't affect anyone's ability to fetch and use it; only whether they see the link in that particular search/list UI
Might want to double-check if/when there's some automatic update that decides to reinstall Snap
> > Snap Store administrators had to remove the snap in accordance with our policies.
>
> Thank you for providing an official answer.
Sounds like someone should change the icons and change the name to make the unofficial Signal snap look properly unofficial. Should protect the application from Signal's controlling tendencies as well as their open source code can and should be redistributed freely.
https://forum.snapcraft.io/t/what-happened-to-signal-desktop...
Look at the github history.
Snap is closed source garbage ware, with MS Windows forced updating and the terribleness of being 10x slower....
So here's how to "Snap-Off" your system https://haydenjames.io/remove-snap-ubuntu-22-04-lts/
cf https://twitter.com/cavalorn/status/654934442549620736?lang=...
I don't use gnome-calculator on Windows because there's no official Windows distribution available for that platform. That doesn't make the Gnome devs lazy, that's just my preferences conflicting with theirs.
You're not entitled to support for your preferred distribution unless you sign some kind of (probably expensive) support contract and other people not working for you for free doesn't make them lazy or stupid.
I am currently setting up a new laptop and so far my plan is to not install it.
Anybody here who uses it? Care to tell why?
Does Ubuntu remove it?
"Snap is a magnificent idea with a still immature realization.[...] The overall user experience with Snaps on Ubuntu is frustrating: several apps won’t start when installed as snaps, others run weird, others take really long time to start. As an example: Telegram as snap takes around 51 sec to be operative, Telegram installed as binary starts in 1,5 sec."
see https://cialu.net/how-to-disable-and-remove-completely-snaps...
Also I was never happy with snap because unable to full control when software will be upgraded (and why). It was the main reason I stopped to use it, after Ubuntu20 make snap a default install complex to remove: https://gioorgi.com/2021/ubuntu-20-failed-me/