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.
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.
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.
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
