SP 2.0: Metadata with EncryptionMethod elements fails to load

[Russ Allbery]

Ferenc Wagner <wferi at niif.hu> writes:

> Great, thanks!  It occured to me that we may also take to opportunity to
> remove the reference to WS-Trust.xsd from the SP catalog.  Sporadic
> warnings appear about this in the 2.0 logs:
>
> WARN XMLTooling.ParserPool [13]: warning on line 0, column 0, message: An exception occurred! Type:RuntimeException, Message:Warning: The primary document entity could not be opened. Id=/usr/share/xml/shibboleth/WS-Trust.xsd

I feel bad that I didn't catch this catalog entry and this Debian-specific
change is causing these errors and any potential user confusion.  But...
at this stage in the release cycle, if it's just noise in logs that this
causes, I'm not sure it's a serious enough problem to push another change
through the release freeze.

Does this cause problems other than the warnings?

> I'm not sure about the best way to do this.  The following commits
> could be cherry-picked or merged into the Lenny branch:
>
> 533b5d91a3b26ee2b9f7883165ad3df563401312
> 43c6606f63b0986c1102d7018d3594a11f3f8236
> a2d1d8e217965f237da6859d407c2a064e188e44
>
> However, this would be dangerous in itself, as the version check in
> the postinst compares to 2.0.dfsg1-4 for handling the
> /etc/apache2/mods-enabled/shib.load -> shib2.load rename.  If
> including that isn't possible (being a quite important change), then
> the check version should be corrected as well.

I don't think that would change anything about that code.  The postinst
fixes things up if the previous installed version is older than
2.0.dfsg1-4 and leaves it alone if 2.0.dfsg1-4 was already installed
(since it would have already fixed the problem).  This should keep working
if we release 2.0.dfsg1-5.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>