Shibboleth Developers

["Scott Cantor" <>]

There have been a couple of bugs reported against the siterefresh tool from
alpha testers, which isn't surprising since I haven't touched it yet, and it
wasn't actually part of the "supported" alpha release.

In response, I've alluded to the fact that I really haven't decided yet what
to do about the tool, but am leaning toward rethinking its purpose. You can
see a bit of that here:

https://bugs.internet2.edu/jira/browse/SSPCPP-30

I think the same arguments, perhaps less so, apply to the Java version,
apart from its function as a file signing utility, something we really
needed to genericize anyway (I mean, requiring keystores just to sign a file
is really hideous).

So in a nutshell, I'll listen to arguments, but my inclination is to dump
siterefresh and replace it with something that is essentially a wrapper
around the metadata plugins and filters in Shib 2.0 to allow for somebody
that needed to test or verify a metadata file out of band before supplying
it to an SP.

The justification for this is that for standard cases, most 2.0 deployers
should be able to turn off their siterefresh scripts and just use the
built-in code that fetches and caches a remote file periodically. I have
backported some code from Xerces 3.0 as part of my 2.7.1 package so that it
can load files from https:// servers, something it can't do currently.

My general outlook is that it's a mistake to try and reinvent curl (or wget)
and that the proper approach is to use those tools to feed stdin if we keep
a tool similar to siterefresh in the picture. As I have done in the past,
the Windows SP will always include a curl.exe for that purpose.

-- Scott