6 ms·

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 "

by mort96 4y ago

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.

mort96 4y ago
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.
- xp84 4y ago
  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.
- sarnowski 4y ago
  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.
  - mort96 4y ago
    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/ https://www.yoctoproject.org/ [2]: https://rauc.io/ https://rauc.io/
    - voakbasda 4y ago
      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.
  - runlevel1 4y ago
    How does that work? I would have expected Canonical to just be the CA.
    - sarnowski 4y ago
      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.
  - voakbasda 4y ago
    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.
    - hamburglar 4y ago
      What gives you any assurance that your inner sig check isn’t tampered?
  - public_defender 4y ago
    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.
    - easrng 4y ago
      iirc fdroid allows apps to be signed by the developer if the builds are reproducible.
emj 4y ago
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.
smallerfish 4y ago
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.
- freedomben 4y ago
  Is the third party maintainer relationship a policy choice by flatpak? or is that just the case because the maintainer built the flatpak first?
  - smallerfish 4y ago
    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.
    - SSLy 4y ago
      This is no worse than distro contributors or say, AUR or Nixpkgs folks packaging 3rd non-free party software.
    - smoldesu 4y ago
      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.
galgalesh 4y ago
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.
- deleted 4y ago
  [deleted]

by mort96 4y ago

mort96 4y ago

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.

xp84 4y ago
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.
sarnowski 4y ago
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.
- mort96 4y ago
  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/ https://www.yoctoproject.org/ [2]: https://rauc.io/ https://rauc.io/
  - voakbasda 4y ago
    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.
- runlevel1 4y ago
  How does that work? I would have expected Canonical to just be the CA.
  - sarnowski 4y ago
    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.
- voakbasda 4y ago
  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.
  - hamburglar 4y ago
    What gives you any assurance that your inner sig check isn’t tampered?
- public_defender 4y ago
  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.
  - easrng 4y ago
    iirc fdroid allows apps to be signed by the developer if the builds are reproducible.

emj 4y ago

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.

smallerfish 4y ago

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.

freedomben 4y ago
Is the third party maintainer relationship a policy choice by flatpak? or is that just the case because the maintainer built the flatpak first?
- smallerfish 4y ago
  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.
  - SSLy 4y ago
    This is no worse than distro contributors or say, AUR or Nixpkgs folks packaging 3rd non-free party software.
  - smoldesu 4y ago
    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.

galgalesh 4y ago

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.

deleted 4y ago
[deleted]