Hacker News Reader

Comment by mort96 | Hacker News Reader

This is not a good look. The snap has been gone for almost a month, with seemingly no information given to the maintainer or users about why, except a belated "we removed it for policy reasons" 21 days ago. And if this happens to maintainers associated with Snapcrafters, imagine how you're treated if you're just some random person or company who maintains your own snap.

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.

View on HN

Another perspective: Canonical's IoT offering, Ubuntu Core, is based around the idea that Canonical provides the base operating system, and you provide your software as a snap, uploaded to Canonical's snap store, and you push updates to your IoT product by pushing an updated snap to the store. That has always rubbed me the wrong way, but "Canonical will just delete the snap and not respond to questions about why" wasn't even something I had considered as a possibility before.

And last time I checked, they refused to let you use your own signing keys. Means you do not get end to end trust for your own bits but need to rely on Canonical that they don’t screw up - with the obvious effect of strong vendor lock-in as I cannot sign and run my own bits.

Yeah, that's the kind of stuff which has made Ubuntu Core rub me the wrong way before this. I'm a much bigger fan of Yocto[1], with something like Rauc[2] for the software upgrade system. It's more work to get going, but in the end, you're in control of your product, not Canonical.

[1]: https://www.yoctoproject.org/

[2]: https://rauc.io/

I have spent years developing systems using Yocto, and it's a steep learning curve for the average developer. Maintaining a proper distribution is not trivial. However, communities exist that want to band together and create distributions that meet their common set of focused needs, and Yocto would be perfect for many of those use cases.

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.

This is the reason that Signal has given for not providing/allowing their client on f-droid (since all f-droid apks are signed by f-droid rather than the maintainer). I wouldn't be surprised if it were the issue here.

iirc fdroid allows apps to be signed by the developer if the builds are reproducible.

Couldn't you just double sign your bits? Sign your payload with your key, then wrap that in a snap with their key; snap verifies the outer sig, then an "inner" installer verifies the sig of the payload. That said, I would run screaming from an ecosystem with such insanity.

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.

What gives you any assurance that your inner sig check isn’t tampered?

How does that work? I would have expected Canonical to just be the CA.

You get your private snap store and upload your snaps to it. Signing and delivery is only assured between the IoT device and the snap store. Not between you (the developer) and the device.

To be fair, as long as you don’t issue a DMCA takedown for your own software, this particular case is not a good example of something to be worried about in that situation. There may be plenty of other concerns, of course.

Snap maintainer here.

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.

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 security team over random volunteers.

I agree, FlatHub isn't ideal either. They also fail to make it clear that the flatpak isn't made by the developers of the software, the "developers" on the Zoom snap lists zoom.us, and the only potential indication that it might not be official is the "See details" link under "Publisher" which takes you to a github contributors list.

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.

Publisher verification for flathub is in beta, you can track progress here: https://discourse.flathub.org/t/situation-report-new-flathub...

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.

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.

> Not really, distributions do not check every piece of code that is packaged and distributed.

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.

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.

It's because Zoom / Jetbrains haven't stepped up to package their software as flatpak, so volunteers got in there. There's a flathub policy that a flatpak project will be handed over to the vendor to maintain if they make that request - which is definitely good, but the fact of those volunteers being able to do this (however well intentioned) is not.

This is no worse than distro contributors or say, AUR or Nixpkgs folks packaging 3rd non-free party software.

Being able to autonomously do things as a community is healthy. All this corporate pandering is not.

Yep. On top of that, some people just straight-up don't intend to port their software to Flatpak. There are a lot of unofficially supported packages (or incomplete ports) that will remain that way forever, which really makes Flatpak no better than the AUR in many respects.

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.

Zoom isn't required to "step up" and use your favorite packager or distribution mechanism.

Same as docker.io stuff, most stuff is just done by volunteers. Debian, php, etc.

The problem here is that JetBrains and Zoom have chosen not to package their apps as Flatpaks.

There is nothing stopping Canonical from offering a Flatpak based App Store that only contains approved and vetted apps.

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

There apparently was communication with someone related Snapcraft so there was effort to communicate, since the account used for upload was a generic one I think they be forgiven for not doing anything more than that. Regarding the reason for removal that is another issue.

Reply on news.ycombinator.com