July 2025 Update

A couple of exigent issues arose that consumed a fair bit of time over the last few weeks. The greater of the two is fairly “public”, the denial of service impact of some malicious scraping of our GitWeb site which was consuming server resources and preventing legitimate access. Obviously this was nobody’s first choice, but we were forced to temporarily disable GitWeb while investigating options. We rely on the GitWeb interface ourselves for a few different needs, including some rewrite rules to access our XML schemas and access to certain test files during unit testing. We deployed workarounds for both cases over the course of a few days and identified a few improvements we need to make to some of our code to ensure that such outages don’t impact running IdPs to any major degree.

In the medium term we had only a couple of options and those are being discussed internally and we hope to finalize a decision this week in consulation with the Board. One of the options, which has some general value to the project independently, is to re-establish a Shibboleth SP in front of GitWeb to prevent anonymous access by robots. While this does introduce some inconvenience, the majority of our members (and even the wider community) will be able to use that without much trouble. We would not intend to actually limit the access on the basis of any data received.

The alternatives are more disuptive to our overall infrastructure, but they are still under consideration, as we have not yet managed to get an SP registered into any eduGAIN federations, though we should be able to do so. Either way, we have options that could be pursued together over time to address different aspects of the problem. We fully recognize that a more ideal option would be GitHub, and we continue to press for resolution to the legal barriers to that option.

Note that even without GitWeb, our source code remains publically and anonymously accessible, per Source Code AccessPreview.

The second issue, of somewhat less urgency, but more long term significance is the awareness that the Spring caretakers (the code now being owned by Broadcom after its purchase of VMware) have been moving to a more rapid timeline for sunsetting the OSS releases of Spring Framework. Most of their individual releases are now receiving about 18 months of support (about 6 months less than before), and it caught us a bit unaware. As of right now, the version we last shipped is EOL. We are facing a quandary now as to exactly what version to ship with a refreshed Spring version and how tightly to couple our release cadence to Spring’s. Strictly speaking, our versioning policy would imply that we have to go in lockstep (minor for minor, major for major) and doing so would imply somewhat shorter support periods than we typically plan for with major IdP releases.

We could also choose to diverge from a strict application of our policy for Spring and maintain IdP branches over time across multiple minor Spring releases, allowing our support timelines to be somewhat more flexible and reduce the sheer number of minor and major releases we would have to produce.

Ultimately, a lot of this centers on two factors:

• a perception (however misguided) that our major upgrades are “hard” to apply;

• risks to deployers of shipping more Spring upgrades in patches and minor upgrades, which itself could make the perception of the upgrade process closer to reality by causing unanticipated disruptions

One way or the other, we will have to ship more frequent patches and upgrades to maintain supported versions of Spring, and the timeline we can allow for supporting major releases may become more compressed. With V4, we had to sunset that support because of Spring 5’s EOL policy. That’s likely to be more common in the future; we need to map out a release schedule far enough ahead of time to allow for a reasonable development story for us, and a reasonable upgrade story for the community. We will be public with this plan once we settle on a roadmap for the next few releases.

In more mundane matters…

We shipped a set ot of OIDC upgrades with some new features and a set of new capabilities to support the proposed OAuth draft. After consideration of the risks, we left these options disabled by default for this release; we expect to tighten these in a future major upgrade to deliver “secure-by-default” configurations that if I had to guess will look a lot like our shipping AES-GCM by default: the right move and a permanent state of “needs to be changed to work with commercial implementations”. Hope I’m wrong, doubt I am.

I published the first set of Rocky / RHEL 10 SP packages, no reports of issues with them so far. Because of an issue with the now-legacy package signing key we used to use, we modified the scripts used to generate package repository files so going forward people installing these repositories should see only the newer signing key (my personal key) rather than the old OBS key, which was long expired. There remain older, totally unsupported packages in our mirrors that are signed with that key and it’s still posted on the download site if it’s needed.

I also made substantial progress on the SP 4 reimplementation, which is now complete enough to perform a complete SAML login exchange, with IdP discovery, and support for attribute export in the manner supported by the current SP. This is essentially a full SP that’s easily beyond the capabilities of the very earliest SP releases, but it remains at most an alpha at this point. A lot of features are still absent, and a lot of documemtation needs to be drafted. That work is now underway, starting with the new agent and progressing later to the Java plugins that turn the IdP platform into a “hub” for SP agents.

The agent documentation isn’t public yet, but it should be available sometime next month, though the Java part will take somewhat more time. I’m excited to see what people make of it. We are very on track for a usable alpha by late this year and I still hope a release in 2026 will be quite possible.