problems with LocalDynamicMetadataResolver and shibb 5.1.6 on rocky9 (tier container)

[Nathan Christopher Lewan]

Yes this does appear to be our local process of generating the digest. The
tool we use to extract the entityID from the metadata (xmllint) is running
a new version in rocky9, and appears to be applying/not removing a newline
character at the end of the parsed entityID, which of course changes the
calculation. Easy enough to resolve at this point. I'd like to determine
how it's getting there exactly, but that's a separate issue/headache ;)

Thanks all for chiming in, appreciate your time on this.



On Thu, Sep 25, 2025 at 2:56 PM Brent Putman via users <users at shibboleth.net>
wrote:

> What Scott said, esp about permissions. But also:
>
>
> On 9/25/25 2:09 PM, Nathan Christopher Lewan via users wrote:
>
> ROCKY 9:
> TRACE
> [org.opensaml.saml.metadata.resolver.impl.LocalDynamicMetadataResolver:118]
> - LocalDynamicMetadataResolver OurLocalMetadataProvider: Attempting to load
> from local source manager with generated key
> 'f4325ed353dcc638925265e7aa47b6dc457b77a4.xml'
>
> ROCKY  8:
> TRACE
> [org.opensaml.saml.metadata.resolver.impl.LocalDynamicMetadataResolver:118]
> - LocalDynamicMetadataResolver OurLocalMetadataProvider: Attempting to load
> from local source manager with generated key
> 'f4325ed353dcc638925265e7aa47b6dc457b77a4.xml'
>
>
> Both your Rocky 8 and 9 examples are consistent in what the provider is
> looking for, i.e. there is no change to the SHA-1 calculation in Java. So
> that's the filename it's going to expect to be there.
>
>
> When I go look on the running container filesystem for 5.1.6 running
> rocky9, I see the digested file referencing the metadata file I mentioned
> above is this:
>
> f2743c7e3c397a27ceec8a2950f1a9994c1c3496.xml -> localtest_site_edu.xml
>
> which doesn't match.
>
> Yes, the mismatch is the problem (assuming that's the digest-named file
> you are expecting it to find).  The issue is likely in whatever/however
> that SHA-1-digested filename is being generated.  I'd look at that as the
> culprit.
>
> As it says in the wiki the entityID should be digested without any
> leading/trailing whitespace, including newline.  So you can test what you
> directory population is doing against what it should be doing with
> something like this:
>
> echo -n "http://localtest.site.edu.edu:8091/sso/metadata"
> <http://localtest.site.edu.edu:8091/sso/metadata> | openssl sha1
>
> If your filenames don't match that CLI test, then your filenames are
> wrong, somehow.
>
> I have tried with multiple metadata files, all that work except with
> rocky9. I verified the metadata files are UTF8 with LF endings.
>
>
> The actual file content, encoding or line endings won't matter, b/c it's
> only the entityID string that is the input to the SHA-1 digest for the
> filename.  If your process to populate the directory is reading the
> metadata XML, extracting the entityID attribute and then digesting it with
> SHA-1, then I'd suspect something in the Rocky9 platform changed that has
> broken that, such as a change to XML parser, or to language interpreter,
> like Python, etc.  You'd need to dig into the details of how you've
> engineered the process that populates your local directory with the
> digested filenames.
>
>
>
>
> I am wondering if there is some sensitivity in string reading that is
> occuring in one process (generating the symlink digest file), and not the
> other(recomputing and searching for it), but I have no idea about that
> process, or if how i've outlined it above with two separate parts is even
> accurate.
>
>
> Yes, almost certainly it's something like that. The digest calculation on
> the Java side in the metadata provider hasn't changed, as indicated by your
> log output.  So I'd suspect your local process for ingesting files and
> populating the directory has inadvertently changed how the digest filename
> is calculated in Rocky9.
>
>
> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>


-- 
**
Nathan Lewan
IT Engineer - Identity and Access Management
Division of Information Technology
University of Maryland
nlewan at umd.edu
301-405-8019
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250926/2e7e4c0f/attachment.htm>