find known application identifiers in opensc-explorer

[frankmorgner]

opensc-explorer: look for known application identifiers with find

[viktorTarasov]

There are few question and suggestions:

• currently the applications list is printed on any 'find' command in MF. Does that's the wanted behavior? My suggestion would be to dedicate new command (something like 'list-applications');
• it would be better to print the AID value in a form suitable to copy&past it for another command, for example for "cd aid:AA:BB:CC:...' ;
• what is the purpose of the 'known_applications' data? As for me all this information is already present in EF.DIR. (Does yours EF.DIR's 'application-template' contain the 'application-label' ?). Do we really need to surcharge the common tool with these data ?
• please, try to follow at least the local coding style: spacing, tab, trailing spaces, ...

[frankmorgner]

• currently the applications list is printed on any 'find' command in MF. Does that's the wanted behavior? My suggestion would be to dedicate new command (something like 'list-applications');

Yes, it is wanted behavior. An application is a DF in the MF. So I think it's OK to list them with find, which is supposed to find files.

• it would be better to print the AID value in a form suitable to copy&past it for another command, for example for "cd aid:AA:BB:CC:...' ;

sc_hex_to_bin also allows spaces between the characters and so do arg_to_path or do_cd respectively. I haven't tried, but looking at the code, I think Copy & Paste could actually work. I check that later.

• what is the purpose of the 'known_applications' data? As for me all this information is already present in EF.DIR. (Does yours EF.DIR's 'application-template' contain the 'application-label' ?).

EF.Dir is not mandatory and it does not necessarily list all applications. In known_applications are listed all aids that I have seen before. They are selected to check if the application is present for the card

Do we really need to surcharge the common tool with these data ?

Sorry, I don't understand the question.

• please, try to follow at least the local coding style: spacing, tab, trailing spaces, ...

Hmm, the trailing spaces have been present before. Sure, I can remove them.

Do you mean tabs instead of spaces in the beginning of a line? OK, can fix that.

Did I miss something else regarding the style?

As general remark: Please provide a configuration for a code beautifier to avoid these problems. A commit hook could be very useful, for example.

[viktorTarasov]

• currently the applications list is printed on any 'find' command in MF. Does that's the wanted behavior? My suggestion would be to dedicate new command (something like 'list-applications');

Yes, it is wanted behavior. An application is a DF in the MF. So I think it's OK to list them with find, which is supposed to find files.

Applications list in opensc-explorer is a great idea, but still, I don't think it has to be printed on any 'find' command -- when looking for FIDs from 0020 to 002F, imho, it's not logic to see the applications list.
More, having dedicated command will allow to get applications list from any local DF, not only from MF.

• what is the purpose of the 'known_applications' data? As for me all this information is already present in EF.DIR. (Does yours EF.DIR's 'application-template' contain the 'application-label' ?).

EF.Dir is not mandatory and it does not necessarily list all applications. In known_applications are listed all aids that I have seen before. They are selected to check if the application is present for the card

If no EF.DIR, it should be present in EF.ATR or in ATR . Anyway, there should be more clever method to get know the on-card application than 'know-by-someone' application lists. For the non-standard card create a card specific tool, as like as many other cards do.

Do we really need to surcharge the common tool with these data ?

Sorry, I don't understand the question.

The applications that are not referenced in EF.DIR, EF.ATR or ATR are highly card-specific data. It should not be present in a common tool like opensc-explorer.
Create your own card specific tool.

• please, try to follow at least the local coding style: spacing, tab, trailing spaces, ...

Hmm, the trailing spaces have been present before. Sure, I can remove them.
Do you mean tabs instead of spaces in the beginning of a line? OK, can fix that.
Did I miss something else regarding the style?

For a while, there is no coding style common for entire project. It'll be.
Until that, I invite you to follow the 'local' coding style of the file where the changes are made.

As general remark: Please provide a configuration for a code beautifier to avoid these problems. A commit hook could be very useful, for example.

Right now I don't know how to do it.
Anyway, I have no admin rights on the OpenSC github project and cannot add the hook.
But, thanks for telling that, I'll think about .

[frankmorgner]

• currently the applications list is printed on any 'find' command in MF. Does that's the wanted behavior? My suggestion would be to dedicate new command (something like 'list-applications');

Yes, it is wanted behavior. An application is a DF in the MF. So I think it's OK to list them with find, which is supposed to find files.

Applications list in opensc-explorer is a great idea, but still, I don't think it has to be printed on any 'find' command -- when looking for FIDs from 0020 to 002F, imho, it's not logic to see the applications list.
More, having dedicated command will allow to get applications list from any local DF, not only from MF.

• what is the purpose of the 'known_applications' data? As for me all this information is already present in EF.DIR. (Does yours EF.DIR's 'application-template' contain the 'application-label' ?).

EF.Dir is not mandatory and it does not necessarily list all applications. In known_applications are listed all aids that I have seen before. They are selected to check if the application is present for the card

If no EF.DIR, it should be present in EF.ATR or in ATR . Anyway, there should be more clever method to get know the on-card application than 'know-by-someone' application lists. For the non-standard card create a card specific tool, as like as many other cards do.

Do we really need to surcharge the common tool with these data ?

Sorry, I don't understand the question.

The applications that are not referenced in EF.DIR, EF.ATR or ATR are highly card-specific data. It should not be present in a common tool like opensc-explorer.
Create your own card specific tool.

find is a brute force tool. It searches for every FID possible. I
would also do this for possible AIDs, but they are simply too long.
Consider the list of known applications as educated guesses. The brute
force approach is independent from the type of card. Note that the ls
command already provides a card specific command to list files.

[frankmorgner]

Changed commit to use tabs instead of spaces. Also, applications and files with FID are better separated now.

[frankmorgner]

Changed commit to use aid format of cd.

As imporvement, the existing commands could be more resilient, by, for example allowing whitespaces in hex data.

[viktorTarasov]

To resume:

• there is segmentation fault in 'try_application()';
• highly specific 'known-applications' are still present in the common tool;
• applications list is still printed on every 'find' command;
• space and tabs mixed (ex. in the part of 'try_application()').

[frankmorgner]

soory for the noise. seems like i pushed something completely wrong to the branch. Now it should work (it actually is tested).

• known applications are still present, but please note that they are not specific to one special card. above, i explained why.
• applications are still printed with find, which i also explained above

[viktorTarasov]

known applications are still present, but please note that they are not specific to one special card. above, i explained why.

Common tools are for the cards that use the common mechanisms, and in particular, the common mechanism to detect the the on-card application.
The 'a priori knowledge' is not a common mechanism to detect on-card application. If your card(s) supports only this one -- please, make a card specific tool.

applications are still printed with find, which i also explained above

• there is the output for an attempt to get the FIDs from 2F00 to 2F10, that for my taste contains a lot of information that has nothing to the requested data:

OpenSC [3F00]> find 2F00 2F10
Applications
Adèle
aid:E828BD080FD2500000040101
Adèle
aid:D2500000044164E86C650101
Adèle Générique
aid:E828BD080FD2500000040301
Adèle Haute Sécurité-Administrateur 2
aid:E828BD080FD2500000040201
ADF Emetteur non P15
aid:414446456D657474657572

FileID Type Size
2F00 wEF 236
2F01 wEF 61

• the command 'cd aid:...' can be executed from any AID/DF of the card. So, if you are implementing the 'list applications' facility, it should have possibility to be executed from any AID/DF of the card, not only from MF.

[JenkinsForOpenSC]

Can one of the admins verify this patch?

[viktorTarasov]

Sorry, this pull request was closed when the unused 'staging' branch of OpenSC github project was deleted.

If this pull request is still actual for you,
please, do the same to the 'master' branch.