Change Details

In gpgconf.h, the enum gc_component_id_t has a comment: ``` /* Component system. Each component is a set of options that can be * configured at the same time. If you change this, don't forget to * update gc_component[] in gpgconf-comp.c. */ ``` it defines an enum value `GC_COMPONENT_TPM2DAEMON` (6) and `GC_COMPONENT_PINENTRY` (8). In gpgconf-comp.c, the table gc_component looks like this: ``` } gc_component[GC_COMPONENT_NR] = { /* Note: The order of the items must match the order given in the * gc_component_id_t enumeration. The order is often used by * frontends to display the backend options thus do not change the * order without considering the user experience. */ { NULL }, /* DUMMY for GC_COMPONENT_ANY */ ``` **but** the component-data for the TPM2 daemon is included only if `BUILD_WITH_TPM2D` is defined. So when that define is off, the gc_component table is one shorter than intended. This has two effects: - read after the end of the table when looping in `gc_component_retrieve_options()` . - mismatch between IDs and the actual entries; in particular, entry 6 in the table is the one for dirmngr, and entry 7 is now pinentry. Code that loops and checks to skip pinentry (enum value 8) now hits pinentry accidentally, as entry 7 in the table. This yields downstream bug report https://bugs.freebsd.org/bugzilla/ show_bug.cgi?id=259775 -- gpg tries to collect options for pinentry; the option-collecting code checks for enum value 8, but reaches pinentry in table entry 7 already. I applied a simple patch that adds ``` #else { NULL }, /* Another dummy, to keep the enum in sync with this table */ #endif ``` so there is a null entry in the table at place 6 (where the tpm daemon goes) and the table's length and entries are in-sync with the enum again.

In gpgconf.h, the enum gc_component_id_t has a comment: ``` /* Component system. Each component is a set of options that can be * configured at the same time. If you change this, don't forget to * update gc_component[] in gpgconf-comp.c. */ ``` it defines an enum value `GC_COMPONENT_TPM2DAEMON` (6) and `GC_COMPONENT_PINENTRY` (8). In gpgconf-comp.c, the table gc_component looks like this: ``` } gc_component[GC_COMPONENT_NR] = { /* Note: The order of the items must match the order given in the * gc_component_id_t enumeration. The order is often used by * frontends to display the backend options thus do not change the * order without considering the user experience. */ { NULL }, /* DUMMY for GC_COMPONENT_ANY */ ``` **but** the component-data for the TPM2 daemon is included only if `BUILD_WITH_TPM2D` is defined. So when that define is off, the gc_component table is one shorter than intended. This has two effects: - read after the end of the table when looping in `gc_component_retrieve_options()` . - mismatch between IDs and the actual entries; in particular, entry 6 in the table is the one for dirmngr, and entry 7 is now pinentry. Code that loops and checks to skip pinentry (enum value 8) now hits pinentry accidentally, as entry 7 in the table. This yields downstream bug report https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259775 -- gpg tries to collect options all components, skipping pinentry; the code skips enum value 8, but reaches pinentry in table entry 7 already. I applied a simple patch that adds ``` #else { NULL }, /* Another dummy, to keep the enum in sync with this table */ #endif ``` so there is a null entry in the table at place 6 (where the tpm daemon goes) and the table's length and entries are in-sync with the enum again.

In gpgconf.h, the enum gc_component_id_t has a comment: ``` /* Component system. Each component is a set of options that can be * configured at the same time. If you change this, don't forget to * update gc_component[] in gpgconf-comp.c. */ ``` it defines an enum value `GC_COMPONENT_TPM2DAEMON` (6) and `GC_COMPONENT_PINENTRY` (8). In gpgconf-comp.c, the table gc_component looks like this: ``` } gc_component[GC_COMPONENT_NR] = { /* Note: The order of the items must match the order given in the * gc_component_id_t enumeration. The order is often used by * frontends to display the backend options thus do not change the * order without considering the user experience. */ { NULL }, /* DUMMY for GC_COMPONENT_ANY */ ``` **but** the component-data for the TPM2 daemon is included only if `BUILD_WITH_TPM2D` is defined. So when that define is off, the gc_component table is one shorter than intended. This has two effects: - read after the end of the table when looping in `gc_component_retrieve_options()` . - mismatch between IDs and the actual entries; in particular, entry 6 in the table is the one for dirmngr, and entry 7 is now pinentry. Code that loops and checks to skip pinentry (enum value 8) now hits pinentry accidentally, as entry 7 in the table. This yields downstream bug report https://bugs.freebsd.org/bugzilla/ show_bug.cgi?id=259775 -- gpg tries to collect options for piall componentry;s, the option-collecting code checks for enum value 8,skipping pinentry; the code skips enum value 8, but reaches pinentry in table entry 7 already. I applied a simple patch that adds ``` #else { NULL }, /* Another dummy, to keep the enum in sync with this table */ #endif ``` so there is a null entry in the table at place 6 (where the tpm daemon goes) and the table's length and entries are in-sync with the enum again.