Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#903163: ITP: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard
73 views
Skip to first unread message
Chris Lamb
Jul 7, 2018, 7:10:02 AM7/7/18
to
Package: wnpp
Severity: wishlist
Owner: la...@debian.org
X-Debbugs-CC: debian...@lists.debian.org
* Package name : gpg-encrypted-root
Version : 0~20170708+git980a0488-1
Upstream Author : Erik Nellessen <erikne...@gmx.de>
* URL : https://github.com/eriknellessen/gpg-encrypted-root
Programming Lang: Shell
Description : Encrypt root volumes with an OpenPGP smartcard
This package adds support for encrypted root volumes installing a LUKS
"password" that is unlocked by an OpenPGP smartcard.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
Severity: wishlist
Owner: la...@debian.org
X-Debbugs-CC: debian...@lists.debian.org
* Package name : gpg-encrypted-root
Version : 0~20170708+git980a0488-1
Upstream Author : Erik Nellessen <erikne...@gmx.de>
* URL : https://github.com/eriknellessen/gpg-encrypted-root
Programming Lang: Shell
Description : Encrypt root volumes with an OpenPGP smartcard
This package adds support for encrypted root volumes installing a LUKS
"password" that is unlocked by an OpenPGP smartcard.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
Guilhem Moulin
Jul 7, 2018, 11:20:02 AM7/7/18
to
Hi Chris,
On Sat, 07 Jul 2018 at 12:05:13 +0100, Chris Lamb wrote:
> Programming Lang: Shell
> Description : Encrypt root volumes with an OpenPGP smartcard
Since it's just a standalone shell script it might make sense to ship it
with ‘cryptsetup-initramfs’ instead :-) See also #888916 (we didn't
find time to review Rian's code yet, though).
Also that hook is making assumption about our own hook's internals, and
as such is not compatible with cryptsetup-initramfs ≥2:2.0.3-2. (FWIW
Rian's hook has the same problem.) Unfortunately, until last month and
#901795 nobody asked us to publish an interface to be used by 3rd-party
hook files. (And 3rd-party hooks using our previous — internal —
interface are most likely all broken right now.)
Cheers,
--
Guilhem.
On Sat, 07 Jul 2018 at 12:05:13 +0100, Chris Lamb wrote:
> Programming Lang: Shell
> Description : Encrypt root volumes with an OpenPGP smartcard
with ‘cryptsetup-initramfs’ instead :-) See also #888916 (we didn't
find time to review Rian's code yet, though).
Also that hook is making assumption about our own hook's internals, and
as such is not compatible with cryptsetup-initramfs ≥2:2.0.3-2. (FWIW
Rian's hook has the same problem.) Unfortunately, until last month and
#901795 nobody asked us to publish an interface to be used by 3rd-party
hook files. (And 3rd-party hooks using our previous — internal —
interface are most likely all broken right now.)
Cheers,
--
Guilhem.
Guilhem Moulin
Jul 7, 2018, 11:30:03 AM7/7/18
to
On Sat, 07 Jul 2018 at 17:08:59 +0200, Guilhem Moulin wrote:
> (And 3rd-party hooks using our previous — internal — interface are
> most likely all broken right now.)
I mean the ones trying to read and parse our internal cryptroot
> (And 3rd-party hooks using our previous — internal — interface are
> most likely all broken right now.)
configuration file (the crypttab(5)-like file stored in the initramfs).
--
Guilhem.
Chris Lamb
Jul 9, 2018, 3:50:03 AM7/9/18
to
Hi,
> ITP: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard
FYI clarifying the copyright situation here:
https://github.com/eriknellessen/gpg-encrypted-root/issues/1
> ITP: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard
FYI clarifying the copyright situation here:
https://github.com/eriknellessen/gpg-encrypted-root/issues/1
Kyle Rankin
Jul 9, 2018, 1:30:04 PM7/9/18
to
Given it is just a shell script, I would vote for incorporating OpenPGP
smartcard support directly into cryptsetup-initramfs so it's available for
users who want encrypted storage without having to know about a standalone
package.
-Kyle
smartcard support directly into cryptsetup-initramfs so it's available for
users who want encrypted storage without having to know about a standalone
package.
-Kyle
Guilhem Moulin
Jul 9, 2018, 2:10:04 PM7/9/18
to
case we shouldn't ship multiple hooks providing essentially the same
functionalities (#888916, #903163). I have a Gnuk Token so I should be
able to test and maintain this :-)
In general, rather than using our internal interface, authors of third
party hooks should either 1/ ask us to document and publish the bits
they need, or 2/ convince us to incorporate their hook & script into
cryptsetup-initramfs, effectively making us maintainers.
Back to https://github.com/eriknellessen/gpg-encrypted-root, I see the
hook is copying private key material to the initramfs, but /initrd.img
is just a cpio archive which is created with mode 0644 minus umask… so
without additional protection in place [0] (which the README doesn't
mention) any local user can read the (hopefully symmetrically encrypted)
private key material! It's not clear to me why they need the private
key files, but at the very least a loud warning should be shown if the
umask is too permissive.
--
Guilhem.
[0] For instance setting UMASK=0077 in /etc/initramfs-tools/initramfs.conf.
Chris Lamb
Jul 16, 2018, 5:20:03 AM7/16/18
to
Dear Guilhem,
> hook is copying private key material to the initramfs, but […]
My gut tells me we should incoropate OpenPGP support directly into
Debian's src:cryptsetup simply based on ensuring its on-going
maintainability, etc. Especially important given that, for example,
an API change or other breakage might result in an unbootable system.
Does that work for you in principle Guilhem? I'm assuming we can
"just" merge in the aforementioned package (!) and fix up some of the
issues, including the umask one you already outlined.
What would be the next steps here? :)
Best wishes,
> hook is copying private key material to the initramfs, but […]
My gut tells me we should incoropate OpenPGP support directly into
Debian's src:cryptsetup simply based on ensuring its on-going
maintainability, etc. Especially important given that, for example,
an API change or other breakage might result in an unbootable system.
Does that work for you in principle Guilhem? I'm assuming we can
"just" merge in the aforementioned package (!) and fix up some of the
issues, including the umask one you already outlined.
What would be the next steps here? :)
Best wishes,
Guilhem Moulin
Jul 16, 2018, 1:40:03 PM7/16/18
to
Hi Chris,
On Mon, 16 Jul 2018 at 10:15:47 +0100, Chris Lamb wrote:
>> Back to https://github.com/eriknellessen/gpg-encrypted-root, I see the
>> hook is copying private key material to the initramfs, but […]
>
> My gut tells me we should incoropate OpenPGP support directly into
I assume you mean OpenPGP *smartcard* here: symmetric OpenPGP encryption
is supported 2:1.0.3-3 released 12 years ago (and that's the hook and
boot scripts which Peter then Erik forked) :-)
> Does that work for you in principle Guilhem? I'm assuming we can
> "just" merge in the aforementioned package (!) and fix up some of the
> issues, including the umask one you already outlined.
>
> What would be the next steps here? :)
I'm in favor of adding OpenPGP smartcard support to src:cryptsetup, but
not more that one set of hook & boot scripts.
Since there is already #888916 open requesting merging of some initramfs
scripts providing OpenPGP smartcard support, and 888916 < 903163, it'd
polite of us cryptsetup package maintainers to review Rian's code as
well before including anything.
We've been quite busy lately with the massive refactoring and the couple
of regressions that followed, but I hope to take a closer look at both
proposals during DebCamp next week. Naturally, help is welcome :-)
I'm not sure it's worth shipping another “Architecture: all” binary
package to src:cryptsetup, though (as opposed to including the keyscript
to cryptsetup-run and the initramfs bits to cryptsetup-initramfs, like
we're doing for decrypt_gnupg, decrypt_keyctl, decrypt_opensc, etc.).
Sure, splitting cryptsetup-run and cryptsetup-initramfs further means we
can assign more fine-grained dependencies, but in the end it'll just be
a tiny shell script in each package, so is it worth the effort? Also
`update-initramfs -u` will complain if the required binaries (pcsd, gpg,
etc.) cannot be copied; and the user has to install these to be able to
set up the mapping in the first place.
(If we add another “Architecture: all” binary package we should also
split cryptsetup-run and cryptsetup-initramfs for the sake of
consistency. Not sure it's worth the effort, but now-ish would be a
good time to do this since we've already split cryptsetup-initramfs
away. I personally don't have strong feelings either way; CC'ing Jonas
who might have a different opinion.)
Cheers,
--
Guilhem.
On Mon, 16 Jul 2018 at 10:15:47 +0100, Chris Lamb wrote:
>> Back to https://github.com/eriknellessen/gpg-encrypted-root, I see the
>> hook is copying private key material to the initramfs, but […]
>
> My gut tells me we should incoropate OpenPGP support directly into
is supported 2:1.0.3-3 released 12 years ago (and that's the hook and
boot scripts which Peter then Erik forked) :-)
> Does that work for you in principle Guilhem? I'm assuming we can
> "just" merge in the aforementioned package (!) and fix up some of the
> issues, including the umask one you already outlined.
>
> What would be the next steps here? :)
not more that one set of hook & boot scripts.
Since there is already #888916 open requesting merging of some initramfs
scripts providing OpenPGP smartcard support, and 888916 < 903163, it'd
polite of us cryptsetup package maintainers to review Rian's code as
well before including anything.
We've been quite busy lately with the massive refactoring and the couple
of regressions that followed, but I hope to take a closer look at both
proposals during DebCamp next week. Naturally, help is welcome :-)
I'm not sure it's worth shipping another “Architecture: all” binary
package to src:cryptsetup, though (as opposed to including the keyscript
to cryptsetup-run and the initramfs bits to cryptsetup-initramfs, like
we're doing for decrypt_gnupg, decrypt_keyctl, decrypt_opensc, etc.).
Sure, splitting cryptsetup-run and cryptsetup-initramfs further means we
can assign more fine-grained dependencies, but in the end it'll just be
a tiny shell script in each package, so is it worth the effort? Also
`update-initramfs -u` will complain if the required binaries (pcsd, gpg,
etc.) cannot be copied; and the user has to install these to be able to
set up the mapping in the first place.
(If we add another “Architecture: all” binary package we should also
split cryptsetup-run and cryptsetup-initramfs for the sake of
consistency. Not sure it's worth the effort, but now-ish would be a
good time to do this since we've already split cryptsetup-initramfs
away. I personally don't have strong feelings either way; CC'ing Jonas
who might have a different opinion.)
Cheers,
--
Guilhem.
Chris Lamb
Jul 16, 2018, 1:50:02 PM7/16/18
to
Dear Guilhem,
> > My gut tells me we should incoropate OpenPGP support directly into
>
> I assume you mean OpenPGP *smartcard* here
Yes, mea culpa; wasn't paying attention! :)
> Since there is already #888916 open requesting merging of some initramfs
> scripts providing OpenPGP smartcard support, and 888916 < 903163, it'd
> polite of us cryptsetup package maintainers to review Rian's code as
> well before including anything.
Of course and I totally agree with this and your following paragraphs.
So, whilst I will be at DebCamp too (yay) I unfortunately won't have
any hardware to test with and for various reasons I should keep
commitments low at this point.
(Can we get something into shape on a branch for Kyle to test, or are
the bug references you cite above enough?)
> > My gut tells me we should incoropate OpenPGP support directly into
>
> I assume you mean OpenPGP *smartcard* here
> Since there is already #888916 open requesting merging of some initramfs
> scripts providing OpenPGP smartcard support, and 888916 < 903163, it'd
> polite of us cryptsetup package maintainers to review Rian's code as
> well before including anything.
So, whilst I will be at DebCamp too (yay) I unfortunately won't have
any hardware to test with and for various reasons I should keep
commitments low at this point.
(Can we get something into shape on a branch for Kyle to test, or are
the bug references you cite above enough?)
Guilhem Moulin
Jul 16, 2018, 2:20:03 PM7/16/18
to
On Mon, 16 Jul 2018 at 18:39:59 +0100, Chris Lamb wrote:
> So, whilst I will be at DebCamp too (yay) I unfortunately won't have
> any hardware to test with and for various reasons I should keep
> commitments low at this point.
Sure thing! I was planning to do some triaging anyway :-) (#888916 has
> So, whilst I will be at DebCamp too (yay) I unfortunately won't have
> any hardware to test with and for various reasons I should keep
> commitments low at this point.
been open for a while already and it's unfortunate that we didn't find
time to provide any follow-up yet.)
> (Can we get something into shape on a branch for Kyle to test, or are
> the bug references you cite above enough?)
link to the respective repositories, but hopefully we'll have something
after DebCamp. I'll poke you once this is the case! :-)
--
Guilhem.
Chris Lamb
Jul 23, 2018, 8:50:03 AM7/23/18
to
Hi Jonas et al.,
> I don't think that adding a new binary package for OpenPGP smartcard
> support is a good idea and would oppose to it
Might smartcard support require some smartcard-specific packaged
dependencies that would
be solved somewhat elegantly by having a separate binary package?
(Just to clarify, do you mean a new binary package as part of
src:cryptsetup or a new binary package as part of some other
hypothetical source package?)
Best wishes,
> I don't think that adding a new binary package for OpenPGP smartcard
> support is a good idea and would oppose to it
Might smartcard support require some smartcard-specific packaged
dependencies that would
be solved somewhat elegantly by having a separate binary package?
(Just to clarify, do you mean a new binary package as part of
src:cryptsetup or a new binary package as part of some other
hypothetical source package?)
Best wishes,
Guilhem Moulin
Jul 29, 2018, 4:30:03 PM7/29/18
to
Hi,
On Sat, 07 Jul 2018 at 17:08:59 +0200, Guilhem Moulin wrote:
(It's directed at upstream but since I don't use GitHub I'm commenting
here instead :-P I wouldn't mind maintaining this in src:cryptsetup as
I wrote earlier.) The two approaches are quite similar and my
(hopefully constructive) criticism mostly applies to both. While IMHO
neither can be merged in as is, there are good ideas from both so I'm
sure together we can find a solution that fits all needs :-)
cryptgnupg_sc:
* Since the recent refactoring in 2:2.0.3-2, the ‘cryptgnupg_sc’ hook
file changed drastically [0]. 2:2.0.3-2 wasn't released yet when the
hook file was written, but now ‘cryptgnupg_sc’ needs to be modified
accordingly :-P
* Copying not only the (encrypted) key file and the public keyring,
but also the private-keys-v1.d directory, sounds very odd to me.
What is the rationale for doing so? AFAICT the whole point of the
smartcard solution is avoid exposing private key material to the
initramfs image. I'd suggest to hardcode
/etc/cryptsetup-initramfs/pubring.gpg instead (or
/etc/cryptsetup-initramfs/gnupghome/…).
* We don't want to copy_exec() .so that are explicitly versioned, as the
likelyhood of breaking things is high. See
https://salsa.debian.org/cryptsetup-team/cryptsetup/blob/master/debian/initramfs/hooks/cryptopensc#L49
for an alternative solution.
decrypt_gnupg_sc:
* How common are the cards requiring pcscd(8) that don't work with the
existing ‘decrypt_opensc’ keyscript but do work with the
‘decrypt_gnupg_sc’ keyscript?
Cheers,
--
Guilhem.
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888916#10
On Sat, 07 Jul 2018 at 17:08:59 +0200, Guilhem Moulin wrote:
> On Sat, 07 Jul 2018 at 12:05:13 +0100, Chris Lamb wrote:
>> Programming Lang: Shell
>> Description : Encrypt root volumes with an OpenPGP smartcard
>
>> Programming Lang: Shell
>> Description : Encrypt root volumes with an OpenPGP smartcard
>
> See also #888916 (we didn't find time to review Rian's code yet,
> though).
I did that now [0], and here is a review of Erik's and Peter's approach.
> though).
(It's directed at upstream but since I don't use GitHub I'm commenting
here instead :-P I wouldn't mind maintaining this in src:cryptsetup as
I wrote earlier.) The two approaches are quite similar and my
(hopefully constructive) criticism mostly applies to both. While IMHO
neither can be merged in as is, there are good ideas from both so I'm
sure together we can find a solution that fits all needs :-)
cryptgnupg_sc:
* Since the recent refactoring in 2:2.0.3-2, the ‘cryptgnupg_sc’ hook
file changed drastically [0]. 2:2.0.3-2 wasn't released yet when the
hook file was written, but now ‘cryptgnupg_sc’ needs to be modified
accordingly :-P
* Copying not only the (encrypted) key file and the public keyring,
but also the private-keys-v1.d directory, sounds very odd to me.
What is the rationale for doing so? AFAICT the whole point of the
smartcard solution is avoid exposing private key material to the
initramfs image. I'd suggest to hardcode
/etc/cryptsetup-initramfs/pubring.gpg instead (or
/etc/cryptsetup-initramfs/gnupghome/…).
* We don't want to copy_exec() .so that are explicitly versioned, as the
likelyhood of breaking things is high. See
https://salsa.debian.org/cryptsetup-team/cryptsetup/blob/master/debian/initramfs/hooks/cryptopensc#L49
for an alternative solution.
decrypt_gnupg_sc:
* How common are the cards requiring pcscd(8) that don't work with the
existing ‘decrypt_opensc’ keyscript but do work with the
‘decrypt_gnupg_sc’ keyscript?
Cheers,
--
Guilhem.
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888916#10
Peter Lebbing
Aug 1, 2018, 12:10:02 PM8/1/18
to
Hi Guilhem and others,
On Mon, 30 Jul 2018 04:16:23 +0800 Guilhem Moulin <gui...@debian.org>
wrote:
the smartcard stubs for the OpenPGP card are created (per README.md[1]).
This separate GnuPG homedir, specifically meant just for the unlocking
of the LUKS container, is then copied to the initramfs. If this were not
done, you'd have to do "gpg --card-status" in your initramfs to create
these stubs everytime you boot, before decryption. It'd get awkward if
you forgot to insert your smartcard, because adding --card-status makes
it a two-step process: first --card-status, second --decrypt. Right now,
if you forgot to insert your smartcard, the --decrypt would fail and be
retried. The failure would prompt you to insert your smartcard.
It's not copying your normal GnuPG private-keys-v1.d to initramfs,
that'd be not so clever. Still, in the interest of clarity, it warns the
user that if they dumped sensitive information in /etc/keys, they might
want to reconsider.
> decrypt_gnupg_sc:
> * How common are the cards requiring pcscd(8) that don't work with the
> existing ‘decrypt_opensc’ keyscript but do work with the
> ‘decrypt_gnupg_sc’ keyscript?
It's more tied to the reader rather than the card. My own smartcard
reader works great with the internal CCID driver of GnuPG, and my
version of this script does not have pcscd. Erik Nellessen apparently
has a smartcard reader that is not supported by GnuPG, but the card in
it is still an OpenPGP smartcard, AFAIK. I'm glad I have a
GnuPG-supported reader myself, it makes it all a lot smoother.
HTH,
Peter.
[1]
<https://github.com/eriknellessen/gpg-encrypted-root/blob/master/README.md>
--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
On Mon, 30 Jul 2018 04:16:23 +0800 Guilhem Moulin <gui...@debian.org>
wrote:
> * Copying not only the (encrypted) key file and the public keyring,
> but also the private-keys-v1.d directory, sounds very odd to me.
> What is the rationale for doing so?
First, a new GnuPG --homedir /etc/keys is created, and in that homedir,
> but also the private-keys-v1.d directory, sounds very odd to me.
> What is the rationale for doing so?
the smartcard stubs for the OpenPGP card are created (per README.md[1]).
This separate GnuPG homedir, specifically meant just for the unlocking
of the LUKS container, is then copied to the initramfs. If this were not
done, you'd have to do "gpg --card-status" in your initramfs to create
these stubs everytime you boot, before decryption. It'd get awkward if
you forgot to insert your smartcard, because adding --card-status makes
it a two-step process: first --card-status, second --decrypt. Right now,
if you forgot to insert your smartcard, the --decrypt would fail and be
retried. The failure would prompt you to insert your smartcard.
It's not copying your normal GnuPG private-keys-v1.d to initramfs,
that'd be not so clever. Still, in the interest of clarity, it warns the
user that if they dumped sensitive information in /etc/keys, they might
want to reconsider.
> decrypt_gnupg_sc:
> * How common are the cards requiring pcscd(8) that don't work with the
> existing ‘decrypt_opensc’ keyscript but do work with the
> ‘decrypt_gnupg_sc’ keyscript?
reader works great with the internal CCID driver of GnuPG, and my
version of this script does not have pcscd. Erik Nellessen apparently
has a smartcard reader that is not supported by GnuPG, but the card in
it is still an OpenPGP smartcard, AFAIK. I'm glad I have a
GnuPG-supported reader myself, it makes it all a lot smoother.
HTH,
Peter.
[1]
<https://github.com/eriknellessen/gpg-encrypted-root/blob/master/README.md>
--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
Peter Lebbing
Aug 1, 2018, 1:10:03 PM8/1/18
to
By the way, I think it would be much cooler if GnuPG used
pinentry-curses or pinentry-tty, rather than the current
/lib/cryptsetup/askpass and --pinentry-mode loopback. That would also
gracefully ask for the smartcard to be inserted if it were forgotten or
the wrong one was inserted, and prompt the user multiple times when they
mistype their passphrase/PIN. I didn't look into this for stretch yet.
Peter.
pinentry-curses or pinentry-tty, rather than the current
/lib/cryptsetup/askpass and --pinentry-mode loopback. That would also
gracefully ask for the smartcard to be inserted if it were forgotten or
the wrong one was inserted, and prompt the user multiple times when they
mistype their passphrase/PIN. I didn't look into this for stretch yet.
Peter.
Chris Lamb
Sep 1, 2018, 7:00:02 AM9/1/18
to
Dear Guilhem et al.,
> > So, whilst I will be at DebCamp too (yay) I unfortunately won't have
> > any hardware to test with and for various reasons I should keep
> > commitments low at this point.
>
> Sure thing! I was planning to do some triaging anyway :-) (#888916 has
> been open for a while already and it's unfortunate that we didn't find
> time to provide any follow-up yet.)
Just wondering what the current status of this was? We (with Purism hat
on...) would love to get something we could start testing on, even if
it were on a branch etc. etc.
Best wishes,
> > So, whilst I will be at DebCamp too (yay) I unfortunately won't have
> > any hardware to test with and for various reasons I should keep
> > commitments low at this point.
>
> Sure thing! I was planning to do some triaging anyway :-) (#888916 has
> been open for a while already and it's unfortunate that we didn't find
> time to provide any follow-up yet.)
on...) would love to get something we could start testing on, even if
it were on a branch etc. etc.
Best wishes,
Guilhem Moulin
Sep 2, 2018, 11:00:03 AM9/2/18
to
Hi Chris,
On Sat, 01 Sep 2018 at 11:50:47 +0100, Chris Lamb wrote:
>>> So, whilst I will be at DebCamp too (yay) I unfortunately won't have
>>> any hardware to test with and for various reasons I should keep
>>> commitments low at this point.
>>
>> Sure thing! I was planning to do some triaging anyway :-) (#888916 has
>> been open for a while already and it's unfortunate that we didn't find
>> time to provide any follow-up yet.)
>
> Just wondering what the current status of this was? We (with Purism hat
> on...) would love to get something we could start testing on, even if
> it were on a branch etc. etc.
Sorry, I've been rather short on time lately; will try to take another
stab at this the week after next.
--
Guilhem.
On Sat, 01 Sep 2018 at 11:50:47 +0100, Chris Lamb wrote:
>>> So, whilst I will be at DebCamp too (yay) I unfortunately won't have
>>> any hardware to test with and for various reasons I should keep
>>> commitments low at this point.
>>
>> Sure thing! I was planning to do some triaging anyway :-) (#888916 has
>> been open for a while already and it's unfortunate that we didn't find
>> time to provide any follow-up yet.)
>
> Just wondering what the current status of this was? We (with Purism hat
> on...) would love to get something we could start testing on, even if
> it were on a branch etc. etc.
stab at this the week after next.
--
Guilhem.
Chris Lamb
Sep 14, 2018, 7:00:03 AM9/14/18
to
Hey Guilhem,
> Sorry, I've been rather short on time lately; will try to take another
> stab at this the week after next.
Sure thing. Do let me know whether it would help if you had specific
hardware or things like that; I can get them sent out you. (Even if it
would duplicate what you would already have.)
> Sorry, I've been rather short on time lately; will try to take another
> stab at this the week after next.
hardware or things like that; I can get them sent out you. (Even if it
would duplicate what you would already have.)
Chris Lamb
Sep 22, 2018, 4:30:03 AM9/22/18
to
Hey Guilhem,
> Sorry, I've been rather short on time lately; will try to take another
> stab at this the week after next.
No worries at all; how you getting on?
> Sorry, I've been rather short on time lately; will try to take another
> stab at this the week after next.
Guilhem Moulin
Sep 23, 2018, 12:10:03 AM9/23/18
to
Hi Chris,
On Fri, 14 Sep 2018 at 11:46:26 +0100, Chris Lamb wrote:
>> Sorry, I've been rather short on time lately; will try to take another
>> stab at this the week after next.
>
> Sure thing. Do let me know whether it would help if you had specific
> hardware or things like that; I can get them sent out you. (Even if it
> would duplicate what you would already have.)
Thanks for the offer! I don't think I *need* extra hardware, though: I
still have the GNUK token Niibe-san generously gave me some years ago,
and QEMU's USB device pass-through works like a charm :-)
Cheers,
--
Guilhem.
On Fri, 14 Sep 2018 at 11:46:26 +0100, Chris Lamb wrote:
>> Sorry, I've been rather short on time lately; will try to take another
>> stab at this the week after next.
>
> Sure thing. Do let me know whether it would help if you had specific
> hardware or things like that; I can get them sent out you. (Even if it
> would duplicate what you would already have.)
still have the GNUK token Niibe-san generously gave me some years ago,
and QEMU's USB device pass-through works like a charm :-)
Cheers,
--
Guilhem.
Guilhem Moulin
Sep 23, 2018, 12:10:03 AM9/23/18
to
On Wed, 01 Aug 2018 at 19:05:20 +0200, Peter Lebbing wrote:
> By the way, I think it would be much cooler if GnuPG used
> pinentry-curses or pinentry-tty, rather than the current
> /lib/cryptsetup/askpass and --pinentry-mode loopback. That would also
> gracefully ask for the smartcard to be inserted if it were forgotten or
> the wrong one was inserted, and prompt the user multiple times when they
> mistype their passphrase/PIN. I didn't look into this for stretch yet.
Agreed, and implemented :-)
> By the way, I think it would be much cooler if GnuPG used
> pinentry-curses or pinentry-tty, rather than the current
> /lib/cryptsetup/askpass and --pinentry-mode loopback. That would also
> gracefully ask for the smartcard to be inserted if it were forgotten or
> the wrong one was inserted, and prompt the user multiple times when they
> mistype their passphrase/PIN. I didn't look into this for stretch yet.
--
Guilhem.
Guilhem Moulin
Sep 23, 2018, 12:10:03 AM9/23/18
to
Hi Peter,
On Wed, 01 Aug 2018 at 17:51:43 +0200, Peter Lebbing wrote:
> On Mon, 30 Jul 2018 04:16:23 +0800 Guilhem Moulin <gui...@debian.org> wrote:
>> * Copying not only the (encrypted) key file and the public keyring,
>> but also the private-keys-v1.d directory, sounds very odd to me.
>> What is the rationale for doing so?
>
> First, a new GnuPG --homedir /etc/keys is created, and in that homedir,
> the smartcard stubs for the OpenPGP card are created (per README.md[1]).
> This separate GnuPG homedir, specifically meant just for the unlocking
> of the LUKS container, is then copied to the initramfs. If this were not
> done, you'd have to do "gpg --card-status" in your initramfs to create
> these stubs everytime you boot, before decryption. It'd get awkward if
> you forgot to insert your smartcard, because adding --card-status makes
> it a two-step process: first --card-status, second --decrypt. Right now,
> if you forgot to insert your smartcard, the --decrypt would fail and be
> retried. The failure would prompt you to insert your smartcard.
>
> It's not copying your normal GnuPG private-keys-v1.d to initramfs,
> that'd be not so clever. Still, in the interest of clarity, it warns the
> user that if they dumped sensitive information in /etc/keys, they might
> want to reconsider.
I see, thanks for the explanation. Still, I'm not fond of this because
it ties the code to gpg(1) implementation details, and if for some
reason someone uses that homedir to add generate an (on-disk) key, it'll
end up in the initramfs without apparent change on `update-initramfs -u`…
It's possible to copy only the stubs an not the real key material, but
the complexity is not worth it IMHO. We already have some logic in
place to wait until the source device is present, so we can as well wait
until the card is present. I pushed a branch to the Debian repo with a
shell loop; it might be cleaner to do it with gpg-connect-agent(1) (and
replace `gpg --card-status` with `gpg-connect-agent LEARN /bye`), but
I've not been able to that. (AFAICT its status code is always 0, and it
has way to echo text to a file descriptor other than stdout.)
>> decrypt_gnupg_sc:
>> * How common are the cards requiring pcscd(8) that don't work with the
>> existing ‘decrypt_opensc’ keyscript but do work with the
>> ‘decrypt_gnupg_sc’ keyscript?
>
> It's more tied to the reader rather than the card. My own smartcard
> reader works great with the internal CCID driver of GnuPG, and my
> version of this script does not have pcscd. Erik Nellessen apparently
> has a smartcard reader that is not supported by GnuPG, but the card in
> it is still an OpenPGP smartcard, AFAIK. I'm glad I have a
> GnuPG-supported reader myself, it makes it all a lot smoother.
OK. decrypt_* isn't the right place to start pcscd though, because we
want these scripts to work not only at initramfs stage, but also in the
main system. I left it out for now, but I'll later adapt cryptopensc's
local-{top,bottom} scripts to ensure pcscd is started at early boot
stage.
By the way, I also added a local-bottom script to kill gpg-agent and
scdaemon before execution is turned over to the init binary :-)
Cheers,
--
Guilhem.
On Wed, 01 Aug 2018 at 17:51:43 +0200, Peter Lebbing wrote:
> On Mon, 30 Jul 2018 04:16:23 +0800 Guilhem Moulin <gui...@debian.org> wrote:
>> * Copying not only the (encrypted) key file and the public keyring,
>> but also the private-keys-v1.d directory, sounds very odd to me.
>> What is the rationale for doing so?
>
> First, a new GnuPG --homedir /etc/keys is created, and in that homedir,
> the smartcard stubs for the OpenPGP card are created (per README.md[1]).
> This separate GnuPG homedir, specifically meant just for the unlocking
> of the LUKS container, is then copied to the initramfs. If this were not
> done, you'd have to do "gpg --card-status" in your initramfs to create
> these stubs everytime you boot, before decryption. It'd get awkward if
> you forgot to insert your smartcard, because adding --card-status makes
> it a two-step process: first --card-status, second --decrypt. Right now,
> if you forgot to insert your smartcard, the --decrypt would fail and be
> retried. The failure would prompt you to insert your smartcard.
>
> It's not copying your normal GnuPG private-keys-v1.d to initramfs,
> that'd be not so clever. Still, in the interest of clarity, it warns the
> user that if they dumped sensitive information in /etc/keys, they might
> want to reconsider.
it ties the code to gpg(1) implementation details, and if for some
reason someone uses that homedir to add generate an (on-disk) key, it'll
end up in the initramfs without apparent change on `update-initramfs -u`…
It's possible to copy only the stubs an not the real key material, but
the complexity is not worth it IMHO. We already have some logic in
place to wait until the source device is present, so we can as well wait
until the card is present. I pushed a branch to the Debian repo with a
shell loop; it might be cleaner to do it with gpg-connect-agent(1) (and
replace `gpg --card-status` with `gpg-connect-agent LEARN /bye`), but
I've not been able to that. (AFAICT its status code is always 0, and it
has way to echo text to a file descriptor other than stdout.)
>> decrypt_gnupg_sc:
>> * How common are the cards requiring pcscd(8) that don't work with the
>> existing ‘decrypt_opensc’ keyscript but do work with the
>> ‘decrypt_gnupg_sc’ keyscript?
>
> It's more tied to the reader rather than the card. My own smartcard
> reader works great with the internal CCID driver of GnuPG, and my
> version of this script does not have pcscd. Erik Nellessen apparently
> has a smartcard reader that is not supported by GnuPG, but the card in
> it is still an OpenPGP smartcard, AFAIK. I'm glad I have a
> GnuPG-supported reader myself, it makes it all a lot smoother.
want these scripts to work not only at initramfs stage, but also in the
main system. I left it out for now, but I'll later adapt cryptopensc's
local-{top,bottom} scripts to ensure pcscd is started at early boot
stage.
By the way, I also added a local-bottom script to kill gpg-agent and
scdaemon before execution is turned over to the init binary :-)
Cheers,
--
Guilhem.
Guilhem Moulin
Sep 23, 2018, 12:20:03 AM9/23/18
to
On Sat, 22 Sep 2018 at 09:04:49 +0100, Chris Lamb wrote:
>> Sorry, I've been rather short on time lately; will try to take another
>> stab at this the week after next.
>
> No worries at all; how you getting on?
Thanks for the poke :-) Fortunately I did have some quiet evenings last
>> Sorry, I've been rather short on time lately; will try to take another
>> stab at this the week after next.
>
> No worries at all; how you getting on?
week, and finally pushed a new branch derived from Peter and Erik's work:
https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard
Works with my GNUK token, both at initramfs stage and in the main
system. The main difference is that only the pubring is copied to the
initramfs, not the whole GnuPG homedir. See Messages #65 and #120 for
the rationale, and ‘debian/README.gnupg-sc’ for the HOWTO.
cheers,
--
Guilhem.
Peter Lebbing
Sep 23, 2018, 7:40:02 AM9/23/18
to
Hi Guilhem!
On 23/09/2018 05:57, Guilhem Moulin wrote:
> We already have some logic in place to wait until the source device is
> present, so we can as well wait until the card is present.
Note that GnuPG now supports multiple card readers at the same time. The
solution will fail then. Furthermore, it also precludes showing the nice
prompt with /which/ smartcard to insert for people with multiple
smartcards. Further reflection might reveal other cases where it is
suboptimal or wrong... How about copying the whole homedir without
random_seed, but first checking to make sure there are only smartcard
keys as private keys? I think the following does that:
--8<---------------cut here---------------start------------->8---
#!/bin/sh
UNSAFEKEYS=$(gpg --batch --with-colons --homedir /etc/keys --list-secret-keys | \
gawk -F: '$1=="sec" || $1=="ssb" \
{ if ($15 !~ /D27600012401.*/ && $15 != "#") { print $5 } }')
if [ -n "$UNSAFEKEYS" ]; then
echo "Non-smartcard keys found:\n${UNSAFEKEYS}\nAborting" >&2
exit 1
fi
--8<---------------cut here---------------end--------------->8---
It will only accept true OpenPGP smartcard keys (matched on ISO 7816
Application Identifier) or empty stubs (no secret key whatsoever). No
other secret key material should be necessary for this particular
application. Note that the dialect is dash; if run in bash, echo would
need -e.
Whatever the solution, I think it's a good idea to copy *.conf to the
GnuPG homedir as well (that's not an implementation detail, it's a
supported API).
I'm a bit worried that currently, the implementation detail that the old
pubring.gpg format is the same format as gpg --export is being used.
This is tripping up people upgrading to GnuPG 2.1, and I think it's a
better idea to avoid it here as well. The attached patch tries to do
this (but obviously doesn't combine well with the proposal of copying
the whole homedir, which would get this for free :-).
> By the way, I also added a local-bottom script to kill gpg-agent and
> scdaemon before execution is turned over to the init binary :-)
A good idea. If we copy a whole homedir, it might be needed to put the
homedir in its regular place for that. I suppose this is possible? I
think gpgconf can only manage daemons started with a default homedir.
Cheers,
Peter.
On 23/09/2018 05:57, Guilhem Moulin wrote:
> We already have some logic in place to wait until the source device is
> present, so we can as well wait until the card is present.
solution will fail then. Furthermore, it also precludes showing the nice
prompt with /which/ smartcard to insert for people with multiple
smartcards. Further reflection might reveal other cases where it is
suboptimal or wrong... How about copying the whole homedir without
random_seed, but first checking to make sure there are only smartcard
keys as private keys? I think the following does that:
--8<---------------cut here---------------start------------->8---
#!/bin/sh
UNSAFEKEYS=$(gpg --batch --with-colons --homedir /etc/keys --list-secret-keys | \
gawk -F: '$1=="sec" || $1=="ssb" \
{ if ($15 !~ /D27600012401.*/ && $15 != "#") { print $5 } }')
if [ -n "$UNSAFEKEYS" ]; then
echo "Non-smartcard keys found:\n${UNSAFEKEYS}\nAborting" >&2
exit 1
fi
--8<---------------cut here---------------end--------------->8---
It will only accept true OpenPGP smartcard keys (matched on ISO 7816
Application Identifier) or empty stubs (no secret key whatsoever). No
other secret key material should be necessary for this particular
application. Note that the dialect is dash; if run in bash, echo would
need -e.
Whatever the solution, I think it's a good idea to copy *.conf to the
GnuPG homedir as well (that's not an implementation detail, it's a
supported API).
I'm a bit worried that currently, the implementation detail that the old
pubring.gpg format is the same format as gpg --export is being used.
This is tripping up people upgrading to GnuPG 2.1, and I think it's a
better idea to avoid it here as well. The attached patch tries to do
this (but obviously doesn't combine well with the proposal of copying
the whole homedir, which would get this for free :-).
> By the way, I also added a local-bottom script to kill gpg-agent and
> scdaemon before execution is turned over to the init binary :-)
homedir in its regular place for that. I suppose this is possible? I
think gpgconf can only manage daemons started with a default homedir.
Cheers,
Peter.
Peter Lebbing
Sep 23, 2018, 10:00:02 AM9/23/18
to
On 23/09/2018 13:32, Peter Lebbing wrote:
> How about copying the whole homedir without random_seed, but first
> checking to make sure there are only smartcard keys as private keys?
However, we should specifically exclude openpgp-revocs.d as well. The
> How about copying the whole homedir without random_seed, but first
> checking to make sure there are only smartcard keys as private keys?
whole "is the homedir an API or implementation detail" is a bit muddy
IMHO. I think openpgp-revocs.d is an API, since it is not *consumed* by
GnuPG AFAIK, so it must be something meant for others (users,
frontends), right? So I think we're not intruding on implementation
details by omitting this directory.
Peter Lebbing
Sep 23, 2018, 10:10:03 AM9/23/18
to
On 23/09/2018 13:32, Peter Lebbing wrote:
> How about copying the whole homedir without
> random_seed, but first checking to make sure there are only smartcard
> keys as private keys?
O dear, this might not be enough. The agent can also hold non-OpenPGP
> random_seed, but first checking to make sure there are only smartcard
> keys as private keys?
keys. SSH keys are an example of what I'm actually using myself.
This might need some more thought... I'm not really happy with the "wait
for a random smartcard to be available and import that as stubs"
solution, but copying the whole homedir might need some more tuning as
well... Or we just accept that people who put data in a directory named
cryptsetup-initramfs should expect that this data ends up in their
initramfs, and limit our safety checks. We can still document it,
obviously, with a clearly phrased warning that although the key itself
is encrypted, nothing else is.
Anyway, Guilhem, thanks for working on this!
Guilhem Moulin
Sep 23, 2018, 11:10:02 AM9/23/18
to
Hi,
On Sun, 23 Sep 2018 at 13:32:44 +0200, Peter Lebbing wrote:
> --8<---------------cut here---------------start------------->8---
> #!/bin/sh
>
> UNSAFEKEYS=$(gpg --batch --with-colons --homedir /etc/keys --list-secret-keys | \
> gawk -F: '$1=="sec" || $1=="ssb" \
> { if ($15 !~ /D27600012401.*/ && $15 != "#") { print $5 } }')
>
> if [ -n "$UNSAFEKEYS" ]; then
> echo "Non-smartcard keys found:\n${UNSAFEKEYS}\nAborting" >&2
> exit 1
> fi
> --8<---------------cut here---------------end--------------->8---
I was thinking about something like that, and that's why I was referring
to by “the complexity is not worth it IMHO”. `--list-secret-keys`
implicitly launches gpg-agent(1) for that homedir, which will need to be
shut down afterwards (unless it was started manually before). Also,
while the bits that matter (the pubring and the stubs) will seldom
change hence /etc is probably the right place to store these, /etc might
be read-only when the initramfs image is generated. Since gpg(1) needs
a writeable homedir, we'd need to copy stuff around.
> Whatever the solution, I think it's a good idea to copy *.conf to the
> GnuPG homedir as well
I'm reluctant to do that since there are plenty of options that would
break the setup: ‘no-autostart’, ‘keyring’, ‘pinentry-program
/path/to/custom/wrapper’, ‘pinentry-program /usr/bin/pinentry-gtk’,
etc., and (beside ‘trusted-key’ maybe) I don't see a valid usecase for
custom config files yet.
> I'm a bit worried that currently, the implementation detail that the old
> pubring.gpg format is the same format as gpg --export is being used.
> This is tripping up people upgrading to GnuPG 2.1, and I think it's a
> better idea to avoid it here as well.
The `--export` command produces RFC 4880 compatible output, which is
also the format for gpgv(1) keyrings and is bound to be supported
forever by gpg(1) (possibly via intermediate upgrade to .kbx like for
the private key material). Why would that block migration to GnuPG 2.1?
>> By the way, I also added a local-bottom script to kill gpg-agent and
>> scdaemon before execution is turned over to the init binary :-)
>
> A good idea. If we copy a whole homedir, it might be needed to put the
> homedir in its regular place for that. I suppose this is possible? I
> think gpgconf can only manage daemons started with a default homedir.
gpgconf(1) honors GNUPGHOME (and has an undocumented --homedir flag
since 2.1.7 AFAIK):
$ GNUPGHOME=/tmp/abc gpgconf --list-dirs homedir
/tmp/abc
$ gpgconf --homedir /tmp/abc --list-dirs homedir
/tmp/abc
--
Guilhem.
On Sun, 23 Sep 2018 at 13:32:44 +0200, Peter Lebbing wrote:
> --8<---------------cut here---------------start------------->8---
> #!/bin/sh
>
> UNSAFEKEYS=$(gpg --batch --with-colons --homedir /etc/keys --list-secret-keys | \
> gawk -F: '$1=="sec" || $1=="ssb" \
> { if ($15 !~ /D27600012401.*/ && $15 != "#") { print $5 } }')
>
> if [ -n "$UNSAFEKEYS" ]; then
> echo "Non-smartcard keys found:\n${UNSAFEKEYS}\nAborting" >&2
> exit 1
> fi
> --8<---------------cut here---------------end--------------->8---
to by “the complexity is not worth it IMHO”. `--list-secret-keys`
implicitly launches gpg-agent(1) for that homedir, which will need to be
shut down afterwards (unless it was started manually before). Also,
while the bits that matter (the pubring and the stubs) will seldom
change hence /etc is probably the right place to store these, /etc might
be read-only when the initramfs image is generated. Since gpg(1) needs
a writeable homedir, we'd need to copy stuff around.
> Whatever the solution, I think it's a good idea to copy *.conf to the
> GnuPG homedir as well
break the setup: ‘no-autostart’, ‘keyring’, ‘pinentry-program
/path/to/custom/wrapper’, ‘pinentry-program /usr/bin/pinentry-gtk’,
etc., and (beside ‘trusted-key’ maybe) I don't see a valid usecase for
custom config files yet.
> I'm a bit worried that currently, the implementation detail that the old
> pubring.gpg format is the same format as gpg --export is being used.
> This is tripping up people upgrading to GnuPG 2.1, and I think it's a
> better idea to avoid it here as well.
also the format for gpgv(1) keyrings and is bound to be supported
forever by gpg(1) (possibly via intermediate upgrade to .kbx like for
the private key material). Why would that block migration to GnuPG 2.1?
>> By the way, I also added a local-bottom script to kill gpg-agent and
>> scdaemon before execution is turned over to the init binary :-)
>
> A good idea. If we copy a whole homedir, it might be needed to put the
> homedir in its regular place for that. I suppose this is possible? I
> think gpgconf can only manage daemons started with a default homedir.
since 2.1.7 AFAIK):
$ GNUPGHOME=/tmp/abc gpgconf --list-dirs homedir
/tmp/abc
$ gpgconf --homedir /tmp/abc --list-dirs homedir
/tmp/abc
--
Guilhem.
Guilhem Moulin
Sep 23, 2018, 11:30:03 AM9/23/18
to
On Sun, 23 Sep 2018 at 16:00:30 +0200, Peter Lebbing wrote:
> I'm not really happy with the "wait for a random smartcard to be
> available and import that as stubs" solution,
Note that in principle we can wait for a smartcard with a given serial
> I'm not really happy with the "wait for a random smartcard to be
> available and import that as stubs" solution,
number to be inserted, with `gpg-connect-agent 'SCD SERIALNO openpgp'
/bye` or similar.
> but copying the whole homedir might need some more tuning as
> well... Or we just accept that people who put data in a directory named
> cryptsetup-initramfs should expect that this data ends up in their
> initramfs, and limit our safety checks. We can still document it,
> obviously, with a clearly phrased warning that although the key itself
> is encrypted, nothing else is.
generation as quiet as possible. Users (understandably) become worried
— and file bugs — when kernel upgrades or similar produce warnings,
especially when early boot stage is involved ;-)
> Anyway, Guilhem, thanks for working on this!
--
Guilhem.
Guilhem Moulin
Sep 23, 2018, 11:40:03 AM9/23/18
to
Hi,
On Mon, 06 Aug 2018 at 13:09:13 +0200, Jonas Meurer wrote:
> Am 23.07.2018 um 14:42 schrieb Chris Lamb:
> Still, if we would split the gnupg smartcard keyscript into an own
> binary package, we would have to do the same for decrypt_gnupg,
> decrypt_opensc and decrypt_ssl. Which would mean four new binary
> packages.
More, if were to further split the initramfs integration. For instance
in the case of OpenPGP smartcards, pinentry-gtk (the default pinentry
flavor) will suffice for the normal system, but pinentry-curses |
pinentry-tty is required for unlocking to work at early boot stage.
Tight dependencies are great, but is it really worth it for a package
with just a dozen of lines of shell code and 10× as much meta-data?
Cheers,
--
Guilhem.
On Mon, 06 Aug 2018 at 13:09:13 +0200, Jonas Meurer wrote:
> Am 23.07.2018 um 14:42 schrieb Chris Lamb:
> Still, if we would split the gnupg smartcard keyscript into an own
> binary package, we would have to do the same for decrypt_gnupg,
> decrypt_opensc and decrypt_ssl. Which would mean four new binary
> packages.
More, if were to further split the initramfs integration. For instance
in the case of OpenPGP smartcards, pinentry-gtk (the default pinentry
flavor) will suffice for the normal system, but pinentry-curses |
pinentry-tty is required for unlocking to work at early boot stage.
Tight dependencies are great, but is it really worth it for a package
with just a dozen of lines of shell code and 10× as much meta-data?
Cheers,
--
Guilhem.
Peter Lebbing
Sep 23, 2018, 12:10:04 PM9/23/18
to
On 23/09/2018 17:02, Guilhem Moulin wrote:
> I was thinking about something like that, and that's why I was referring
> to by “the complexity is not worth it IMHO”. `--list-secret-keys`
> implicitly launches gpg-agent(1) for that homedir, which will need to be
> shut down afterwards (unless it was started manually before).
Oh, I hadn't realized. That's a blocking issue.
> I was thinking about something like that, and that's why I was referring
> to by “the complexity is not worth it IMHO”. `--list-secret-keys`
> implicitly launches gpg-agent(1) for that homedir, which will need to be
> shut down afterwards (unless it was started manually before).
> I'm reluctant to do that since there are plenty of options that would
> break the setup: ‘no-autostart’, ‘keyring’, ‘pinentry-program
> /path/to/custom/wrapper’, ‘pinentry-program /usr/bin/pinentry-gtk’,
> etc., and (beside ‘trusted-key’ maybe) I don't see a valid usecase for
> custom config files yet.
would be picked up from the normal homedir. scdaemon options like
disable-ccid, enable-pinpad-varlen, disable-pinpad and maybe reader-port
might be useful in some setups where card readers are not completely
compliant with GnuPG's expectations. I couldn't find any useful
(documented :-) options for gpg or gpg-agent either.
> The `--export` command produces RFC 4880 compatible output, which is
> also the format for gpgv(1) keyrings and is bound to be supported
> forever by gpg(1) (possibly via intermediate upgrade to .kbx like for
> the private key material).
always hear and repeat myself that the format of a keyring is an
implementation detail, and anybody building keyrings this way should be
prepared for problems, which they do have. [1] is fresh in my memory,
but it might actually have been caused by a different problem. It's not
the first time it's cropped up though.
> Why would that block migration to GnuPG 2.1?
be constructing keyrings with --export, this has to my knowledge never
been an intended feature. You use --no-default-keyring --keyring X
--import to build keyrings only (well, appending is possible with
--primary-keyring as well). I don't see a reason to be using the
--export approach here anyway?
> gpgconf(1) honors GNUPGHOME (and has an undocumented --homedir flag
> since 2.1.7 AFAIK):
documentation to check, well... :-)
I'm going to raise the issue of how private the directory/filename
structure in private-keys-v1.d is on GnuPG-Users. Because if they are
deemed an acceptable API, we could just copy a configurable .key stub,
or even find it ourself from an OpenPGP key identifier and
--with-keygrip --with-colons --list-secret-keys etcetera.
It would be easier if we could just --import a stub.
On 23/09/2018 17:17, Guilhem Moulin wrote:
> If we want this to be widely used we should make initramfs image
> generation as quiet as possible.
generation. Just say that anything in /etc/cryptsetup-initramfs is going
to end up unencrypted in the initramfs, but that since the key for
unlocking the filesystem is already stored encrypted in that directory,
this does not compromise the unlock key. This obviously implies anything
else would be compromised. IMHO, sometimes good documentation can take
the place of full automation/checking.
Cheers,
Peter.
[1] https://lists.gnupg.org/pipermail/gnupg-users/2018-September/060936.html
Guilhem Moulin
Sep 24, 2018, 5:50:03 AM9/24/18
to
On Sun, 23 Sep 2018 at 17:59:20 +0200, Peter Lebbing wrote:
>> I'm reluctant to do that since there are plenty of options that would
>> break the setup: ‘no-autostart’, ‘keyring’, ‘pinentry-program
>> /path/to/custom/wrapper’, ‘pinentry-program /usr/bin/pinentry-gtk’,
>> etc., and (beside ‘trusted-key’ maybe) I don't see a valid usecase for
>> custom config files yet.
>
> I meant *.conf files specific to the initramfs
Sure, me too :-) But I'm afraid of ending up in a situation similar to
>> I'm reluctant to do that since there are plenty of options that would
>> break the setup: ‘no-autostart’, ‘keyring’, ‘pinentry-program
>> /path/to/custom/wrapper’, ‘pinentry-program /usr/bin/pinentry-gtk’,
>> etc., and (beside ‘trusted-key’ maybe) I don't see a valid usecase for
>> custom config files yet.
>
> I meant *.conf files specific to the initramfs
caff(1)'s, where in order to avoid maintaining two sets of conf files
some users end up symlinking them (or blindly copying them). I hadn't
thought of scdaemon.conf, but at least for gpg.conf and gpg-agent.conf
I'm really not convinced of the usefulness to give users the stick to
beat themselves with.
>> The `--export` command produces RFC 4880 compatible output, which is
>> also the format for gpgv(1) keyrings and is bound to be supported
>> forever by gpg(1) (possibly via intermediate upgrade to .kbx like for
>> the private key material).
>
> Is this documented that it is bound to be supported by gpg? Because I
> always hear and repeat myself that the format of a keyring is an
> implementation detail, and anybody building keyrings this way should be
> prepared for problems, which they do have. [1] is fresh in my memory,
> but it might actually have been caused by a different problem. It's not
> the first time it's cropped up though.
let's now wait for Werner's reply :-)
>> Why would that block migration to GnuPG 2.1?
>
> It's not related to migration here. I meant that you aren't supposed to
> be constructing keyrings with --export, this has to my knowledge never
> been an intended feature. You use --no-default-keyring --keyring X
> --import to build keyrings only (well, appending is possible with
> --primary-keyring as well).
upgrades, we have to trust that GnuPG developers have well thought-out
upgrade paths and migrations. It's just a (documented) fact that today
(GnuPG 2.2.10) `gpg --import` uses ‘pubring.kbx’ as default public
keyring (and falls back to ‘pubring.gpg’); with <2.1 it was
‘pubring.gpg’; and for all I know it might be ‘pubring.kbx2’ in some
later version. Since keyrings created with a particular version of
GnuPG might be used by any (later) version, they need to remain
supported; either directly, or through a migration mechanism.
> I don't see a reason to be using the --export approach here anyway?
gpg --export $KEYID | gpg --homedir="$(mktemp -d)" --import
creates a trust database ‘trustdb.gpg’ (unless we pass `--trust-model=always`),
a backup keyring ‘pubring.kbx~’ and an empty directory ‘private-keys-v1.d’.
It also launches gpg-agent(1) and dirmngr(1) processess (unless we pass
`--no-autostart`), and if there is no /run/user/$UID directory, uses
destination homedir for the agent / dirmngr sockets. Moreover if the
new homedir starts being further used, for instance because the user
runs `--card-status`, one might find stalled lock files, and/or
‘reader_$N.status’ for the reader status changes.
These files are most likely harmless but needlessly clutter the
initramfs image. If we're peeking at the directory to copy only the
files we need, we might end up relying on some implemention details and
break forward compatibility. (For instance the default public keyring
filename might change — again — in the future.)
--
Guilhem.
Peter Lebbing
Sep 24, 2018, 8:30:03 AM9/24/18
to
On 24/09/2018 11:42, Guilhem Moulin wrote:
> Sure, me too :-) But I'm afraid of ending up in a situation similar to
> caff(1)'s, where in order to avoid maintaining two sets of conf files
> some users end up symlinking them (or blindly copying them). I hadn't
> thought of scdaemon.conf, but at least for gpg.conf and gpg-agent.conf
> I'm really not convinced of the usefulness to give users the stick to
> beat themselves with.
Luckily, this particular application should just be working after
> Sure, me too :-) But I'm afraid of ending up in a situation similar to
> caff(1)'s, where in order to avoid maintaining two sets of conf files
> some users end up symlinking them (or blindly copying them). I hadn't
> thought of scdaemon.conf, but at least for gpg.conf and gpg-agent.conf
> I'm really not convinced of the usefulness to give users the stick to
> beat themselves with.
initial setup, no need to mess with it anymore unless you buy a new
smartcard reader.
I think scdaemon.conf is necessary for some people.
> Since /etc/cryptsetup-initramfs normally won't be re-written upon
> GnuPG upgrades, we have to trust that GnuPG developers have well
> thought-out upgrade paths and migrations. It's just a (documented)
> fact that today (GnuPG 2.2.10) `gpg --import` uses ‘pubring.kbx’ as
> default public keyring (and falls back to ‘pubring.gpg’); with <2.1 it
> was ‘pubring.gpg’; and for all I know it might be ‘pubring.kbx2’ in
> some later version. Since keyrings created with a particular version
> of GnuPG might be used by any (later) version, they need to remain
> supported; either directly, or through a migration mechanism.
straight-forward. Export to /etc/cryptsetup-initramfs/pubkey.gpg, and in
the decrypt script, --import that first. I see you already use a
default, empty homedir anyway, might as well just --import to that. I do
wonder why you ended up creating the homedir manually, doesn't GnuPG do
that for you when it's the /default/ homedir? I can't just try it out
and see myself, I don't have a Debian testing handy :-). Can build one,
obviously.
My assumption was that when GnuPG significantly changes, changes to
/etc/cryptsetup-initramfs would be necessary anyway. But let's see
whether the keyring format is declared stable.
For now, the --import during initramfs appeals most to me.
>
>> I don't see a reason to be using the --export approach here anyway?
>
> I'm not fond of the `| gpg --import` due to the added clutter. Today
>
> gpg --export $KEYID | gpg --homedir="$(mktemp -d)" --import
>
> creates a trust database ‘trustdb.gpg’ (unless we pass
> `--trust-model=always`), a backup keyring ‘pubring.kbx~’ and an empty
> directory ‘private-keys-v1.d’. It also launches gpg-agent(1) and
> dirmngr(1) processess (unless we pass `--no-autostart`), and if there
> is no /run/user/$UID directory, uses destination homedir for the agent
> / dirmngr sockets.
sure), but it now is all sorts of not fine indeed (lost my actual
trustdb; luckily I have daily backups to rely on). All the other issues
but the trustdb issue are caused by the temporary homedir. This
invocation seems to be fine:
$ TMPTRUST=$(mktemp)
$ gpg --no-default-keyring --keyring /home/peter/test.kbx --trustdb-name="$TMPTRUST" --import test.gpg
$ rm "$TMPTRUST"
But I notice your phrasing "today" :-). This might not be future-proof,
although very little truly is, of course. We are here because it's not
the standalone binary gpg 1.4 was anymore. And it used to be possible
to just import smartcard stubs.
My 2 cents,
Peter.
Guilhem Moulin
Sep 24, 2018, 8:20:02 PM9/24/18
to
On Mon, 24 Sep 2018 at 14:11:02 +0200, Peter Lebbing wrote:
> Well, the ultimate fail-safe migration mechanism is very
> straight-forward. Export to /etc/cryptsetup-initramfs/pubkey.gpg, and in
> the decrypt script, --import that first. I see you already use a
> default, empty homedir anyway, might as well just --import to that.
Ah yeah, I hadn't thought about this, but that's nice and foolproof
> Well, the ultimate fail-safe migration mechanism is very
> straight-forward. Export to /etc/cryptsetup-initramfs/pubkey.gpg, and in
> the decrypt script, --import that first. I see you already use a
> default, empty homedir anyway, might as well just --import to that.
indeed, thanks!
> I do wonder why you ended up creating the homedir manually, doesn't
> GnuPG do that for you when it's the /default/ homedir? I can't just
> try it out and see myself, I don't have a Debian testing handy :-).
> Can build one, obviously.
warning and I'm always afraid that adding `--quiet` would silence too
much. (However I have no problem adding `--quiet` to `--import` since
public key management operations have less moving parts. So with your
trick above the manual creation should be moot.)
> All the other issues but the trustdb issue are caused by the temporary
> homedir.
/etc/cryptsetup-initramfs pubring by using the directory as temporary
homedir. My bad, sorry. Then shouldn't the following be enough, and
save a temporary file?
`| gpg --no-default-keyring --keyring … --trust-model=always --import`
I like your above trick better, though: the command to generate keyrings
is simpler, and not tied to a particular keyring format.
--
Guilhem.
Peter Lebbing
Sep 25, 2018, 10:30:02 AM9/25/18
to
On 25/09/2018 02:10, Guilhem Moulin wrote:
> Then shouldn't the following be enough, and
> save a temporary file?
>
> `| gpg --no-default-keyring --keyring … --trust-model=always --import`
I thought so but was wrong.
> Then shouldn't the following be enough, and
> save a temporary file?
>
> `| gpg --no-default-keyring --keyring … --trust-model=always --import`
Without relocating trustdb.gpg to somewhere else, it will lose all
information in there. The only key in the keyring is the imported key,
and all other trust info is purged, even though there is trust-model
always. This is the user's real homedir... and what I meant when I said
I lost my actual trustdb.
That was the purpose of TMPTRUST.
But since the --import should be fast enough to an empty keyring, it is
much more solid to just --import inside the initramfs.
Guilhem Moulin
Nov 3, 2018, 8:30:02 PM11/3/18
to
Hi Chris,
On Sun, 23 Sep 2018 at 06:10:52 +0200, Guilhem Moulin wrote:
> Fortunately I did have some quiet evenings last week, and finally
> pushed a new branch derived from Peter and Erik's work:
>
> https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard
Did you have time to look at this branch yet? (Just rebased it on top
of ‘debian/2%2.0.5-1’ and applied a couple of changes.)
Cheers,
--
Guilhem.
On Sun, 23 Sep 2018 at 06:10:52 +0200, Guilhem Moulin wrote:
> Fortunately I did have some quiet evenings last week, and finally
> pushed a new branch derived from Peter and Erik's work:
>
> https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard
of ‘debian/2%2.0.5-1’ and applied a couple of changes.)
Cheers,
--
Guilhem.
Chris Lamb
Nov 4, 2018, 5:40:03 AM11/4/18
to
Dear Guilhem,
> > https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard
>
> Did you have time to look at this branch yet? (Just rebased it on top
> of ‘debian/2%2.0.5-1’ and applied a couple of changes.)
Oh dear, I was not aware this was blocking on my end. Kyle, how'd
you feel about checking this branch out?
> > https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard
>
> Did you have time to look at this branch yet? (Just rebased it on top
> of ‘debian/2%2.0.5-1’ and applied a couple of changes.)
you feel about checking this branch out?
Guilhem Moulin
Nov 4, 2018, 8:40:02 AM11/4/18
to
On Sun, 04 Nov 2018 at 05:35:44 -0500, Chris Lamb wrote:
>>> https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard
>>
>> Did you have time to look at this branch yet? (Just rebased it on top
>> of ‘debian/2%2.0.5-1’ and applied a couple of changes.)
>
> Oh dear, I was not aware this was blocking on my end.
Oops sorry for the bad communication, should have poked you earlier
>>> https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard
>>
>> Did you have time to look at this branch yet? (Just rebased it on top
>> of ‘debian/2%2.0.5-1’ and applied a couple of changes.)
>
> Oh dear, I was not aware this was blocking on my end.
in October then :-P
> Kyle, how'd you feel about checking this branch out?
provide the .deb instead :-) Alternatively, you could manually copy the
relevant files:
install -oroot -groot -m0755 -t /lib/cryptsetup/scripts ./debian/scripts/decrypt_gnupg-sc
install -oroot -groot -m0644 -t /usr/share/doc/cryptsetup-run ./debian/README.gnupg-sc
install -oroot -groot -m0755 -t /usr/share/initramfs-tools/hooks ./debian/initramfs/hooks/cryptgnupg-sc
install -oroot -groot -m0755 -t /usr/share/initramfs-tools/scripts/local-bottom ./debian/initramfs/scripts/local-bottom/cryptgnupg-sc
--
Guilhem.
Kyle Rankin
Nov 6, 2018, 2:40:02 PM11/6/18
to
On Sun, Nov 04, 2018 at 02:38:29PM +0100, Guilhem Moulin wrote:
> On Sun, 04 Nov 2018 at 05:35:44 -0500, Chris Lamb wrote:
> >>> https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard
> >>
> >> Did you have time to look at this branch yet? (Just rebased it on top
> >> of ‘debian/2%2.0.5-1’ and applied a couple of changes.)
> >
> > Oh dear, I was not aware this was blocking on my end.
>
> Oops sorry for the bad communication, should have poked you earlier
> in October then :-P
>
> > Kyle, how'd you feel about checking this branch out?
Providing me the deb would remove any risk that any bugs I find were caused
> On Sun, 04 Nov 2018 at 05:35:44 -0500, Chris Lamb wrote:
> >>> https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard
> >>
> >> Did you have time to look at this branch yet? (Just rebased it on top
> >> of ‘debian/2%2.0.5-1’ and applied a couple of changes.)
> >
> > Oh dear, I was not aware this was blocking on my end.
>
> Oops sorry for the bad communication, should have poked you earlier
> in October then :-P
>
> > Kyle, how'd you feel about checking this branch out?
by some mistake on my part in merging and building that branch, so if you
could provide me the deb that would be much appreciated, that way we are at
least a QA team of two :)
-Kyle
Guilhem Moulin
Nov 6, 2018, 5:00:03 PM11/6/18
to
On Tue, 06 Nov 2018 at 11:15:57 -0800, Kyle Rankin wrote:
> On Sun, Nov 04, 2018 at 02:38:29PM +0100, Guilhem Moulin wrote:
>> On Sun, 04 Nov 2018 at 05:35:44 -0500, Chris Lamb wrote:
>>>>> https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard
>>>>
>>>> Did you have time to look at this branch yet? (Just rebased it on top
>>>> of ‘debian/2%2.0.5-1’ and applied a couple of changes.)
>>>
>>> Oh dear, I was not aware this was blocking on my end.
>>
>> Oops sorry for the bad communication, should have poked you earlier
>> in October then :-P
>>
>>> Kyle, how'd you feel about checking this branch out?
>
> Providing me the deb would remove any risk that any bugs I find were caused
> by some mistake on my part in merging and building that branch, so if you
> could provide me the deb that would be much appreciated, that way we are at
> least a QA team of two :)
There is no merging involved as I rebased the branch on top of master :-)
> On Sun, Nov 04, 2018 at 02:38:29PM +0100, Guilhem Moulin wrote:
>> On Sun, 04 Nov 2018 at 05:35:44 -0500, Chris Lamb wrote:
>>>>> https://salsa.debian.org/cryptsetup-team/cryptsetup/tree/openpgp-smartcard
>>>>
>>>> Did you have time to look at this branch yet? (Just rebased it on top
>>>> of ‘debian/2%2.0.5-1’ and applied a couple of changes.)
>>>
>>> Oh dear, I was not aware this was blocking on my end.
>>
>> Oops sorry for the bad communication, should have poked you earlier
>> in October then :-P
>>
>>> Kyle, how'd you feel about checking this branch out?
>
> Providing me the deb would remove any risk that any bugs I find were caused
> by some mistake on my part in merging and building that branch, so if you
> could provide me the deb that would be much appreciated, that way we are at
> least a QA team of two :)
But fair enough, you can use the cryptsetup packages from my private APT
repository:
echo "deb http://guilhem.org/debian sid main" >>/etc/apt/sources.list
apt-key add /tmp/7420DF86BCE15A458DCE997639278DA8109E6244.asc
apt update
apt upgrade
The OpenPGP key used to sign the ‘Release’ file (and the source
packages) is the one I'm using for Debian uploads; its primary key has
the following fingerprint:
7420 DF86 BCE1 5A45 8DCE 9976 3927 8DA8 109E 6244
Alternatively, you can manually download & install the binary packages
from
https://guilhem.org/debian/pool/main/c/cryptsetup/
(Only ‘cryptsetup-initramfs’ and ‘cryptsetup-run’ are relevant in this
context: the former for the initramfs boot scripts, the latter for the
decryption script and documentation.)
Cheers,
--
Guilhem.
Chris Lamb
Nov 6, 2018, 5:30:03 PM11/6/18
to
Dear Guilhem,
> But fair enough, you can use the cryptsetup packages from my private APT
> repository:
>
> echo "deb http://guilhem.org/debian sid main" >>/etc/apt/sources.list
> apt-key add /tmp/7420DF86BCE15A458DCE997639278DA8109E6244.asc
> apt update
> apt upgrade
Neat, thanks for providing this. I'll assume Kyle is happy to go
ahead and use these. :)
> But fair enough, you can use the cryptsetup packages from my private APT
> repository:
>
> echo "deb http://guilhem.org/debian sid main" >>/etc/apt/sources.list
> apt-key add /tmp/7420DF86BCE15A458DCE997639278DA8109E6244.asc
> apt update
> apt upgrade
ahead and use these. :)
Kyle Rankin
Nov 7, 2018, 4:10:03 PM11/7/18
to
add this support to an existing LUKS root partition by just using
luksAddKey and making sure the crypttab was updated and update-initramfs
was run. Note that in the case of a root partition, boot splash needs to be
disabled so you can enter the GPG PIN.
-Kyle
Guilhem Moulin
Nov 7, 2018, 8:10:03 PM11/7/18
to
On Wed, 07 Nov 2018 at 13:05:17 -0800, Kyle Rankin wrote:
> I've tested these debs and can confirm everything works.
Awesome, thanks for the feedback!
> I've tested these debs and can confirm everything works.
> I was also able to add this support to an existing LUKS root partition
> by just using luksAddKey and making sure the crypttab was updated and
> update-initramfs was run.
(not specific to that keyscript) that one might want to add ‘key-slot=1’
to the crypttab(5) entry. Indeed the first (and only) passphrase after
`luksFormat` “occupies” the 0th keyslot, and after `luksAddKey` the new
passphrase “occupies” the first keyslot available. If one doesn't add
‘--keyslot=$INDEX’ when unlocking, then all key slots are tried one
after the other until the passphrase manages to open one; in practice
the extra KDF runs needlessly delay the boot by a few seconds.
> Note that in the case of a root partition, boot splash needs to be
> disabled so you can enter the GPG PIN.
breaks unlocking via passfifo (hence remotely via SSH, although it's not
really the use-case in this context) — which is something I should
document, but I believe it's much more important to print the number of
remaining attempts on failure, given that too many failures will freeze
the card. (It should be feasible to retrieve the “PIN retry counter”
values from the `gpg --card-status` output and add it to the askpass
prompt, but that adds complexity and clunkiness IMHO.)
Furthermore, as Peter pointed out earlier, another advantage of using
pinentry is that if needed the user is asked to insert the smartcard
identified with its Serial Number (taken from the private key stubs).
However that doesn't happen currently because I'm really worried about
copying real private key material to the initramfs along with the stubs;
GnuPG upstream was asked about a documented API to retrieve the stubs
but hasn't answered yet AFAIK. I'm not sure if the implementation
currently found in our branch would choke if the wrong smartcard is
inserted: I wasn't able to test this as I have only one token :-)
--
Guilhem.
Peter Lebbing
Nov 8, 2018, 6:30:03 AM11/8/18
to
On 08/11/2018 02:07, Guilhem Moulin wrote:
> However that doesn't happen currently because I'm really worried about
> copying real private key material to the initramfs along with the stubs;
> GnuPG upstream was asked about a documented API to retrieve the stubs
> but hasn't answered yet AFAIK. I'm not sure if the implementation
> currently found in our branch would choke if the wrong smartcard is
> inserted: I wasn't able to test this as I have only one token :-)
I have an idea on how to do this all more elegantly, but I haven't found
> However that doesn't happen currently because I'm really worried about
> copying real private key material to the initramfs along with the stubs;
> GnuPG upstream was asked about a documented API to retrieve the stubs
> but hasn't answered yet AFAIK. I'm not sure if the implementation
> currently found in our branch would choke if the wrong smartcard is
> inserted: I wasn't able to test this as I have only one token :-)
the time to work it out yet. Please don't block on this when the current
solution works for single reader, single smartcard cases. I don't know
when I'll find the time, but I'll try something out and submit it as a
patch.
I can test with multiple test readers and cards and intend to do so.
(For someone wondering: why do we need support for multiple card
readers? Consider the situation where a laptop has a built-in smartcard
reader but the user wishes to use a GnuK, which is a removable USB
device, to unlock his partition instead. This user cannot remove the
built-in smartcard reader.)
Cheers,
Chris Lamb
Nov 21, 2018, 11:20:02 AM11/21/18
to
Hi Peter et al.,
Guilhem Moulin wrote:
> > GnuPG upstream was asked about a documented API to retrieve the stubs
> > but hasn't answered yet AFAIK.
Did they get back to you yet out of interest, Guilhem?
> > I'm not sure if the implementation currently found in our branch would
> > choke if the wrong smartcard is inserted: I wasn't able to test this
> > as I have only one token :-)
Can I fix that for you? (Serious offer; I can get this shipped to
you ASAP...)
> I have an idea on how to do this all more elegantly, but I haven't found
> the time to work it out yet. Please don't block on this when the current
> solution works for single reader, single smartcard cases.
Indeed, it would be great to see this land in the main Debian
packages; what are the remaining blockers to this? :)
Guilhem Moulin wrote:
> > GnuPG upstream was asked about a documented API to retrieve the stubs
> > but hasn't answered yet AFAIK.
> > I'm not sure if the implementation currently found in our branch would
> > choke if the wrong smartcard is inserted: I wasn't able to test this
> > as I have only one token :-)
you ASAP...)
> I have an idea on how to do this all more elegantly, but I haven't found
> the time to work it out yet. Please don't block on this when the current
> solution works for single reader, single smartcard cases.
packages; what are the remaining blockers to this? :)
Guilhem Moulin
Nov 21, 2018, 11:50:03 AM11/21/18
to
Hi,
On Wed, 21 Nov 2018 at 11:12:08 -0500, Chris Lamb wrote:
> Guilhem Moulin wrote:
>>> GnuPG upstream was asked about a documented API to retrieve the stubs
>>> but hasn't answered yet AFAIK.
>
> Did they get back to you yet out of interest, Guilhem?
Peter last poked Werner on Nov 09 but there wasn't any reply from him.
(At least not on the gnupg-users list.)
>>> I'm not sure if the implementation currently found in our branch would
>>> choke if the wrong smartcard is inserted: I wasn't able to test this
>>> as I have only one token :-)
>
> Can I fix that for you? (Serious offer; I can get this shipped to
> you ASAP...)
Hmm on second thought the offer is tempting; if you're also attending
35c3 then shipping won't even be necessary ;-)
>> I have an idea on how to do this all more elegantly, but I haven't found
>> the time to work it out yet. Please don't block on this when the current
>> solution works for single reader, single smartcard cases.
>
> Indeed, it would be great to see this land in the main Debian
> packages; what are the remaining blockers to this? :)
There are none AFAIK, since the current shortcomings have been
acknowledged as non-blocking. And yes it makes sense to upload to
unstable quickly, so we have a chance to fix possible bugs before the
freeze. (Wanted to close #901795 too, but it can be done in a separate
upload.) I'll merge and upload before the week-end :-)
Cheers,
--
Guilhem.
On Wed, 21 Nov 2018 at 11:12:08 -0500, Chris Lamb wrote:
> Guilhem Moulin wrote:
>>> GnuPG upstream was asked about a documented API to retrieve the stubs
>>> but hasn't answered yet AFAIK.
>
> Did they get back to you yet out of interest, Guilhem?
(At least not on the gnupg-users list.)
>>> I'm not sure if the implementation currently found in our branch would
>>> choke if the wrong smartcard is inserted: I wasn't able to test this
>>> as I have only one token :-)
>
> Can I fix that for you? (Serious offer; I can get this shipped to
> you ASAP...)
35c3 then shipping won't even be necessary ;-)
>> I have an idea on how to do this all more elegantly, but I haven't found
>> the time to work it out yet. Please don't block on this when the current
>> solution works for single reader, single smartcard cases.
>
> Indeed, it would be great to see this land in the main Debian
> packages; what are the remaining blockers to this? :)
acknowledged as non-blocking. And yes it makes sense to upload to
unstable quickly, so we have a chance to fix possible bugs before the
freeze. (Wanted to close #901795 too, but it can be done in a separate
upload.) I'll merge and upload before the week-end :-)
Cheers,
--
Guilhem.
Chris Lamb
Nov 21, 2018, 12:30:03 PM11/21/18
to
Dear Guilhem,
> >>> I'm not sure if the implementation currently found in our branch would
> >>> choke if the wrong smartcard is inserted: I wasn't able to test this
> >>> as I have only one token :-)
> >
> > Can I fix that for you? (Serious offer; I can get this shipped to
> > you ASAP...)
>
> Hmm on second thought the offer is tempting; if you're also attending
> 35c3 then shipping won't even be necessary ;-)
Name/link the exact device and I'll get it to you! (Alas I won't be
at 35C3...)
> There are none AFAIK, since the current shortcomings have been
> acknowledged as non-blocking. And yes it makes sense to upload to
> unstable quickly, so we have a chance to fix possible bugs before the
> freeze. (Wanted to close #901795 too, but it can be done in a separate
> upload.) I'll merge and upload before the week-end :-)
Neat, looking forward to it. :)
Regards,
> >>> I'm not sure if the implementation currently found in our branch would
> >>> choke if the wrong smartcard is inserted: I wasn't able to test this
> >>> as I have only one token :-)
> >
> > Can I fix that for you? (Serious offer; I can get this shipped to
> > you ASAP...)
>
> Hmm on second thought the offer is tempting; if you're also attending
> 35c3 then shipping won't even be necessary ;-)
at 35C3...)
> There are none AFAIK, since the current shortcomings have been
> acknowledged as non-blocking. And yes it makes sense to upload to
> unstable quickly, so we have a chance to fix possible bugs before the
> freeze. (Wanted to close #901795 too, but it can be done in a separate
> upload.) I'll merge and upload before the week-end :-)
Regards,
Peter Lebbing
Nov 25, 2018, 8:20:03 AM11/25/18
to
Hi,
On 21/11/2018 17:46, Guilhem Moulin wrote:
> Peter last poked Werner on Nov 09 but there wasn't any reply from him.
> (At least not on the gnupg-users list.)
Nope, no reply, unfortunately.
> Hmm on second thought the offer is tempting; if you're also attending
> 35c3 then shipping won't even be necessary ;-)
I have once programmed GnuK into a very cheap Maple Mini clone for
somebody. He hasn't tried to use it yet, but I don't expect any issues.
It's not a really practical form-factor for mobile use (it needs a USB
cable, it's not a "stick" form), but for development on a desktop, it
should be fine.
I'll bring one programmed with GnuK to the 35C3. I also ordered another
ten; if they come over from China in time, I'll program them as well,
give you another one and pass them around to interested people.
These are the boards:
<https://www.aliexpress.com/store/213957/search?origin=n&SortType=bestmatch_sort&SearchText=STM32F103CBT6>
If you want to protect them a bit, just put some shrink tube around it.
HTH,
On 21/11/2018 17:46, Guilhem Moulin wrote:
> Peter last poked Werner on Nov 09 but there wasn't any reply from him.
> (At least not on the gnupg-users list.)
> Hmm on second thought the offer is tempting; if you're also attending
> 35c3 then shipping won't even be necessary ;-)
somebody. He hasn't tried to use it yet, but I don't expect any issues.
It's not a really practical form-factor for mobile use (it needs a USB
cable, it's not a "stick" form), but for development on a desktop, it
should be fine.
I'll bring one programmed with GnuK to the 35C3. I also ordered another
ten; if they come over from China in time, I'll program them as well,
give you another one and pass them around to interested people.
These are the boards:
<https://www.aliexpress.com/store/213957/search?origin=n&SortType=bestmatch_sort&SearchText=STM32F103CBT6>
If you want to protect them a bit, just put some shrink tube around it.
HTH,
0 new messages