Bug 188407 - Please compile with --enable-extendedapdu
Please compile with --enable-extendedapdu
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: pcsc-lite (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bob Relyea
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-09 03:42 EDT by Brad Hards
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: f7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-31 19:08:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brad Hards 2006-04-09 03:42:18 EDT
Description of problem:  
While doing some tests with Athena RSA smartcards with an Athena smartcard  
reader, I found that openssl wouldn't generate an RSA key on the card. After  
downloading the pcsc-lite source, and rebuilding with --enable-extendedapdu,  
it worked correctly.  
  
Version-Release number of selected component (if applicable):  
1.3.0-1.fc5   
  
How reproducible:  
Always, with this hardware/smartcard combination  
  
Steps to Reproduce:  
1. Install pcsc-lite-1.3.0 
  
2. Download and install reader drivers  
http://www.athena-scs.com/downloads/asedriveiiie-3.2.tar.bz2   
configure and install.  
  
3. Install opensc (plus libp11 and engine_pkcs11 from   
http://www.opensc.org, I'll file another bug on this) 
  
4. Start pcsc-lit daemon 
  
5. Download Athena PKCS#11 binary from:  
http://alon.barlev.googlepages.com/libasepkcs.so.bz2  
  
This should be uncompressed and go into /usr/lib/pkcs11  
  
6. Grab latest version of easy-rsa:  
  
svn export   
http://svn.openvpn.net/projects/openvpn/contrib/alon/easy-rsa/2.0   
easy-rsa  
  
7. Now you can use easy-rsa in order do manage your PKI   
environment.  
  
Start with editing vars.  
  
Then:  
. ./vars  
./clean-all  
./pkitool --initca  
  
You have a CA up and running.  
  
Next, insert your new token:  
./pkitool --pkcs11-slots /usr/lib/pkcs11/libasepkcs.so  
  
Record your slot id.  
  
Initialize your token:  
./pkitool --pkcs11-init /usr/lib/pkcs11/libasepkcs.so [slot]  
  
Enrol a new certificate:  
./pkitool --pkcs11 /usr/lib/pkcs11/libasepkcs.so [slot] 00   
00 client1  
 
 
Actual results:  
All appears to work, until the last (certificate generation) step, which 
produces a lot of errors and doesn't generate the certificate or private key.  
  
 
Expected results:  
Certificate is generated correctly.  
  
Additional info:  
That option just increases the size of the APDU buffer. It should have no 
ill-effects.
Comment 1 Ville Skyttä 2006-04-09 04:29:49 EDT
Looks innocent enough, but I'll ping upstream beacause if there are no adverse
side effects, I'm wondering why it's not on by default, nor are Debian or SuSE
pcsc-lite packages built with that option.
Comment 2 Brad Hards 2006-04-09 05:20:00 EDT
No problem - seems like a good approach. FWIW: apparently the Gentoo e-builds 
turn this option on by default. 
Comment 3 Ville Skyttä 2006-04-10 13:09:18 EDT
Ludovic (Cc'd) replied and said he'd get back to me on this.  Some related info:
http://archives.neohapsis.com/archives/dev/muscle/2006-q1/0381.html
Comment 4 Ludovic Rousseau 2006-05-24 03:39:25 EDT
As I said in the message you refer to it is mainly a problem of memory and CPU
consumption.

What you SHALL NOT do in install a libpcsclite and a pcscd with differen
configuration (libpcsclite with support of extended APDU and pcscd without or
the reverse). The communication between them will just not work.

I am working on integrating a better way to support extended APDU. Extended APDU
will then be active by default in the next pcsc-lite release.
Comment 5 Ville Skyttä 2006-05-24 13:32:33 EDT
Thanks for the comments, Ludovic.

Having a mismatch between pcscd and libpcsclite is very unlikely to happen with
the FE packages, but how about other applications that use libpcsclite in
general (both in FE and locally compiled)?

Let's say app X was compiled against the current libpcsclite version which uses
the default APDU's.  Now, if one rebuilds libpcsclite (and pcscd) using extended
APDU's, would app X break if it's not recompiled against the new libpcsclite?

Anyway, I'm personally fine with waiting for the next version.
Comment 6 Ludovic Rousseau 2006-05-25 17:17:48 EDT
You do not have to rebuild your application. libpcsclite is API and ABI
compatible with or without support of extended APDU. Of course you will not have
access to extended APDU if libpcsclite is not compiled with it but I will not
crash. You will just get a SCARD_E_INSUFFICIENT_BUFFER error if your buffer is
too big (Microsoft does not define a SCARD_E_TOO_BIG_BUFFER, Maybe
SCARD_E_INVALID_PARAMETER should be use instead?).
Comment 7 Ville Skyttä 2006-08-23 14:31:38 EDT
Reassigning to FC maintainer.  Based on the 1.3.2 release notes, upgrading to it
would take care of this?
Comment 8 Bob Relyea 2006-11-01 19:50:59 EST
I've finally pushed 1.3.2 to devel, does that take care of the problem, or do we
need to add the flag still?

bob
Comment 9 Brad Hards 2006-11-02 01:46:36 EST
I am not in a position to test for a couple of weeks, but I have no problems 
with this bug being closed if you are confident that this is sorted.
Comment 10 Bob Relyea 2006-11-02 11:15:30 EST
I'm not completely confident, and it doesn't hurt to leave it open until it's
verified. I'll move it to modified. when you get a chance to test it go ahead
hand mark it verified if it works or back to assigned if it doesn't.

thanks.

bob

Note You need to log in before you can comment on or make changes to this bug.