Sure, charter is at https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Council
Fri, Aug 30
Tue, Aug 27
Jul 18 2019
Jul 17 2019
May 21 2019
Apr 24 2019
@Eevans @Clarakosi This one is a bit out of our wheelhouse and something we can provide only a cursory review of. I'd like to propose the following: The Security team can perform a basic security review of this but I would recommend a secondary review by our 3rd party partners at BishopFox. That said, the 2nd review would incur some cost but I'm not sure how much. Do you have any budget available for something like that??
Mar 26 2019
Mar 20 2019
Mar 17 2019
Todays updates sent to wikitech-l https://lists.wikimedia.org/pipermail/wikitech-l/2019-March/091769.html
Jan 18 2019
Dec 12 2018
Thanks everyone of for their thoughtful consideration. I have no issues nor do I see a conflict with temporarily allowing the use of this so we can complete our work with our 3rd party partners.
Thanks for commenting. To clarify, are you saying that there is no free filesystem software that will meet our needs? Given that @Platonides offered a decent amount of alternatives in T210667#4789273, it would be helpful if it could be explained why none of those alternatives are sufficient. That will help me when I reach out to various free software upstreams so they can improve their software so it will meet our needs - a goal that I think we all share.
Dec 11 2018
There are two types of good password generation:
- A medium-length string of random uppercase/lowercase/numbers (say 12 or 16 characters), with easily confusable characters removed from the pool.
- A long human-readable text of space-separated random dictionary words (probably 5 or 6 words), e.g. diceware.
I'm not sure the first is worth doing as the only sane way to use such passwords is a password manager and that can generate random passwords just fine. (Maybe there are less technical users who have problems with password managers and just write the passwords down, but those are better served by diceware style passwords anyway since words are easier to type.) OTOH it is very trivial to implement.
The second is good for people who need to memorize the password for some reason, or need to type it in often (ie. often log in on foreign machines). The best library I have seen for it is grempe/diceware (test page), which has support for ~20 languages (of course it would be fairly trivial to add more). Word lists are around 100K which is a bit large but they don't exactly make an effort to reduce the size, which could be done pretty easily.
Dec 7 2018
This feels a bit rushed. Maybe I am just not aware that the preparations already happened, in which case apologies in advance, but otherwise I would recommend pushing out the date by a month or so and doing more groundwork.
Dec 4 2018
Well, WMF != MW. But if the intention is to make these changes for all users and help "harden" MW core at the same time, I'm fine with making that change in MW core too
Dec 3 2018
- With respect to the WMF charter and the values and manifestation thereof, it seems the exception process and/or the bar for each use case is at the discretion of WMF leadership and probably specifically most informed by WMF technical leadership. I'll defer to @JBennett who has more information.
Nov 30 2018
I think that was meant for using it for email lookup, not passwords? If your password hash is in the dump, the applicability of that is pretty clear.
Nov 27 2018
Related: T197577: Increase password policies for the 'steward' group and others
Yeah, good catch. Makes sense to bump this one up too. I forget, though... do Stewarts also need 2FA? If so, the length is less of an issue.
Nov 26 2018
I'm in favor of removing unblock self. It's overly permissive to allow admins to unlock themselves and we should follow some level of separation of duties to ensure proper governance. Let's go ahead and make this change.
Nov 1 2018
Oct 29 2018
+1 from me
Oct 10 2018
Sep 27 2018
Sep 17 2018
Sep 13 2018
Our process around security incident response is evolving and something the security team is working to improve. We're not there yet but we are definatley making improvements.
Sep 11 2018
This 1st round is really to address changes to our wiki password policy. Phase 2 is being planned and will address 2FA for privileged users.
Sep 7 2018
Sep 4 2018
Aug 13 2018
Jul 2 2018
Has legal reviewed this? I don't see any comments from them in this ticket. I'd like to sort out a process for reviewing items like this. It's sort of in-between security/privacy/data governance. I'll put together a strawman review process so to help us avoid delays and follow up with Stas.
Jun 6 2018
May 3 2018
I need to be able to access logstash to invistigate security incidents. So, i'll similar access to Brian Wolff or Sam Reed.
Your Full Name: John Bennett
developer access userid: jbennett
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDIOdNYh9J4uSm7uuVZG7zttu/9Xtk5IaCPSokdOyhNnAoMBE51mnTZTrGm+SxUTfXs3tniklrn2lZtDDookMOnDFzN/HwhKbw0QEsef9f2hOVj16QLF5jqdZi8Tk/15OOaHJST4/BafT3uFpMnaQLRpApfSYlKvqLxs2cZFLCtfZZ2HscCpNUPpbNLyRg0OcPoFhjui+dnVZJR856L+wStSFv9oUytshOa0/JYd0VMRV78kDcXIKIMbaqufhaMKCel3lA7QnJzQMoTvWY/FB888koHza+si0bzwc/DhQE19kE6Oobu8WabmDwiP3sQyiuc+bEM6Xn3YUer8nnJoBPx john@gpants
Apr 19 2018
What's the data? From our clicktracking efforts what will we be collecting?
Mar 19 2018
Feb 23 2018
*Is each 'group' required to have their own repo? How is that access and credential sharing determined?
*If that's not the case, how will we prevent credential disclosure to folks who have access to the repo but dont have a need to know all the creds?
*Do people know to update creds when someone no longer requires access to them (leaves the foundation, changes groups, etc)?