SP downloading and xmldsig-validating remote XML metadata on every start

[Peter Schober]

I've built a new VM (Debian Stable, with current shib packages from
Debian) where I fail to see any effects of the verifyBackup="false"
XML attribute I've set on the MetadataFilter/@type="Signature"
(or "will reload remote resource at most every 7200 seconds", for that
matter).
I.e., the remote metadata from the parent XML MetadataProvider is
always downloaded and also signature-validated on every startup.

shibd.log looks the same in both cases, whether it's a first start (or
/var/cache/shibboleth/ has been cleared after stopping and before
starting shibd) or a later one, e.g.:

2023-03-17 17:19:41 DEBUG OpenSAML.MetadataProvider.XML : using remote resource (https://example.org/metadata.xml)
2023-03-17 17:19:41 DEBUG OpenSAML.MetadataProvider.XML : backup remote resource to (/var/cache/shibboleth/metadata.xml)
2023-03-17 17:19:41 DEBUG OpenSAML.MetadataProvider.XML : will reload remote resource at most every 7200 seconds
2023-03-17 17:19:41 DEBUG OpenSAML.MetadataProvider.XML : remote metadata resource will be backed up to (/var/cache/shibboleth/metadata.xml.b228)
2023-03-17 17:19:41 DEBUG OpenSAML.MetadataProvider.XML : loading configuration from external resource...
2023-03-17 17:19:41 DEBUG OpenSAML.MetadataProvider.XML : writing to backing file: /var/cache/shibboleth/metadata.xml.b228
2023-03-17 17:19:41 DEBUG XMLTooling.libcurl.InputStream : libcurl trying to fetch https://example.org/metadata.xml 
[...]
2023-03-17 17:19:43 INFO OpenSAML.MetadataProvider.XML : loaded XML resource (https://example.org/metadata.xml)
2023-03-17 17:19:43 DEBUG XMLTooling.Signature : unmarshalling ds:Signature
2023-03-17 17:19:45 INFO OpenSAML.MetadataProvider : applying metadata filter (RequireValidUntil)
2023-03-17 17:19:45 INFO OpenSAML.MetadataProvider : applying metadata filter (Signature)
2023-03-17 17:23:32 INFO OpenSAML.MetadataProvider : applying metadata filter (EntityRole)
2023-03-17 17:23:33 DEBUG OpenSAML.MetadataProvider.XML : committing backup file to permanent location (/var/cache/shibboleth/metadata.xml)

I.e., the metadata is successfully cached in
/var/cache/shibboleth/metadata.xml and with correct (AFAICT;
everything from of the packages) ownership (and no systemd
limits/jailing in place, either):

$ ls -l /var/cache/shibboleth/metadata.xml
-rw-r--r-- 1 _shibd _shibd 78768586 Mar 17 17:19 /var/cache/shibboleth/metadata.xml

shibd runs as that same user (again, unmodified by me):

$ ps aux | grep /shib[d]
_shibd      5418  100 58.2 1454992 1179540 ?     Rsl  17:33   1:26 /usr/sbin/shibd -f -F

When using a very large metadata aggregate to test it's obvious
signature validation is actually being performed (cf. the ~4 min in
the log above).

SP configuration used:
https://wiki.univie.ac.at/display/federation/Shibboleth+SP+3#ShibbolethSP3-Metadataconfiguration
Specifically the MetadataFilter I'm asking about looks like this:
  <MetadataFilter type="Signature" certificate="metadata-signing.crt" verifyBackup="false"/>

Current date:

$ date -u +%Y-%m-%dT%TZ
2023-03-17T17:27:38Z

validUntil from the cached metadata:

$ xmlstarlet sel -t -v '//_:EntitiesDescriptor/@validUntil' -n /var/cache/shibboleth/metadata.xml 
2023-03-31T07:12:18Z

cacheDuration from the cached metadata:

$ xmlstarlet sel -t -v '//_:EntitiesDescriptor/@cacheDuration' -n /var/cache/shibboleth/metadata.xml 
PT12H

The web server hosting the metadata supports last-modified and etag
HTTP Reponse headers:

$ curl -sS -I https://example.org/metadata.xml 2>&1 | egrep -i "^(last-modified|etag)"
last-modified: Fri, 17 Mar 2023 07:12:21 GMT
etag: "4b1e9ca-5f7134c5a9f40"

The software starts correctly ("listener service starting") and no
errors or warnings in the log.

Any ideas why verifyBackup="false" wouldn't "take"?
Or why not even "will reload remote resource at most every 7200
seconds" seems to be adhered to (as the metadata is reloaded and
re-signature-validated on every stop/start cycle)?

(No SELinux on this machine. ;))

-peter