Well in my view, if we do not have the break BC escape hatch we may not be able to fix some of the issues at all.
If you have a method that returns a collection of things and then you change the contract so that it now only returns the subset of things that the current authentication is allowed to know about... that is breaking BC in the strict sense, but it is the only way to fix a security hole of the `XYZ.getWidgets() returns all the Widgets even the ones that the user does not have permission to see` variety. Similarly a `XYZ. getWidget(name)` may have to return `null` for a Widget `name` that exists but the user does not have permission to access. There are plugins that may break because of this behaviour... for example a plugin might assume that `XYZ. getWidget(name)==null` implies that the widget does not exist and thus `XYZ.addWidget(name,widget)` will succeed... So the fix I would prefer to see in the above example is that `XYZ.getWidgets()` returns the subset that the user has permission to see, `XYZ.getWidget(name)` returns null both for widgets that do not exist and widgets that the user does not have permission to see and `XYZ.addWidget(name,widget)` either does a no-op or throws an exception when trying to replace a widget that you do not have permission to access... all those changes risk breaking plugins... If we don't do that fix, then what we have is `XYZ.getWidgets()` returning all widgets, we mark that as `@Restricted(DoNotUse.class)` and add `XYZ.getUserVisibleWidgets()` hoping that the downstream plugins update and get the fix... until then we have just pushed the SECURITY-XYZ issue into 5 SECURITY-... issues in those five plugins that used `XYZ.getWidgets()`... that is not what core should be doing IMHO... it doesn't make sense to trade one SECURITY issue in core for 5 SECURITY issues in plugins... better is to trade one SECURITY issue in core for 5 JENKINS issues in plugins... that lets a wider group of people work on fixing those bugs On 15 September 2015 at 13:44, ogondza <[email protected]> wrote: > On Tuesday, September 15, 2015 at 2:04:54 PM UTC+2, Stephen Connolly wrote: >> >> >> The security fixes are typically prepared in advance for this reason >> and pushed to every branch at the same time to minimize exposure. If >> we do not do the concurrent releases then LTS becomes vulnerable. > > > I understand that, though it is enough we dictate LTS users when to update > (even if there is no other way, they are hardly happy about that). If those > users can not rely there will be no breaking changes (even within one LTS > line) it will hurt stability (because of the breakage we may caused) and > security (as admins can postpone the upgrade because of the potential of > breakage) IMO. > > What is the other side of the coin here? The fixes will be smaller and > simpler for sure if we are allowed not to preserve BC in 100% of cases. > Anything else? > > -- > oliver > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/a2b2e18e-41d2-4c29-a1ce-03392a5b8509%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxhEru%2BGh-pMMH%2BTRozgSQ-rJ62aheT1DSgcEPXNdaK3w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
