On Tue, Sep 15, 2015 at 6:39 AM, Stephen Connolly <[email protected]> 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. > 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. > 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. > Do we leave the field as is and just introduce the new accessor methods I think so, combined with `@Restricted`. > 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]. 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.
