<div dir="ltr">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 ;)<br><br>Thanks all for chiming in, appreciate your time on this.<br><br><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Sep 25, 2025 at 2:56 PM Brent Putman via users <<a href="mailto:users@shibboleth.net">users@shibboleth.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>What Scott said, esp about permissions. But also:</p>
<p><br>
</p>
<div>On 9/25/25 2:09 PM, Nathan Christopher
Lewan via users wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">ROCKY 9:<br>
<div>TRACE
[org.opensaml.saml.metadata.resolver.impl.LocalDynamicMetadataResolver:118]
- LocalDynamicMetadataResolver OurLocalMetadataProvider:
Attempting to load from local source manager with generated
key 'f4325ed353dcc638925265e7aa47b6dc457b77a4.xml'</div>
</div>
</div>
</blockquote>
<blockquote type="cite">ROCKY 8:<br>
TRACE
[org.opensaml.saml.metadata.resolver.impl.LocalDynamicMetadataResolver:118]
- LocalDynamicMetadataResolver OurLocalMetadataProvider:
Attempting to load from local source manager with generated key
'f4325ed353dcc638925265e7aa47b6dc457b77a4.xml'</blockquote>
<br>
<p>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.</p>
<br>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>f2743c7e3c397a27ceec8a2950f1a9994c1c3496.xml ->
localtest_site_edu.xml</div>
<div><br>
</div>
<div>which doesn't match.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<p>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. <br>
</p>
<p>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:</p>
<p><span><code style="white-space:pre-wrap"><span><span><span></span><span>echo</span><span> -n </span><span><a href="http://localtest.site.edu.edu:8091/sso/metadata" target="_blank">"http://localtest.site.edu.edu:8091/sso/metadata"</a></span><span> </span><span>|</span><span> openssl sha1</span></span></span></code></span></p>
<p>If your filenames don't match that CLI test, then your filenames
are wrong, somehow.</p>
<br>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div>I have tried with multiple metadata files, all that work
except with rocky9. I verified the metadata files are UTF8
with LF endings.</div>
</div>
</div>
</blockquote>
<br>
<p>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.<br>
</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>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.<br>
</div>
</div>
</div>
</blockquote>
<br>
<p>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.</p>
<p><br>
</p>
</div>
-- <br>
For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><font color="#888888">**</font><br style="color:rgb(136,136,136)"><div dir="ltr" style="color:rgb(136,136,136)"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Nathan Lewan<div>IT Engineer - Identity and Access Management</div><div>Division of Information Technology</div><div>University of Maryland</div><div><a href="mailto:nlewan@umd.edu" target="_blank">nlewan@umd.edu</a></div><div>301-405-8019</div></div></div></div></div></div></div></div></div>