Re: [opensc-devel] A bug in ifd_atr_parse for ATRs with absent TD1...TD4
thanks, commited to openct trunk. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ACL types for the PINs
Am Dienstag 03 November 2009 13:41:07 schrieb Viktor TARASOV:
> Hi,
>
> I would like to update the support of the Oberthur card
> and to implement the PIN unblocking style of the Oberthur's native
> middleware.
>
> For the Oberthur card a PIN is some internal object (it's not like a SDO
> object)
> and the ACLs for the PIN operations ('RESET', 'CHANGE' and 'DEFINE')
> are included into the ACLs of the parent DF.
>
> So, my question is.
> Will it be acceptable to introduce some new SC_AC_OP_ types
> to make possible the control of these ACLs by the card profile?
sorry, not much clue here how opensc works with acls.
when you create / set ACL on a DF, you need to know both the
settings for the DF itself, as well for embedded objects?
so you need extra flags passed down the chain to handle those?
or can you create the DF firsth with conserative settings,
and have a second funciton call to update it to set the
values for the embedded objects?
how do other cards work? I guess the df is created with
df acl passed to it, and the pin is created with pin acl
passed down the function chain?
Regards, Andreas
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] 'return' versus 'SC_FUNC_RETURN'
hmm, debugging is a problem in opensc code. here are my ideas. I haven't figured out how to ltrace opensc, mostly when it used via opensc- pkcs11.so. so what can I do to find a bug? a) gdb and single step, taking notes till I find out how opensc works in some area and get a clue where the bug is. b) ask for a log file and see if I can figure out what is going wrong. but a) doesn't help if other people have a problem, I would need to reproce the problem first, and thus very few people can debug a problem (those with the same OS, the same app, the same card...). b) also doesn't work great. some parts are far to noisy (card matching works well, but generates hundreds of lines of debug code). and asn.1 analysis might be too chatty too, unless of course the problem is wit the format of some card - missing or extra entries etc. also not every function has good debug code, e.g. the parameters aren't in the debug file, so I have little clue what is going on. having no debug code/files is not an option, I guess. so the best we can do is to go through functions, and make sure each and every core function prints debug info when entered (including the parameters), and prints the result when it is leaving. extra debug in the middle, if it is a complex function is welcome too. so what is useful of the code in src/libopensc/log.h? sc_error should and everything related to error fd needs to go - it caused debug log files without the error information, a very bad idea. (IIRC martin did that already?) every debug macro or function call should contain the debug level, and the macro/function should check it against ctx->debug. all log.h functions get the context already. SC_FUNC_CALLED should go away - functions have parameters, those help in debugging a lot. SC_FUNC_RETURN doesn't tell us what is returned (unless the function returns only the value). so if we change the code, can we find better macros / ways to debug problems? __FILE__ and __LINE__ are not very important to me, at least it is easy to find out where a function begins, even without that. but parameters or some detailed info what went wrong, that all could help. > Does it exists any rule for the assigning of the debug level for debug > messages ? lets put everything at 1, isolate whole function blocks that are too chatty, and put them on a different level. (asn.1=2, card matching=3?). we could also go for a flag based system, if that is preferable. also (thought I guess it is already gone): suppressing errors isn't fine with me. without debugging active, opensc shouldn't print anything. that is what return codes are for, maybe the app can handle it. not printing stuff when debugging is on might leave out important parts too. what do you think? Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] 'return' versus 'SC_FUNC_RETURN'
Viktor TARASOV wrote: > In a fact, I was looking through libopensc/pkcs.c (ex. +365, +525, ..) . > Sorry, should be read as In a fact, I was looking through libopensc/pkcs15.c (ex. +365, +525, ..) . Regards, Viktor Tarasov. > >> ___ >> opensc-devel mailing list >> opensc-devel@lists.opensc-project.org >> http://www.opensc-project.org/mailman/listinfo/opensc-devel >> >> >> > > > -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] 'return' versus 'SC_FUNC_RETURN'
Aleksey Samsonov wrote: > Viktor TARASOV wrote: > >> my general question is: >> will you agree to have a little bit more of the debug messages in the >> common sources ? >> IMHO, it will facilitate the debugging and the comprehension of the 'how >> it works'. >> > > If it is useful, yes. > > >> I mean, at least, to use more of the log macros ( SC_FUNC_RETURN, >> SC_FUNC_CALLED and SC_TEST_RET) >> instead of simple 'return SC_xxx', >> to use the 'return' macro in the functions that starts from 'call' >> macro, etc. >> > > > Using everywhere these log macros is not reasonable. > It can make the simple code too difficult, overloaded with details. > But if the function is big and with complicated logic, additional > detailed log will be useful. True criterion is common sence. > I see, thank you, I will try to trust my common sense. >> (Sometimes, in the sources, there is an textual duplicate of the >> existing macros). >> > > What do you want to change and where? > In a fact, I was looking through libopensc/pkcs.c (ex. +365, +525, ..) . >> Does it exists any rule for the assigning of the debug level for debug >> messages ? >> > > I think we have to follow common sence. > In the same direction, some features that we are locally using: Duplicate the 'sc_error' messages as the 'sc_debug' ones with some low level of importance. Sometimes it not evident to find the correspondence . Message time stamp (1 msec resolution for Windows. For Linux it's 1 sec -- was not able to do better in a simple manner) . In the reader logs (for ex. in pcsc_transmit() of reader-pcsc.c) insert the reader's name . It helps. Kind wishes, Viktor Tarasov. > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] 'return' versus 'SC_FUNC_RETURN'
Aleksey Samsonov wrote: >> Does it exists any rule for the assigning of the debug level for debug >> messages ? > > I think we have to follow common sence. > Also you can find some information here http://www.opensc-project.org/pipermail/opensc-devel/2009-September/012466.html ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] 'return' versus 'SC_FUNC_RETURN'
Hello, Viktor TARASOV wrote: > Hi, > > my general question is: > will you agree to have a little bit more of the debug messages in the > common sources ? > IMHO, it will facilitate the debugging and the comprehension of the 'how > it works'. If it is useful, yes. > I mean, at least, to use more of the log macros ( SC_FUNC_RETURN, > SC_FUNC_CALLED and SC_TEST_RET) > instead of simple 'return SC_xxx', > to use the 'return' macro in the functions that starts from 'call' > macro, etc. Using everywhere these log macros is not reasonable. It can make the simple code too difficult, overloaded with details. But if the function is big and with complicated logic, additional detailed log will be useful. True criterion is common sence. > (Sometimes, in the sources, there is an textual duplicate of the > existing macros). What do you want to change and where? > Does it exists any rule for the assigning of the debug level for debug > messages ? I think we have to follow common sence. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] 'return' versus 'SC_FUNC_RETURN'
Hi, my general question is: will you agree to have a little bit more of the debug messages in the common sources ? IMHO, it will facilitate the debugging and the comprehension of the 'how it works'. I mean, at least, to use more of the log macros ( SC_FUNC_RETURN, SC_FUNC_CALLED and SC_TEST_RET) instead of simple 'return SC_xxx', to use the 'return' macro in the functions that starts from 'call' macro, etc. (Sometimes, in the sources, there is an textual duplicate of the existing macros). Does it exists any rule for the assigning of the debug level for debug messages ? Kind wishes, Viktor Tarasov. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
