If I create a snap package with lets say 5 dependencies. Do I have to create a new package version everytime a dependency gets a (security) update?

I mean the advantage of .deb packages is that in Ubuntu/Debian for example I can use a library and once that library gets an update that means an update for a part of my software too. And as they only submit security updates I can be (99%) sure that the library update will not break the API so that my software could break.


The short answer is yes, you'll need to rebuild your snap if you need to update a dependency. However, there's a longer answer here, too.

Say you have some application that uses SSL (could be some embedded software or a full-blown website using Apache). You do your research and utilize specific key exchange and symmetric algorithms. Now say a security vulnerability was discovered in SSL, and a new version was released. Just because it's a security release doesn't mean the patched vulnerability was in one of the algorithms you used. What if it wasn't? What if, by patching that vulnerability in an algorithm you didn't use, something you did use was broken or compromised (happened to me recently with PHP)? If you're bundling it you can make the call about whether or not you need to upgrade on a use-by-use basis. You can also test it extensively before rolling it out to all your users. There's also the possibility that the distribution you're targeting has a different version of SSL that doesn't work with your piece of software, where bundling it in the snap provides for a common experience across platforms.

There's definitely a trade off between the benefits of sharing dependencies and the benefits of bundling them.

  • 1
    You have answered a few snap questions recently, with some degree of authority. Are you a dev? If not, can you link to credible sources? If so, can you create some credible sources? – muru Jun 15 '16 at 18:06
  • 1
    (Aside from that: If I have to trust every dev's judgement and understanding of OpenSSL code instead of, say, the Canonical security team or that of Debian maintainers who have been handling OpenSSL for years, talk of snap security is a load of hogwash.) – muru Jun 15 '16 at 18:08
  • 2
    If you install software from a developer, you are trusting that developer. The question of how they handle SSL is a good example - just having a patched version of a library doesn't help you if the app developer doesn't use the library wisely. There are lots of examples of apps that have bad security because of bad choices of algorithms or key management or signature checking - nothing to do with the version of OpenSSL they linked against. It's wise to understand this - you don't magically get security by getting a newer library on your system. – Mark Shuttleworth Jun 16 '16 at 7:26
  • 2
    By contrast, if an app IS compromised, a deb will usually let the attacker go all over the system, while a snap will not. No system is perfect, but it's reasonable to say that snaps are a useful improvement in some cases. – Mark Shuttleworth Jun 16 '16 at 7:27
  • 1
    @MarkShuttleworth I might trust dev X to deliver a decent app in language Y, but I might not trust them to understand whether a particular patch to OpenSSL can cause problems for them, and it seems to me, that's what snaps require of them. That's a level of technical detail I don't really think most application developers are comfortable with, which is why they (and users) rely on libraries like OpenSSL and distributions like Ubuntu. Of course, I'm a nobody, so my opinion doesn't count. (Also, snaps might be confined, that doesn't mean they don't handle user data, … – muru Jun 19 '16 at 19:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.