[RFC] Stop depending on OpenKeychain
Closed this issue ยท 17 comments
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?
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.
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.
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.
I like the removal of the dependency, makes setting up this application much simpler.
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.
This sounds promising! What other steps need to be taken? I will gladly help in any way I can.
This sounds promising! What other steps need to be taken? I will gladly help in any way I can.
Once we have the build set up, the next steps will be to decide on what functionality from OpenKeychain we intend to support and build the UI for each of them. For a minimum viable version the ability to import one key and being able to encrypt/decrypt should be enough, then we'll move on to multiple keys, generating SSH keys from GPG keys, and NFC support for Yubikeys before this will be done. Lots to do :)
Also, this is a great opportunity to make sure APS will be able to support alternative backends, if the need arises in the future. My personal (somewhat radical) hope is that PGP will die as a standard sooner rather than later and get replaced with something more adequate for the modern world (e.g. something based on saltpack or age).
Also, this is a great opportunity to make sure APS will be able to support alternative backends, if the need arises in the future. My personal (somewhat radical) hope is that PGP will die as a standard sooner rather than later and get replaced with something more adequate for the modern world (e.g. something based on saltpack or age).
That is indeed the plan. I and @Skrilltrax sketched out a basic common API over this weekend to rebuild our internals off of and I fully intend to support age as a first-party backend.
Milestone: #1441 begins work on being able to decrypt passwords using Gopenpgp. This already works quite well, and we can roll it out to snapshot users once the necessary key management infrastructure around it is ready.
OpenKeychain has officially dropped the ball and gone into maintenance mode: open-keychain/open-keychain@6f38af1
I think there might be an additional issue that leads to Password Store + OpenKeychain not working at all anymore for me on a (fresh) Android 11 install due to a change when it comes to a permission: open-keychain/open-keychain#2701
I think there might be an additional issue that leads to Password Store + OpenKeychain not working at all anymore for me on a (fresh) Android 11 install due to a change when it comes to a permission: open-keychain/open-keychain#2701
The restrictions apply when apps target Android 11, which we do not.
Closing the issue as the RFC has been accepted for a while. I'll raise a separate issue tracking the implementation of this.
Having a question:
is it compatible If i use smart phone to maintain my master private key๏ผ
I mean now i generate a master key by openkeychain and automaticly create a subkey to be used to encrypt the password. I import the subkey to my mac for password manager.
The reason is:
- i don't want to import my private key to my computor's mac.
- with fingerprint and facial unlock tech i think smart phone is more safer than my mac.