opensc.config: defaults are overwriting specific apps' configuration

[frankmorgner]

It seems to me that the app pkcs15-init section in the opensc configuration does not cause any reaction .. config:

app default {

}
app pkcs15-init {
        debug = 255;
        debug_file = opensc-debug_init.txt;
}

After initializing the card, I don't have the opensc-debug_init.txt file created..

Accordingly, app default overwrites the information in the app pkcs11-init section.

The debug file is created with the following configuration (no app default section):

app pkcs15-init {
        debug = 255;
        debug_file = opensc-debug_init.txt;
}

For this reason, it is not even possible to turn off the file cache only for app pkcs15-init, but leave it on in the app default section.

Originally posted by @popovec in #2804 (comment)

[dengert]

If app default has no entries is it dropped?

Does the app pkcs15-init section need a framework pkcs15 section?

sc_pkcs15_bind is where the use_file_cache = scconf_get_str(conf_block, "use_file_caching", use_file_cache); is set, I was not going to insert any card will testing with `pkcs15-init.
When is sc_pkcs15_bind called when running pkcs15-init?

Some simple tests if app default has debug and debug file set
and app pkcs15-init section has a different debug and debug file,
The debug log was written to the file from the app pkcs15-init section.

[Jakuje]

I think there are several problems when we will start use multiple blocks. The first logging example will not work because:

• the pkcs15-init sets some debug and debug_file when initializing context with the --verbose argument. The can only increase debug log. This is mostly ok.
• the load_parameters() handles the debug_file weirdly -- if it is in the block, it is set, if it is not in the last block (last block in the order of processing is most of the time the app default block), its unset even if it was set by previous blocks. I think this is a bug that should be fixed.

About the file_caching, the issue is that the sc_get_conf_block() returns only the first framework pkcs15 block in the first app block, regardless it contains the options we search for later or not. So if the first matched app block (in this case the app pkcs15-init) contains the framework pkcs15, it overrides the whole framework pkcs15 in the default block configuration. I think this is at least confusing and should be explicitly explained somewhere to avoid the need to read through the code to understand how the configuration works.