Tracking issue for RFC 1195: Migrate away from OpenKeychain

[msfjarvis]

This is the tracking issue for the implementation of RFC #1195

Steps

• Introduce alternate PGP backend based on Gopenpgp (Add initial implementation of Gopenpgp-backed PGP #1441)
• Replace Gopenpgp with PGPainless (Switch new PGP backend to use PGPainless #1522)
• Implement a key management interface
  • Allow listing keys by type (public/private)
  • Allow deleting keys
• Implement key import step in onboarding to allow users to pick a key to initialize repositories with
• Implement passphrase caching (ref OpenKeychain)
• Offer a migration path to OpenKeychain users to import keys exported from OpenKeychain into APS
• Remove OpenKeychain support completely

Unresolved questions

• How will we handle migration? Do we attempt to automate this in any fashion or simply write documentation for users to follow? We will not
• What constitutes feature parity?
• Do we release another major version when we drop OpenKeychain? We're dropping it straight away

[daraul]

Do we release another major version when we drop OpenKeychain?

I would say yes. This is a fairly major change.

How will we handle migration? Do we attempt to automate this in any fashion or simply write documentation for users to follow?

I would prefer the migration be automatic, but concise documentation on the process would be welcome either way.

[msfjarvis]

Do we release another major version when we drop OpenKeychain?

I would say yes. This is a fairly major change.

Agreed.

How will we handle migration? Do we attempt to automate this in any fashion or simply write documentation for users to follow?

I would prefer the migration be automatic, but concise documentation on the process would be welcome either way.

I haven't thought a lot about how this migration would happen, considering the fact that OpenKeychain encrypts the exported keys but I do think it'd be nice to be able to handle it on-device. Will have to investigate this down the line.

[msfjarvis]

Passing note, we definitely wanna do passphrase caching. Doing it securely might be a challenge but dear god users will chew me out if I make them enter their passphrase every single time.

[malte-v]

I assume support for hardware OpenPGP keys needs to be implemented by us, then? It looks like PGPainless doesn't support this kind of functionality.

[msfjarvis]

I assume support for hardware OpenPGP keys needs to be implemented by us, then? It looks like PGPainless doesn't support this kind of functionality.

That is correct.

[Myridium]

Thanks all for your work. I rely on this application.

[msfjarvis]

Status update

• PGPainless backend now supports importing keys
• Decryption now takes the password from the user rather than hard-code it into the app
• You can opt into the PGPainless backend through a settings option

Next steps

• Make encrypt/decrypt use the key from .gpg-id instead of attempting all keys
• Reimplement error handling to surface them to the UI rather than crash the app

[malte-v]

For hardware security key support, I think this might be of use: https://github.com/cotechde/hwsecurity
It's GPL3 licensed, pure Java and thoroughly documented at https://hwsecurity.dev/.

[msfjarvis]

For hardware security key support, I think this might be of use: cotechde/hwsecurity It's GPL3 licensed, pure Java and thoroughly documented at hwsecurity.dev.

We're aware of the Cotech SDK, but we don't have plans to use their OpenPGP library as of now. So far, I can't even get their official sample app to generate an OpenPGP key onto my test Yubikey so it's fairly certain that a lot of pain is headed my way when it eventually comes time to support security keys with the PGPainless backend.

[msfjarvis]

Error handling rework has landed in #1672, incorrect passwords will now pop up the password dialog once more with indication that the previously entered password was incorrect. Work on respecting the values from .gpg-id has also begun, with the refactor in #1669 paving the way for more accurately mimicking the OpenKeychain behavior w.r.t. key selection.

[daiaji]

Sometimes I have to wait a while to view my saved passwords and they don't show up right away, is this because OpenKeychain performs badly?

[msfjarvis]

Sometimes I have to wait a while to view my saved passwords and they don't show up right away, is this because OpenKeychain performs badly?

Not strictly OpenKeychain's performance, but the transport mechanism it uses to talk to apps. Android's Binder IPC is typically rather constrained and can often be very slow.

[moppman]

Status update

• PGPainless backend now supports importing keys
• ...

I just installed the most recent snapshot version and tried to import a pgp secret key.
I'm getting a (generic?) error message saying "error on pgp key import for input string "<my_key_id>"".

[msfjarvis]

Status update

• PGPainless backend now supports importing keys
• ...

I just installed the most recent snapshot version and tried to import a pgp secret key. I'm getting a (generic?) error message saying "error on pgp key import for input string "<my_key_id>"".

That's expected, the diagnostics are not in great shape at the moment. If you can provide clear reproduction steps from creating a new key on your PC to the import failing in APS I can try to replicate and debug it.

[moppman]

Status update

• PGPainless backend now supports importing keys
• ...

I just installed the most recent snapshot version and tried to import a pgp secret key. I'm getting a (generic?) error message saying "error on pgp key import for input string "<my_key_id>"".

That's expected, the diagnostics are not in great shape at the moment. If you can provide clear reproduction steps from creating a new key on your PC to the import failing in APS I can try to replicate and debug it.

Sure. Note that I tried to import my "regular" key, i.e. I didn't create a new one.

1. gpg --export-secret-keys --output sec.pgp --armor my@email.com
2. Transfer sec.pgp to phone
3. Import sec.pgp via pgp settings in APS

The key is a password-protected RSA2048 key with two user IDs. The import error is the same for armored and non-armored keys.

[msfjarvis]

Reproduced the issue.

[msfjarvis]

Import failure is fixed in snapshot builds with #1741

[msfjarvis]

pgpainless/pgpainless#261 should help with improving how errors are surfaced to users

[msfjarvis]

Work on .gpg-id support is stalled at the moment, I ran into a couple issues that I didn't have enough time and motivation to fix. Will try and pick it back up again.

In the mean time I ended up doing a modernization pass on the cotech hwsecurity SDK since the GPL version seems all but abandoned. The changes are up in our fork. I'm not going to do anything else with it anytime soon, but if someone wants to work on supporting hardware security keys in APS then they should use that fork.

[msfjarvis]

.gpg-id support has been implemented in #2080

[blabno]

What's the status? Which branch is this features being worked on?

[msfjarvis]

What's the status? Which branch is this features being worked on?

The status is in the issue body. The work is being merged as it's being completed so the branch to track is develop, the default branch of this repo.

[msfjarvis]

8af09d5 guards crypto operations with a check that ensures there is at least one PGP key imported or offers up the key import flow. This fixes the dubious UX of asking for a password during decryption before throwing an unhelpful NoKeysProvided error.

[apprehensions]

Implement passphrase caching

I have imported my GPG key from OpenKeychain manually, and Password store keeps asking for my passphrase, in which it does not care about the passphrase and accepts anything anyway..

Edit: it seems that Password store requires a passphrase for the PGP key, even if it is empty. I have learned that having it be empty seems like a bad security practice, so i added one and my problem was fixed (alongside enabling passphrase caching.)

[msfjarvis]

Implement passphrase caching

I have imported my GPG key from OpenKeychain manually, and Password store keeps asking for my passphrase, in which it does not care about the passphrase and accepts anything anyway..

The prompt being shown is a known bug (#2836), I tried fixing it but it didn't quite work and I haven't had any time to dedicate to Password Store since.

[l3u]

Considering the newly emerged problems with GnuPG 2.4 and OpenKeychain (cf. open-keychain/open-keychain#2900 etc.): The porting away from OpenKeychain seems to be quite finished. Are there plans to release this soonish?

[msfjarvis]

Considering the newly emerged problems with GnuPG 2.4 and OpenKeychain (cf. open-keychain/open-keychain#2900 etc.): The porting away from OpenKeychain seems to be quite finished. Are there plans to release this soonish?

There are still plenty of open bugs and general UX issues with the app that I would like to address before a release.

Edit: FWIW, migrating away from OpenKeychain does not resolve the issues with AEAD which remains unsupported by PGPainless as well.

[mannp]

For an attempting new user like myself, some ux issues make the app annoying to use and I am still not onboard.

A shame, as there isn't really an alternative.

[l3u]

Edit: FWIW, migrating away from OpenKeychain does not resolve the issues with AEAD which remains unsupported by PGPainless as well.

Yeah, I know meanwhile ;-) But it can be shipped around by simply disabling AEAD (OCB) in the key itself, cf. https://wiki.archlinux.org/title/GnuPG#Disable_unsupported_AEAD_mechanism

I'm just using your outstanding pass Android frontend on a quasi-daily basis (also for OTP auth) and I wondered what's the plan for the new major release. However, thanks a lot for working on this!

[nicolidin]

Hi, is this version handles smart card (yubikey) for gpg ? if, no will it handles it ?

[msfjarvis]

Hi, is this version handles smart card (yubikey) for gpg ? if, no will it handles it ?

Support for hardware keys is a work in progress: #2170

[HamzaMateen]

@msfjarvis is there any plan on making the release any sooner to move away from the OpenKeychain ...? Thanks!

[msfjarvis]

@msfjarvis is there any plan on making the release any sooner to move away from the OpenKeychain ...? Thanks!

I can't answer the question in any capacity. My personal interest in the project is at an all time low, I have received next to no external contributions so there isn't someone else I can hand things off to, and the whole thing is a large mess which requires a motivated individual to weed through — which I no longer am.

For the foreseeable future the snapshot builds are the only thing close to a release this project will get, and I may choose to simply archive the repository and let a fork emerge naturally.

[HamzaMateen]

Ohh that's a very sad development. I wish I could be of some help in any capacity to sift tjrough the problems but that's simply not the case. I understand your position though. I hope someone comes along to save this very nice project from potential stall. I will try the builds till then.

Can only hope for the best. Thannks for the prompt response.

[l3u]

I really love this app and I have been using it ever since I learned it existed – I would be totally happy to see it being kept alive … no matter what the crypto backend is … sadly, I have no idea about Android coding, so I can't contribute anything :-(

[iavael]

@msfjarvis that's unfortunate to read, but anyway thank you for this project and for your hard work 🫡

[msfjarvis]

I have made the decision to archive the project for reasons outlined here.

This issue is being closed to ensure everyone subscribed to it is made aware of this change in the app's maintenance status.