Development and Releases with Security Fixes

[gregorydlogan]

Hi all,

Recently we have been discussing how to handle releases with security fixes in them. Many adopters can't or won't upgrade immediately, however attacks commence immediately upon release. Because of that, we've thinking about how to handle releases with security fixes going forward. Regardless of what we end up doing going forward, the intention is to announce the presence of a security issue in a release at least a week prior to its release date - no more surprise fixes you find out about the day of release! But how should we handle the details. Some ideas which have been floated:

• Announce the presence of a fix in a given release, but do not release the details until some time after the actual release
  • Counterpoint: Any semi-competent AI will be quickly parse out the details from the git history
• Announce the presence of a fix in a given release, only release a binary version, and hold the vulnerability details and code until some time after the actual release.
  • Counterpoint: Substantial overhead for committers
• Maintain a two channel release stream, where paying adopters can access the latest release, and non-paying adopters can access the previous release. For example, paying adopters would get 20.6 immediately, and non-paying adopters would get access to 20.5 at the same time.
  • Counterpoint: High overhead, may not be legal in the EU
• Same as above, but non-paying
  • Counterpoint: Same high overhead, but now without the funding to help deal with the overhead. This does help with the legality though.

These are obviously not the only options, and community suggestions would be very welcome either here, or in technical meeting on November 10. My goal is to round up as many committers as possible for that meeting, with the idea that we might be able to discuss further at the virtual summit. See you there!

[rrolf]

Hi Greg, where does the idea of a paid recent and unpaid older release beeing illegal in the EU base on? A paid access to the most recent release would also have the benefit that we have first a filter that not the bad guys also subscribe to the latest release channel (although it should not be the only filter). I only had in mind that public institutions paying for something that is not an added value would be a problem. I would not go for the public version beeing 1 release late, I would go for a delayed release like 2 weeks after, to give subscribers enough time to update, before the bot come. Regards Rüdiger Am 14.10.26 um 04:37 schrieb Greg Logan:

…

Hi all, Recently we have been discussing how to handle releases with security fixes in them. Many adopters can't or won't upgrade immediately, however attacks commence immediately upon release. Because of that, we've thinking about how to handle releases with security fixes going forward. Regardless of what we end up doing going forward, the intention is to announce the presence of a security issue in a release at least a week prior to its release date - no more surprise fixes you find out about the day of release! But how should we handle the details. Some ideas which have been floated: * Announce the presence of a fix in a given release, but do not release the details until some time after the actual release o Counterpoint: Any semi-competent AI will be quickly parse out the details from the git history * Announce the presence of a fix in a given release, only release a binary version, and hold the vulnerability details and code until some time after the actual release. o Counterpoint: Substantial overhead for committers * Maintain a two channel release stream, where paying adopters can access the latest release, and non-paying adopters can access the previous release. For example, paying adopters would get 20.6 immediately, and non-paying adopters would get access to 20.5 at the same time. o Counterpoint: High overhead, may not be legal in the EU * Same as above, but non-paying o Counterpoint: Same high overhead, but now without the funding to help deal with the overhead. This does help with the legality though. These are obviously not the only options, and community suggestions would be very welcome either here, or in technical meeting on November 10. My goal is to round up as many committers as possible for that meeting, with the idea that we might be able to discuss further at the virtual summit. See you there! — Reply to this email directly, view it on GitHub <#8134?email_source=notifications&email_token=AAOOOFP7NU3RKLTK3OUMU3T5T3RE7A5CNFSNUABBM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63RPGEYTAMJTG4ZTRJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOOOFJUQ7EQCGVABCHKUXT5T3RE7AVCNFSNUABIKJSXA33TNF2G64TZHMYTCNJRHE4DMOBXHNCGS43DOVZXG2LPNY5TCMJQGEZTOMZYUF3AE>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAOOOFLT54UEKKZ7MEC5YQ35T3RE7A5CNFSNUABBM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63RPGEYTAMJTG4ZTRJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AAOOOFP52JA72VQI4QZ5XWD5T3RE7A5CNFSNUABBM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63RPGEYTAMJTG4ZTRJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Rüdiger Rolf, M.A. - Stellvertretender Geschäftsführer - Universität Osnabrück Zentrum für Digitale Lehre, Campusmanagement und Hochschuldidaktik (virtUOS) Seminarstr. 20, 49074 Osnabrück Telefon: (0541) 969-6511 - Fax: (0541) 969-16511 ***@***.*** Internet:www.virtuos.uni-osnabrueck.de

[gregorydlogan]

There was a concern raised that placing security issues behind a paywall is not allowed within the EU - I haven't actually looked into this though.

[mtneug]

My understanding is that vendors (like elan or shio) need to provide security updates free of (extra?) charge within the support cycle (my understanding, 2 years in the case of an Opencast release). I'm not sure if delayed security updates are ok.

However, I'm not a big fan of this proposal in general. IMO, this violates the "social contract" we have with the community. Also, sticking with the Apache 2.0 license, anybody can publish the code within the "closed timeframe". I maintain public forks with my patches. Should I have to make them private as well to introduce the security patches there?

[gregorydlogan]

I don't disagree re: the social contract. So then are we (barring someone's brilliant idea) restricted to just giving some kinds of heads up ahead of time so that adopters, vendor represented or not, are braced for impact?

Re the forks, that's a really good point. Anyone working with even potentially public forks risks accidentally pre-releasing things.