[Muscle] [PATCH] Do not use EEPROM (at all) with cards that support extended APDUs

[Joao Pedro]

"s.ferey" <s.ferey at wanadoo.fr> wrote:

> Joao Pedro wrote :
>> Ludovic Rousseau <ludovic.rousseau at gmail.com> wrote:
>>
>>> Joao, do you want a write access to the Applet code? I am not a java
>>> card user so can't review or comment on your patches. It would be more
>>> efficient to commit yourself the changes (after discussing them on
>>> this list if needed).
>>>
>> Wow, thank you for your trust! I want to accept, but I'm afraid that,
>> maybe, I'm not experienced enough to handle this kind of responsibility.
>> I've just recently started learning about smart cards and have learned a
>> lot with people like you, Ludovic, Sylvain, etc... But I don't know if
>> I'm really prepared. Maybe if Sylvain is also interested (Sylvain please
>> comment on this), we could share write access. If you've been following
>> the recent discussions, he has shown to be a very talented and
>> experienced java card developer...
>
> I don't feel necessary to share the write access, it should be managed
> by a few number of personns - or it will be a wiki-repository, it can
> be fine, but it's different.
>
> I'm not fluent with svn, nor with the diff tool you used to generate
> the logs posted in this list, so I'm not skilled to manage the
> repository.
Ok, I can handle this task.

> OOH, I'm quite experienced (about 10 years) in applet development,
> so I will accept to review the suggested changes before they are
> recorded; if you don't feel confident to commit yourself, I can
> manage the approval. And of course, if anyone wants to propose
> a change, I can review it.
That would be great!

Regarding the new middleware mentioned earlier (in case changes are  
needed), I think we can have two initial approaches:
1. Create a patch to Musclecard's middleware after the applet is  
changed and then wait for approval (in case the API changes) - this  
can be done but, to be honest, I don't use it and  I'm not very  
familiar with it right now. We could study the middleware's source and  
then we could implement the changes. But I think this would have to be  
discussed first on the list to know what the creators/maintainers  
think about the idea...

2. Change/create a new OpenSC [1] driver for the "new" CardEdge  
applet. OpenSC is the middleware I use and I'm familiar with the  
Muscle driver. I prefer the OpenSC middleware because it is (anyone  
please correct me if I'm wrong) more maintained. For example, with  
OpenSC + the CardEdge applet I have my smart card fully integrated  
with Mac OS X (I can sign emails, login with the smart card, etc.).  
The downside is that the the OpenSC Muscle driver doesn't take full  
advantage of the CardEdge applet (some operations are not used) and it  
has to emulate a PKCS #15 file system because OpenSC depends on it.

The source code of the Muscle driver in OpenSC is at [2] and [3].

I don't know... this is only an idea... Suggestions are welcome.

Regards,
Joao

[1] - http://www.opensc-project.org/
[2] -  
http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card-muscle.c
[3] -  
http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/muscle.c
[4] -  
http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/muscle-filesystem.c