overhaul multi-device recipients synchronization #54

arcxio · 2025-03-17T23:00:58Z

QOL update for multiple computers using the same password store.

recipients are additionally tracked in the password store and can be indexed in a git repository (resolves #50)

rekey is seamlessly integrated and is triggered automatically when recipients change

contrib/pa-rekey is repurposed to rotate identities with a better UX (resolves #53)

identity and recipients files are independently created

Apple's Secure Enclave and TPM support

arcxio · 2025-08-01T14:57:36Z

pa

 pw_add() {
    if yn "generate a password?"; then
-        pass=$(rand_chars "${PA_LENGTH:-50}" "${PA_PATTERN:-A-Za-z0-9-_}") ||
+        pass=$(rand_chars "${PA_LENGTH:-50}" "${PA_PATTERN:-A-Za-z0-9-_}")


enabling pipefail broke this because of SIGPIPE in rand_chars, and because there was no pipefail the errors weren't handled anyway, so it was a bug either way

arcxio · 2025-08-02T02:22:42Z

@biox hey jes I'm pretty satisfied with the changes in this PR at this point and I'm curious to see what you think and whether we should go through with it at all. it would be my largest contribution yet, with various tweaks here and there concerning git synchronization and key management, and I think it would greatly improve the experience of setup with multiple computers. I have already used this branch to transfer my actual store to the new PC, and it boiled down to: pa git remote add, pa git pull, pa git push on the new computer, then pa git pull and pa git push on the old computer, and finally pa git pull on the new computer again, and I was ready to go. each computer got its own identity, recipients synchronization and reencryption happened automatically. I'm not sure it gets simpler than this.

my main concern here is that rekeying depends on pipefail. without it pa overwrites all passwords with encrypted empty data if decryption fails, and it's expected to fail after cloning the store to a system without suitable identity. I couldn't come up with a better way to prevent it. I could assign the decrypted data to a variable, handle fails, then pass it to age for encryption through heredoc as with pa add, but it seems hacky and pipefail is a much more natural solution here. I don't consider pipefail usable until shellcheck supports it (#32), but it should be resolved soon after the new debian release which is expected to come out next week.

arcxio · 2025-08-02T02:29:44Z

pa


    glob "$command" 'g*' && {
-        git "$@"
+        git "$@" && change_keys


not strictly neccessary, but I figured it would be neat to have a consistent usable store after just one git operation. for example, it would allow to use pa-urn to archive the store after pa git pulling without an intermediate command just for rekeying, and the other change_keys is there for non-git synchronization

arcxio · 2025-08-02T02:31:35Z

pa

        # Assign this diff driver to all passwords.
-        printf '%s\n' '*.age diff=age' >.gitattributes
+        printf '%s\n' "*.age diff=age
+.gitattributes merge=union


so that repos initialized after the change wouldn't conflict on merge with repos initialized before it

arcxio · 2025-08-02T02:33:04Z

pa

-        git config user.name >/dev/null || git config user.name pa
-        git config user.email >/dev/null || git config user.email ""
+        git config user.email >/dev/null ||
+            git config user.email "${EMAIL:-$(id -u -n)@$(uname -n)}"


username@host would be more useful for git logs with multiple hosts

I found out that user.name is not required to git, it can be inferred from user.email

arcxio · 2025-08-02T02:34:50Z

pa

+            cp "$recipients_file" "$recipients_sync"
+
+            # Purge git repository to prevent leaks for unwanted recipients.
+            [ -d .git ] && find .git ! -name config -type f -exec rm -f {} +


justification: #50 (comment)

arcxio · 2025-08-02T02:48:33Z

contrib/pa-rekey

one use case that was handled better with pa-rekey that would be a bit more involved without it is changing the identity. by default, if you run pa-rekey it generates a new key pair and reencrypts all passwords for it, useful for example in case the identity is leaked. in my view integrating a contrib as part of automatic flow is a big win, and it's inconvenient to maintain two tools for key managament (particularly because of stuff like #53), so I would think about how to incorporate that use case into our new rekey logic as another issue

rewrote pa-rekey to reflect this

arcxio · 2025-08-10T18:01:38Z

contrib/pa-rekey

repurposed to only changing the identity, utilizing the added rekeying logic in pa

biox · 2025-09-15T21:35:41Z

@arcxio - sorry for the silence here, i've been watching your updates & waiting for a moment of stasis before diving into review (i'm moving houses rn and haven't had a lick of spare time recently). are you satisfied with the current state of this PR? if so, i'll give it a full review sometime in the next few days.

arcxio · 2025-09-16T02:07:49Z

@biox your review will be appreciated any time! there's no rush really, I'm still not sure this can be merged at least until dash will get a release with pipefail, and that won't happen earlier than the end of this year. it's just been my on and off side project, which got bloated over time as I looked for more things to improve with regards to key management.

that being said, the main bulk (change_recipients function) I'd say is pretty stable, it was extensively tested and I don't have any ideas on how to significantly improve upon it. as I mentioned it's been really useful for my own store and dramatically improved UX in my view, admittedly at substantial complexity cost - and I'm curious to see if you'd say I made worthwhile tradeoffs here.

I've just rebased on main and will try to abstain from refactoring attempts for now, it feels OK to me at the moment.

arcxio · 2025-09-16T02:31:10Z

README


  dependencies
    - age
    - age-keygen


technically age-keygen is optional now as it can be substituted with plugins below, but since it's expected to be delivered with age I don't think it matters (and it's always used as a default fallback)

biox · 2025-12-13T20:55:54Z

hi @arcxio! i'm finally done moving, so i should be able to commit more time to pa again. just wondering what status is here - ready for a review? or should i wait for the aforementioned dash release?

arcxio · 2025-12-14T06:18:46Z

just wondering what status is here - ready for a review? or should i wait for the aforementioned dash release?

hey @biox! it's ready. dash release already happened, so pipefail should be available just about everywhere now

arcxio requested a review from biox March 17, 2025 23:00

arcxio force-pushed the recipients_sync branch from c1ebb84 to 42d0bbe Compare March 18, 2025 01:15

arcxio marked this pull request as ready for review March 18, 2025 01:23

arcxio force-pushed the recipients_sync branch 2 times, most recently from 320b29b to 9737526 Compare April 16, 2025 05:02

arcxio force-pushed the recipients_sync branch 4 times, most recently from c3d1b5b to 8528801 Compare August 1, 2025 14:53

arcxio commented Aug 1, 2025

View reviewed changes

arcxio force-pushed the recipients_sync branch from 8528801 to f609dff Compare August 2, 2025 01:52

arcxio commented Aug 2, 2025

View reviewed changes

arcxio force-pushed the recipients_sync branch 5 times, most recently from 3ce4738 to ffdc1ce Compare August 7, 2025 02:36

arcxio commented Aug 10, 2025

View reviewed changes

contrib/pa-rekey

Copy link

Collaborator Author

arcxio Aug 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

repurposed to only changing the identity, utilizing the added rekeying logic in pa

arcxio force-pushed the recipients_sync branch 3 times, most recently from fae3f83 to 7d84b89 Compare August 11, 2025 06:30

arcxio marked this pull request as draft August 11, 2025 10:48

arcxio marked this pull request as ready for review August 11, 2025 11:20

arcxio force-pushed the recipients_sync branch 2 times, most recently from 55fef4e to a27defa Compare August 18, 2025 03:14

arcxio force-pushed the recipients_sync branch 6 times, most recently from b86c94a to af1e5c9 Compare August 21, 2025 09:51

arcxio force-pushed the recipients_sync branch 5 times, most recently from 6fc8408 to 8eb82ba Compare August 26, 2025 07:12

arcxio force-pushed the recipients_sync branch 7 times, most recently from 994c125 to b82999b Compare September 5, 2025 07:53

arcxio force-pushed the recipients_sync branch from 97d1c1a to 1d3bb0c Compare September 16, 2025 02:02

arcxio commented Sep 16, 2025

View reviewed changes

arcxio force-pushed the recipients_sync branch from 1d3bb0c to 168ea4d Compare September 17, 2025 08:20

arcxio force-pushed the recipients_sync branch from 168ea4d to 11ca949 Compare October 8, 2025 11:41

arcxio added 2 commits November 29, 2025 12:49

enable pipefail

65b6361

overhaul multi-device recipients synchronization

92f2c53

arcxio force-pushed the recipients_sync branch from 11ca949 to 92f2c53 Compare November 29, 2025 11:55

overhaul multi-device recipients synchronization #54

Are you sure you want to change the base?

overhaul multi-device recipients synchronization #54

Uh oh!

Conversation

arcxio commented Mar 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arcxio Aug 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

arcxio commented Aug 2, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

biox commented Sep 15, 2025

Uh oh!

arcxio commented Sep 16, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

biox commented Dec 13, 2025

Uh oh!

arcxio commented Dec 14, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

arcxio commented Mar 17, 2025 •

edited

Loading

arcxio Aug 1, 2025 •

edited

Loading