From: Dirk-Willem v. G. <di...@we...> - 2015-06-02 15:32:29
|
We seem to be a bit trusting of the cruft which can be on a card; found I needed below to stop naughty cards from causing segfaults (and hence locking subsequent users out of their desktops (a bit of fragility outside OpenSC)). Just wondering - is this sort of thing common (and should I scan most of the code for this) — or have i found a rare case ? Dw. https://github.com/OpenSC/OpenSC/commit/1061b5ded0edbc6a1f2cb4fd599b7c950ffe18ff src/libopensc/dir.c @@ -149,6 +149,10 @@ int sc_enum_apps(sc_card_t *card) r = sc_select_file(card, &path, &card->ef_dir); LOG_TEST_RET(ctx, r, "Cannot select EF.DIR file"); + if (card->ef_dir == NULL) { + LOG_TEST_RET(ctx, SC_ERROR_INVALID_CARD, "EF(DIR) nonexistant."); + } + if (card->ef_dir->type != SC_FILE_TYPE_WORKING_EF) { sc_file_free(card->ef_dir); card->ef_dir = NULL; src/libopensc/pkcs15.c @@ -1044,6 +1044,10 @@ sc_pkcs15_bind_internal(struct sc_pkcs15_card *p15card, struct sc_aid *aid) sc_log(ctx, "Cannot make absolute path to EF(ODF); error:%i", err); goto end; } + if (p15card->file_odf == NULL) { + sc_log(ctx, "After making absolute path to EF(ODF) still no odf."); + goto end; + } sc_log(ctx, "absolute path to EF(ODF) %s", sc_print_path(&tmppath)); err = sc_select_file(card, &tmppath, &p15card->file_odf); } @@ -1059,6 +1063,8 @@ sc_pkcs15_bind_internal(struct sc_pkcs15_card *p15card, struct sc_aid *aid) goto end; } + assert(p15card->file_odf); + len = p15card->file_odf->size; if (!len) { sc_log(ctx, "EF(ODF) is empty”); |
From: Douglas E E. <dee...@gm...> - 2015-06-02 16:42:17
|
On 6/2/2015 10:32 AM, Dirk-Willem van Gulik wrote: > We seem to be a bit trusting of the cruft which can be on a card; found I needed below to stop naughty cards > from causing segfaults (and hence locking subsequent users out of their desktops (a bit of fragility outside OpenSC)). > > Just wondering - is this sort of thing common (and should I scan most of the code for this) — or have i found a rare case ? It depends. The part of OpenSC that tries to determine the type of card, would be more likely to run into "naughty cards" or cards that don't follow all the standards or cards that have not been initialized as expected. Cards that may have worked with older versions of OpenSC, may not work with newer versions, as newer code may not have been tested against the older cards For example There are cards that emulate PKCS#15 and newer code added to OpenSC for example the sc_enum_apps() may not be emulated correctly. For example the ODF in older code does not need to be emulated. Not clear if it does now. Older versions of cards that may have worked before. But newer versions of the card or the files on new cards are not the same as before because the card issuer changed something. Can you say what cards caused these problems? > > Dw. > > https://github.com/OpenSC/OpenSC/commit/1061b5ded0edbc6a1f2cb4fd599b7c950ffe18ff > > src/libopensc/dir.c > @@ -149,6 +149,10 @@ int sc_enum_apps(sc_card_t *card) > r = sc_select_file(card, &path, &card->ef_dir); > LOG_TEST_RET(ctx, r, "Cannot select EF.DIR file"); > > + if (card->ef_dir == NULL) { > + LOG_TEST_RET(ctx, SC_ERROR_INVALID_CARD, "EF(DIR) nonexistant."); > + } > + > if (card->ef_dir->type != SC_FILE_TYPE_WORKING_EF) { > sc_file_free(card->ef_dir); > card->ef_dir = NULL; > > src/libopensc/pkcs15.c > @@ -1044,6 +1044,10 @@ sc_pkcs15_bind_internal(struct sc_pkcs15_card *p15card, struct sc_aid *aid) > sc_log(ctx, "Cannot make absolute path to EF(ODF); error:%i", err); > goto end; > } > + if (p15card->file_odf == NULL) { > + sc_log(ctx, "After making absolute path to EF(ODF) still no odf."); > + goto end; > + } > sc_log(ctx, "absolute path to EF(ODF) %s", sc_print_path(&tmppath)); > err = sc_select_file(card, &tmppath, &p15card->file_odf); > } > @@ -1059,6 +1063,8 @@ sc_pkcs15_bind_internal(struct sc_pkcs15_card *p15card, struct sc_aid *aid) > goto end; > } > > + assert(p15card->file_odf); > + > len = p15card->file_odf->size; > if (!len) { > sc_log(ctx, "EF(ODF) is empty”); > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
From: Dirk-Willem v. G. <di...@we...> - 2015-06-03 08:46:01
|
> On 02 Jun 2015, at 18:36, Douglas E Engert <dee...@gm...> wrote: > > > > On 6/2/2015 10:32 AM, Dirk-Willem van Gulik wrote: >> We seem to be a bit trusting of the cruft which can be on a card; found I needed below to stop naughty cards >> from causing segfaults (and hence locking subsequent users out of their desktops (a bit of fragility outside OpenSC)). >> >> Just wondering - is this sort of thing common (and should I scan most of the code for this) — or have i found a rare case ? > > It depends. The part of OpenSC that tries to determine the type of card, would be more likely to run into "naughty cards" > or cards that don't follow all the standards or cards that have not been initialized as expected. > > Cards that may have worked with older versions of OpenSC, may not work with newer versions, as newer code > may not have been tested against the older cards For example There are cards that emulate PKCS#15 and newer code > added to OpenSC for example the sc_enum_apps() may not be emulated correctly. For example the ODF in older code > does not need to be emulated. Not clear if it does now. > > Older versions of cards that may have worked before. But newer versions of the card or the files on new cards > are not the same as before because the card issuer changed something. > > Can you say what cards caused these problems? We dove into this because we saw a card specifically designed to make (login) daemons segfault (and hence fall back to lesser systems due to non ideal designed processes). This is basically an organisational/procedure attack - where a DoS leads to the human/apparatus complex to do unsafe things to tide over; and the exploit is then there; not in OpenSC per-se. By pure co-incidence (going through old logs) we discovered that various AET cards; including a card issued to most Dutch civil servants also causes pretty much all opensc tools (and pkcs11/15) to segfault. In this case it is more ‘silly’ — cards respond to queries with a: { (char []) "I am the SafeSign Applet of A.E.T. Europe B.V. please authenticate yourself\n”, 0x90, 0x00 } that confuses OpenSC enough to segfault in various places on mere insertion/query. Dw. > >> >> Dw. >> >> https://github.com/OpenSC/OpenSC/commit/1061b5ded0edbc6a1f2cb4fd599b7c950ffe18ff >> >> src/libopensc/dir.c >> @@ -149,6 +149,10 @@ int sc_enum_apps(sc_card_t *card) >> r = sc_select_file(card, &path, &card->ef_dir); >> LOG_TEST_RET(ctx, r, "Cannot select EF.DIR file"); >> >> + if (card->ef_dir == NULL) { >> + LOG_TEST_RET(ctx, SC_ERROR_INVALID_CARD, "EF(DIR) nonexistant."); >> + } >> + >> if (card->ef_dir->type != SC_FILE_TYPE_WORKING_EF) { >> sc_file_free(card->ef_dir); >> card->ef_dir = NULL; >> >> src/libopensc/pkcs15.c >> @@ -1044,6 +1044,10 @@ sc_pkcs15_bind_internal(struct sc_pkcs15_card *p15card, struct sc_aid *aid) >> sc_log(ctx, "Cannot make absolute path to EF(ODF); error:%i", err); >> goto end; >> } >> + if (p15card->file_odf == NULL) { >> + sc_log(ctx, "After making absolute path to EF(ODF) still no odf."); >> + goto end; >> + } >> sc_log(ctx, "absolute path to EF(ODF) %s", sc_print_path(&tmppath)); >> err = sc_select_file(card, &tmppath, &p15card->file_odf); >> } >> @@ -1059,6 +1063,8 @@ sc_pkcs15_bind_internal(struct sc_pkcs15_card *p15card, struct sc_aid *aid) >> goto end; >> } >> >> + assert(p15card->file_odf); >> + >> len = p15card->file_odf->size; >> if (!len) { >> sc_log(ctx, "EF(ODF) is empty”); >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... <mailto:Ope...@li...> >> https://lists.sourceforge.net/lists/listinfo/opensc-devel <https://lists.sourceforge.net/lists/listinfo/opensc-devel> >> > > -- > > Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm...>> > > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... <mailto:Ope...@li...> > https://lists.sourceforge.net/lists/listinfo/opensc-devel <https://lists.sourceforge.net/lists/listinfo/opensc-devel> |
From: Douglas E E. <dee...@gm...> - 2015-06-03 16:47:42
|
Good point. A card to designed to cause a segfault... We really do need to make sure we don't segfault. On 6/3/2015 3:44 AM, Dirk-Willem van Gulik wrote: > >> On 02 Jun 2015, at 18:36, Douglas E Engert <dee...@gm... <mailto:dee...@gm...>> wrote: >> >> >> >> On 6/2/2015 10:32 AM, Dirk-Willem van Gulik wrote: >>> We seem to be a bit trusting of the cruft which can be on a card; found I needed below to stop naughty cards >>> from causing segfaults (and hence locking subsequent users out of their desktops (a bit of fragility outside OpenSC)). >>> >>> Just wondering - is this sort of thing common (and should I scan most of the code for this) — or have i found a rare case ? >> >> It depends. The part of OpenSC that tries to determine the type of card, would be more likely to run into "naughty cards" >> or cards that don't follow all the standards or cards that have not been initialized as expected. >> >> Cards that may have worked with older versions of OpenSC, may not work with newer versions, as newer code >> may not have been tested against the older cards For example There are cards that emulate PKCS#15 and newer code >> added to OpenSC for example the sc_enum_apps() may not be emulated correctly. For example the ODF in older code >> does not need to be emulated. Not clear if it does now. >> >> Older versions of cards that may have worked before. But newer versions of the card or the files on new cards >> are not the same as before because the card issuer changed something. >> >> Can you say what cards caused these problems? > > We dove into this because we saw a card specifically designed to make (login) daemons segfault (and hence fall back to lesser systems due to non ideal designed processes). > > This is basically an organisational/procedure attack - where a DoS leads to the human/apparatus complex to do unsafe things to tide over; and the exploit is then there; not in OpenSC per-se. > > By pure co-incidence (going through old logs) we discovered that various AET cards; including a card issued to most Dutch civil servants also causes pretty much all opensc tools (and pkcs11/15) to > segfault. > > In this case it is more ‘silly’ — cards respond to queries with a: > > { > (char []) "I am the SafeSign Applet of A.E.T. Europe B.V. please authenticate yourself\n”, > 0x90, 0x00 > } > > that confuses OpenSC enough to segfault in various places on mere insertion/query. > > Dw. > >> >>> >>> Dw. >>> >>> https://github.com/OpenSC/OpenSC/commit/1061b5ded0edbc6a1f2cb4fd599b7c950ffe18ff >>> >>> src/libopensc/dir.c >>> @@ -149,6 +149,10 @@ int sc_enum_apps(sc_card_t *card) >>> r = sc_select_file(card, &path, &card->ef_dir); >>> LOG_TEST_RET(ctx, r, "Cannot select EF.DIR file"); >>> >>> +if (card->ef_dir == NULL) { >>> +LOG_TEST_RET(ctx, SC_ERROR_INVALID_CARD, "EF(DIR) nonexistant."); >>> +} >>> + >>> if (card->ef_dir->type != SC_FILE_TYPE_WORKING_EF) { >>> sc_file_free(card->ef_dir); >>> card->ef_dir = NULL; >>> >>> src/libopensc/pkcs15.c >>> @@ -1044,6 +1044,10 @@ sc_pkcs15_bind_internal(struct sc_pkcs15_card *p15card, struct sc_aid *aid) >>> sc_log(ctx, "Cannot make absolute path to EF(ODF); error:%i", err); >>> goto end; >>> } >>> +if (p15card->file_odf == NULL) { >>> +sc_log(ctx, "After making absolute path to EF(ODF) still no odf."); >>> +goto end; >>> +} >>> sc_log(ctx, "absolute path to EF(ODF) %s", sc_print_path(&tmppath)); >>> err = sc_select_file(card, &tmppath, &p15card->file_odf); >>> } >>> @@ -1059,6 +1063,8 @@ sc_pkcs15_bind_internal(struct sc_pkcs15_card *p15card, struct sc_aid *aid) >>> goto end; >>> } >>> >>> +assert(p15card->file_odf); >>> + >>> len = p15card->file_odf->size; >>> if (!len) { >>> sc_log(ctx, "EF(ODF) is empty”); >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Opensc-devel mailing list >>> Ope...@li... <mailto:Ope...@li...> >>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >>> >> >> -- >> >> Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm...>> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... <mailto:Ope...@li...> >> https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
From: Frank M. <mo...@in...> - 2015-06-04 09:16:30
|
We've discussed this kind of issue earlier. Yes, we need to fix those issues if we can. In the past couple of month we fixed a lot of issues that were discovered by static code analysis, for this reason. However, we still believe that a malicious card requires more or less physical access to the machine. With this premise there are a number of problems arising that are currently more likely to be exploited. Am 3. Juni 2015 18:41:47 MESZ, schrieb Douglas E Engert <dee...@gm...>: >Good point. A card to designed to cause a segfault... We really do >need to make sure we don't segfault. > >On 6/3/2015 3:44 AM, Dirk-Willem van Gulik wrote: >> >>> On 02 Jun 2015, at 18:36, Douglas E Engert <dee...@gm... ><mailto:dee...@gm...>> wrote: >>> >>> >>> >>> On 6/2/2015 10:32 AM, Dirk-Willem van Gulik wrote: >>>> We seem to be a bit trusting of the cruft which can be on a card; >found I needed below to stop naughty cards >>>> from causing segfaults (and hence locking subsequent users out of >their desktops (a bit of fragility outside OpenSC)). >>>> >>>> Just wondering - is this sort of thing common (and should I scan >most of the code for this) — or have i found a rare case ? >>> >>> It depends. The part of OpenSC that tries to determine the type of >card, would be more likely to run into "naughty cards" >>> or cards that don't follow all the standards or cards that have not >been initialized as expected. >>> >>> Cards that may have worked with older versions of OpenSC, may not >work with newer versions, as newer code >>> may not have been tested against the older cards For example There >are cards that emulate PKCS#15 and newer code >>> added to OpenSC for example the sc_enum_apps() may not be emulated >correctly. For example the ODF in older code >>> does not need to be emulated. Not clear if it does now. >>> >>> Older versions of cards that may have worked before. But newer >versions of the card or the files on new cards >>> are not the same as before because the card issuer changed >something. >>> >>> Can you say what cards caused these problems? >> >> We dove into this because we saw a card specifically designed to make >(login) daemons segfault (and hence fall back to lesser systems due to >non ideal designed processes). >> >> This is basically an organisational/procedure attack - where a DoS >leads to the human/apparatus complex to do unsafe things to tide over; >and the exploit is then there; not in OpenSC per-se. >> >> By pure co-incidence (going through old logs) we discovered that >various AET cards; including a card issued to most Dutch civil servants >also causes pretty much all opensc tools (and pkcs11/15) to >> segfault. >> >> In this case it is more ‘silly’ — cards respond to queries with a: >> >> { >> (char []) "I am the SafeSign Applet of A.E.T. Europe B.V. please >authenticate yourself\n”, >> 0x90, 0x00 >> } >> >> that confuses OpenSC enough to segfault in various places on mere >insertion/query. >> >> Dw. >> >>> >>>> >>>> Dw. >>>> >>>> >https://github.com/OpenSC/OpenSC/commit/1061b5ded0edbc6a1f2cb4fd599b7c950ffe18ff >>>> >>>> src/libopensc/dir.c >>>> @@ -149,6 +149,10 @@ int sc_enum_apps(sc_card_t *card) >>>> r = sc_select_file(card, &path, &card->ef_dir); >>>> LOG_TEST_RET(ctx, r, "Cannot select EF.DIR file"); >>>> >>>> +if (card->ef_dir == NULL) { >>>> +LOG_TEST_RET(ctx, SC_ERROR_INVALID_CARD, "EF(DIR) nonexistant."); >>>> +} >>>> + >>>> if (card->ef_dir->type != SC_FILE_TYPE_WORKING_EF) { >>>> sc_file_free(card->ef_dir); >>>> card->ef_dir = NULL; >>>> >>>> src/libopensc/pkcs15.c >>>> @@ -1044,6 +1044,10 @@ sc_pkcs15_bind_internal(struct >sc_pkcs15_card *p15card, struct sc_aid *aid) >>>> sc_log(ctx, "Cannot make absolute path to EF(ODF); error:%i", err); >>>> goto end; >>>> } >>>> +if (p15card->file_odf == NULL) { >>>> +sc_log(ctx, "After making absolute path to EF(ODF) still no >odf."); >>>> +goto end; >>>> +} >>>> sc_log(ctx, "absolute path to EF(ODF) %s", >sc_print_path(&tmppath)); >>>> err = sc_select_file(card, &tmppath, &p15card->file_odf); >>>> } >>>> @@ -1059,6 +1063,8 @@ sc_pkcs15_bind_internal(struct sc_pkcs15_card >*p15card, struct sc_aid *aid) >>>> goto end; >>>> } >>>> >>>> +assert(p15card->file_odf); >>>> + >>>> len = p15card->file_odf->size; >>>> if (!len) { >>>> sc_log(ctx, "EF(ODF) is empty”); >>>> >>>> >>>> >>>> >------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Opensc-devel mailing list >>>> Ope...@li... ><mailto:Ope...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >>>> >>> >>> -- >>> >>> Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm...>> >>> >>> >>> >------------------------------------------------------------------------------ >>> _______________________________________________ >>> Opensc-devel mailing list >>> Ope...@li... ><mailto:Ope...@li...> >>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> > >-- > > Douglas E. Engert <DEE...@gm...> > > >------------------------------------------------------------------------------ >_______________________________________________ >Opensc-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opensc-devel -- Frank Morgner |
From: Dirk-Willem v. G. <di...@we...> - 2015-06-04 09:37:48
|
On 04 Jun 2015, at 11:16, Frank Morgner <mo...@in...> wrote: > We've discussed this kind of issue earlier. Yes, we need to fix those issues if we can. In the past couple of month we fixed a lot of issues that were discovered by static code analysis, for this reason. However, we still believe that a malicious card requires more or less physical access to the machine. With this premise there are a number of problems arising that are currently more likely to be exploited. Right - may be good to stress here that in this case the original vector was RFID ‘cards’. We’re fairly sure it was a virtual card/emulated thing - and likely not physically that near either. Dw. |
From: Douglas E E. <dee...@gm...> - 2015-06-04 10:29:48
|
On 6/4/2015 4:16 AM, Frank Morgner wrote: > We've discussed this kind of issue earlier. Yes, we need to fix those issues if we can. In the past couple of month we fixed a lot of issues that were discovered by static code analysis, for this > reason. However, we still believe that a malicious card requires more or less physical access to the machine. With this premise there are a number of problems arising that are currently more likely to > be exploited. If the machine is accessible via Remote Desktop(windows) or rdesktop(linux) the attacked does not have to have physical access. The OpenSC code is run on the machine, not the attacker's machine. > > > Am 3. Juni 2015 18:41:47 MESZ, schrieb Douglas E Engert <dee...@gm...>: > > Good point. A card to designed to cause a segfault... We really do need to make sure we don't segfault. > > On 6/3/2015 3:44 AM, Dirk-Willem van Gulik wrote: > > > On 02 Jun 2015, at 18:36, Douglas E Engert <dee...@gm... <mailto:dee...@gm...>> wrote: > > > > On 6/2/2015 10:32 AM, Dirk-Willem van Gulik wrote: > > We seem to be a bit trusting of the cruft which can be on a card; found I needed below to stop naughty cards > from causing segfaults (and hence locking subsequent users out of their desktops (a bit of fragility outside OpenSC)). > > ! Just wondering - is this sort of thing common (and should I scan most of the code for this) — or have i found a rare case ? > > > It depends. The part of OpenSC that tries to determine the type of card, would be more likely to run into "naughty cards" > or cards that don't follow all the standards or cards that have not been initialized as expected. > > Cards that may have worked with older versions of OpenSC, may not work with newer versions, as newer code > may not have been tested against the older cards For example There are cards that emulate PKCS#15 and newer code > added to OpenSC for example the sc_enum_apps() may not be emulated correctly. For example the ODF in older code > does not need to be emulated. Not clear if it does now. > > Older versions of cards that may have worked before. But newer versions of the card or the files on new cards > are not the same as before because the card issuer changed something. > Can you say what cards caused these problems? > > > We dove into this because we saw a card specifically designed to make (login) daemons segfault (and hence fall back to lesser systems due to non ideal designed processes). > > This is basically an organisational/procedure attack - where a DoS leads to the human/apparatus complex to do unsafe things to tide over; and the exploit is then there; not in OpenSC per-se. > > By pure co-incidence (going through old logs) we discovered that various AET cards; including a card issued to most Dutch civil servants also causes pretty much all opensc tools (and pkcs11/15) to > segfault. > > In this case it is more ‘silly’ — cards respond to queries with a: > > { > (char []) "I am the SafeSign Applet of A.E.T. Europe B.V. please authenticate yourself\n”, > 0x90, 0x00 > } > > that confuses OpenSC enough to segfault in various places on mere insertion/que! ry. > > Dw. > > > > Dw. > > https://github.com/OpenSC/OpenSC/commit/1061b5ded0edbc6a1f2cb4fd599b7c950ffe18ff > > src/libopensc/dir.c > @@ -149,6 +149,10 @@ int sc_enum_apps(sc_card_t *card) > r = sc_select_file(card, &path, &card->ef_dir); > LOG_TEST_RET(ctx, r, "Cannot select EF.DIR file"); > > +if (card->ef_dir == NULL) { > +LOG_TEST_RET(ctx, SC_ERROR_INVALID_CARD, "EF(DIR) nonexistant."); > +} > + > if (card->ef_dir->type != SC_FILE_TYPE_WORKING_EF) { > sc_file_free(card->ef_dir); > card->ef_dir = NULL; > > src/libopensc/pkcs15.c > @@! -1044,6 +1044,10 @@ sc_pkcs15_bind_internal(struct sc_pkcs15_card *p15card, struct sc_aid *aid) > sc_log(ctx, "Cannot make absolute path to EF(ODF); error:%i", err); > goto end; > } > +if (p15card->file_odf == NULL) { > +sc_log(ctx, "After making absolute path to EF(ODF) still no odf."); > +goto end; > +} > sc_log(ctx, "absolute path to EF(ODF) %s", sc_print_path(&tmppath)); > err = sc_select_file(card, &tmppath, &p15card->file_odf); > } > @@ -1059,6 +1063,8 @@ sc_pkcs15_bind_internal(struct sc_pkcs15_card *p15card, struct sc_aid *aid) > goto end; > } > > +assert(p15card->file_odf); > + > len = p15card->file_odf->size; > if (!len) { > sc_log(ctx, "EF(ODF) is empty”); > > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Opensc-devel mailing list > Ope...@li... <mailto:Ope...@li...> > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > -- > > Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm...>> > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Opensc-devel mailing list > Ope...@li... <mailto:Ope...@li...> > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > -- > Frank Morgner -- Douglas E. Engert <DEE...@gm...> |