Bug 188407
| Summary: | Please compile with --enable-extendedapdu | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Brad Hards <bradh> |
| Component: | pcsc-lite | Assignee: | Bob Relyea <rrelyea> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | extras-qa, ludovic.rousseau, scop |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | f7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-05-31 23:08:51 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Brad Hards
2006-04-09 07:42:18 UTC
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. No problem - seems like a good approach. FWIW: apparently the Gentoo e-builds turn this option on by default. 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 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. 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. 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?). Reassigning to FC maintainer. Based on the 1.3.2 release notes, upgrading to it would take care of this? 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 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. 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 |