[Muscle] Re: Muscle mailing list access

[Sylvain Ferey]

Hi Martin,

>>these points are not closed, nor their purposes is to criticize the applet,
>>I asked several times if the applet is currently supported, and in case by
>>who (group or person) and didn't get any responses.
>
><http://svn.debian.org/viewsvn/muscleplugins/trunk/MCardApplet/?rev=284#dirlist>http://svn.debian.org/viewsvn/muscleplugins/trunk/MCardApplet/?rev=284#dirlist


Many thanks for that link !! I missed it.
All my comment (including those regarding the "encrypt issue") was made 
from an analysis of the decompiled class files found on muscle site.
That full source contains much more functions, this minimal version was 
certainly build to make as less assumptions on the platforms as possible.



>reveals that Mr. Ludovic Rousseau and Mr. Karsten Ohme are the last 
>contributors, if you are able to improve the overall design and compliancy 
>please feel invited to join the project at
>
><http://alioth.debian.org/projects/muscleplugins>http://alioth.debian.org/projects/muscleplugins

thanks for the invitation ;-)


>>Posting on a mailing-list expose contributors to spam - since actual 
>>email address
>>is required (I do receive a lot of new spams since I'm posting there).
>
>We had lots of spam here in the list, before David switched to that 
>policy. I doubt that my presence especially here has significantly 
>increased spam in my mailboxes, but I never analyzed that and BTW: how could I?

my point was certainly a little bit wrong, if this list is not present - 
with full authors email address - on a web site, the new spams do not come 
from this subscription.


>P.S.: I use the the muscleapplet 0.9.8 on a Cyberflex DeveloperAccess32K 
>and CFlex64K e-gate from Schlumberger/Axalto since more than 4 years for 
>daily signing and encryption work and never had problems with ISO 
>compliancy, EEPROM damage and the like.

AFAIK the e-gate uses "indestructible memory" - mem. that can be write w/o 
limit.
more classic cards including Cyberflex grant only 100.000 write operations 
for EEPROM cell; the applet makes useless EEPROM writes but once per 
signature & cell, the card will so not be damaged before a quiet long time; 
I saw some guys polling their cards with signature requests issued at least 
every seconds, in such case they kill cards in quiet short time.

ISO compliance simply facilitates card integration into different 
frameworks, once it works on a given env. nobody cares nor remembers how 
compliant it was. At the card level, ISO compliance also allows better code 
reuse, but it's not an user's concern.

Sylvain.