Signatures files in latest release

[bleetsheep]

The latest release no longer has .sig files. Is this a one-off bug or will releases no longer be signed?

[tasn]

They were omitted on purpose. I'm still on the fence with what to do there (would love some input).
They were removed because the new release wasn't built on my own development box, but instead was moved to be built using a CI service. It makes the builds more reliable, easier to deploy and more importantly let us control the OS versions we build on so that it works for a variety of users.
For instance, what actually triggered this change was a user not able to use it on macOS 10.13 because my macOS development machine was on 10.15. We had the same issue with Linux previously (which is why we switched to building it inside a container running an old Ubuntu version).

This is why we switched to CI, now how does it relate to signing? We could potentially sign those builds, though we would just be adding a false sense of security as we didn't build these binaries, so potentially, if there was an issue, signing wouldn't solve it in 99% of the cases.

I'm going to leave this ticket open, so there could be a discussion here. If people feel strongly that releases should be signed, we can try figuring it out, though I think that if you need this higher security assurance, maybe consider building it yourself/using a trusted source (such as a Linux distro)?

Would love to hear your thoughts.

[quantumpacket]

though we would just be adding a false sense of security as we didn't build these binaries

Thank you for considering this and taking action by not providing the signatures.

If people feel strongly that releases should be signed, we can try figuring it out, though I think that if you need this higher security assurance, maybe consider building it yourself/using a trusted source (such as a Linux distro)?

In my opinion, I think signatures should be provided as it provides a much easier way to verify the integrity of a file (import trusted key if not already done, download files, gpg --verify, done) opposed to having a user take the effort to setup a dev environment and build the app (create virtualenv, download source, git gpg verify source, install app), which not everyone may know how to do, let alone properly. This otherwise, raises the bar for adoption of etesync for those who want to make sure they are getting a trusted version, and may have an unintended side effect where people choose to not verify due to inconvenience.

Hopefully there is a solution for this that provides the signatures again, takes care of those edge cases, and doesn't incur an unnecessary burden on the maintainers. :)

[bleetsheep]

@quantumpacket But what extra assurance does a signature give when the binary was built by a random server which pulled the code from GitHub? Previously the binaries were pushed by the dev to GitHub together with signatures, so the signatures prevent a scenario where GitHub is untrustworthy, either because GitHub got breached or because the developer's account did (in some way that didn't affect their private PGP keys). Now, we're trusting both GitHub and the build server. The build server could add a signature so we're sure it's not GitHub being breached but... in the scenario where either GitHub is compromised, the attacker can just change the code and trigger a build and replace a release right? So it wouldn't defend against either scenario. Or do you mean to defend against a breach of the CA system, where the attacker MITMs the target and replaces the download but wouldn't be able to forge the binary's signature while not being in a position to MITM the build server and replace the code it downloads from GitHub?

Also,

I think signatures should be provided as it provides a much easier way to verify the integrity [as] opposed to having a user take the effort to [build from verified source]

While I agree that it's less specific and extensive knowledge to learn to do a signature check than learn to build this specific software and verify git commits, I think most people with either of those skills will be part of the multi-colored section in a Venn diagram. But of course, provided signatures being of any use is contingent on the answer to the above.

@tasn

I'm still on the fence with what to do there (would love some input).

Sorry for not responding actually, I did consider it and have discussed with others but had not really come to a satisfactory conclusion.

The scenario where GitHub is breached and etesync-dav binaries are replaced is rather specific, though given just how immensely important GitHub has become (if you could freely change code on GitHub and let it be part of an update, you could run code on virtually any computer on or off this planet... that's a target if I ever saw one) and the resulting likelihood that it will ever get breached (question of when rather than if), the real question is whether etesync-dav is run by anyone within the attacker's scope. Given that end-to-end encrypted calendars are, shall I say, somewhat paranoid and limited to hi-tech users at the moment, it isn't unthinkable that one of etesync-dav's users is someone of interest to a nation state or another similarly advanced attacker.

And so I can't really decide if the scenario is exceedingly unlikely or actually quite plausible. Perhaps not for me personally but for everyone else running this as well (I see you are a pentester, so you frequently have access to reports of unpatched and perhaps novel vulnerabilities for customers that I can only presume are valuable to breach). Given how much other stuff we trust that comes directly from GitHub which we don't check the developer's signatures for, though, one could choose to just trust GitHub. It's still yet another dependency to trust a random build system when we're already trusting GitHub, but adding keys to the build server or signing whatever the build server returns doesn't help that in any realistic way that I can tell, nor can I think of another solution that would let the build server be there without needing to trust it (deterministic builds, but then if they were deterministic the developer could just run the build themselves, which would be necessary to check the build matches, making the build server redundant).

I suppose it could work the other way around: if we trust the build server, can it verify git commits reliably? For that to work, it must receive the fingerprint or public key to use from the developer directly rather than pulling that from GitHub (and I don't mean a key server where anyone can put any key, I mean something like a settings field on the build system where the developer can enter their fingerprint or key). That way we don't trust GitHub but only the build server. (Well, and the developer, but that's a given.)

I don't see a good solution here that lets us verify that the build coming from a build server outside of the developer's control matches the developer's code. And I'm not saying that a build server outside of your control is an unreasonable requirement in this situation.

[y-x41]

@tasn Since the linux distribution is already trusted, it would make sense to
build on that. Pip then introduces another party that would need to be trusted.
They don't offer a mechanism to verify the integrity of packages downloaded
from there. So the conclusion from that would be to use the packages provided
by the distribution instead. Along with the signed release tags from both
etesync-dav and pyetesync (now etebase-py?) that should provide a solid base to
build off of.

Currently, to run etesync-dav without any packages directly from pip/github,
one has to run the instructions from .travis.yml to build the binary with
pyinstaller. Pyinstaller is, however, not in the debian or fedora repositories.
So one would have to run scripts/etesync-dav directly, which doesn't seem to
currently be supported.

What if the project was instead runnable from script/etesync-dav? That way
the trust chain only consists of a trustworthy OS and your PGP key. In order to
avoid any version compatibility issues a docker/podman container could be built
on top of a distribution with recent packages, like fedora.

We tried to run the script by itself but only stumbled into more and more
errors. If you think it is a good way forward to have a container that can run
the code without external dependencies, I would really appreciate such a
container. Alternatively, if you think we could achieve this ourselves, any
pointers would be appreciated.

[quantumpacket]

But what extra assurance does a signature give when the binary was built by a random server which pulled the code from GitHub

@bleetsheep I think you misunderstood what I said. I never said to provide signatures for the current build server releases. Hence I thanked the dev for no longer providing them due to that fact. I totally agree Github can't be trusted, for other reasons as well :P

I am asking for providing signatures again, but after a secure implementation is setup. The table is open for ideas on how to do that, and I was just providing my opinion that signatures would be beneficial and to not abandon looking for a solution to securely provide them again.

While I agree that it's less specific and extensive knowledge to learn to do a signature check than learn to build this specific software and verify git commits

Maybe we can add some documentation with the correct step-by-step commands to properly download the source from git, verify, etc. to help lower the bar for less savvy users and make it more clear that the current releases are not as "trusted" as they may think.

but then if they were deterministic the developer could just run the build themselves, which would be necessary to check the build matches, making the build server redundant

PEP 552 allows reproducible builds, open bug. But as you said, it makes the build server redundant as the dev would still need to compile on their trusted platform to get the correct hashes to sign.

[tasn]

Sorry it took me a bit of time to respond. I wanted to think this properly rather than provide a knee-jerk reaction.

@quantumpacket, I agree. It should be easier. I was just trying to avoid false assurances.

@bleetsheep

I suppose it could work the other way around: if we trust the build server, can it verify git commits reliably? For that to work, it must receive the fingerprint or public key to use from the developer directly rather than pulling that from GitHub (and I don't mean a key server where anyone can put any key, I mean something like a settings field on the build system where the developer can enter their fingerprint or key). That way we don't trust GitHub but only the build server. (Well, and the developer, but that's a given.)

Ha, that's exactly what I came here to suggest. I can make the build server verify the tagged releases so at least we know for sure that nothing was modified on github. This reduces the issue to only trust Travis.

@y-x41, this is easy to do. You don't need pyinstaller that, you can just run the script directly. You just need to have everything in the correct place. Here is for example the spec file for the Arch Linux (AUR) package: https://aur.archlinux.org/packages/etesync-dav/
We need to get more distros to package it, that's for sure, but that's the best solution.

Another thought I have: it may not be reproducible builds, but it's close. If memory serves, PyInstaller is essentially a small binary that extracts a payload and runs it. The payload includes Python, binary deps, and the Python sources. Maybe all of these can be verified separately (rather than the thing as a whole). Though it sounds very time consuming so I'm not sure it's a top priority.

As for building the binaries ourselves again: there are two main reasons why we stopped:

1. It was incredibly painful to jump between three machines (or VMs) and build + upload the binaries. It made it so I was less likely to want to make a new release, and thus less likely to fix issues. This is not theoretical, it was my actual emotional state, and with the CI this was all alleviated. I fixed a lot of issues since switching to CI.
2. The builds were not working for some reason. The problem is that PyInstaller bundles some libraries that expect certain deps to be available on your system. If you are using a recent Linux distribution (I use Arch) any binaries built by you would not run on e.g. Debian or Ubuntu. So we had to use VMs/Docker for that. It's less of a concern for Linux, because it's easy to spin up VMs. The problem was macOS which suffers from the same issue so we needed to build things on an old mac. This is even worse because developing for iOS requires the most recent mac version. So this forces us to have another build machine.

[tasn]

Note to self: while at it, probably change it to be signed using minisign/signify as it'll be much easier to setup and pass the keys to the build machines, as well as rotate them if needed. We can sign these with the main PGP key.