Talk:Requests for comment/MediaWiki HTTPS policy

Questions

• Is the purpose of the proposed IP-based blacklist to account for geolocation (China, Iran) and the Wikipedia Zero exceptions?
• How would the list of IPs be created and updated? Would it be hardcoded, or part of a list that's editable on-wiki? I can imagine admins or Stewards asking for the latter, but OTOH, a single shared list between wikis would make more sense for cluster-wide consistency.

Ping @CSteipp (WMF): for comment. Steven Walling (talk) 05:05, 26 November 2014 (UTC)

Yep, the IP-based list is for China, Iran, and Zero. I envision the policies being setup in the mediawiki config by default (I'm aiming the syntax to be roughly like setting up group rights in LocalSettings), but the process can be extended by other extensions. So if Zero wants to update the policy based on the wiki page in zero portal (which they will), they'll be able to do so. But I'm not planning to implement that in core, since it's going to be pretty specific to the use case (Zero portal being a great example-- it's on a separate wiki, has it's own rules for editing, but it should be easy for them to implement a hook that looks up their cached set of configs and applies it on all wikis). CSteipp (WMF) (talk) 06:08, 26 November 2014 (UTC)

RFC Feedback

• Architecturally, we'll do the config setup during mediawiki startup, and then have something in RequestContext to get the current policy
  • <TimStarling> I just want to make sure we are doing no processing on startup, just loading configuration arrays
  • <TimStarling> I think the two options for lazy loading are static function and RequestContext
  • <legoktm> how early is this being called? I remember calling getUser too early would break stuff
  • <TimStarling> my inclination would be to do things the old way and let everything be migrated to the new way in a batch, once the new way exists
  • <csteipp> Alright, I'll update the code examples to focus on doing this mostly from RequestContext.
• Add HSTS to the proposal
• Rename "User policies" to "Group-based policies". Their intent is to allow policies like, bureaucrats must have passwords with at least 8 chars.
• Ordering of rules should be configurable. Some suggestions for making this work that doesn't over-complicate were thrown around, I'll try some and see what they could look like.
  • <hashar> like Apache OrderAllow ?
  • <TimStarling> or integer priority?
  • <bd808> !important
• <TimStarling> I'm not sure how they would work exactly, but I guess something like the callback mechanism is needed
• Security (https, ..., hsts, whatever new fancy supported thing, not overrideable by user preferences) should be the default. Current version needs a ton of settings to be enabled for that effect. Easy to miss one.