Implement mitigations for mdui:Logo elements with umlauts

[philsmart]

PHP-based metadata refresh machines are failing on the umlaut in <mdui:Logo height="68" width="240">https://mdv.aai.dfn.de/media/logos/e115/Logo-SLUB_Geschäftsbrief.jpg</mdui:Logo>. We are going to add a rule that strips any mdui:logo that contains non-ASCII characters.

Whether non-ASCII characters are allowed in URIs is something we are trying to work out in parallel. It seems possible from RFC 3986 that they are not [1]. However, given that we have implementations that do not support it, it seems pragmatic to remove them from the aggregate.

[1] https://www.gnu.org/software/emacs/manual/html_node/url/URI-Encoding.html

[philsmart]

The testbed rule will need to check for an error if it spots such a URL. The pipeline process will remove it.

[philsmart]

Noting this is going to be similar to strip-mdui-logo-http.xsl

[philsmart]

This [^\x00-\x7F] regex would be any character not in the ASCII range (a character not in the range starting at value \x00 and ending at value \x7F).

[iay]

Very hard to do in XSLT, probably a lot easier to do if you use the validation framework and look for explicit regular expressions in the string. Of course that's only going to give you the ability to reject the entity, not filter stuff out, but perhaps that's acceptable given the alternative outcome.

You probably want to exclude the low values as well, things like \x07 are not really things you expect in URIs.

[philsmart]

Thanks, @iay. Yes, it seems hard to do in XSLT 1.0. I've naively tested a reject string regex validator:

<bean p:id="non-ascii" parent="mda.RejectStringRegexValidator"
                    p:regex=".*[^\x00-\x7F].*"
                    p:message="mdui:Logo contains non-ascii characters" />

Which picks this up, but also some others (looking into it). But yes, this will reject the entity, not strip it out.

[iay]

You might look into the character class matchers. Java regular expressions have a lot of helpers like that.

Another thing we could consider in the longer term would be to look into extending the MDA with something that allows validators to be used as predicates, and add an ElementRemovingStage based on such a predicate. Not sure how much rework that would imply, so that's not on the cards for MDA 1.0. Something to come back to after the IdP 5.2 / MDA 1.0 releases are out of the door, perhaps.

[alexstuart]

Very hard to do in XSLT, probably a lot easier to do if you use the validation framework and look for explicit regular expressions in the string. Of course that's only going to give you the ability to reject the entity, not filter stuff out, but perhaps that's acceptable given the alternative outcome.

Yes, I think that's acceptable. As I understand it, there are currently no entities with problematic URLs, so implementing a more invasive response won't affect existing entities.

[philsmart]

You might look into the character class matchers. Java regular expressions have a lot of helpers like that.

Good point, it seems from https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/regex/Pattern.html that you can use:

• \p{ASCII} -> All ASCII:[\x00-\x7F]

[philsmart]

OK, so replacing with the character class works:

<bean p:id="non-ascii" parent="mda.RejectStringRegexValidator"
                    p:regex=".*[^\p{ASCII}].*"
                    p:message="mdui:Logo contains non-ascii characters" />

It possibly needs refining; Ian's comment about \x07, and it is catching a contains non-breaking space. contains non-breaking space is already caught by check_mdui_logo_url/nbs and results in a rejection of the entity. If we add this check alongside check_mdui_logo_url/nbs in check_mdui_logo_url, then I can not see harm in either of them catching the error (although there are more possible error messages, one less specific than the other).

[alexstuart]

1. Yes, it probably does need refining, although any check which improves the import rules by filtering out non-ASCII is better than what we currently have, and would allow those deployments to consume metadata. I'd say we should land is as-is.
2. There are other places where problematic input triggers more than one error condition. That's ok.

[philsmart]

This is in a partial state, I can not sync the new validator from ukf-meta until #132 is completed.