Create gpg signed deb package for Debian/Ubuntu

[tanx]

See: https://github.com/signalapp/Signal-Desktop/blob/development/package.json#L195

And https://blog.packagecloud.io/eng/2014/10/28/howto-gpg-sign-verify-deb-packages-apt-repositories/

[tanx]

This is how Signal is installed on Debian (https://signal.org/download/):

curl -s https://updates.signal.org/desktop/apt/keys.asc | sudo apt-key add -
echo "deb [arch=amd64] https://updates.signal.org/desktop/apt xenial main" | sudo tee -a /etc/apt/sources.list.d/signal-xenial.list
sudo apt update && sudo apt install signal-desktop

[torkelrogstad]

$ curl -s https://packagecloud.io/install/repositories/torkelrogstad/lightning-app/script.deb.sh | sudo bash
$ sudo apt-get install lightning-app=0.2.0-prealpha.21

:slightly_smiling_face:

As per #523: After spending a couple of hours doing research on different solutions (Launchpad.net, self hosted PPA, etc), a hosted solution like Packagecloud.io seems like the best way to do it. It looks like it's easy to set up Travis auto push (docs), it's not too expensive, and they've also got some sort of possibility for open source software using their services for free. As far as I can tell, they implement automatic GPG signing.

By judging from the output of my apt, Slack does their Debian package handling this way:

$ sudo apt update
...
Hit:19 https://packagecloud.io/slacktechnologies/slack/debian jessie InRelease

[tanx]

@torkelrogstad cool!

As far as I can tell, they implement automatic GPG signing.

Is it possible to sign the deb bundle on travis or does the signing key need to reside with Packagecloud.io?

[tanx]

After spending a couple of hours doing research on different solutions (Launchpad.net, self hosted PPA, etc), a hosted solution like Packagecloud.io seems like the best way to do it.

Bitcoin Core also hosts on Launchpad. Isn't that hosted by Canonical?

[torkelrogstad]

Is it possible to sign the deb bundle on travis or does the signing key need to reside with Packagecloud.io?

I believe the signing key needs to be on the Packagecloud servers. Also, a slightly important detail: It's actually not the .deb packages that are signed, typically. The metadata about the package repository is signed, and that is used to verify the integrity of the package. We could sign the package ourselves before pushing it to Packagecloud, but they are going to sign the metadata anyways. Checking package signatures is disabled by default in most package managers, so it wouldn't matter too much anyways.

Bitcoin Core also hosts on Launchpad. Isn't that hosted by Canonical?

Yes, that's correct. Launchpad is also free. The issue with using Launchpad, is in how to upload the packages. If I've understood this correctly, you can't just upload a .deb and be done with it. You have to use dput to upload the package, and dput expects a .changes file, constructing the new .deb package from that. The .changes file is basically a diff file for packages. I tried to generate such a file from two slightly different builds of the wallet, but couldn't figure it out. It also doesn't seem like electron-builder supports generating the correct files for Launchpad.

[tanx]

@torkelrogstad thanks for all your research. Very helpful!

Checking package signatures is disabled by default in most package managers, so it wouldn't matter too much anyways.

Interesting. This is probably because unlike Apple or Microsoft there isn't really a central CA system or GPG key directly in place for linux distros. Yay decentralization 😃

In that case we could also just stick with AppImage for now and just sign that bundle using our own GPG key on travis. That way folks could at least manually verify using GPG on the command line. We'd just need to add a simple shell script after the deploy step and upload the GPG signature file to our github release. The upside would be wide linux distro support with a single format (which mean less complexity). The only downside I currently see is broken lightning: uri handling (which is something we can probably live with for now).

Thoughts?

[torkelrogstad]

The AppImage approach is reasonable for now, I think. One downside to it is that it doesn't integrate with the traditional way of managing software on your system. On Ubuntu, it doesn't show up in neither the graphical nor CLI tools when looking for installed software, and uninstalling it involves manually deleting a file in a hidden folder in your home folder. I therefore prefer deb packages when downloading software.

One other solution would be to build Snaps instead of an AppImage. Snaps are also very widely distributable, but they integrate better with the existing ways of managing software (at least on Ubuntu).

[tanx]

Does snap support auto update. Seems like only AppImage supports that? https://github.com/electron-userland/electron-builder/issues/1138

In general, I feel pretty good about having a first working (if not perfect) solution with auto update for all Linux distros right now. If we see a large percentage of our user base using Linux, we might decide to optimize for specific distro in the future. But given our resource constraints I feel like that's premature optimization. I suspect there will be many other bugs and UX issues to address before we hit relevant traction anyway.

[torkelrogstad]

I can try to make a test Snap, and see if I can get it to auto update.

[torkelrogstad]

I created a test snap, and got it to auto update. I used the official Snapcraft guide, on a Ubuntu 16.04 VM, as 18.04 had issues with external libraries (as mentioned in the guide). Seeing as Snap auto update works well, I'd suggest using that instead of AppImage. That would give us a URL we could share to users, as well as proper integration into existing ways of managing software.

Snap building worked out of the box, the only change I had to make was in package.json, by setting "target": ["Appimage", "snap"] instead of "target": "AppImage"

@tanx

[torkelrogstad]

A note on auto updating: I'm not quite sure how auto updating using an AppImage worked, but with a snap the application auto updated without even prompting to install a new version. So UX wise, I'd say that is pretty good.

[tanx]

A note on auto updating: I'm not quite sure how auto updating using an AppImage worked,

There is a prompt to update in all current build target afaik. @valentinewallace has been using the AppImage on Ubuntu, so she might know more.

but with a snap the application auto updated without even prompting to install a new version. So UX wise, I'd say that is pretty good.

What if the user is in the middle of performing a transaction?

[torkelrogstad]

What if the user is in the middle of performing a transaction?

I'm not exactly sure. I've made a post on the official Snapcraft.io forums, and will update you if I get an answer there.