I don't think everyone is basically agreeing and the contention points appear to be small, but we can't make blanket statements like "the security hole trumps backwards compatibility." It's obviously more nuanced than that. Generally we tried to keep both goals.
Fortunately, so far as I recall for most issues, we didn't have to break backward compatibility and in doing so we didn't feel like we had to make the fix "ugly." SECURITY-144 was a complicated example --- it added a new API (which we generally try to avoid in security fixes) but it was not a binary incompatible change. The situation we need to avoid is to require a non-trivial number of plugins to be updated as a part of the core update. We cannot coordinate fixes in those plugins with core release due to the way security fixes are prepared, and users have no effective means to update them all in one. There are also many users who don't care about the vulnerability the fix is addressing, and we want to make sure fixes are not affecting them. And above all, if we end up creating a perception that security fixes are risky, that's very dangerous. And it's hard to win back that kind of trust once we lose them. Those are some of the arguments why backward compatibility is important, and why we have to have damn good reasons if we are going to break them. 2015-09-15 3:39 GMT-07:00 Stephen Connolly <[email protected]> : > Those of us who are on the jenkins-cert list have probably seen my > comments about how there needs to be some guidance from the community > on how far SECURITY issue fixes can go. > > I am starting this thread to try and start compiling that guidance. > > The general problem (as I cannot share the specifics outside of the > jenkins-cert list) is as follows: > > * User raises a SECURITY issue from noticing some implicitly defined > API of Jenkins has a hole of some sort > * We have to fix the issue, but fixing it will involve changing the > implicitly defined API and thus risking breaking existing "users" of > the implicitly defined API > * Much heated debate around should we leave the old API present and > try and redirect to the new one (thereby leaving the hole open) or > break existing plugins and close the hole. > > In some cases it is possible to use a system property to re-enable the > hole for those users who are accepting of the risk... but other cases > require changing class structures (this can range from encapsulating > fields to completely reworking the java class that gets returned) > > My view is that a hole is a hole until it is fully plugged, and if > plugging the hole means that some plugins break, well sorry but > SECURITY... now by all means we should seek to minimize that breakage > *while closing the hole*... and where possible we should provide a > System property based switch to re-open the hole for those users who > upgrade and are ok with the risk. > > Let's take a semi-concrete example: > > In order to fix SECURITY-144 we had to change the interface of > h.r.Callable to include the role checking... being pre-java 8 we > cannot use default methods, so this was a backwards incompatible > change... any plugin that does not implement the role checking method > would potentially be broken... as a result - and after much debate - > it was decided that a majority of people implicitly trust their slaves > as much as the master and so the role checking is likely not required > for maybe 60-70% of installations. Thus the role checking ships off by > default and we implemented a way to whitelist plugins that are > compiled without role-checking support. Thus if you have slaves that > are less trusted than the master you can opt-in to the higher security > requirements... if there are plugins that you need that get broken, > you can white-list those specific plugins if you absolutely need to. > > The point here is that we closed the hole. We felt the risk of plugins > being broken was sufficiently high that the hole would not be closed > by default (The plan is to measure the plugins with support for roles > and once above a threshold then turn on secure by default) but when > the security is turned on it is on. > > So what kind of things do we need guidance on: > > * Some methods of some objects allow you to discover information about > other objects that you do not have permission to discover. > - Do we just protect the ways that we know about and leave the > original method present with a @Restricted(DoNotUse.class) so that > when plugins upgrade their core version they are forced to switch to > the new method; or > - Do we change the contract of the current method (so it now > returns maybe a null or throws an exception or omits entries from a > collection) so that the method does what it was originally supposed to > do but didn't... this may break existing plugins in fun and exciting > ways > > * Some objects have public fields that are either mutable or of a type > that needs to be changed in order to remove the hole. > - Do we leave the field as is and just introduce the new accessor > methods - leaves the hole as is... so we have to rely on adding a > stapler action method (since they are higher priority than public > fields) to mask that route to discovery via Web and hope that there > are no other routes to that field... > - Do we say kill that field, you shouldn't have been using it (oh > and let's hire a hitman to find the lazy developer who made a public > field rather than use their IDE to generate getters and setters) and > risk breaking any plugins that actually use the field. > > * Some HTTP requests can be used for more than their original intended > purpose. Jenkins Admins may well have discovered this and - rather > than thinking oh look a security issue - used such back doors to do > important things for their instance > - Do we try and make such back-door usage as safe as possible - > which in a sense makes this side-usage officially part of the API of > that HTTP request > - Do we lock the HTTP request down to its original intended > purpose and break any side-effect usage that Jenkins Admins were > hijacking? > > There are probably other classes of guidance required, but my brain is > melted trying to derive the classes from the issues I am aware of so I > cannot think of any others at the moment. > > It all boils down to the question: > > Which is more important, maintaining backwards compatibility or fixing > the security hole. > > My view is that fixing the security hole trumps backwards > compatibility, if we have to break a few plugins or a Jenkins admin > has to find a different way to solve their problem... well sorry but > SECURITY... that doesn't mean we should start by breaking backwards > compatibility, rather we should do everything we can to close the hole > while maintaining backwards compatibility... but when that isn't > enough to close the hole (and usually it is not enough BTW)... well we > need to close the hole. > > Over to you! > > -- > 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%2BnPnMw6rhFBDP-jjqaaNN8YZoxT1kqGUXR1F9hvDT6s%2B01_Bw%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- Kohsuke Kawaguchi -- 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/CAN4CQ4xo3-yc2uvCBY%2BbK64Jjm6wW1yUhOBc96043dZh%2BgdaVw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
