opensc-devel — discussion of developement of OpenSC and related projects

Re: [Opensc-devel] Release 0.15.0

[Douglas E E. <dee...@gm...>]

On 5/17/2015 2:41 AM, David Woodhouse wrote:
> On Sat, 2015-05-16 at 23:17 +0200, Viktor Tarasov wrote:
>> release 0.15.0 is published,
>
> Um,... really?
>
> As discussed in ticket #468 this version of libopensc.so.3 is
> binary-incompatible with the libopensc.so.3 from previous OpenSC
> releases. So anything linked against it may just crash on updating to
> 0.15.0.
>
> And it still doesn't seem to work with OpenVPN because of issue #333
> (which affects all platforms except Windows, I believe). We merged a
> *test* case for that bug, but AFAICT didn't actually fix the bug.
>
> (I say both those things looking at the commit logs but without actually
> re-testing. I'm a little busy right now but I'd tried to make sure those
> bugs were both known so that the release didn't happen without them
> fixed...)
>
> Should we be looking to do a 0.15.1 release within the next few days
> with those addressed?

I agree.

In the past we had pre-releases and release candidates. This time we have
jumped over any release candidate (and the change to test it) and now need a 0.15.1.

#git tag -l
0.12.2
0.12.2-rc1
0.13.0
0.13.0pre1
0.13.0rc1
0.14.0
0.14.0rc2
0.14.0rtm
0.15.0
maintainer-pgp-pub
v0.12.2
v0.15.0-pre1
v0.15.0-pre2
v0.15.0-pre3


>

-- 

  Douglas E. Engert  <DEE...@gm...>

Re: [Opensc-devel] Release 0.15.0

[David W. <dw...@in...>]

On Sat, 2015-05-16 at 23:17 +0200, Viktor Tarasov wrote:
> release 0.15.0 is published,

Um,... really?

As discussed in ticket #468 this version of libopensc.so.3 is
binary-incompatible with the libopensc.so.3 from previous OpenSC
releases. So anything linked against it may just crash on updating to
0.15.0.

And it still doesn't seem to work with OpenVPN because of issue #333
(which affects all platforms except Windows, I believe). We merged a
*test* case for that bug, but AFAICT didn't actually fix the bug.

(I say both those things looking at the commit logs but without actually
re-testing. I'm a little busy right now but I'd tried to make sure those
bugs were both known so that the release didn't happen without them
fixed...)

Should we be looking to do a 0.15.1 release within the next few days
with those addressed?

-- 
dwmw2

[Opensc-devel] Release 0.15.0

[Viktor T. <vik...@gm...>]

Hi,

release 0.15.0 is published,

https://sourceforge.net/projects/opensc/files/OpenSC/opensc-0.15.0/
https://opensc.fr/jenkins/view/OpenSC-release/
https://github.com/OpenSC/OpenSC/releases/tag/0.15.0

Thank you for your contributions, tests, ideas, discussions.

Best regards,
Viktor.



On 03/22/2015 05:44 PM, Andreas Schwier wrote:
> Hi Viktor,
>
> I've done a complete regression test with the SmartCard-HSM during which
> we discovered a broken commit.
>
> I've added pull request 399 to revert this commit and fix parameter
> checking.
>
> Other than that, the current master works with the SmartCard-HSM.
>
> Andreas
>
> On 03/22/2015 11:28 AM, Viktor Tarasov wrote:
>> Hi,
>>
>> I propose to prepare the next 0.15.0 release. The dedicated branch is created.
>>
>> Please tell if there are outstanding bugs that have to be fixed,
>> something essential is still to be integrated into this release.
>>
>> Any proposals, suggestions, test results are heartily wellcome.
>>
>> Best regards,
>> Viktor.
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Opensc-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>

[Opensc-devel] Smartcard HSM USB token ssh-add issue on Mac Leopard

[Sanaullah <san...@gm...>]

Hi,

I am trying to configure the Smardcard HSM USB token for Mac 10.6.8
Leopard. I am facing issue when trying to add the token using ssh-add

I run the ssh-agen in debug mod.

sh-3.2# eval 'ssh-agent -d'
SSH_AUTH_SOCK=/tmp/ssh-AAUNUBmuQtRI/agent.1830; export SSH_AUTH_SOCK;
echo Agent pid 1830;


 san$ ssh-add -s /usr/lib/opensc-pkcs11.so
Enter passphrase for PKCS#11:
SSH_AGENT_FAILURE
Could not add card: /usr/lib/opensc-pkcs11.so

I haven't seen anything in the logs of ssh-agent. I am using opensc-0.13
and openssh 5.9p1

sh-3.2# opensc-tool -l
# Detected readers (pcsc)
Nr.  Card  Features  Name
0    Yes             SCM SCR 355 00 00

the issue seems to looks the same which reported previously
https://github.com/OpenSC/OpenSC/issues/354

Any suggestion?

The same token is working fine in Ubunu 14.04

Regards,
Sanaullah

Re: [Opensc-devel] Towards release 0.15.0

[David W. <dw...@in...>]

On Thu, 2015-05-14 at 10:15 +0100, David Woodhouse wrote:
> 
> Is this one already known?
> 
> [dwoodhou@i7 tools]$ ./pkcs11-tool -t --login
> Using slot 1 with a present token (0x1)
> Segmentation fault (core dumped)
> Program received signal SIGSEGV, Segmentation fault.

Further investigation shows this is actually caused by using the
*installed* version of opensc-pkcs11.so and not the one in the build
tree.

The size of struct sc_pin_cmd_pin changed, and thus we are no longer
binary-compatible with the original libopensc.so.3 — so using the
installed (0.14.0) opensc-pkcs11.so against the libopensc in the build
tree causes this crash.

Don't we need an soname bump following commit 5757d82cc?

And also, now that the --module option to pkcs11-tool is optional,
shouldn't it automatically use the version in the build tree, when run
from the build tree? Normally we expect that kind of thing to be
entirely self-contained, setting rpaths or LD_LIBRARY_PATH as
appropriate so that a test in the build tree doesn't end up using a
mixture of old and new.

That isn't working for the DEFAULT_PKCS11_PROVIDER, it seems.

And in fact it isn't looking in /usr/lib64/pkcs11/ for modules
*either*, On this system that's where they live...

-- 
dwmw2

Re: [Opensc-devel] Towards release 0.15.0

[David W. <dw...@in...>]

On Wed, 2015-03-25 at 23:55 +0100, Frank Morgner wrote:
> I'd like to add #403 to the list of minor fixes, so we now have the
> following issues on the todo list:
> 
> #395
> #399
> #403

Is this one already known?

[dwoodhou@i7 tools]$ ./pkcs11-tool -t --login
Using slot 1 with a present token (0x1)
Segmentation fault (core dumped)
Program received signal SIGSEGV, Segmentation fault.
sc_transmit_apdu (card=card@entry=0x622fb0, apdu=apdu@entry=0xffff800000002fa1)
    at apdu.c:567
567             sc_detect_apdu_cse(card, apdu);
(gdb) p apdu
$1 = (sc_apdu_t *) 0xffff800000002fa1
(gdb) p *apdu
Cannot access memory at address 0xffff800000002fa1
(gdb) bt
#0  sc_transmit_apdu (card=card@entry=0x622fb0, 
    apdu=apdu@entry=0xffff800000002fa1) at apdu.c:567
#1  0x00007ffff7c8a30b in iso7816_pin_cmd (card=0x622fb0, data=0x7fffffffad40, 
    tries_left=0x0) at iso7816.c:1094
#2  0x00007ffff7c82df4 in sc_pin_cmd (card=0x622fb0, data=0x7fffffffad40, 
    tries_left=0x0) at sec.c:161
#3  0x00007ffff7a03469 in C_GetTokenInfo (slotID=1, pInfo=0x7fffffffd070)
    at framework-pkcs15.c:500
#4  0x000000000040696e in get_token_info (slot=<optimized out>, 
    info=info@entry=0x7fffffffd070) at pkcs11-tool.c:2944
#5  0x0000000000406e06 in login (session=6564752, login_type=1)
    at pkcs11-tool.c:1113
#6  0x000000000040301c in main (argc=<optimized out>, argv=<optimized out>)
    at pkcs11-tool.c:796

[dwoodhou@i7 tools]$ LD_LIBRARY_PATH=/ssd/git/OpenSC/src/libopensc/.libs valgrind .libs/pkcs11-tool --login -t
==8491== Memcheck, a memory error detector
==8491== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==8491== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==8491== Command: .libs/pkcs11-tool --login -t
==8491== 
==8491== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==8491==    at 0x3841A0F9CD: send (send.c:27)
==8491==    by 0x3848E06E50: MessageSend (winscard_msg.c:389)
==8491==    by 0x3848E06F67: MessageSendWithHeader (winscard_msg.c:328)
==8491==    by 0x3848E02B56: SCardConnect (winscard_clnt.c:831)
==8491==    by 0x4C5A382: pcsc_detect_readers (reader-pcsc.c:1091)
==8491==    by 0x4C2EA8F: sc_ctx_detect_readers (ctx.c:634)
==8491==    by 0x4C2F543: sc_context_create (ctx.c:757)
==8491==    by 0x53FBC2B: C_Initialize (pkcs11-global.c:229)
==8491==    by 0x402E65: main (pkcs11-tool.c:690)
==8491==  Address 0xffeffec06 is on thread 1's stack
==8491==  in frame #3, created by SCardConnect (winscard_clnt.c:780)
==8491== 
Using slot 1 with a present token (0x1)
==8491== Conditional jump or move depends on uninitialised value(s)
==8491==    at 0x4C3C1EF: iso7816_pin_cmd (iso7816.c:1084)
==8491==    by 0x4C34DF3: sc_pin_cmd (sec.c:161)
==8491==    by 0x540C468: C_GetTokenInfo (framework-pkcs15.c:500)
==8491==    by 0x40696D: get_token_info (pkcs11-tool.c:2944)
==8491==    by 0x406E05: login (pkcs11-tool.c:1113)
==8491==    by 0x40301B: main (pkcs11-tool.c:796)
==8491== 
==8491== Conditional jump or move depends on uninitialised value(s)
==8491==    at 0x4C3F9BD: sc_transmit_apdu (apdu.c:560)
==8491==    by 0x4C3C30A: iso7816_pin_cmd (iso7816.c:1094)
==8491==    by 0x4C34DF3: sc_pin_cmd (sec.c:161)
==8491==    by 0x540C468: C_GetTokenInfo (framework-pkcs15.c:500)
==8491==    by 0x40696D: get_token_info (pkcs11-tool.c:2944)
==8491==    by 0x406E05: login (pkcs11-tool.c:1113)
==8491==    by 0x40301B: main (pkcs11-tool.c:796)
==8491== 
==8491== Use of uninitialised value of size 8
==8491==    at 0x4C3F9F2: sc_detect_apdu_cse (apdu.c:363)
==8491==    by 0x4C3F9F2: sc_transmit_apdu (apdu.c:567)
==8491==    by 0x4C3C30A: iso7816_pin_cmd (iso7816.c:1094)
==8491==    by 0x4C34DF3: sc_pin_cmd (sec.c:161)
==8491==    by 0x540C468: C_GetTokenInfo (framework-pkcs15.c:500)
==8491==    by 0x40696D: get_token_info (pkcs11-tool.c:2944)
==8491==    by 0x406E05: login (pkcs11-tool.c:1113)
==8491==    by 0x40301B: main (pkcs11-tool.c:796)
-- 
dwmw2

Re: [Opensc-devel] Towards release 0.15.0

[David W. <dw...@in...>]

On Tue, 2015-05-12 at 21:28 +0200, Ludovic Rousseau wrote:
> What may happen is that the process is forked between steps 2 and 3.
> Both processes (father and son) share the same socket connection to
> pcscd. They are both identified as client 14.
> 
> One process releases the context while the other process wants to
> continue to use it.

Right. That's close enough to what I had understood that I'm going to
pretend I was correct :)

> In your patch at
> http://sourceforge.net/p/opensc/mailman/message/34086897/ you write:
> +               /* We cannot touch the PC/SC context since it
> +                * belongs to the parent process. FIXME: For now
> +                * just leak it */
> +               context = NULL;
> 
> This is not a leak. With pcsc-lite nothing is allocated on the client
> side.

The difference between the code I add, and the existing call to
C_Finalize() that it replaces, is partly that the new version does not
make the call to sc_release_context().

The penultimate line of sc_release_context(), in src/libopensc/ctx.c,
is 'free(ctx)'.

We are not freeing that memory. That's what I meant when I said it was
a 'leak'.

However, I'm not sure we care. After we fork, there are a *lot* of
other data structures left lying around that are no longer reachable.
And probably stacks of other threads in the original parent, and other
stuff. I'm not going to lose sleep over it.

>  So after a fork no resource is duplicated (except an open file
> descriptor).

An open file descriptor which we happily pass on to whatever is
executed by the child process. We should open our file descriptors
with O_CLOEXEC, but that's a somewhat orthogonal issue.

> So it is fine to just ignore a PC/SC context in one of the two
> processes after a fork.
> It is NOT fine to release a PC/SC context in one process and continue
> to use it in the other process.

Right. You can use it in *one* of the two processes after a fork.
It doesn't have to be the *parent* process.

In the PKCS#11 case it isn't "one of the two processes" that may
continue to use an established context. It is only the parent. At
least according to the non-normative Usage Guide. Right there in
§2.5.2 where it basically *tells* you to violate the POSIX
restrictions on what you can do in the child after forking from a
multi-threaded process :)

Unless it's absolutely necessary, I don't think PC/SC should impose
those same semantics — I think "one of the two" is the better answer.

> 1. Maybe I should reuse the version found in
> https://anonscm.debian.org/cgit/pcsclite/PCSC.git/commit/?id=2a8bd7a0
> 2. Or maybe the developer knows what he is doing and PC/SC should not
> automatically invalidate handles in the son process.
> What do you prefer?

I think what I just said translates to preferring the latter of these.

> > That crash certainly shouldn't happen, and looks like a PC/SC bug.
> 
> Crashing is not the correct way to manage the fork :-)

Hey, it leaves you with only one process and thus no contention about
which one owns the context :)

> I think your patch in
> http://sourceforge.net/p/opensc/mailman/message/34086897/ is a 
> correct way to solve the problem (on the PC/SC side).

On the OpenSC side, you mean?

-- 
David Woodhouse                            Open Source Technology Centre
Dav...@in...                              Intel Corporation

Re: [Opensc-devel] Towards release 0.15.0

[Douglas E E. <dee...@gm...>]

I would like to see "PIV - read just length of object to get size" #462
included in 0.15.0. I see it is in master as:

https://github.com/OpenSC/OpenSC/commit/c7af08c68a5bb3e753b008822e947d52016266c0

On 5/11/2015 11:09 AM, Viktor Tarasov wrote:
> Hi,
>
> I would like to finalize the next release during the upcoming weekend,
> the main awaited feature - update of minidriver - is merged into master and release branches.
>
> It's still time to fix the outstanding bugs or to attach the pending issues to the departing train.




>
> Tests of current 'master' or 'O.15.0' branch are heartily welcomed,
> especially the minidriver -- smartcard logon, PIN management.
>
> Best regards,
> Viktor.
>
>
>
> On 03/22/2015 11:28 AM, Vikt,
>
> or Tarasov wrote:
>> Hi,
>>
>> I propose to prepare the next 0.15.0 release. The dedicated branch is created.
>>
>> Please tell if there are outstanding bugs that have to be fixed,
>> something essential is still to be integrated into this release.
>>
>> Any proposals, suggestions, test results are heartily wellcome.
>>
>> Best regards,
>> Viktor.
>>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> .
>

-- 

  Douglas E. Engert  <DEE...@gm...>

Re: [Opensc-devel] Travis-ci problems?

[Frank M. <mo...@in...>]

Seems to happen from time to time. osx is still an experimental feature of Travis ci.

Frank Morgner

Am 13.05.2015 2:58 vorm. schrieb Douglas E Engert <dee...@gm...>:
>
>
>
> https://travis-ci.org/OpenSC/OpenSC/jobs/62309767 
>
> No output has been received in the last ... minutes, this potentially indicates a stalled build or something wrong with the build itself. 
>
> The build has been terminated 
>
>
>
>
> -- 
>
>   Douglas E. Engert  <DEE...@gm...> 
>
>
> ------------------------------------------------------------------------------ 
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications 
> Performance metrics, stats and reports that give you Actionable Insights 
> Deep dive visibility with transaction tracing using APM Insight. 
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y 
> _______________________________________________ 
> Opensc-devel mailing list 
> Ope...@li... 
> https://lists.sourceforge.net/lists/listinfo/opensc-devel 

[Opensc-devel] Travis-ci problems?

[Douglas E E. <dee...@gm...>]

https://travis-ci.org/OpenSC/OpenSC/jobs/62309767

No output has been received in the last ... minutes, this potentially indicates a stalled build or something wrong with the build itself.

The build has been terminated




-- 

  Douglas E. Engert  <DEE...@gm...>

Re: [Opensc-devel] Towards release 0.15.0

[Ludovic R. <lud...@gm...>]

Hello,

2015-05-12 16:29 GMT+02:00 David Woodhouse <dw...@in...>:
> On Tue, 2015-05-12 at 11:43 +0200, Frank Morgner wrote:
>>
>> Is this identical to https://github.com/OpenSC/OpenSC/issues/333 ;?
>
>
> It's closely related, at least.
>
> It all stems from the recommendation in the PKCS#11 Usage Guide that a
> process should call C_Initialize() on loaded modules immediately after
> forking.
>
>> As far as I can see from the github issue, #333 is a problem in
>> Apple's PC/SC implementation
>
> I'm not entirely sure where the finger should be pointed. Quite
> frankly, it would be better just not to make the pointless call to
> C_Initialize() when *all* we are going to do after forking is exec
> something else. I actually have a cheap hack to 'fix' the problem in
> OpenVPN just by using vfork() instead of fork(), so the problematic
> pthread_atfork() handler doesn't run :)
>
> OpenSC is potentially implicated here, because after a fork it is
> confusing PC/SC by continuing to let both parent and child talk to
> pcscd over the same RPC mechanism. Or maybe PC/SC isn't "confused" per
> se — maybe the child tells it to power down the card, and the parent
> then continues to try to use it?

I have re-read your logs at http://david.woodhou.se/pcsc-debug.txt

What happens (if I interpret the logs correctly) is that:
1- the application is creating a PC/SC context at line 142
00000322 winscard_svc.c:353:ContextThread() Received command:
ESTABLISH_CONTEXT from client 14

The client is identified as client 14 on the pcscd side.

2- the context is used

3- the context is released at line 816
00000108 winscard_svc.c:353:ContextThread() Received command:
RELEASE_CONTEXT from client 14
00000009 winscard.c:227:SCardReleaseContext() Releasing Context: 0x3FA91BB
00000004 winscard_svc.c:461:ContextThread() RELEASE_CONTEXT rv=0x0 for client 14

4- the context is reused at line 864
00021883 winscard_svc.c:353:ContextThread() Received command:
CMD_GET_READERS_STATE from client 14
00000033 winscard_svc.c:353:ContextThread() Received command:
CMD_GET_READERS_STATE from client 14
00000096 winscard_svc.c:353:ContextThread() Received command:
CMD_GET_READERS_STATE from client 14
00000052 winscard_svc.c:353:ContextThread() Received command:
CMD_GET_READERS_STATE from client 14
00000022 winscard_svc.c:353:ContextThread() Received command: STATUS
from client 14
00000007 winscard_svc.c:944:MSGCheckHandleAssociation() Invalidated handle

What may happen is that the process is forked between steps 2 and 3.
Both processes (father and son) share the same socket connection to
pcscd. They are both identified as client 14.

One process releases the context while the other process wants to
continue to use it.

In your patch at
http://sourceforge.net/p/opensc/mailman/message/34086897/ you write:
+               /* We cannot touch the PC/SC context since it
+                * belongs to the parent process. FIXME: For now
+                * just leak it */
+               context = NULL;

This is not a leak. With pcsc-lite nothing is allocated on the client
side. So after a fork no resource is duplicated (except an open file
descriptor).
So it is fine to just ignore a PC/SC context in one of the two
processes after a fork.
It is NOT fine to release a PC/SC context in one process and continue
to use it in the other process.

pcsc-lite had different versions of code to manage fork() in the client library.
https://anonscm.debian.org/cgit/pcsclite/PCSC.git/commit/?id=b4d935a73e84b899dbf63bc97bca0c50c9b84f5b
https://anonscm.debian.org/cgit/pcsclite/PCSC.git/commit/?id=76d1226ca6443c5ce2b3564369ed97ac9dbb9acb
https://anonscm.debian.org/cgit/pcsclite/PCSC.git/commit/?id=2a8bd7a04bedcf99f8d8214b2ecbf8f0ef268c6f
https://anonscm.debian.org/cgit/pcsclite/PCSC.git/commit/?id=a6b3ab6d44f5f8768b6ddb55c9aeb2ff3bd78578

1. Maybe I should reuse the version found in
https://anonscm.debian.org/cgit/pcsclite/PCSC.git/commit/?id=2a8bd7a04bedcf99f8d8214b2ecbf8f0ef268c6f
2. Or maybe the developer knows what he is doing and PC/SC should not
automatically invalidate handles in the son process.
What do you prefer?

I am afraid the PC/SC specification have not documented what should
happen after a fork().
Windows has nothing equivalent to fork(). So the "do like Windows"
will not help pcsc-lite.

> In the OSX case shown in #333 it seem OSX has a different RPC
> mechanism for talking to PC/SC than Linux, and when OpenSC misuses the
> parent's connection from the child there's actually a crash in the RPC
> library.
>
> That crash certainly shouldn't happen, and looks like a PC/SC bug.

Crashing is not the correct way to manage the fork :-)

> But I think it's still really an OpenSC issue.
>
>> Also, please open a PR with your example code on github to get feedback.
>> Then this issue doesn't lost in some mail archive.
>
> I've updated #333 with a reference to the test case and noted that it
> occurs on Linux too.

I think your patch in
http://sourceforge.net/p/opensc/mailman/message/34086897/ is a correct
way to solve the problem (on the PC/SC side).

Regards,

-- 
 Dr. Ludovic Rousseau

Re: [Opensc-devel] Towards release 0.15.0

[David W. <dw...@in...>]

On Tue, 2015-05-12 at 11:43 +0200, Frank Morgner wrote:
> 
> Is this identical to https://github.com/OpenSC/OpenSC/issues/333 ;? 


It's closely related, at least.

It all stems from the recommendation in the PKCS#11 Usage Guide that a
process should call C_Initialize() on loaded modules immediately after
forking.

> As far as I can see from the github issue, #333 is a problem in
> Apple's PC/SC implementation

I'm not entirely sure where the finger should be pointed. Quite
frankly, it would be better just not to make the pointless call to
C_Initialize() when *all* we are going to do after forking is exec
something else. I actually have a cheap hack to 'fix' the problem in
OpenVPN just by using vfork() instead of fork(), so the problematic
pthread_atfork() handler doesn't run :)

OpenSC is potentially implicated here, because after a fork it is
confusing PC/SC by continuing to let both parent and child talk to
pcscd over the same RPC mechanism. Or maybe PC/SC isn't "confused" per
se — maybe the child tells it to power down the card, and the parent
then continues to try to use it?

In the OSX case shown in #333 it seem OSX has a different RPC
mechanism for talking to PC/SC than Linux, and when OpenSC misuses the
parent's connection from the child there's actually a crash in the RPC
library.

That crash certainly shouldn't happen, and looks like a PC/SC bug.
But I think it's still really an OpenSC issue.

> Also, please open a PR with your example code on github to get feedback.
> Then this issue doesn't lost in some mail archive.

I've updated #333 with a reference to the test case and noted that it
occurs on Linux too.

-- 
dwmw

Re: [Opensc-devel] Towards release 0.15.0

[Frank M. <mo...@in...>]

On Monday, May 11 at 05:28PM, David Woodhouse wrote:
> On Mon, 2015-05-11 at 18:09 +0200, Viktor Tarasov wrote:
> > I would like to finalize the next release during the upcoming weekend
> > ,
> > the main awaited feature - update of minidriver - is merged into 
> > master and release branches.
> > 
> > It's still time to fix the outstanding bugs or to attach the pending 
> > issues to the departing train.
> 
> It would be good to fix the breakage with calling C_Initialize() in the
> child after fork, which prevents OpenSC from working correctly when used
> with OpenVPN: http://sourceforge.net/p/opensc/mailman/message/34086897/

Is this identical to https://github.com/OpenSC/OpenSC/issues/333 ? As
far as I can see from the github issue, #333 is a problem in Apple's
PC/SC implementation

Also, please open a PR with your example code on github to get feedback.
Then this issue doesn't lost in some mail archive.

-- 
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc

Re: [Opensc-devel] Towards release 0.15.0

[David W. <dw...@in...>]

On Mon, 2015-05-11 at 18:09 +0200, Viktor Tarasov wrote:
> I would like to finalize the next release during the upcoming weekend
> ,
> the main awaited feature - update of minidriver - is merged into 
> master and release branches.
> 
> It's still time to fix the outstanding bugs or to attach the pending 
> issues to the departing train.

It would be good to fix the breakage with calling C_Initialize() in the
child after fork, which prevents OpenSC from working correctly when used
with OpenVPN: http://sourceforge.net/p/opensc/mailman/message/34086897/



-- 
dwmw2

Re: [Opensc-devel] Towards release 0.15.0

[Viktor T. <vik...@gm...>]

Hi,

I would like to finalize the next release during the upcoming weekend,
the main awaited feature - update of minidriver - is merged into master and release branches.

It's still time to fix the outstanding bugs or to attach the pending issues to the departing train.

Tests of current 'master' or 'O.15.0' branch are heartily welcomed,
especially the minidriver -- smartcard logon, PIN management.

Best regards,
Viktor.



On 03/22/2015 11:28 AM, Vikt,

or Tarasov wrote:
> Hi,
>
> I propose to prepare the next 0.15.0 release. The dedicated branch is created.
>
> Please tell if there are outstanding bugs that have to be fixed,
> something essential is still to be integrated into this release.
>
> Any proposals, suggestions, test results are heartily wellcome.
>
> Best regards,
> Viktor.
>

Re: [Opensc-devel] OpenSC minidriver and Windows Authenticode certificates

[Andreas S. <and...@ca...>]

Dear Marco,

the SmartCard-HSM only supports encrypted key import for security
reason. This will not work with tools provided by OpenSC.

We generally advice users to generate keys on the device and use the
backup/restore facility for important keys. This ensures proper access
control to key material and ensures secrecy even while keys are in transit.

The SmartCard-HSM SDK contains a script to import RSA keys from PKCS#12
files into a SmartCard-HSM. The SDK is a commercial product, but if you
need just the script, then that will be available for free under NDA.

Please send me a pm, so we can get that sorted out.

Andreas

On 05/07/2015 03:49 PM, Marco Giuliani wrote:
> Hello,
> I just got a smartcard-HSM and I wanted to use it to store my code signing certificate used for usermode and kernelmode Authenticode code signing. I have a PFX file right now, containing the public+private key and I saw that signtool.exe can use CSP to sign PE files. 
> Did anybody try storing the code signing certificate into a HSM like Smartcard-HSM through OpenSC and using it for code signing?
> Does anybody know how to properly do it? Like how to convert the PFX in something I can import to the HSM?
> Thanks for your support!
> Marco 		 	   		  
> 
> 
> 
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> 
> 
> 
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> 


-- 

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Schülerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org
                 http://www.smartcard-hsm.com

Re: [Opensc-devel] iso7816_process_fci: getting the size of the file

[Douglas E E. <dee...@gm...>]

On 5/10/2015 1:48 PM, Vincent Le Toux wrote:
> Hi,
>
> I've a question about how the file size is retrieved.
> It is implemented in iso7816.c: https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/iso7816.c#L362-373
>
> I'm not a DER expert that's why I'm asking.

DER is ASN.1

This has been handy...
"A Layman's Guide to a Subset of ASN.1, BER, and DER"
can be found as html or PDF:

http://luca.ntop.org/Teaching/Appunti/asn1.html

http://homepages.dcc.ufmg.br/~coelho/nm/asn.1.intro.pdf

>
> Is a size encoded with the attribute 0x80 with 4 bytes valid ?
> How can I find the difference between 0x81 & 0x80 ?

http://en.wikipedia.org/wiki/X.690
Sounds like you are referring to "The definite form" vs "The indefinite form"

>
> I get a card with both 0x80 (4 bytes) and 0x81 (2 bytes) tags.
> If a 4 bytes is valid, I'd like to propose a patch to the iso7816.c file to handle it.


ISO7816-4 5.2.1 SIMPLE-TLV, 5.2.2 BER-TLV, and  5.2.2.2 BER-TLV length fields
and the lengths are handled differently. So you need to know which one is being used.

>
> regards,
> --
> --
> Vincent Le Toux
>
> My Smart Logon
> www.mysmartlogon.com <http://www.mysmartlogon.com/>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

-- 

  Douglas E. Engert  <DEE...@gm...>

Re: [Opensc-devel] iso7816_process_fci: getting the size of the file

[Vincent Le T. <vin...@my...>]

got the anwser:
in ISO/IEC 7816-4:2013(E), chapter 7.4.3.

Table 10 — Control parameter data objects

Tag | Length | Value | Applies to
'80' Var. Number of data bytes in the file, excluding structural
information Any EF*
'81' Var. Number of data bytes in the file or DO, including structural
information if any File* or DO*

both tag 0x80 and 0x81 can be 4 bytes in length

vincent

2015-05-10 21:57 GMT+02:00 Vincent Le Toux <vin...@my...>
:

> Hi Frank
>
> Can you indicate to me in which chapter for iso 7816-4 the variable 0x80
> encoding size is defined ?
> I have the ISO/IEC 7816-4:2013 version.
>
> Thanks in advance
>
> regards,
> Vincent
>
> 2015-05-10 21:18 GMT+02:00 Frank Morgner <mo...@in...>
> :
>
>> On Sunday, May 10 at 08:48PM, Vincent Le Toux wrote:
>> > Hi,
>> >
>> > I've a question about how the file size is retrieved.
>> > It is implemented in iso7816.c:
>> >
>> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/iso7816.c#L362-373
>> >
>> > I'm not a DER expert that's why I'm asking.
>> >
>> > Is a size encoded with the attribute 0x80 with 4 bytes valid ?
>> > How can I find the difference between 0x81 & 0x80 ?
>> >
>> > I get a card with both 0x80 (4 bytes) and 0x81 (2 bytes) tags.
>> > If a 4 bytes is valid, I'd like to propose a patch to the iso7816.c
>> file to
>> > handle it.
>>
>> You most likely are interested in the 0x80 size only. See
>>
>> http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_5_basic_organizations.aspx#table2
>>
>> Newer versions of ISO 7816-4 define the length of 0x80 to be variable
>> and the length of 0x81 to be 2. So your card is conforming to the
>> standard though there are cases where the ISO's restriction does not
>> make sense.
>>
>> --
>> Frank Morgner
>>
>> Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
>> OpenPACE                        http://openpace.sourceforge.net
>> IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Opensc-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>>
>
>
> --
> --
> Vincent Le Toux
>
> My Smart Logon
> www.mysmartlogon.com
>



-- 
--
Vincent Le Toux

My Smart Logon
www.mysmartlogon.com

Re: [Opensc-devel] iso7816_process_fci: getting the size of the file

[Vincent Le T. <vin...@my...>]

Hi Frank

Can you indicate to me in which chapter for iso 7816-4 the variable 0x80
encoding size is defined ?
I have the ISO/IEC 7816-4:2013 version.

Thanks in advance

regards,
Vincent

2015-05-10 21:18 GMT+02:00 Frank Morgner <mo...@in...>:

> On Sunday, May 10 at 08:48PM, Vincent Le Toux wrote:
> > Hi,
> >
> > I've a question about how the file size is retrieved.
> > It is implemented in iso7816.c:
> >
> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/iso7816.c#L362-373
> >
> > I'm not a DER expert that's why I'm asking.
> >
> > Is a size encoded with the attribute 0x80 with 4 bytes valid ?
> > How can I find the difference between 0x81 & 0x80 ?
> >
> > I get a card with both 0x80 (4 bytes) and 0x81 (2 bytes) tags.
> > If a 4 bytes is valid, I'd like to propose a patch to the iso7816.c file
> to
> > handle it.
>
> You most likely are interested in the 0x80 size only. See
>
> http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_5_basic_organizations.aspx#table2
>
> Newer versions of ISO 7816-4 define the length of 0x80 to be variable
> and the length of 0x81 to be 2. So your card is conforming to the
> standard though there are cases where the ISO's restriction does not
> make sense.
>
> --
> Frank Morgner
>
> Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
> OpenPACE                        http://openpace.sourceforge.net
> IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
>


-- 
--
Vincent Le Toux

My Smart Logon
www.mysmartlogon.com

Re: [Opensc-devel] iso7816_process_fci: getting the size of the file

[Frank M. <mo...@in...>]

On Sunday, May 10 at 09:18PM, Frank Morgner wrote:
> On Sunday, May 10 at 08:48PM, Vincent Le Toux wrote:
> > Hi,
> > 
> > I've a question about how the file size is retrieved.
> > It is implemented in iso7816.c:
> > https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/iso7816.c#L362-373
> > 
> > I'm not a DER expert that's why I'm asking.
> > 
> > Is a size encoded with the attribute 0x80 with 4 bytes valid ?
> > How can I find the difference between 0x81 & 0x80 ?
> >
> > I get a card with both 0x80 (4 bytes) and 0x81 (2 bytes) tags.
> > If a 4 bytes is valid, I'd like to propose a patch to the iso7816.c file to
> > handle it.
> 
> You most likely are interested in the 0x80 size only. See
> http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_5_basic_organizations.aspx#table2
> 
> Newer versions of ISO 7816-4 define the length of 0x80 to be variable
> and the length of 0x81 to be 2. So your card is conforming to the
> standard though there are cases where the ISO's restriction does not
> make sense.

Update: The newest version of the standard should have both length variable.

-- 
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc

Re: [Opensc-devel] iso7816_process_fci: getting the size of the file

[Frank M. <mo...@in...>]

On Sunday, May 10 at 08:48PM, Vincent Le Toux wrote:
> Hi,
> 
> I've a question about how the file size is retrieved.
> It is implemented in iso7816.c:
> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/iso7816.c#L362-373
> 
> I'm not a DER expert that's why I'm asking.
> 
> Is a size encoded with the attribute 0x80 with 4 bytes valid ?
> How can I find the difference between 0x81 & 0x80 ?
>
> I get a card with both 0x80 (4 bytes) and 0x81 (2 bytes) tags.
> If a 4 bytes is valid, I'd like to propose a patch to the iso7816.c file to
> handle it.

You most likely are interested in the 0x80 size only. See
http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_5_basic_organizations.aspx#table2

Newer versions of ISO 7816-4 define the length of 0x80 to be variable
and the length of 0x81 to be 2. So your card is conforming to the
standard though there are cases where the ISO's restriction does not
make sense.

-- 
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc

[Opensc-devel] iso7816_process_fci: getting the size of the file

[Vincent Le T. <vin...@my...>]

Hi,

I've a question about how the file size is retrieved.
It is implemented in iso7816.c:
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/iso7816.c#L362-373

I'm not a DER expert that's why I'm asking.

Is a size encoded with the attribute 0x80 with 4 bytes valid ?
How can I find the difference between 0x81 & 0x80 ?

I get a card with both 0x80 (4 bytes) and 0x81 (2 bytes) tags.
If a 4 bytes is valid, I'd like to propose a patch to the iso7816.c file to
handle it.

regards,
-- 
--
Vincent Le Toux

My Smart Logon
www.mysmartlogon.com

Re: [Opensc-devel] RFC7512: The PKCS #11 URI Scheme

[David W. <dw...@in...>]

On Fri, 2015-04-24 at 14:25 +0100, David Woodhouse wrote:
> On Fri, 2015-04-24 at 12:56 +0200, Ludovic Rousseau wrote:
> > [1] http://www.bortzmeyer.org/7512.html (in french)
> 
> Note that the Fedora packaging guidelines mentioned there are purely a
> *proposal*, put forth by myself. It's not part of the official Fedora
> packaging guidelines yet.

Update: it is now, or will be once the Fedora Packaging Committee gets
round to writing up the decision they just made in today's meeting.

If there is any software in Fedora which uses X.509 certificates but
which *doesn't* automatically use the PKCS#11 providers from the
system's p11-kit configuration, and/or which doesn't accept
certificates specified in the form of a RFC7512 PKCS#11 URI, please
file a bug and mark it as blocking the 'PKCS#11 sanity tracker':

https://bugzilla.redhat.com/showdependencytree.cgi?id=PKCS11

-- 
David Woodhouse                            Open Source Technology Centre
Dav...@in...                              Intel Corporation

[Opensc-devel] OpenSC minidriver and Windows Authenticode certificates

[Marco G. <mar...@ou...>]

Hello,
I just got a smartcard-HSM and I wanted to use it to store my code signing certificate used for usermode and kernelmode Authenticode code signing. I have a PFX file right now, containing the public+private key and I saw that signtool.exe can use CSP to sign PE files. 
Did anybody try storing the code signing certificate into a HSM like Smartcard-HSM through OpenSC and using it for code signing?
Does anybody know how to properly do it? Like how to convert the PFX in something I can import to the HSM?
Thanks for your support!
Marco 		 	   		  

Re: [Opensc-devel] Pinpad support with PC/SC

[Ludovic R. <lud...@gm...>]

2015-04-21 9:56 GMT+02:00 Ludovic Rousseau <lud...@gm...>:
> 2015-04-21 9:51 GMT+02:00 Martin Paljak <ma...@ma...>:
>> On 21/04/15 10:44, Ludovic Rousseau wrote:
>>> Comments, questions, remarks, etc. are greatly welcome.
>>
>> A HTML version with linkable sections.
>
> Good idea. But...
> Documentation from the PC/SC workgroup are .doc files converted to .pdf.
>
> I think that providing an HTML version will be too much change for the
> workgroup. I will try to push the idea.

The HTML version of the PC/SC specifications are now online at the
same place as the PDF version [1].
The conversion DOC -> HTML has been done using Google Docs and are not
perfect. For example the table of contents is not URL links to other
parts of the document.

If you know a better DOC to HTML convert tool please tell me. I tried
LibreOffice.org but the result is not much better. Using Microsoft
Word has other problems.

Bye

[1] http://pcscworkgroup.com/specifications/specdownload.php

-- 
 Dr. Ludovic Rousseau