I also reproduced this bug. I am using a PIV configured YubiKey 5C NFC for GNOME Smartcard login, which uses pam_pkcs11, and pam_pkcs11 uses opensc to read it via pcscd.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 19 2023
Dec 9 2022
Oct 26 2022
Oct 1 2022
In T6218#163787, @gouttegd wrote:Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work?
Yes. Scute relies on those to interact with the token.
Sep 30 2022
Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work?
Sep 29 2022
Merged the changes in t6002 branch into master.
Sep 28 2022
That sounds quite cool.
Actually we developed PIV support to allow the use of PIV X.509 certificates and OpenPGP keys with Yubikeys. In fact, GnuPG is able to switch between the Yubikey PIV and OpenPGP applications on-the-fly while keeping their PIN verification states.
I was indeed using version 1.5.0 for testing, but I wish to clarify the purpose of Scute in my setup before proceeding.
Sep 27 2022
Which version of Scute are you using?
Using Scute as a drop-in replacement doesn't currently work. Perhaps my config needs more adjustments than just:
module = /usr/lib/x86_64-linux-gnu/scute/scute.so
Sep 26 2022
Yes, I meant to use Scute as pkcsc11 module for pam_pkcs11. Thanks for explaining more verbosely what I meant.
I think Werner may have confused pam_pkcs11 with gnupg-pkcs11-scd. :)
I'm not sure what you mean with using Scute as PKCS#11 provider instead of pam_pkcs11, as pam_pkcs11 is not a provider but a user of PKCS#11
There is a reason why pcsc-shared is not the default ;-). Please try using Scute (best the t6002 branch until it has been merged) as pkcs#11 provider instead of pam_pkcs11. And you should of course use the stable version of GnuPG and not the LTS (2.2).
Sep 17 2022
A better solution could always be found later
Aug 26 2022
Aug 22 2022
I tested with a self-signed one.
Did you test with a self-signed cert? I ran into the problem that the selection only showed the root certificate, the signing works using the leaf cert, but the root cert was put into the signature. Changing Scute to only return the leaf certificate made it work but verification failed.
I can successfully sign with LibreOffice Writer (using Brainpool with Yubikey). I need to do:
- Tools
- Optoins
- LibreOffice - Security - Certificate Path
- Select the profile of "firefox:default-esr" for NSS certificate directory
- LibreOffice - Security - Certificate Path
- Optoins
Aug 5 2022
Firefox nicely shows the 3 NIST certificates from my Telesec card but not the important Brainpool certificate for eIDAS. It turns out that Firefox does not support Brainpool, despite that a patch has been provided 8 years ago. See https://bugzilla.mozilla.org/show_bug.cgi?id=943639 . Thus there is currently no way to use LibreOffice or Okular to signe PDFs because they rely on NSS.
Jul 22 2022
@gniibe Thanks!
In the repo, for all related software, it's done.
Note that versions since 2020-11-07 to 2021-07-03 have major problem with non-POSIX shell, which doesn't support $(..) construct.
Jul 18 2022
Thank you.
Jun 30 2022
Kleopatra uses SCD READCERT for reading certificates from the PIV app. This is used to import the certificates stored by the PIV app. I'm not sure whether this is really needed. Maybe we could/should use "learn card" for this instead.
We could change how device keys are listed. Currently, Scute does KEYINFO --list, then asking gpgsm for each certificate.
The change requires "KEYINFO --list" command. This is not available through remote access of gpg-agent (extra socket).
Jun 15 2022
In the branch https://dev.gnupg.org/source/Scute/history/t6002/ , by the commit rS123d617ebefe: Less administration of devices by scute., things has been changed.
Jun 13 2022
I realized that we need to invent a way to represent KEYGRIP (40-byte string) in the scheme of PKCS#11; PKCS#11 uses fixed-size string (space padded) for it's label (32) and serialno (16). Basically, it identifies the device by slot number.
May 24 2022
For testing, I can use these sites for client certificate authentication:
https://stackoverflow.com/questions/38095559/https-test-server-that-checks-client-certificates
Aug 13 2021
Apr 18 2021
t-link does not do antthing useful, anyway. I don't think it is justified to add dlopen stuff. Running real test is anyway a manual action; for a full test automation we would need to emulate all supported cards.
Apr 17 2021
the t-link test should dlopen scute.so in runtime rather than link against it in build-time.
Apr 16 2021
As of slibtool commit 9c5ba5eb, scute now builds out of the box. I'd still recommend taking the above into consideration, though.
For what it's worth, scute is in violation of gnu libtool's documentation. Building with gnu libtool:
Apr 13 2021
In T5394#145082, @werner wrote:Regarding slibtool: I would actually like to have an easier to maintain tool than libtool (of which we use our own version) for GnuPG related software. However, its requirement "the compiler should support -std=c99" is currently a no-starter for libgcrypt and some other libs.
Regarding your patch, I am personally not opposed to it, but apparently Debian’s policy says the library/module should be called scute while Gentoo’s policy says it should be called libscute… What should an upstream developer do?
Apr 12 2021
Regarding slibtool: I would actually like to have an easier to maintain tool than libtool (of which we use our own version) for GnuPG related software. However, its requirement "the compiler should support -std=c99" is currently a no-starter for libgcrypt and some other libs.
Mar 31 2021
Looks good to me: "make && make check" passes.
FWIW, in GnuPG we use
Mar 30 2021
It should be fixed with 49ad2b0e05e3fcb8c8c2e23bb1c6063b390dee02, though I don’t have a gcc-10 to check. It does work with gcc-9.3 with -fno-common.
Mar 26 2021
It's OK not supporting generation in PostScript format.
Thus, we can remove image_eps support.
Then, convert is not required any more.
Mar 25 2021
Fixed with commit 4d95b7457d62bf785a2157bb2cfa002bde7ff8f5. It turned out the test the convert was already there, but its result was not used to decide whether to build the doc or not.
Mar 24 2021
I agree about checking for convert (but maybe just skip building the doc instead of aborting everything if convert cannot be found).
Jan 7 2021
Sep 13 2019
Sep 11 2019
I could not reproduce such a failure either under any conditions.
Sep 10 2019
In my debian buster pbuilder enviornment I got the following failure when packaging master (beta195):
Sep 9 2019
With the build problem on Mac OS now fixed with d551cf9, barring any last minute issue I plan to do the actual release by the end of the day tomorrow (10 September).
If I understand correctly, the problem stems from the -module flag added to the LDFLAGS in commit dc2211179. It's that flag that instruct libtool to create a bundle (.so file) instead of a dynamically linked shared library (.dylib file). But that flag is needed to force automake to accept that the library is to be named scute instead of libscute (without that flag automake errors out, complaining that scute.la is not a standard libtool library name).
Given that 1.5 already had that problem, I would suggest to ignore that bug for the 1.6 release. We can work on that later.
I just checked that Scute builds cleanly on Slackware, Debian, and in a cross-compilation setup against Mingw32.
Sep 6 2019
Jul 13 2017
"gouttegd (Damien Goutte-Gattat)" <noreply@dev.gnupg.org> writes:
I've just pushed the two fixes. `GNUPGHOME` is now set to the tests directory when running the tests and `gpg-connect-agent` is now looked for in `PATH` at runtime. When the tests are run, Scute now contacts the agent intended for the tests instead of any agent running on behalf of the Jenkins user. And so the tests pass or skip appropriately.
Jul 12 2017
I've just pushed the two fixes. GNUPGHOME is now set to the tests directory when running the tests and gpg-connect-agent is now looked for in PATH at runtime.
Jul 11 2017
All build artifacts are accessible
I see several problems here:
All build artifacts are accessible, e.g.: https://jenkins.gnupg.org/job/scute/ws/XTARGET/native/obj/tests/test-suite.log
Jul 7 2017
OK, I pushed my fix into master.
Jul 6 2017
The canonical repo is git://git.gnupg.org . We have not yet mirrored it at dev.gnupg.org.
Since there is no news for the last two weeks, I am wondering: am I the one blocking the situation here? Are you waiting for me to do something to make progress?
Jun 27 2017
Jun 23 2017
Yes, I am ready to accept write access to the Scute repository.
Justus, please apply the patches.
Jun 22 2017
I think the best method to make sure Scute can always find the socket is to use gpg-connect-agent to ask for the socket: we call gpg-connect-agent 'GETINFO socket_name' /bye and read the reply.
Jun 6 2017
Mar 30 2017
Nov 6 2015
This is ambiguous and the email is not mentioned. Given how old this is and
Niibe's opinion, I'm closing this issue.
Jul 16 2013
I maintain scute in Debian. It works for me for years.
I suspect it was build time issue.
Apr 16 2011
1.4.0 works, indeed. I didn't realize that was the latest version. The web page
is woefully out-of-date, but following the ftp link got me what I needed.
Apr 8 2011
Scute 1.2.0 is very old. It should be fixed in 1.4.0.
Mar 1 2011
Marcus, can you please look at it?