[BUG] please add a reason for this fork

[532910]

Describe the bug

Every time I come across a fork, I have just one question: what is the reason?

Title says: "Passkey Edition", but https://github.com/agrahn/Android-Password-Store also has a passkey support.

Steps to reproduce

nothing to reproduce

Expected behavior

clean explanation

Screenshots

No response

Device information

• Device: [e.g. Google Pixel 2]
• OS: [e.g. Android R]
• App version: [e.g. 1.13.5]

Additional context

No response

[pando85]

Fair question. I agree that the reason for this fork should be documented more clearly in the README.

The short version is: this fork was not originally my preferred solution. I first tried to add passkey support to the actively maintained Android Password Store fork rather than maintain another fork.

The history is roughly:

• I first proposed passkey/FIDO2 support in "[FEATURE] Passkeys/FIDO2 support agrahn/Android-Password-Store#629" ([FEATURE] Passkeys/FIDO2 support agrahn/Android-Password-Store#629).
• I then implemented it and opened "PR Passkeys Support agrahn/Android-Password-Store#775 — Passkeys Support" (Passkeys Support agrahn/Android-Password-Store#775). The goal from the beginning was interoperability with "passless" (https://github.com/pando85/passless), so the same passkey stored in a Git/OpenPGP-backed "pass" repository could be used from Linux and Android.
• The maintainer initially welcomed the contribution and reviewed parts of it. I addressed the review comments and CI failures, and by the end of March the CI was green. On May 30 I explicitly asked whether there was anything else blocking the merge and offered to work on it, but did not receive another response in the PR.
• I eventually continued the work in this fork and closed the old PR from my side once the branches had diverged.
• Later, Android Password Store implemented its own passkey support in "PR Passkey support agrahn/Android-Password-Store#960" (Passkey support agrahn/Android-Password-Store#960), using a different storage design.

There was unfortunately also some friction around that process. When explaining why he implemented it separately, the maintainer described my contribution as "mainly, if not totally, vibe-coded", called it bloated, asked "Did the author ever use the app in production?", and later described this project publicly as "non-functional, insecure AI-slop" while speculating that it might exist to promote Passless:

• "discussion in PR Passkey support agrahn/Android-Password-Store#960" (Passkey support agrahn/Android-Password-Store#960 (comment))
• "later comment in issue [BUG] Passkey format seems not interoperable with desktop application (passless) agrahn/Android-Password-Store#996" ([BUG] Passkey format seems not interoperable with desktop application (passless) agrahn/Android-Password-Store#996 (comment))

I don't think those characterizations were particularly constructive, especially the speculation about motivation. That said, I also don't want to pretend that all of the technical criticism was wrong. The first implementation had real problems. For example, passkey encryption did not correctly honor hierarchical ".gpg-id" recipient policies, and the OpenPGP decryption path did not properly support protected/multiple keys. Those were valid findings, and they were subsequently treated as security issues and fixed:

• "security(passkeys): resolve encryption recipients from the nearest applicable .gpg-id #49 — resolve encryption recipients from the nearest ".gpg-id"" (security(passkeys): resolve encryption recipients from the nearest applicable .gpg-id #49)
• "security(passkeys): select the matching OpenPGP decryption key and support protected secret keys #7 — correctly select/unlock OpenPGP decryption keys" (security(passkeys): select the matching OpenPGP decryption key and support protected secret keys #7)

That is also my view of how this should work: finding serious problems in contributed code is useful and welcome; reviewing and fixing them is part of software development. Whether some of the code was written with the assistance of coding agents is much less important to me than whether the resulting code can be understood, tested, reviewed and maintained.

Why does this fork still exist now that both support passkeys?

The important difference today is not simply "this one has passkeys".

The design goal of this fork is cross-platform interoperability with Passless. Android and Linux are intended to share the same encrypted credential representation and the same Git-backed "pass" store, so a credential created on one platform can be used on the other.

The other APS implementation deliberately chose a different representation: it Base64URL-encodes its passkey representation as textual "pass" content. That is a perfectly reasonable design choice, but it is a different compatibility contract. The consequence was documented by a user in "agrahn#996" (agrahn#996): credentials created by APS 2.0 and Passless were not mutually interoperable. The maintainer's response makes clear that this difference is intentional and that he would prefer Passless to adopt the APS format instead.

I prefer the opposite direction: one shared passkey format across Passless, soft-fido2 and the Android provider, with both implementations evolving together and compatibility tested between them.

So I would describe the choice as:

• If you want Android Password Store with its own passkey implementation and its interpretation of traditional "pass" storage semantics, the agrahn fork is a valid choice.
• If you want Android to be part of the same Passless/passkey setup used on Linux, including bidirectional credential interoperability, that is the main reason this fork exists.

There are other implementation and security differences by now, but I think interoperability and independent development direction are the cleanest explanation for why maintaining the fork still makes sense.

And yes: this should be summarized in the README rather than requiring somebody to reconstruct the history from old issues and PRs. Thanks for raising it.

[pando85]

@forkline prepare a PR for clarifying this in a better way in the README. Don't go into much detail but explain it better. You can link this PR for a more detailed answer.

[forkline-bot]

PR created: #170

Added a concise "Why this fork?" section to the README explaining that the fork exists for cross-platform interoperability with passless — sharing the same encrypted credential format and Git-backed pass store between Android and Linux. Links to issue #169 for the full history.