> > I think it is worth considering having a “risk slider” setting in > Jenkins configuration: >
+1, but probably it's hard to manage so many security modes. I would propose to add a single "SECURITY.PARANOID" mode, which would be available through system properties or the global security page. FWIW I am not aware of any actual regressions from this delivered fix > and I still think we should have just enabled it by default +1 if we have an opportunity to disable the security fixes on the per-issue basis. In such case the admins would have an option to temporary fix the regressions on their own risk. If we (as in the people on the > jenkins-cert list) do not create the downstream tracking bugs for the > side-effects of breaking BC then we are in just the same place as if > we didn't create the downstream SECURITY issues to investigate each > plugin's use of the old method and replace it with the new method as > appropriate ... Same 1 -> N issue multiplication concern In several pending PRs N will be too big (see the parallel jenkinsci-cert thread if you have an access). I doubt we can cover all usage cases even in OSS and to create follow-up issues in plugins. вторник, 15 сентября 2015 г., 16:12:28 UTC+3 пользователь Stephen Connolly написал: > > On 15 September 2015 at 13:53, Jesse Glick <[email protected] > <javascript:>> wrote: > > On Tue, Sep 15, 2015 at 6:39 AM, Stephen Connolly > > <[email protected] <javascript:>> wrote: > >> In some cases it is possible to use a system property to re-enable the > hole > > > > Generally I would really push back on introducing alternate behaviors > > using a system property, especially something important like this. > > > > I think it is worth considering having a “risk slider” setting in > > Jenkins configuration: > > > > 1. My instance has no security, whatever, stop asking me questions. > > 2. I have some basic login authentication, but am not worried about > > concerted attacks. > > 3. OK, defend against the obvious stuff like CSRF attacks, but do not > > get too exotic. > > 4. Please do not keep any secrets on local disk. My build slaves are > > not trusted. Users must be compartmentalized and never see information > > about other teams. > > 5. I work for the government. I cannot discuss details. > > > > Just a simple sliding scale, and then we can infer various other > > security settings based on this. Obviously when we can defend against > > something with no downside, we just do it, but this master setting > > would help us decide when to make certain compromises. > > > > Recent versions of the JRE do this, FWIW. > > I like this model... we would need to build guidance for assessing > security issues against that categorization > > > > >> 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 > > > > Generally agree. > > > >> The point here is that we closed [SECURITY-144]. 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. > > > > FWIW I am not aware of any actual regressions from this delivered fix > > and I still think we should have just enabled it by default. And is > > anyone actually tracking follow-up tasks from this? AFAIK we shipped > > and then it just dropped off the radar. > > Yeah I know (I am a sad panda) > > > > >> 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 > > > > +1 on this approach when feasible. > > The problem I see is that we have just transformed one SECURITY-... > issue against core into N x SECURITY-... issues against plugins that > use the old method... some of them may not be exposing the issue in > their use of the method, but each and every one needs to be > assessed... given the extra work involved in handling SECURITY issues > (needing CVEs etc, reduced number of collaborators, etc) I think it is > actually better if the downstream side-effects are just regular bugs. > So fixing the existing method - even if that risks breaking plugins - > is IMHO better than the `@Restricted(DoNotUse.class)` model... *BUT* > we'd still need to go and create all those downstream JENKINS issues > as part of the SECURITY fix... If we (as in the people on the > jenkins-cert list) do not create the downstream tracking bugs for the > side-effects of breaking BC then we are in just the same place as if > we didn't create the downstream SECURITY issues to investigate each > plugin's use of the old method and replace it with the new method as > appropriate > > > > >> Do we leave the field as is and just introduce the new accessor methods > > > > I think so, combined with `@Restricted`. > > Same 1 -> N issue multiplication concern > > > > >> Do we lock the HTTP request down to its original intended > >> purpose and break any side-effect usage that Jenkins Admins were > >> hijacking? > > > > IMO yes. > > > > -- > > 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] <javascript:>. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1c%3DN8kkdZexpnt8VNLMVQ9tr7P6%2Bo3JVn03n0JqSxGWw%40mail.gmail.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/dbd3cee4-2023-43cb-892c-264c38bd0e5d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
