[tanjiroK-coder]

_cupsSetDefaults reads client.conf into a _cups_client_conf_t and then copies each setting into the per-thread globals, but digestoptions never makes that trip, so cg->digestoptions keeps its zero value (None) no matter what the file says. The parser side is fine: cups_read_client_conf and the macOS preferences path both turn DigestOptions DenyMD5 into cc.digestoptions, and _httpSetDigestAuthString checks cg->digestoptions before answering an MD5 Digest challenge. The result is that the documented knob for refusing MD5 Digest does nothing, so a server or an on-path attacker on a plain http:/ipp: connection can still send WWW-Authenticate: Digest ... algorithm=MD5 (or an RFC 2069 challenge) and collect the MD5 of username:realm:password for offline cracking from a client whose admin opted out of it. I noticed it while reading the Digest code and confirmed it with a small harness: with DigestOptions DenyMD5 in $CUPS_SERVERROOT/client.conf the unpatched library reports digestoptions 0 and builds an Authorization: Digest ... algorithm=MD5 string for both the RFC 2617 and RFC 2069 forms; after the change both return false and DigestOptions None still produces them. The copy is unconditional, like uatokens, because there is no public setter that could have set it first. CUPS 2.x usersys.c has the same gap. The cups unit tests pass on macOS apart from the testjson cupsJSONImportURL fetch of accounts.google.com, which fails on this machine for CA reasons unrelated to the change.

Changelog: - Fixed the "DigestOptions DenyMD5" setting in client.conf having no effect.

[michaelrsweet]

LGTM, thanks!