Tommaso Cucinotta wrote: > Karsten Ohme wrote: > >> Is there a scheme for the version/release names of MCardApplet? What is >> the next version/release after 0.9.11? What happens if a function is >> deleted? If added? If the API has changed? >> > In the first proposal, it was the usual meaning for package versioning: > x) change rightmost number if just patched, repackaged, ... > x) change central number if functionality was added retaining backward > compatibility > x) change leftmost number for change of API and/or behaviour. > > GetStatus reports proto version and applet version. the second should > behave as the leftmost.central > of the applet package (well, different versions for applet itself and > package are possible). proto version > is supposed to be used for the purpose of understanding if a given MCard > plugin can talk to an on-card applet, > and is just 2 numbers, that should report leftmost.central numbers of > the protocol spec. > > Looking at just the delete related commands, seems a functionality add > (0.10.0 ?). Don't know if you > kept compatibility at the APDU level for other commands.
Yes. The applet checks the expected response and incoming data length and reacts accordingly. David proposed 1.0.1. Dont' know how this fit with the above. The libtool versioning scheme would say: current:revision:age There were added functions so increment current -> 1 The interface was changed, so revision is reset to 0. This release is backwards compatible with the previous release. So age is incremented, well this is not possible because age is always smaller or equal then current to indicate the compatibility. So the 11 would be actual 1. But for the CardEdge applet this does bot matter, this is only used for Unix libraries to detect if they are compatible with each other. So, 1.0.1 is a beautiful number and does fit in the above scheme. Your above scheme would say x) change rightmost number if just patched, repackaged, ... -> Does not apply. x) change central number if functionality was added retaining backward compatibility -> 10 x) change leftmost number for change of API and/or behavior -> 1 So 1.10.0 would be the result. > The listing restricted to usable objects would be a change of semantics > of the ListObjects/ListKeys > commands, and I would recommend keeping it as a separate patch. I have written to Peter separately, the patch cannot be applied 1:1 because the internals have changed. I got the response that the email address does not exist anymore. Well, I can keep this feature in mind and some day ... > > Just remembering that we need another thing into the TODO list, if > you're updating it: > x) support of a read-only flag for keys that says if they were generated > on-board with no > export allowed, or not (i.e. the p#11 never_exportable flag). don't > know if anybody > added it, but was a missing feature. What is the difference between the usual ACL read parameter and the read only flag? At the moment 0xFFFF 0x0020 0x0020 would mean that it cannot be read (exported) (0xFFFF) and only used (0x0020) and deleted (0x0020) by PIN#1. Please explain. Karsten > > Bye, > > T. > >> http://www.andamooka.org/reader.pl?pgid=autobookautobook_92 >> >> Thanks, Karsten >> >> Karsten Ohme wrote: >> >> >>> Ludovic Rousseau schrieb: >>> >>> >>> >>>> On 03/10/05, Karsten Ohme <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>> >>>>> So a new branch for CVS or ... or how can the different directory >>>>> structure be solved? Is it possible to move files in CVS? I believe >>>>> this >>>>> is a reason for SVN. >>>>> >>>> >>>> >>>> The two SVN repositories for muscleplugins and muscleapps have been >>>> created [1]. I will convert CVS to SVN soon. >>>> >>>> >>>> >>>> >>>>> How the compilation will look like, depends on the system. Maybe a >>>>> configurator for cards like Tommaso proposed will execute the task and >>>>> create the actual build files for a card. >>>>> >>>> >>>> >>>> No idea. I let you chose the most sensible way. >>>> >>>> Bye, >>>> >>> >>> A new version is out there which I would propose for a final new version >>> regarding the included features. >>> >>> http://web.inf.tu-dresden.de/~ko189283/MuscleCard/ >>> >>> All features are again described here: >>> >>> For the applet: >>> >>> http://web.inf.tu-dresden.de/~ko189283/MuscleCard/MCardAppletChanges.html >>> >>> >>> For the Muscle Framework: >>> >>> http://web.inf.tu-dresden.de/~ko189283/MuscleCard/libmusclecardChanges.html >>> >>> >>> From the last posting this has changed: >>> >>> Objects and Keys can be moved (renamed). >>> Objects and Key can only be associated with ACLs if also these IDs are >>> logged in. >>> If an ID is deleted, every object and key it owned is destroyed and all >>> ACLs are cleared form this ID. >>> >>> I would appreciate some tests from interested people. Together with the >>> libmusclecard version, MCardPlugin and muscleTool form the above page it >>> should be possible to test everything. I tested it in Debian GNU/Linux >>> and Windows XP. >>> >>> Are there any other security considerations? >>> >>> @Peter: Would you mind to include your patch to this version, that only >>> usable objects are listed for logged IDs? >>> >>> With some time, I will commit it into SVN. >>> >>> Bye, Karsten >>> >>> _______________________________________________ >>> Muscle mailing list >>> [email protected] >>> http://lists.drizzle.com/mailman/listinfo/muscle >>> >> >> >> _______________________________________________ >> Muscle mailing list >> [email protected] >> http://lists.drizzle.com/mailman/listinfo/muscle >> >> > > _______________________________________________ > Muscle mailing list > [email protected] > http://lists.drizzle.com/mailman/listinfo/muscle _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
