Live data from Hacker News

Why is there only one Snap Store?

merlijn.sebrechts.be

41–50 of 362 posts

Re: Why is there only one Snap Store?

#41

Earlier quoted context omitted.

> All Snaps are now digitally signed by Canonical, so you actually need to have the end-user install a forked snap tool Isn't the client side open source so you can put your own signature? Digital signing things seems a good idea for security.

I wish, but the signature is actually compiled into the snapd (the software on your system)'s binary. Deliberately impossible to reconfigure. Like I said, you can change the signature... by distributing a forked binary to users that would be incompatible with the main store.

You can always modify the Linux Kernel system call "open" to detect when an attempt to open the certificate is being attempted and then read out your own certificate.

Re: Why is there only one Snap Store?

#42

Earlier quoted context omitted.

> All Snaps are now digitally signed by Canonical, so you actually need to have the end-user install a forked snap tool Isn't the client side open source so you can put your own signature? Digital signing things seems a good idea for security.

I wish, but the signature is actually compiled into the snapd (the software on your system)'s binary. Deliberately impossible to reconfigure. Like I said, you can change the signature... by distributing a forked binary to users that would be incompatible with the main store.

Isn't this good? I mean if you are a distribution you compile the software yourself so you can add the distribution keys (there are some that don't compile stuff ).

Probably you are thinking there should be atext file in your home where you could add new signature to be sued, but that could be a security issue so probably needs to be something more safe,did any serious patch was sent to improve this and was it rejected or why we expect Canonical to prioritize this over other issues?

Re: Why is there only one Snap Store?

#43
post #32

What does snap do that flatpak doesn't?

Flatpak can not currently run on servers, only desktops. I'm not sure if there are plans to change this, if anyone knows I'd be interested in finding out.

At least for now, there are no plans to change this because Flatpak (if I recall) requires dbus. You might find some interesting info on that.

Re: Why is there only one Snap Store?

#44
post #21

Earlier quoted context omitted.

The LXC/LXD folks at Canonical are doing great work with adding kernel features for namespaces etc. I think the "problem" is that Canonical has figured out - correctly - that all their worthwhile stuff needs to be done upstream of Ubuntu. Even their packagers know to try to get things in Debian first and to reduce diffs when they can. Unfortunately, that means that the unique Ubuntu secret sauce is all the weird stuf…

I got so excited about LXD ... until I found out it requires snap. My first "cup of ubuntu" was well over 10 years ago now and I've always wanted to see it succeed. It's repeated squandering of so much potential. Edit: I was referring to LXD usage on Ubuntu-20.04 and versions going forward (I should have made that clear in the post). Sure, snap isn't technically required since you can "change distros" or "compile it…

It does not require snap, it is just the default way to install it. You can compile it yourself, or check the repositories of your distro of choice otherwise.

I think Arch has it in their repositories, for example.

Re: Why is there only one Snap Store?

#45
post #38

Earlier quoted context omitted.

Ideally you'd be able to add the alternative store's public key to the existing snap client. Like you can do with existing package managers to include alternative repos

They deliberately designed the software to not allow that without you forking. I mean, it is trivially easy for Canonical to just put the public key in a file and have Snap read from that key. Instead, they've hard-compiled it in. Three years ago, I actually had a discussion with them about External Repositories. It's called "External Repositories?" on the forum and has, like, over 200 messages on it. They didn't bud…

Was there a competent patch submitted about keys and was this discussed in public? I imagine you can't just drop the keys in a random text file, it must be protected like the passwords file.

Re: Why is there only one Snap Store?

#46
post #19

Earlier quoted context omitted.

I'm curious to try GNU Guix, does it sufffer from the same problems as Nix? (Edit: looking at https://guix.gnu.org/en/videos/everyday-use-of-gnu-guix,-par... from the top of https://guix.gnu.org/ , basic installation and removal of packages looks exactly like apt, literally the same command line with 'apt' replaced with 'guix' and 'sudo' unnecessary because you can install packages per user.)

I admit I've not checked and have just assumed the package list is both ideologically- and mindshare-crippled, due to the GNU on the name and the seemingly low rate of use, respectively. Nb I think free software goals are great and all but if I need Slack for work or need my proprietary wifi card to work using a binary blob then I f#cking need those things, and it's nice if my package manager can install them for me.…

You can use Guix on distros with impure repos, not just the GNU Guix system, and use the host distro's packages for proprietary software (if you can't just use Slack's web client, or use a laptop with a freedom-respecting wifi card / a little dongle / ethernet).

Re: Why is there only one Snap Store?

#47

Earlier quoted context omitted.

Also, moving control from the user to the developer. Snaps automatically update, and until recently had no way to disable this behavior. This is a poor security choice, and means that a stable system cannot be made. While apt can still be used, many packages were replaced by snaps, completely defeating the purpose.

"many packages" as in "less than 10 out of 10s of thousands".

notably, I thought ripgrep became a snap?

Re: Why is there only one Snap Store?

#48

Earlier quoted context omitted.

Pollute your mount list and make your software start way slower and take up more space. Also sometimes break or require intervention for basic operation due to security restrictions on it. The benefits are supposed to be that they're more secure, more portable, and don't junk up your system with files strewn everywhere. Personally I'm waiting for a better solution than anything we've seen so far for the first of thos…

What's so impressive about Homebrew specifically?

1) Rarely breaks. Worst I've seen is needing a permissions tweak after an OS upgrade, in many years of use. Back when I switched from Macports I switched because ordinary usage kept rendering Macports so goddamn broken that it was easier to nuke its directory and start over rather than figure out how to fix whatever my bold command of "install package" had destroyed this time. I've never seen normal or even slightly abnormal use put Homebrew in a broken state that required manual intervention to fix.

2) Command line UI is alright. This should be a given but isn't always.

3) Can manage proprietary software for me. There's almost nothing I use (maybe actually nothing?) on my Mac that Homebrew doesn't have an up-to-date package for, aside from Apple-provided apps.

4) Enough people use it that despite being a semi-free-for-all community-run thing packages are pretty much never broken, including the proprietary ones. I'm also continually surprised by how often I find some obscure thing with five stars on Github, want to try it out, and sure enough, there's a Homebrew package.

5) Lets you manage your packages with ordinary user-level permissions. No root elevation required.

6) I can clean practically all of what it's done and get back to a nearly-vanilla system (with the exception of some of the proprietary apps) by deleting one directory. My system and GUI will still boot like nothing's happened. IMO keeping your user-level packages strictly separate from the system-level ones, and managed totally separately, is absolutely the right way to go. I didn't realize how much I wanted this until I started using Homebrew on a Mac, after many many years of Linux package management.

7) It leaves system-level packages that it upgrades alone, so doesn't break core system stuff (I would fucking love this to become a norm on Linux—system uses and assumes latest LTS version for stuff like Python, but I can install whatever version I like for my own use, without affecting that whatsoever and without having to use a different goddamn version-management tool for every single language)

8) I'm pretty sure you can have more than one version of something installed at once and there's a command to switch between them (juggling symlinks, probably), but my recollection of this is vague and may be wrong.

9) If you're actually doing multi-user on your desktop/laptop I think it lets you have per-user install directories and active packages—but I don't really know anyone who does this, and haven't known people to share a computer, really, since over 15 years ago. Amusingly enough, iPads, with practically nothing resembling multi-user support, are the exception to this use pattern, as those seem to get shared among members of a family all the time.

Bad things:

1) Requires Ruby (seems like a dumb complaint, I know, but I hate installing an entire scripting language for a single command line tool, and no not all Linux distros ship with Ruby by default, far from it)

2) I dunno if it still does (I'm working mostly on Debian now) but for approximately forever it's had a completely braindead default for how often it auto-updates its package list when running other commands, and you had to go change that every time you installed it on a new machine so you'd not rip your hair out in frustration when your command to install a package was delayed because it'd been a whopping 16 minutes since the last time it checked for updated packages. Why the hell this didn't default to, like, 12 hours or something is entirely beyond me. AFAIK everyone hates the default behavior, to the point that it's become a common jokey-reference among Mac nerds, and I've never been able to figure out why anyone would want it.

Re: Why is there only one Snap Store?

#49
It does not seem that the author is affiliated with Canonical. Ideally, Canonical should be the ones defending their product.

IMO, it is okay for the backend to be propriety as long there is a published, easy to implement protocol for talking to snapd (along with an accessible way for clients to configure snapd). Otherwise, there is lock-in to the service. It's not just the FOSS community that should be concerned, but business users as well. Do you want to internally distribute in-house snaps via Canonical's servers?

> DockerHub and GitHub are insanely popular and they are completely proprietary.

These are arguments against, not for, using these services. And many proprietary SaaS companies sell installations on on-prem air gapped servers.

Re: Why is there only one Snap Store?

#50

Earlier quoted context omitted.

They deliberately designed the software to not allow that without you forking. I mean, it is trivially easy for Canonical to just put the public key in a file and have Snap read from that key. Instead, they've hard-compiled it in. Three years ago, I actually had a discussion with them about External Repositories. It's called "External Repositories?" on the forum and has, like, over 200 messages on it. They didn't bud…

Was there a competent patch submitted about keys and was this discussed in public? I imagine you can't just drop the keys in a random text file, it must be protected like the passwords file.

They're public keys so they can be in plaintext and protected by 0644. They don't really have to be different from apt keys.
Post reply on HN