ini_file - support optional spaces around section names

[utoddl]

trafficstars

ini_file - Support optional spaces between section names and their surrounding brackets

SUMMARY

Some ini files have spaces between some of their section names and the brackets that enclose them. This is documented in the openssl.cnf(5) man page. In order to manage files such as openssl.cnf with ini_file before now, one would have to include spaces in the section name like this:

    section: ' crypto_policy '
    option: Options
    value: UnsafeLegacyRenegotiation

This change implements matching section headers with such optional spaces, removing the need to include those spaces in the task's section: parameter. Existing tasks using the workaround above will continue to work, even in cases where spaces in section headers are subsequently removed.

ISSUE TYPE

• Bugfix Pull Request

COMPONENT NAME

ini_file

ADDITIONAL INFORMATION

Here's an actual "legacy" production ini_file task. Note the spaces in the section name. These spaces have been necessary because the target file has these spaces already.

    - name: Configure UnsafeLegacyRenegotiation in /etc/pki/tls/openssl.cnf
      community.general.ini_file:
        path: /etc/pki/tls/openssl.cnf
        section: ' crypto_policy '
        option: Options
        value: UnsafeLegacyRenegotiation
        state: present
        exclusive: false
        create: false
        backup: true

After this change, those spaces are no longer necessary. Furthermore, the above task will continue to work even if someone removes the spaces from the target file's crypto_policy section header.

[felixfontein]

I wonder whether this should better be configurable, since there could be INI parsers which consider [foo] and [ foo ] to be two distinct sections (and maybe in some cases you even need both in the same file?). If that would be the case, this change would be breaking for users which rely on the existing behavior.

[felixfontein]

(I have zero idea whether that's actually the case. It's just that there are so many flavors of INI files that I woudn't be surprised if that's the case...)

[ansibullbot]

cc @jpmens @noseka1 click here for bot help

[utoddl]

I admit I had not considered the possibility that someone / something may be using outer spaces as a discriminator between otherwise identically named sections. But I would be extremely surprised.

The point of ini files is to have a format that is

• easily read by machines
• easily maintained by humans

The latter point seems to exclude "significant leading/trailing spaces" shenanigans. Adding a flag later if necessary could be considered, but without evidence of such cases in the wild I don't think it's worthwhile bloating ini_file's options with something the almost certainly will never be used.

[utoddl]

I should add that, with this change, section: ' foo ' would match existing section headers like:

[foo]
[ foo]
[foo ]
[ foo ]
[    foo     ]

However, if it caused the creation of a section, that header would be exactly as specified:

[ foo ]

in this case.

[felixfontein]

I admit I had not considered the possibility that someone / something may be using outer spaces as a discriminator between otherwise identically named sections. But I would be extremely surprised.

The point of ini files is to have a format that is

* easily read by machines

* easily maintained by humans

The latter point seems to exclude "significant leading/trailing spaces" shenanigans. Adding a flag later if necessary could be considered, but without evidence of such cases in the wild I don't think it's worthwhile bloating ini_file's options with something the almost certainly will never be used.

I agree it's not very likely (and I hope nobody ever does that - but then, you never know ;) ). I think it's OK to merge this without making it configurable; in case someone actually needs this we can add a flag later to toggle the behavior.

[russoz]

hi @utoddl

I left a formatting suggestion on the test script. It's a minor thing but it would help with readability. Other than that, I think this is good to go.

[patchback[bot]]

Backport to stable-8: 💚 backport PR created

✅ Backport PR branch: patchback/backports/stable-8/4363f8764b44a6bf62f671954642f60f9e76186c/pr-8075

Backported as https://github.com/ansible-collections/community.general/pull/8135

🤖 @patchback I'm built with octomachinery and my source is open — https://github.com/sanitizers/patchback-github-app.

[felixfontein]

@utoddl thanks for your contribution! @russoz thanks for reviewing this!