[Spice-devel] RFC - Direct smart card support in libcacard/spice-gtk

[Jeremy White]

>>
>> I am hoping to ask:
>>
>>    1.  Does this basic approach seem reasonable?
>
> I think VCardEmulType VCARD_EMUL_PASSTHRU was supposed to be used for
> this case, although the current code doesn't make it straightforward
> to add that, as it initializes nss in vcard_emul_init. It should be
> possible to change that though.

Yeah, I didn't see a clear way to make use of that.  If we're going to 
proceed, and put it in libcacard, it seems to me that the nomenclature 
is a bit off.  That is, vcard_emul_nss.c sort of holds the 'main' entry 
points (e.g. vcard_emul_init/vcard_emul_options).

Arguably, if we have a 'real' card, it seems like that stuff should 
shift into vcard and/or vreader and/or a new file, and the emul stuff 
should become subsidiary.

That started to become invasive in a way that messed with doing a fun 
little one of POC, so I didn't :-/.

If there is a more surgical way that makes sense to you, I'd appreciate 
a pointer.  I tend to get myopic on these things.


>
> It probably doesn't make much sense to push this in libcacard if you
> don't reuse any of the cacard framework.

Hmm.  So you're suggesting that if libcacard doesn't seem like a good 
home, we should move this back to spice-gtk?

>
>> I believe that, with this change, a system that was not otherwise using a
>> smart card could relay that smart card on to a distant Spice server. I'm
>> uncertain what would happen in the case where the smart card was in use by
>> the local system.  That's something I'll need to probe yet.  I imagine that
>> it won't work, but have no real hard evidence for that :-/.
>
> It could be that pcscd can actually lock concurrent requests and reply
> from overlaping each others, but I don't think it can handle context
> switch and apparently there is no context lock when connecting with
> pc/sc api. So it will likely go wrong in some cases.

Yeah.  I think my greatest fear is that it will appear to work, but go 
subtly wrong in hard-to-detect ways :-/.

Cheers,

Jeremy