Android-password-store: [RFC] Stop depending on OpenKeychain

Created on 7 Nov 2020  路  4Comments  路  Source: android-password-store/Android-Password-Store

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. Golang's crypto APIs are maintained by Filippo Valsorda who is a very respected name in the field of cryptography, 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?
A-PGP C-rfc C-technical-debt E-hard P-medium

Most helpful comment

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

All 4 comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

msfjarvis picture msfjarvis  路  3Comments

cole-h picture cole-h  路  4Comments

Shiroukoji picture Shiroukoji  路  4Comments

crosser picture crosser  路  5Comments

532910 picture 532910  路  4Comments