Attention is currently required from: laforge, lynxis lazus.

Patch set 8:Code-Review +1

View Change

2 comments:

• File host/lib/apdu_dispatch.c:

  • Patch Set #3, Line 120: ac->hdr.cla & 0x80 && /* check for GP */

    I don't know what I should do here. […]

    From what I can see the behavior is not GP specific. The ETSI TS 102 221 Table 7.1 suggests the same behavior. It may be the case that ETSI has followed GP here so that there is no incompatibility. In Annex C you find example transactions that illustrate how the procedure byte mechanism works.

    You can also look at pysim/pySim/transport/__init__.py. There we have the behavior implemented in __send_apdu_T0. The check is a little different. The special handling applies for Case1, Case2 and Case3 here (maybe we should be more precise here).

    I think the whole idea behind this is that if someone sends a C-APDU that generates data on the card and gets the length wrong. Then the card sends 6CXX, where XX is the correct length. The terminal then sends a corrected C-APDU and everything can continue normally without involving the higher layers.

• File host/tests/apdu_dispatch/apdu_dispatch_test.c:

  • Patch Set #3, Line 70: OSMO_ASSERT(rc == APDU_ACT_TX_CAPDU_TO_CARD);

    I've added a check on apdu_case.

    Done

To view, visit change 43185. To unsubscribe, or for help writing mail filters, visit settings.