[RFC] Stop depending on OpenKeychain

[msfjarvis]

Summary

Remove OpenKeychain as the PGP solution of choice and use ProtonMail's gopenpgp as a native library to implement PGP operations via JNI. This allows us to be essentially self-hosted, simplifying some extremely annoying shenanigens we have to pull off to satisfy OpenKeychain's activity results based API.

Motivation

Despite what their maintainers have said, the project is more or less dead. Issues aren't being fixed and pull requests are not being reviewed. We've worked around this previously by replacing the API library with our own, but it's about time we break this dependency for good.

We have multiple issues blocked on OpenKeychain (#1189, #998) that can be trivially resolved with an in-house implementation that we have better control over. gopenpgp's crypto APIs are actively maintained by the ProtonMail team, ensuring that security related bugs should be few and far between, which cannot be guaranteed from OpenKeychain which had its last audit many years ago and is clearly unmaintained as discussed above.

Drawbacks

We will have to build out a significant chunk of UI to make this work. I currently do not plan to offer the ability to generate keys, so that should take off some of the load.

We will most certainly face backlash from users about having to keep keys in sync at two places. Quite frankly, I do not care. By virtue of staying on top of the latest in the field of Android security as we have all this time, we're already doing better than OpenKeychain. I would much rather have users be mildly inconvenienced occasionally than have breaking bugs all the time.

This will require at least one maintainer to have working Golang proficiency. I do not believe we have such a maintainer as of now, but I am willing to fill that void.

The build system will now need to be equipped to build Golang binaries. There are plugins for Gradle that allow Golang libraries to be built, but it remains to be seen if they can be used to supply binary dependencies to other modules.

This build system complication will most certainly have us booted off F-Droid. Yet again, I do not particularly care. An Android app store that wants to build binaries itself but can't keep up with updates to the official build tool for Android does not deserve to block my work in any fashion. Users who use F-Droid should be aware that they're buying into a shoddy ecosystem.

Prior Art

This has not been discussed previously, but passforios has been using gopenpgp for a while now with relative success outside one issue that was worked around easily.

Unresolved questions

Certainly a lot, a non-exhaustive list of high level concerns is as follows

• What will the UI look like?
• How does this fit into the onboarding process?
• What subset of OpenKeychain functionality do we offer?

[fmeum]

The OpenKeychain developers are thinking of making the app a library, which would help with some of the issue we are experiencing.

We should also keep in mind that a great feature of OpenKeychain is the support for NFC tokens. In fact, this is the primary reason for my usage of APS and pass on general. While this could possibly be implemented along the Go backend, it would add work.

[msfjarvis]

The OpenKeychain developers are thinking of making the app a library, which would help with some of the issue we are experiencing.

Valodim from OpenKeychain messaged me expressing his intent around that idea in January of this year, and has been on radio silence since. I'm not very optimistic of their timeline.

We should also keep in mind that a great feature of OpenKeychain is the support for NFC tokens. In fact, this is the primary reason for my usage of APS and pass on general. While this could possibly be implemented along the Go backend, it would add work.

I find the effort to outcome tradeoff worthwhile even with the addition of NFC token support.

I'm not starting work immediately, so if you can convince me that OpenKeychain has a concrete plan other than "We wanna do this" I will gladly forego the RFC and be glad of dodging a bullet.

[fmeum]

I'll see whether I can get an update on the OpenKeychain library timeline.

If it comes to it, I might be able to contribute NFC support as I have worked with the OpenPGP applet before.

[daraul]

I like the removal of the dependency, makes setting up this application much simpler.

[msfjarvis]

Just a passing note, but building gopenpgp appears to be an extremely easy affair and thanks to their gomobile support, it generates an aar file with the native libraries and some Java glue code that we can use to interface with the high-level public API.

We can wire this into our own build system and introduce a build-time Golang dependency on everyone, or script up the deployment of new gopenpgp versions to Maven Central which we can then consume via a Gradle dependency.

Either way, the first step towards getting this going is looking to be easier than I previously anticipated.

[CodedCraft]

This sounds promising! What other steps need to be taken? I will gladly help in any way I can.