April 2026 Update
Primary work right now is centered around preparing for the next IdP patch, continuing active development workstreams (SP4, OID Federation) and rolling with the latest infrastructure challenges.
Best guess right now is an IdP patch (V5.2.2) will be coming in early May but no later than end of that month. We will have some more to say on this via the typical channels in the near future once the schedule is clearer.
We have not received significant testing feedback on the SP, but development has started on some of the major development tasks left, starting with logout support and some internal code redesign to clean up and enhance the state management and CSRF mitigations. Once that work is done, especially the logout features, we’ll be ready to release a second alpha of the Agent, probably in early Summer. The largest remaining functional task is probably the audit logging in the Hub. An initial draft of a lot of the formal SAML reference documentation is also done, with the OpenID work to follow. That’s not meant to be introductory, it’s the deep dive into all the settings currently implemented.
The “legacy” SP is going to need a refresh to migrate the Windows package to a supported version of OpenSSL, likely 3.5, which is an LTS release that is supported through 2030, by which time that code will absolutely be retired. We hope that this will not be difficult, but we have a lot of legacy code that relies on deprecated OpenSSL APIs and there are certainly the possibility of additional work being necessary, or even (outside chance) functional limitations if we can’t justify the work to reimplement something. We should have a handle on that by May and if it’s a routine update we will get another Windows package update done by then. If a serious security issue arises, we will of course have to accelerate that timeline.
As I write this update, we are coming out of the latest challenge with our infrastructure, which we are really beginning to outgrow. Our Maven repositories experienced a major spike in traffic, some (but not all) of which was coming from some abusive clients that we have since blocked. That plus adding capacity has restored stability, but as with the Codeberg migration, we have to do something different here. Options for adding a caching/CDN layer to that part of our system are being explored.
While we would love for that “something” to simply be putting the artifacts in Maven Central, I’m sorry to have to keep repeating that that’s not going to happen until such time as we have a company or non-profit organization to assume the liability for doing so. The instant that changes, we are happy to do so. We do not blame Maven Central for that requirement, we never have.
In the meantime, thank you to the community members who offered to help and are actively helping to look into some of the options for fixing the situation. In the meantime, I’ll make or repeat a few points:
We don’t owe anybody anything unless they’re paying members of the Consortium. We have no intention of denying members access to the artifacts and if it ever became necessary to close off public access, we will provide access by other means as expediently as we can.
We don’t intend to close off public access, but you most certainly need to understand we can and will if there’s no other way to maintain our own access and that of our members. If we did, the source code would remain accessible via Codeberg.
Anybody using any remote repository is simply asking for problems if they aren’t using a caching repository tool in front of those sources to maintain access in the event of outages. If you can’t swing that, then you’d best be able to tolerate some outages.
If you do insist on treating a small open source project’s web server as mission critical, then maybe consider subscribing to that projects announcement mailing list so you know when something’s up?