Distributing KeePassXC as a snap

This is a guest post by Jonathan White (find him on Github) one of the developers behind keepassxc. If you would like to contribute a guest post, please contact [email protected] .

Can you tell us about KeePassXC?

KeePassXC, for KeePass Cross-Platform Community Edition, is an extension of the KeePassX password manager project that incorporates major feature requests and bug fixes. We are an active open source project that is available on all Linux distributions, Windows XP to 10, and Macintosh OSX. Our main goal is to incorporate the features that the community wants while balancing portability, speed, and ease of use. Some of the major features that we have already shipped are browser integration, YubiKey authentication, and a redesigned interface.

How did you find out about snaps?

I learned about snaps through an article on Ars Technica about a year ago. Since then I dove into the world of building and deploying snaps through the KeePassXC application. We deployed our first snap version of the app in January 2017.

What was the appeal of snaps that made you decide to invest in them?

The novelty of bundling an application and deploying it to the Ubuntu Store, for free, was really attractive. It also meant we could bypass the lengthy review and approval process of the official apt repository.

How does building snaps compare to other forms of packaging you produce? How easy was it to integrate with your existing infrastructure and process?

The initial build of the snapcraft.yaml file was a bit rough. At the time, the documentation did not provide many full-text examples of different build patterns. It only took a couple of iterations before a successful snap was built and tested locally. The easiest part was publishing the snap for public consumption, that took a matter of minutes.

With the introduction of build.snapcraft.io, the integration with our workflow has improved greatly. Now we can publish snaps immediately upon completion of a milestone, or even intermediate builds for develop.

Do you currently use the snap store as a way of distributing your software? How do you see the store changing the way users find and install your software?

Yes, we use the snap store exclusively for our deployment. It is a critical tool for our distribution with over 18,000 downloads in less than 4 months! The store also ensures users have the latest version and it is always guaranteed to work on their system.

What release channels (edge/beta/candidate/stable) in the store are you using or plan to use?

We use the stable channel for milestone releases and the edge channel for intermediate builds (nightlies).

Is there any other software you develop that might also become available as a Snap in the future?

Not at this time, but if I ever publish another cross-platform tool, I will certainly use the ubuntu store and snap builds.

How do you think packaging KeePassXC as a snap helps your users? Did you get any feedback from them?

Our users are able to discover, download, and use our app in a matter of seconds through the Ubuntu store. Packaging as a snap also removes the dependency nightmare of different Linux distributions. Snap users easily find us on Github and provide feedback on their experience. Most of the issues we have run into involve theming, plugs, and keyboard shortcuts.

How would you improve the snap system?

First I would make it easier to navigate around the developer section of the ubuntu store. It is currently a little confusing on how to get to where your current snaps are. [Note: this is work in progress, stay tuned!]

As far as snaps themselves, I wish they were built more like docker containers where different layers could be combined dynamically to provide the final product. For example, our application uses Qt5 which causes the snap size to bloat up to 70 MB. Instead, the Qt5 binaries should be provided as an independent, shared snap that gets dynamically loaded with our application’s snap. This would greatly cut down on the size and compile time of the deployment; especially if you have multiple Qt apps which all carry their own unique build. [Note: Content interfaces were built for this purpose]

Reduce the number of plugs that require manual connection. It would also be helpful if there was a GUI for the user to enable plugs for specific snaps.

Finally, I had the opportunity to try out the new build.snapcraft.io tool. It seems like the perfect answer to keeping up to date with building and deploying snaps to the store. The only downside I found was that it was impossible to limit the building to just the master and develop branch. This caused over 20 builds to be performed due to how active our project was (PR’s, feature branches, etc). [Note: Great feedback! build.snapcraft.io is evolving this is definitely something we’ll look into]