#1413 Create Python verification method that checks for illegal '.inf' override entries in 'default.cfg' sections
Closed: migrated 3 years ago by dmoluguw. Opened 8 years ago by mharmsen.

As time has gone on, the number of parameters specified within the various sections of the '/etc/pki/default.cfg' file has rapidly increased.

A very common problem that has occurred is when the user attempts to override a variable in this file within their specified override '.inf' file.

One approach to resolve this issue is to create and provide a verification method that reads in the '/etc/pki/default.cfg' file section-by-section, and then reads in the '.inf' override section-by-section, and verify that each specified override parameter exists within the corresponding section.

An alternative approach may be to read-in the '/etc/pki/default.cfg' file and 'flatten' it, read in the '.inf' override file and 'flatten' it, and then compare that all of the parameters exist. Such a change, however, would result in a necessary logic change that 'flattening' all parameters would need to be done very early on, and the repercussions of such a change may have undesired side-effects.


Per CS/DS meeting of 06/15/2015: 10.2.6

Upping priority to 'critical' --- this routine is just too useful for debugging problems (especially with HSMs)!

It looks like a simple and well-defined task. Let's see if I can come up with a patch today.

I've created a simple script that loads default.cfg and compares it to a mandatory cfg file. It detects additional sections and options.

Please have a look.

After discussion on IRC with Endi, we arrived at some concerns that such a routine will not be able to have adequate testing before the next deadline.

For example:

<mharmsen>edewata: actually, this has also made me nervous about including the
verification routine (not concerned about the correctness of the code -- simply
concerned about the sheer lack of time for testing)
<edewata> mharmsen: yeah, i'd rather we do the verification in 10.3 after we
formalized where things should go (with sufficient testing)
<edewata> mharmsen: in 10.3 we can generate warnings if the params aren't
specified in the correct place
<edewata> mharmsen: and we can add a strict mode where it will fail if the
location is incorrect
<mharmsen> edewata: agreed --- I will place a comment in that ticket

cheimes: I will not move this to 10.3 yet, but I will downgrade this ticket to 'major' for 10.2.6

I understand and share your concern. How about I turn the check into an optional feature with a command line option for now? That way the validation code isn't execute at all. In the future the feature is enabled by default (aka strict mode).

Patch posted on pki-devel for review.

Per impromptu 10.2.6 meeting of 7/17/2025: 10.2.7

Per CS/DS Meeting of 08/03/2015: 10.3

Metadata Update from @mharmsen:
- Issue assigned to cheimes
- Issue set to the milestone: UNTRIAGED

7 years ago

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/1974

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Metadata Update from @dmoluguw:
- Issue close_status updated to: migrated
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata