Open siwhitehouse opened 1 year ago
@siwhitehouse
I'm a member of the tech and security teams for CKAN, and as such, I'm one of the ones supporting the core software.
Our version of 2.9.8 is effectively 2.9.9, as we applied the security patch from 2.9.9 prior to the public release. We rolled this out early during the embargo period due to the severity of the issue.
In terms of the major version (2.9->2.10) there's some code changes in extensions that are required for that upgrade, and we'll need to budget time for that upgrade.
We discussed this today as the solution to resolving #413
I'm not sure how much of a "big deal" an upgrade to CKAN is, so I'm erring on the side of caution: I'm happy for someone to tell me that I'm being over cautious!
I'm imagining that the first step after doing the upgrade will be to respond to any errors that emerge during the upgrade process itself, along with any testing of functionality based on Derilinx' experience of upgrading.
Then, it would be useful for someone to do a click-through test of all of the various bits of functionality that the Registry offers. I would suggest that @cormachallinanderilinx does this to avoid the overhead of reporting issues. I'm conscious as well that a number of publishers make automated updates to their Registry entries, so we should be careful to test API access.
Once we've resolved anything that comes up as a result of that testing on staging, I'd like to set a date for upgrading the live instance, that we can communicate to the community for awareness. We send out the newsletter around the middle of each month, so I would hope for a timescale along the lines of:
We'll also want to make sure that the upgrade happens at a time when we've got good availability of support staff, and away from any politically sensitive deadlines (such as data pulls for indexes).
Hopefully, all of this will prove to be unnecessary, but I think we're good to be cautious.
There's certainly going to be some changes at the extension level to deal with the new features of the CKAN backend. That's relatively managable, as there's a pretty clear way to do the update. https://docs.ckan.org/en/2.10/changelog.html#removals-and-deprecations
The biggest issue I can see happening is that the legacy API Keys are removed in 2.10, replaced by API Tokens. They're essentially compatible on the client side, but it requires everyone updating their credentials in automated systems.
Just to recap, I think our plan of action is:
First, find out how our users use the API Then, decide on how we support them to update their credentials; this will depend on exactly what we discover about usage. Resolving this question could be important here. Then, do the things I described earlier to make sure that we're confident in the upgraded state.
We've made the announcement on IATI Connect and there have been no concerns raised so I think we can proceed with this.
@cormachallinanderilinx please give us a week's notice of when this upgrade will take place so that we can make sure that we are adequately covered on Support, just in case.
Hi Rob, Lets do it Monday/Tuesday week, so the 21st or 22nd? It should be a quick upgrade.
Thanks @cormachallinanderilinx . Just checking: is that ok with you @siwhitehouse ?
@robredpath aiui Staging has already been upgraded. So long as @cormachallinanderilinx is happy with the testing he has done there, I'd say we can update on the 22nd. This will give me time to inform support colleagues.
Brief Description I think we are currently running on an unsupported CKAN version
Severity High
Issue Location In
view-source:https://iatiregistry.org/
there is the following element<meta name="generator" content="ckan 2.9.8" />
According to the CKAN documentation
and
@cormachallinanderilinx Can you clarify, please? Is the version unsupported and, if it is, what options do we have for upgrading?