[02:39:31] Hey [02:43:49] I accidentally pressed the blue +2 button on Gerrit. I immediately removed the +2. Will that be enough to stop the merge? [04:41:47] Guess we'll find out! [09:51:30] hi! i got set of wikipedia pages with about 15000 files listed under "File:". files under your.org are stored in hashed directories and i can download them from commons.wikimedia.org with Special:Filepath. i'm not sure how i can make use of your.org archive without downloading whole thing or at least scraping files list [10:28:46] How do I show a custom message on special:CreateAccount on my wiki? [11:03:02] cheers, can someone help me debug an error due to automatic ssl being "enforced" by likely pluggableauth or simplesamlphp (cannot pinpoint which) [11:04:23] i aim to for the moment not use ssl in my docker container but my simplesaml login after it succeeds sends me onto an https:// page which doesn't establish as it's an invalid ssl format (i don't want to use it but somehow the browser is expecting ssl) [12:58:52] Sveta: in general you can load the page with an extra uselang=qqx query parameter, that will show you which customizable messages are used on the page [16:04:17] anyone using pluggableauth in here? [16:05:32] mvaenskae_mobile: neither PluggableAuth nor the SimpleSAMLphp extension enforce ssl, but perhaps the SimpleSAMLphp library does. See https://simplesamlphp.org/docs/stable/. [16:08:30] CindyCicaleseWMF: ah, that is very good to know -- i have tried my best to read up on the documentation and, without any malicious intention, it is a bit of a black box in the start :) [16:11:11] CindyCicaleseWMF: i get an explicit redirect to https though when i click on my login button -- the whole url that i get for logging in is the following (put to pastebin, really long): https://bpaste.net/show/e3df185abf64 [16:14:26] mvaenskae_mobile: So, if you access http://mydomain.com/simplesaml/... directly from your browser, you are redirected to https://mydomain.com/simplesaml/... ? [16:15:05] and after successful login on a mock ldap installation (simplesamlphp actually works in authentication as the test page gives me all the user details that are in the mock ldap installation) it just tells me "SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG" in firefox, chromium is a lot less verbose on that even (and i get always an [16:15:11] https website, automatic redirection to it even if i remove the 's') [16:15:42] no, there is no redirection then -- only when i try to have a login via mediawiki's login [16:15:54] not 100% sure, but I thought that the SAML spec *requires* that you use TLS (aka https) [16:16:27] I was wondering the same. I've also used it with https. [16:16:37] Skizzerz: that would be a somewhat small bummer as that makes ldap integration a tiny bit harder for me [16:16:42] also=>always [16:17:02] why not just spin up https? it's super easy these days [16:17:07] can get a free cert from letsencrypt [16:17:26] (and their certbot script even takes care of configuring the webserver for you) [16:17:57] this would be part of a larger network of kubepods which are all secured by the build infrastructure that generates on the fly ssl certs per pod and i was asked (and voluntered) to dockerize mediawiki with ldap support [16:18:44] letsencrypt is done automagically for me by other maintainers who built the base images and generated all the CI [16:19:33] this would be all for a student association to revamp the horrible state of our current environment and use the ldap-access we have to authenticate valid students [16:19:43] ah [16:20:40] so this is not commercial in any way and i for my part would want to also spin up my own mediawiki instance later on with different authentication approaches just because i need better docs myself [16:20:44] perhaps I'm a bit confused as to why you're using both ldap and saml [16:21:13] Skizzerz: is there an ldap only approach for >=mediawiki-1.27? [16:21:16] saml is more for single-sign-on stuff, and ldap doesn't have any capability like that baked in (although there are other services which are saml providers) [16:21:38] whereas if you go pure ldap, you type in your credentials in mediawiki and it auths them against the ldap server itself [16:21:42] rather than going through a middleman [16:22:08] later on i think we want to also have our own oauth-based approach for active members of the student association and an internal wiki as well [16:22:10] which route you go largely depends on your school's IT policies; I know many schools aren't super keen on having arbitrary username/password forms in apps if SSO is available [16:22:43] mvaenskae_mobile: https://www.mediawiki.org/wiki/Extension:LDAP_Authentication [16:23:06] Skizzerz: my mediawiki is >=1.27 [16:23:09] The LDAP Authentication plugin works to a limited extent in 1.27, but there are some cases that do not work. You may find that it works OK for you. [16:23:24] the big scary warning on the top is saying that auto authentication (aka authing using kerberos to automatically log you in with your windows credentials) doesn't work [16:23:39] the base extension still works fine in providing a username/password input on the login form that auths against ldap [16:23:50] There is also work going on to develop a new version of LDAP Authentication over PluggableAuth, but it is still in development. [16:24:18] may i ask what the state on that is? [16:25:15] mvaenskae_mobile: for what you want, the existing extension should support everything you need. The automatic login part that doesn't work is a very small component and only is useful in tightly-controlled corporate settings or computer labs [16:25:32] i am by no means competent to help in the development of said plugin (i am neither a php dev nor do i know the ldap standard) so i hope to not sound rude in any way with my "request" for help :) [16:26:30] hexmode: may be able to give an update on the new LDAP version. But, I agree that the current extension may very well work for your environment. [16:28:13] that is good to know then [16:28:39] i tried to just not use it and go the saml route as it looked to be better supported and therefore receive bug fixes and security fixes [16:29:12] this will likely end up as a "mvaenskae configures it and it runs well for 3 years without any maintenance and noone dare touches mediawiki" [16:30:42] that's why i tried the best principled approach to not use software i know which is in an abandoned state [16:35:19] I understand your concern. To your original question, I'm guessing that the redirect is being triggered by the simpleSAMLphp PHP library. [16:35:50] hate to break it to you, but you won't go 3 years without maintenance [16:35:59] no mediawiki releases are supported for that long [16:36:32] er, LTS ones are [16:36:35] but you still need to patch them [16:37:19] https://www.mediawiki.org/wiki/Version_lifecycle [16:37:40] CindyCicaleseWMF: i will give it a more thorough look and if it works out without http then i am willing to share how i got there :) if not well, i will give ldapauth a try [16:37:55] Skizzerz: well, right now the mediawiki is <1.27 that i am supposed to upgrade so yeah [16:38:27] mvaenskae_mobile: fwiw, I'm setting up a wiki with saml for auth and AD/Ldap for other bits [16:39:00] if I was less lazy I'd (re)write the CAS plugin for AuthManager [16:39:07] but lazy :P [16:39:22] Skizzerz: you will save at least one person's sanity in the future ;) [16:40:41] I also work in edu so I have a CAS setup I can test against while developing, which is the main barrier to writing it [16:42:24] hexmode: i take it is not in a state where configs can be shared? [16:45:56] mvaenskae_mobile: I had ldap + http auth working, but that depended on a binary for apache to handle the SAML auth bit. I [16:46:31] I'm going to be replacing the http auth bit with pluggableauth+simplesamlphp, but I'm also on https [16:46:43] is there a reason you can't use https? [16:47:34] (replacing the binary that handled auth is meant to give me more control + reduce crashes we were seeing) [16:50:35] I'm only seeing mvaenskae_mobile talking on the riot.im side of bridge. What about you, CindyCicalseseWMF (cicalese ) ?? [16:51:17] Oops, and I mis-spelled CindyCicaleseWMF [16:52:34] me too [16:55:51] ooo... but I see you on riot.im. We could just chat here and blissfully ignore everyone except mvaenskae_mobile . I think that is probably not how it is supposed to work. [16:57:49] lol [16:59:00] probably not ;-) [17:00:45] hu? how does riot play into this? :D [17:01:22] hexmode: to my understanding i should not set up any https as this will be done for me automatically [17:01:55] We've set up a bridge between the #mediawiki-general:matrix.org channel on riot.m and here so we could get it working [17:02:13] The nicks with '[m]' are from riot [17:02:52] The riot.im comments were completely unrelated to the SAML/LDAP/SSL discussion [17:03:19] there is an internal network of kube pods that is 'highly' secured and performs load management and HA thanks to... proxmox i think [17:03:23] Trying to debug two things at once . . . :-) [17:03:30] mvaenskae_mobile: that is similar to what I had, I think. You can tell SimpleSAMLphp it is behind a proxy that does SSL [17:03:47] Let me pull up my config [17:04:14] hexmode: thanks! [17:04:26] and the idea is for the docker instances bound to some kube pods to just be discardable due to HA but from the outside be only reachable using https which is generated on the fly per kube pod [17:04:37] oh, that sounds awesome hexmode! [17:04:42] CindyCicaleseWMF: fwiw: that is how MEZA sets it up [17:04:54] interesting [17:04:59] hexmode: you're going to post that page of SimpleSAMLphp configuration instructions soon, right? ;-) [17:05:42] yes, yes. patience. I can only do 5 things at once. [17:05:52] hexmode: we are using nginx if that matters for the config [17:06:04] I'm sure I've seen you do more than 5! [17:06:28] it doesn't matter what your webserver is, iirc [17:09:50] mvaenskae_mobile: think this was the bit I needed: https://pastebin.com/LQkEkv3f [17:11:16] also had enable.http_post = false there if that matters [17:11:38] Checking my Localsettings to see what it has [17:13:38] hm, the baseurl i didn't touch but i had tried with both http_post options [17:15:44] I tried a few different combinations of those two before I got what I needed [17:15:46] sadly it didn't seem to help even after clearing cookies and using a new private browser each times [17:16:07] is your ssl proxy not used during dev/testing? [17:16:56] no [17:17:44] that seems like a recipe for disaster when you move to prod [17:20:07] well, i am told the https layer will work automagically [17:21:00] Sure, if you're told that and it works, the great. But if it doesn't work, then I guess you aren't responsible. So, also great? [17:21:55] it's just that i cannot test it out right now as i get a redirect to https either from simplesamlphp or mediawiki (likely simplesamlphp) [17:23:14] Looking for feedback from any Wikimedia devs here: I'm looking for resources on how to handle GDPR compliance for MW wikis. I'd also be interested in learning how this is handled with Wikipedia. [17:23:30] mvaenskae_mobile: so, this is one place I could see using xdebug's debugger might help. Baring that, grep the source for redirects are replace them wwith print/exit; [17:23:52] hexmode: xdebug i didn't know of :) [17:26:06] Or is there a better channel/resource for discussing MW and GDPR? [17:27:30] and i wasn't also recommended by any of my fellow students the use of xdebug -- thanks for that [17:31:02] justinl: whatis GDPR? [17:32:11] EU reg: General Data Protection Regulation [17:32:54] justinl: some MW devs I know in the EU are probably interested in that [17:34:00] hexmode: so the solution you posted in the pastebin was mostly about having a working ssl already, right? [17:34:25] GDPR compliance is a massive can of worms that anyone who has personally-identifiable information (PII) about EU citizens (and it's even broader than that) must be compliant with. [17:34:26] in case of a non-ssl test setup i think i have to modify quite a lot then to get it working [17:36:00] mvaenskae_mobile: I had ssl to work with but wasn't familiar with the setup. I'm guessing you'll have those two variables to tweak when you move to prod. And I just discovered xdebug integration with my editor (emacs) so I am pretty new to it as well. [17:37:40] justinl: I think an EU group of devs might help. If you have a list of things you need to implement, you could ask here for how. [17:37:57] GDPR affects far more than just EU devs [17:38:16] that said, MediaWiki does not by itself offer any utilities that aid in GDPR compliance [17:39:22] so, it's largely up to you (and your legal team) to piece together your compliance strategy, and determine what needs to be done from a technical standpoint in order to follow it [17:41:07] from a privacy standpoint, MediaWiki already does quite well -- once a user is logged into an account, their IP is not exposed anywhere by default (although it is still stored internally), and details such as email addresses are hidden as well [17:42:02] Skizzerz: right. But if they have q's about specific individual technical issues, they ask here. [17:42:07] however, from a "right to be forgotten" standpoint, that flies in the face of the underlying design of MediaWiki; all deletions are reversible by administrators, and there is no means to "close" an account such that it deletes all of that account's contributions. Suppression may or may not be enough to comply with the right to be forgotten [17:42:20] the general GDPR topic is too broad, though. [17:42:36] With suppression, you can have an even more restricted set of users with access to deleted material, and the 'hideuser' feature lets you block a user and strip their username from all of their past contributions [17:43:27] if you grant your data controller access to those features and nobody else, that may or may not be enough. Your legal team will need to determine that [17:43:49] if you have any other specific questions though, do feel free to ask. We can point you towards core features or extensions which can aid in compliance :) [17:48:19] Skizzerz: Yeah, MW is a very small part of our concerns, our main business concerns regarding GDPR are vastly larger and more complicated, but MW is definitely something that requires addressing, especially to your point about the "right to be forgotten" issue and how MW works. [17:49:24] Also, our use of MW is more like Wikipedia in that we provide the platforms (5 externally facing wikis) and our users handle 99.9999% of the content. [17:52:38] as far as deletion of users, I was looking at UserMerge and possibly first merging any user to be deleted to some general "Privacy" or "GDPR" user or something to that effect. [17:52:57] Then there's also user talk pages, etc. [19:05:31] testing the bridge again [19:06:02] interesting thoughts about the GDPR and MediaWiki. where do the concerns come from – are your wikis used for storage of personal data or are the users not anonymized? [19:08:23] Things like email addresses, IP addresses, and whatever other information users provide that could be used to trace back to them individually. [19:10:44] oh, you are talking about a public wiki? [19:13:23] Yes. We actually have 7 MW wikis, 5 of which are public and 2 are internal. It's the public ones that are the really big concern. [19:15:06] What are the particular issues you're trying to address? [19:15:54] GDPR compliance, e.g. https://www.csoonline.com/article/3202771/data-protection/general-data-protection-regulation-gdpr-requirements-deadlines-and-facts.html [19:16:39] justinl: I understand that, but GDPR is too broad. Which particular issues did you have a question about? [19:17:45] Primarily how to handle PII data, such as encrypting data in flight and at rest and deletion of accounts upon request. [19:18:30] The encryption is a much easier problem to solve than the account deletion, given how MW works. [19:19:05] I guess it's not the storage that is concerning, but the changes and the deletion. I am sure you have looked into pseudonymization – does this not yet help with some concerns? [19:20:03] account mergeing would work for deletion, right? [19:20:10] and account pseudonymization? doesn't really have to be deleted? [19:20:12] Account deletion and/or pseudonymization are exactly what's needed, so developing procedures for all of that, and being able to report compliance, are what I'm investigating. [19:20:45] big challenge, jup! [19:20:46] That depends on legal interpretation of the GDPR rules, which aren't exactly incredibly well-defined. [19:21:35] indeed. what country are you in? [19:21:41] the US [19:22:21] Once you have a definition, see if UserMerge would work. [19:23:46] Yeah, and that's just one part. Right now I'm just doing research for the systems for which I'm responsible as part of my company's overall GDPR compliance project. [19:25:04] is there a general platform/page for united forces around this topic, at least from the MediaWiki side? since we all share those questions. [19:25:22] I'm going to work on testing UserMerge in my dev environment. Haven't really needed to use it before. One nice thing is that it may end up being useful for culling all of the bot-created accounts. We went through many different captcha systems before NoCaptcha finally really eliminated most such account creation. [19:26:07] Not to my knowledge. I've just started doing my investigation this week and not finding a huge amount so far. I'm really hoping to see such a thing develop. [19:26:49] so, you sit in the US but have partners/customers in the EU and that's why you want to comply? Privacy Shield also an option? [19:27:48] Yes, I work for a good size company with an extensive EU presence, of which the wikis are only a small part. [19:28:08] Not sure what you mean by Privacy Shield? [19:32:26] https://en.wikipedia.org/wiki/EU-US_Privacy_Shield [19:32:31] it's controversial, though. [19:33:49] Yeah, that's definitely something that would have to be addressed by our legal team. [19:36:40] that's the difficulty here: it's a legal topic that needs to be translated into software, but nobody yet dares to take the fall, since it's still unclear how it will be sanctioned… [19:38:43] yeah, a lot of what we're hearing in general is "wait and see who's sued first and see how that turns out" :/ [19:40:53] we're offering a solution for the record of processing activities based on MW, if you'd like to have a look. it's not meant to store data though, only data about the data. http://www.datencockpit.at/Datencockpit [19:41:12] that's a very Austrian approach! ;)) [19:41:59] what a coincidence, I just watched an EMWCon video your company did. [19:42:15] https://www.youtube.com/watch?v=59MMWPSIuOk [19:42:42] wait! are you the woman in the video? [19:42:58] haha, wonderful, that's me. [19:43:05] oh wow, that's amazing! :) [19:43:44] the world is small, they say. :) [19:45:36] sabinemelnicki is internet famous [19:46:15] Its good to see people are watching the emwcon videos [19:46:38] agreed. the wmf is getting bang for their $$ [19:47:54] I just happened to find the video searching on mediawiki and gdpr. Wished I could have gone to the conference. We're such heavy users of MW and SMW that I'd love to meet others who use it since I've been managing our wikis for 6 years now basically on my own. It would be great to be able to network in such a niche area more. [19:49:20] justinl: we're rebooting the mediawiki-enterprise mailing list. Several of us meet monthly. [19:50:53] I'm just in a weird spot because I don't actually do editing of wikis, so I'm not really familiar with the intricacies of the language and features, I just build and maintain the web servers and related systems for making the platforms available to our users. I really have been meaning to learn the coding and MW internals more so I can better configure, tune, and troubleshoot the wikis. [19:51:08] hexmode[m]: I'd love to get involved! [19:51:21] justinl: more info: https://www.mediawiki.org/wiki/MediaWiki_Stakeholders'_Group [19:52:14] Fantastic, I'll read through that. Thanks! [19:52:52] and you should definitely try to come to one of the next conferences! [19:52:56] FWIW, the wikis I maintain are the Guild Wars and Guild Wars 2 wikis, e.g. wiki.guildwars2.com. [19:53:45] sabinemelnicki[m: I absolutely will try. Given how the wikis are my primary responsibility, I'm sure I can persuade my management of the benefits. :) [22:59:45] so if I set up a mediawiki site on my server, would the licensing allow me to restrict access to only registered users? Or is it a licensing requirement to have it open (i. e. publicly accessible)? In other words, can I set up a "private" mediawiki site? [23:10:41] Mooniac: License of the software (mediawiki) and content of the wiki aren't related at all. So yes, you can set up a private mediawiki site, that's quite a usual thing. [23:11:19] great, thanks [23:11:42] And can it also be branded. like the "private wikimedia site of company xyz"? [23:12:08] I want to make it a private environment of a partciular company [23:15:31] Mooniac: You can brand it, but you can't call it "private wikimedia site". Wikimedia (!=mediawiki) is a name of the movement that creates e.g. wikipedia, wikibooks etc. and a brand of the wikimedia foundation. [23:16:12] I mistyped. I meant mediawiki [23:19:00] Using MediaWiki to power an intranet site inside a corporate firewall is quite common. You can find skins to install and customize to make the branding look however you'd like. [23:19:43] * bd808 got started with MediaWiki by building an intranet site with it ~2005 [23:20:20] great, thanks [23:43:31] tgr_, thanks for telling me about uselang, really helpful. :-)