Re: [PATCH 0/2] gnu: Add libpcsclite

[Marius Bakke]

Mike Gerwitz <address@hidden> writes:

> Hey, Marius:
>
> Thanks for the quick reply. :)

Hi again,

Sorry for the late reply this time! :)

> On Sat, Oct 22, 2016 at 22:16:34 +0100, Marius Bakke wrote:
>>> * gnu/packages/gnupg.scm (libpcsclite): New variable.
>>
>> I think this should be named "pcsc-lite" to match the upstream name.
>
> I wasn't sure what the Guix naming convention was here---in Debian it's
> libpcsclite1.  I'll make the change, though.

Debian typically separates libraries into their own packages distinct
from any executable binaries. Guix doesn't, although for some very large
packages the libraries may be a separate "output" [0].

Since this package provides both the "pcscd" binary (which is a separate
package in Debian) and libpcsclite.so, using the "project name" is the
correct convention.

[0]: Search the Guix manual for "multiple outputs" for more information
about this. At ~500KiB, multiple outputs is not necessary for pcsc-lite.

>>> * gnu/packages/gnupg.scm (gnupg): Add libpcsclite as propagated-input
>> [...]
>>
>>> +    (propagated-inputs
>>> +     `(("libpcsclite" ,libpcsclite)))
>>>     (arguments
>>> -    `(#:configure-flags '("--enable-gpg2-is-gpg")
>>> +    `(#:configure-flags
>>> +      (list "--enable-gpg2-is-gpg"
>>> +            (string-append "LDFLAGS=-Wl,-rpath="
>>> +                           (assoc-ref %build-inputs "libpcsclite")
>>> +                           "/lib"))
>>
>> The intention here is to make gnupg locate the libpcsclite library at
>> runtime, since it has no build-time checks for it, correct?
>
> Correct.  This is where I spent most of my time Guix-wise.
>
>> I think this approach is fine, if there is no way to make it search
>> the Guix profile paths for the library.
>
> It uses dlopen which looks in RUNPATH.  I used strace to try to figure
> out what else it might be doing, but it looked like the RUNPATH paths
> were all it was checking.
>
> That said, I have no idea what I'm doing, so I'd love to hear a better
> way!  I saw other packages doing this, so I hoped it was somewhat
> acceptable, however dirty.
>
>> However, the LDFLAGS need to be in #:make-flags for this to work, and
>> then pcsc-lite does not need to be propagated, since Guix will scan the
>> output for store references (including rpath entries) and add them as
>> runtime dependencies.
>
> Ah!  Awesome.
>
> Right now I'm using %build-inputs, but that's not going to work anymore
> if pcsc-lite isn't an input.  Should I be adding it to the `input' list
> instead, or is there a better way?
>
> I assume you're looking for something like this:
>
>    (arguments
>     `(#:configure-flags '("--enable-gpg2-is-gpg")
>       #:make-flags (string-append "LDFLAGS=-Wl,-rpath="
>                                   (assoc-ref %build-inputs "pcsc-lite")
>                                   "/lib")

Yes, that's exactly what I meant (note that #:make-flags should be a
list). Then "pcsc-lite" can be moved to (inputs), yet gnupg should be
able to find the library at run-time since it will be added to RUNPATH.

However, since this is only needed for "scdaemon", I noticed NixOS
substitutes the libpcsclite.so with the full path in scdaemon.c [0]
instead of adding it to the RUNPATH of all GPG executables. Can you try
that?

You can verify that an input is referenced after building by running
e.g. `guix gc -R $(./pre-inst-env guix build gnupg)`. These "tricks"
enables us to avoid propagation, so that dependencies of a package does
not end up in your profile.

[1]: 
https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/security/gnupg/21.nix#L31

>> Meanwhile I'll see if I can find a way to test this with a Yubikey.
>> Currently I get:
>> scdaemon[4600]: pcsc_list_readers failed: unknown PC/SC error code 
>> (0x8010002e)
>> ..when using the "gpg-agent --debug-all" command mentioned earlier.
>
> I'm trying to figure out how I got myself into that situation by undoing
> configuration changes, but I'm having trouble reproducing it.  Is that
> the error you're getting from gpg-agent itself, or from gpg based on
> gpg-agent's reply?
>
> I'm not Guix SD yet, but on Trisquel+Guix using my Nitrokey I had to
> modify /etc/libccid_Info.plist, which is part of libccid, according to
> this:
>
>   https://www.nitrokey.com/documentation/installation
>   (Just disable CSS to view without JS.)
>
> I actually completely forgot about libccid.  Perhaps I should add a
> package for that too.

Ah, this was indeed the problem. Forgot that ccid was required too. I
actually made a package for it, but had to employ a few tricks to make
pcsc-lite find the driver: build pcsc-lite with
"--enable-usbdropdir=/var/lib/pcsc/drivers" and then symlink the ccid
drivers there.. Then `gpg --card-status` works after starting pcscd.

This is obviously suboptimal, I'm not sure how to solve it properly yet.
But if it works with pcscd and ccid on a foreign distro, it's not a big
showstopper.

> Please let me know what solution you find, and if libccid does in fact
> solve that problem.  My goal for these changes is to have smartcard
> stuff for popular readers work without any additional effort in Guix; I
> found I was writing an article with a lot of exceptions for getting GPG
> 2.1 working, and would rather just tell people to "use Guix". :)

Awesome :) If you can confirm that it still works for your use case
after the mentioned changes, I think we can push it. Don't forget to add
a copyright line for yourself.

I'll continue working on getting ccid integrated and eventually make a
pcscd service for GuixSD.

I do wonder if we should add a "smartcard.scm" or similar for pcsc, ccid
and friends, since they are not really gnupg projects. Any opinions from
other contributors? This can be fixed up before committing, so just use
gnupg.scm for now.

Can you send an updated patch? :)