June Update

Two months worth of updates to catch up on and there is a lot to report on.

After waiting another few weeks to work out some plugin issues, we shipped the first patch for V4.1 last month. This is V4.1.2 rather than V4.1.1 because one of us luckily discovered a problem with the release after we were done with it. It was traced it to a Maven "behavior" we're still working through but we have a better idea what to watch for and will be working on some automated checks to prevent a recurrence.

The overall fix list for the patch is relatively small, excepting a major X.509 regression, because there haven't been a lot of bug reports yet due to lack of adoption. While a couple of minor edge cases have popped up on some upsupported Java containers, the evidence we have suggests the system file elimination has not proven to be a problem. The one issue that has come up a few times is that people are running into problems caused by upgrading running systems or because of Tomcat caching old jars, which isn't really new but is a bit more noticeable with this upgrade. Part of the process is just developing confidence that the new approaches are working, so we can safely conclude that some kinds of problems are going to be environmental and not a real bug.

One of the reasons for the patch delay was aligning all the OIDC plugins because we discovered the IdP was shipping with some jars we don't need, but that are used by one of the new Duo plugins. Fixing all that, plus fixing some Nimbus bugs to allow our OP implementation to pass the OIDC certification tests, required some plugin updates, and orchestrating all that properly took some care. The latest OIDC plugins actually require this IdP patch and the new plugin machinery allows that to be managed properly even though we didn't anticipate the need, which is why we developed it in the way we did. This is still very raw from a user experience perspective and feedback on the behavior via Jira is still welcome.

Out of all that, we are able to announce that we've passed the OIDC OP certification tests and once the paperwork is done, an official announcement will be forthcoming. Congratulations to Henri on that milestone.

I would also like to draw attention to the fact that when we produce releases we will be (when time permits) updating the SecurityAdvisories page with documentation on any outstanding vulnerabilities in shipped libraries that we are aware of and our reasons for not correcting them (e.g., they're not real, or they don't affect the product, or they're minor but will be dealt with in a subsequent patch). This is intended to assist people getting dinged by automated scanners, which generally don't provide meaningful feedback about what is or isn't a real problem. Of course, if you're not on the latest version, then this is irrelevant because the only solution is going to be to upgrade anyway, nothing new about that.

For the SP, we have held a couple of design discussions on our calls about some of the options involved with reimplementing portions in Java and we are settling at least for now on a design that's much closer to "just reimplement shibd in Java" than I started with. This is still coupled with some ideas we hope will enable more of a shared deployment model for clustered systems by reducing the chatter, but it does avoid the problem of implementing a secure protocol (such as a web service) because of the dependencies and code volume in C++ that would require.

To get to the next phase of work, I have reimplemented the current data structure and IPC remoting code in Java, and eliminated the use of XML as a data serialization format. Once we prototype a shibd "shell", we can begin to sketch out remote APIs (which in this redesign will be fully documented and public) that will be needed to get a better sense of the scope of work and allow it to be split up amongst more Java developers if available. The goal isn't to make a lot of progress on this in 2021 but to get some foundational work done so that we can get serious about it in 2022 and beyond.

In the meantime, we'll maintain things as best we can, and we will probably be producing new packages for the current version to update the platforms we support to reflect the changes over the last year, such as RHEL 6 sunsetting. The new packaging process will drop SUSE support (our packages for SUSE are strictly out of date releases anyway) but allow us to produce packages for Amazon Linux and the new Rocky Linux that appears to be emerging as a CentOS replacement. CentOS 8 itself will probably not make sense to continue worrying about because it will be a moving target like Fedora.

Other notable work includes a lot of initial kick the tires work on the migration from Confluence and Jira Server to Cloud. Because we're in a relatively light period of the development cycle, we're preparing to kick off this process in earnest over the next few months, and it's going to take a lot of calendar time just to allow everything to be moved with the least disruption possible. Expect more concrete public communication about this very shortly. The end result is probably not going to be what everybody would want, including the loss of federated login to our systems, but there's nothing we can really do about that. There are at least some trade offs for that, including the fact that you're generally never logged out either.

Lastly, I want to highlight that the Project Work Items has undergone a major revision and update, and after originally planning to shift a lot of planning over to Jira, we reversed course given the software situation there. Instead I cleaned up the page, separated maintenance from new work, and hopefully provided a decent summary of everything major we have going on, which is a fair amount of stuff. As we develop concrete design plans for some things, we will certainly link them to the roadmap items for those who want more detail.