From sepass at modiot.com  Mon Jul  6 17:45:12 2026
From: sepass at modiot.com (SEPass)
Date: Mon, 06 Jul 2026 13:45:12 -0400
Subject: New iOS client that uses secure enclave
Message-ID: <8733xw57x3.fsf@modiot.com>


Hi All,

  After many years of using YubiKeys on desktops/laptops with
pass/password-store, we could never quite find the same security setup
and simplicity on our phones.

  Recently it sort of dawned on us that since the Apple secure enclave
gives the same "non-extractable" protection as a YubiKey does, we should
be able to use that instead. We couldn't find an app that already does
this, so we wrote one.

  Bit of a fiddly setup process (see
https://github.com/modiotlabs/sepass#using-the-app), but otherwise we're
finding it very useful.

  Would really appreciate any feedback on this that anyone might have,
especially potential vulnerabilities or weak approaches we are
taking. We are not full-time cryptography/security experts, so would
particularly like to see a hearty critique of how we've gone about this
from anyone who is. More info here:

  https://sepass.modiot.com

  https://github.com/modiotlabs/sepass

  

-- 
SEPass 
sepass at modiot.com
https://sepass.modiot.com


From password-store at city17.xyz  Mon Jul  6 21:46:32 2026
From: password-store at city17.xyz (jman)
Date: Mon, 06 Jul 2026 23:46:32 +0200
Subject: New iOS client that uses secure enclave
In-Reply-To: <8733xw57x3.fsf@modiot.com> (sepass@modiot.com's message of "Mon, 
 06 Jul 2026 13:45:12 -0400")
References: <8733xw57x3.fsf@modiot.com>
Message-ID: <874iib3i6f.fsf@nyarlathotep>

SEPass <sepass at modiot.com> writes:

>   Would really appreciate any feedback on this that anyone might have,
> especially potential vulnerabilities or weak approaches we are
> taking. We are not full-time cryptography/security experts, so would
> particularly like to see a hearty critique of how we've gone about this
> from anyone who is.

The first thing that jumps to the eye is that a large language model is listed as co-author of a
substantial part of the codebase with 2 commits for a total diff of +4.527 -9 lines of code. You
might want to clarify your use of the LLM.


From sepass at modiot.com  Tue Jul  7 12:06:13 2026
From: sepass at modiot.com (SEPass)
Date: Tue, 07 Jul 2026 08:06:13 -0400
Subject: New iOS client that uses secure enclave
In-Reply-To: <874iib3i6f.fsf@nyarlathotep> (jman's message of "Mon, 06 Jul
 2026 23:46:32 +0200")
References: <8733xw57x3.fsf@modiot.com> <874iib3i6f.fsf@nyarlathotep>
Message-ID: <87ik6r3sy2.fsf@modiot.com>

jman <password-store at city17.xyz> writes:

> SEPass <sepass at modiot.com> writes:
>
>>   Would really appreciate any feedback on this that anyone might have,
>> especially potential vulnerabilities or weak approaches we are
>> taking. We are not full-time cryptography/security experts, so would
>> particularly like to see a hearty critique of how we've gone about this
>> from anyone who is.
>
> The first thing that jumps to the eye is that a large language model is listed as co-author of a
> substantial part of the codebase with 2 commits for a total diff of +4.527 -9 lines of code. You
> might want to clarify your use of the LLM.


  Thanks jman, good point.

  On this effort, we used Claude (Opus 4.8) initially to talk over the
basic idea of using a device's secure enclave as a mechanism for storing
a GPG private key. Mostly trying to get a handle on the limitations of
P-256 keys (which Apple's SE supports).

  We also used it to help generate some screenshots and verbiage for the
App store submissions. It made short work of the screenshots, but
verbiage was cliched and sloppy, so we had to edit by hand anyway. 

  Commit logs are here:

    https://github.com/modiotlabs/sepass/commits/main/  

  Thanks again for any thoughts on this. 

-- 
SEPass 
sepass at modiot.com
(https://sepass.modiot.com)

From jens.troeger at light-speed.de  Mon Jul 13 03:15:15 2026
From: jens.troeger at light-speed.de (=?utf-8?Q?Jens_Tr=C3=B6ger?=)
Date: Mon, 13 Jul 2026 13:15:15 +1000
Subject: Export and import all store data
Message-ID: <C11F1EEE-4CDA-4ACD-92C5-53D12606BA90@light-speed.de>

Hi,

This is a follow-up to the continued ?There is no assurance this key belongs to the named user? issue I?m encountering with `pass`:

  https://lists.zx2c4.com/pipermail/password-store/2026-April/004974.html 
  https://marc.info/?l=gnupg-users&m=157167920418502 

Would it make sense to have an export/import option, where I can export all or a subset of the password store files into a single cleartext file; and an import option to read that same file and create/update an existing store from its content?

The purpose is to handle situations like mine: create a ?backup? of the existing broken store, and replay it for a new store.

Much thanks,
Jens