Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
Reminder: Please copy/paste the Zoom chat into the notes. If you miss it, this is saved along with the meeting recording, but having it here has benefits.
@Olamide Kolawole explained that proposal changed as linked and described above.
Discussion
@Wayne Schneider This proposal comes from security team identifying issues requiring CSPs. Does not address functional bugs identified after support period date. Is that a concern, or ok to lump those two things together?
@Julian Ladisch The official support period includes both kinds of fixes.
@Wayne Schneider Agreed that it does. Questioning whether that is ok.
@Maccabee Levine If PC can weigh in on this proposal also, I’m ok with them weighing in on that part.
@Wayne Schneider If we are waiting for PC, then timeframe may be too tight. November is too tight to make upgrade decisions by December (short month). Can’t support proposal if that is the timing. But if security and functional fixes were split up, could support this proposal. Concerned that we would say a functional (i.e .data corrupting bug) would be prevented.
@Mark Veksler Lots of institutions are still on Quesnelia even though long out of support. Migration to Sunflower is not forced, people can still stay on Ramsons, risk is low that P1s would be uncovered.
@Julian Ladisch This is about official support period. Fixes are still ok if teams are paid to do so. Just like running a release after official support ends, taking that risk. Can’t say that we do functional support but not security support, it would be misleading.
@Wayne Schneider So if a development team acknowledges a P1 support issue that needs to be backported to Ramsons given lots of users still on Ramsons, would that be a CSP? Or a release made out of the release branch, posted on FOLIO docker presence, but somehow unsupported?
@Julian Ladisch Similar situation right now with Sunflower Okapi, has some security fixes, even though not officially supported. So fixes could be made on Ramsons. If people are willing to provide resources to do the CSPs, even for unsupported Ramsons.
@Olamide Kolawole CSPs are not limited to security fixes – most functional.
@Maccabee Levine Agree, and we will likely still have P1 issues in Ramsons after January. I would be concerned if community had no way to deal with them. If we are still allowing CSPs then that’s fine, but policy should be clear on that.
@Olamide Kolawole Agree that P1s in January would still need a CSP if serious enough. While security patches at that point are not ideal because it requires in-depth knowledge of the dependency. For security issues, the security team opens PRs on the specific modules for the dev teams to review and merge. If there’s a P1 in January for Ramsons, who will fund that, how will that change happen. If it required an upgraded dependency or a patch, who would do that – it’s not a technical question, but we can describe the current landscape.
@Mark Veksler May be helpful to list the various scenarios, P1 / P2, who would need to own it, what potential costs might be. If it’s out of community support, community may decide to fund it. Or if it’s a hosting service provider, they may absorb the cost and do on their own. Should differentiate those two.
@Wayne Schneider Example of something a hosting provider would be managing, outside of community support?
@Mark Veksler For example if a P1 in Quesnelia discovered, community has moved on, but hosting providers may decide to upgrade them to Ramsons or to fix the issue in Q. Would have to use their own resources to provide the fix.
@Wayne Schneider Assumption is that the risk hosting providers and customers would be taking on is the risk to rush an upgrade, rather than generating an unofficial version of the software.
@Mark Veksler Might be case-by-case decision, could be cheaper to implement the fix.
@Wayne Schneider With Log4J there was a configuration mitigation.
@Mark Veksler Yes, third option is to provide a compensating control.
@Kevin Day Add option 6: use commercial support where available, i.e. for Spring Boot. High cost.
@Olamide Kolawole FOLIO module would still need to be upgraded to that version?
@Kevin Day Yes would need a patch separate from the community.
@Olamide Kolawole Falls under option 2 in a way. Commercial support is the one doing the custom patch. Kevin agrees.
@Wayne Schneider It’s a little different, if we did the patch we’d have an Apache-licensed fork. Commercial support maybe not, could introduce proprietary code, require separate release.
@Julian Ladisch Yes, closed source, pay per CPU, and would require a closed repository. Very expensive.
@Florian Gleixner Option 3 (upgrading to next FOLIO version). Actually self-hosters have problems doing this sometimes, if there are bugs, waiting for CSP 1 or 2. Self-hosters also also may have problems contributing to BugFest. So not easy.
@Olamide Kolawole Agree it’s medium impact. If Option 3 is not good on case-by-case, have to choose one of the others.
@Maccabee Levine Just confirming that this addresses only P1 security issues, not the P1 functional issues we discussed earlier. (Olamide confirmed.)
@Tod Olson This document would be useful for sharing with PC how we are thinking about these cost options.
@Olamide Kolawole The security team would not be doing a patch (option 2) if a P1 is discovered in January. So if we want to extend the support period past December to include both security and functional issues, it’s a matter of who is doing the work.
@Maccabee Levine If we don’t adopt this proposal, then Ramsons support date extends further for both security and functional.
@Wayne Schneider I would support something that separated functional and security. If in January a P1 security issue is raised that affects Ramsons, no matter what the policy says, there just isn’t money in the bank to do the backporting. Security teams concerns and cost docs make clear that it wouldn’t be addressed regardless of policy. Communicating that in some way is really important.
@Olamide Kolawole Agree, whether the proposal passes or not, security team would not be doing those patches in January.
@Julian Ladisch Security team would propose the costly patches and upgrades.
@Maccabee Levine Then by not supporting this DR, we split functional and security in effect. Because functional would still be supported, and security in practice would not be.
@Ingolf Kuss Should not have discussed supporting Ramsons longer in the first place.
@Wayne Schneider Encourage not doing nothing, from a communications perspective. Important to raise the risk that we are taking on. At TC we discuss risk in a nuanced way, not just “risk is bad”. Help communicate what kind of risk we’re talking about here.
@Julian Ladisch Separating the security and functional fixes, made a note in the DR. That RMSG can still accept functional fixes as CSPs if there is funding.
@Maccabee Levine Is is possible to remove the funding note on that part? Funding is always a dependency.
@Mark Veksler But who would be fixing / fun it?
@Tod Olson Perhaps the RMSG may accept a functional fix that is offered. Not assigning work, but willing to receive work as offered. Also important that the proposal is extending the security triage.
@Wayne Schneider The funding issue feels like it gets well outside of the technical area, it’s a product decision. If a product is under suport, then fixes are not funded any more than if it’s out of support. We have a convention that dev teams fix P1 bugs. Mark suggesting that dev teams wouldn’t take on that work once unfunded. That feels like a significant decision, and a product (not technical one).
@Mark Veksler Jeremy Huff had suggested an emergency fund for supporting P1 issues that are not funded.
@Maccabee Levine Agree with Wayne. Also worth mentioning that Ramsons P1s will tend to be backporting of Sunflower / Trillium P1s, so different context of development work.
@Mark Veksler There has to be a clear cutoff date, even if not January 1. From EBSCO perspective, will continue to provide support for versions that our hosted customers are running on. During transition period of upgrades, that means support for two versions. Right now doing S upgrades, so supporting R and S. Expect upgrades to go past Jan 1, so will continue to support Ramsons since still hosting those customers. Once all customers are upgraded to latest FOLIO release, then community will need to determine funding for unsupported versions.
@Wayne Schneider Not comfortable bring forward a recommendation that support period for P1 functional issues ends Dec 31, and community needs to come up with emergency funding on short notice. Willing to consider. The problem we’re facing is a result of RMSG decision to push back the release of Trillium. Not an unconsidered decision at the time.
@Olamide Kolawole Funding is not included in this. Julian’s edit to keep it stritctly security minimizes that.