(Sometime i used extra info next to Words for new-reader's better
understanding, pls ignore/skip if you(reader) are already aware of
those short descriptions)
Based on its homepage info, it seems, gdnsd do not support full
DNSSEC yet !
https://github.com/blblack/gdnsd
gdnsd is based on what
1st wrote large response, while i was still in midst of reading
various responses, when i've seen last few responses which have
touched many important factors related to very large scale sites,
and that wikipedia want to keep geo-location geo-feature based
separation(s), then removed various
On Fri, Aug 23, 2013 at 06:53:29AM -0700, Bry8 Star wrote:
At my first few small-scale implementations, i did not pay attention
to rate-limiting techniques, then i realized its importance over time.
RRL support for gdnsd is being tracked upstream at:
https://github.com/blblack/gdnsd/issues/36
On Sat, Aug 17, 2013 at 05:55:36PM -0400, Sumana Harihareswara wrote:
I suggest that we also update either
https://meta.wikimedia.org/wiki/HTTPS or a hub page on
http://wikitech.wikimedia.org/ or
https://www.mediawiki.org/wiki/Security_auditing_and_response with
up-to-date plans, to make it
On Fri, Aug 16, 2013 at 08:04:24PM -0400, Zack Weinberg wrote:
Hi, I'm a grad student at CMU studying network security in general
and censorship / surveillance resistance in particular. I also used
to work for Mozilla, some of you may remember me in that capacity. My
friend Sumana
On Sat, Aug 17, 2013 at 10:13 AM, Tyler Romeo tylerro...@gmail.com wrote:
On Fri, Aug 16, 2013 at 9:59 PM, C. Scott Ananian canan...@wikimedia.org
wrote:
Because the other TLS 1.0 ciphers are *even worse*.
On Sat, Aug 17, 2013 at 6:47 AM, Faidon Liambotis fai...@wikimedia.orgwrote:
First of all, thanks for your input. It's much appreciated. As I'm sure
Sumanah has already mentioned, all of our infrastructure is being developed
in the open using free software and we'd be also very happy to accept
On Sat, Aug 17, 2013 at 12:47 PM, Faidon Liambotis fai...@wikimedia.org wrote:
On Fri, Aug 16, 2013 at 08:04:24PM -0400, Zack Weinberg wrote:
Hi, I'm a grad student at CMU studying network security in general and
censorship / surveillance resistance in particular. I also used to work for
hi faidon, i do not think you personally and WMF are particularly
helpful in accepting contributions. because you:
* do not communicate openly the problems
* do not report upstream publically
* do not ask for help, and even if it gets offered you just ignore it
with quite some arrogance
On Sat, Aug 17, 2013 at 2:19 PM, Brian Wolff bawo...@gmail.com wrote:
Lets not point fingers at specific people. Its really unhelpful and causes
defensiveness.
In the case of gitblit, the problem at this point has been identified (web
spiders DOSing us accidentally). Its really not
On Aug 17, 2013, at 1:33 PM, rupert THURNER rupert.thur...@gmail.com wrote:
hi faidon, i do not think you personally and WMF are particularly
helpful in accepting contributions. because you:
* do not communicate openly the problems
* do not report upstream publically
* do not ask for help,
On 17.08.2013, 22:19 Brian wrote:
its more a config issue on our end than a problem with gitblit.
Frankly, all web apps that allow anons do crazy shit with GET requests
should at least mark critical links with rel=nofollow, so at least
part of the blame lies on Gitblit:)
--
Best regards,
On Sat, Aug 17, 2013 at 7:03 PM, Max Semenik maxsem.w...@gmail.com wrote:
On 17.08.2013, 22:19 Brian wrote:
its more a config issue on our end than a problem with gitblit.
Frankly, all web apps that allow anons do crazy shit with GET requests
should at least mark critical links with
Before this get's lost in the other noise on this thread, I wanted to
address the MediaWiki specific pieces.
On Fri, Aug 16, 2013 at 5:04 PM, Zack Weinberg za...@cmu.edu wrote:
All cookies should be tagged both Secure and HttpOnly (which renders them
inaccessible to accidental HTTP loads and
On 17 August 2013 22:08, Chris Steipp cste...@wikimedia.org wrote:
A strong CSP is #3 on my most-wanted list of security features (after https
and better password hashing). However, that would likely limit things like
editors adding css into their edits, which is pretty controversial.
Do you
Inline css (div style=...)
On Sat, Aug 17, 2013 at 2:09 PM, David Gerard dger...@gmail.com wrote:
On 17 August 2013 22:08, Chris Steipp cste...@wikimedia.org wrote:
A strong CSP is #3 on my most-wanted list of security features (after
https
and better password hashing). However, that
Also inline JavaScript, which MediaWiki has a lot of for the ResourceLoader.
On Aug 17, 2013 5:10 PM, Chris Steipp cste...@wikimedia.org wrote:
Inline css (div style=...)
On Sat, Aug 17, 2013 at 2:09 PM, David Gerard dger...@gmail.com wrote:
On 17 August 2013 22:08, Chris Steipp
Yeah, but I *think* that one can be solved without affecting editors..
Building something to let them style, but in a way that inline css isn't
allowed by the CSP is something I haven't figured out yet.
On Sat, Aug 17, 2013 at 2:11 PM, Tyler Romeo tylerro...@gmail.com wrote:
Also inline
On 08/17/2013 06:47 AM, Faidon Liambotis wrote:
On Fri, Aug 16, 2013 at 08:04:24PM -0400, Zack Weinberg wrote:
Hi, I'm a grad student at CMU studying network security in general
and censorship / surveillance resistance in particular. I also used
to work for Mozilla, some of you may remember
Hi, I'm a grad student at CMU studying network security in general and
censorship / surveillance resistance in particular. I also used to work
for Mozilla, some of you may remember me in that capacity. My friend
Sumana Harihareswara asked me to comment on Wikimedia's plans for
hardening the
I hope I'm not being rude, but everything you've suggested here has already
been discussed. HTTPS and HSTS are already on the schedule once the China
workaround is invented. Cookies are already tagged as Secure and HttpOnly
when over HTTPS. Both the certificate pinning RFC and the DANE RFC have
- Original Message -
From: Zack Weinberg za...@cmu.edu
The first step really must be to enable HTTPS unconditionally for
everyone (whether or not logged in). I see on the roadmap that there
is concern that this will lock out large groups of users, e.g. from
China; a workaround simply
On 8/16/13, Zack Weinberg za...@cmu.edu wrote:
Hi, I'm a grad student at CMU studying network security in general and
censorship / surveillance resistance in particular. I also used to work
for Mozilla, some of you may remember me in that capacity. My friend
Sumana Harihareswara asked me to
- Original Message -
From: Brian Wolff bawo...@gmail.com
Thanks for taking the time to write these two emails. You raise an
interesting point about having everything on one domain. I really
don't think that's practical for political reasons (not to mention
technical disruption), but
On Fri, Aug 16, 2013 at 8:17 PM, Tyler Romeo tylerro...@gmail.com wrote:
With that said, I think the real problem with Wikimedia's security right
now is a pretty big failure on the part of the operations team to inform
anybody as to what the hell is going on. Why hasn't the TLS cipher list
Interesting timing. DNSSEC came up on the NANOG list today -- someone sent
out an FYI to a USENIX paper [1] which shows that the law of unintended
consequences is still strong and active. In the case of DNSSEC; there is an
increased chance of a user being unable to resolve a protected domain --
On Fri, Aug 16, 2013 at 9:25 PM, C. Scott Ananian canan...@wikimedia.orgwrote:
That said, I'm not part of the operations team either so I can't answer
definitively. I agree that it would probably be useful to have more formal
progress reporting. Can't disable RC4 in the cipher suite until
On Fri, Aug 16, 2013 at 9:47 PM, Tyler Romeo tylerro...@gmail.com wrote:
To be fair, I'm really only talking about non-restrictive changes. For
example, right now we *only* have RC4. Rather than disable RC4 (which would
have consequences), I'm saying why haven't other normal ciphers been
On Fri, Aug 16, 2013 at 9:59 PM, C. Scott Ananian canan...@wikimedia.orgwrote:
Because the other TLS 1.0 ciphers are *even worse*.
https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what
...except they're not (in all major browsers and the latest stable
Please read the link I provided more carefully. Apple devices and browsers
are still vulnerable.
--scott
On Aug 16, 2013 10:14 PM, Tyler Romeo tylerro...@gmail.com wrote:
On Fri, Aug 16, 2013 at 9:59 PM, C. Scott Ananian canan...@wikimedia.org
wrote:
Because the other TLS 1.0 ciphers are
30 matches
Mail list logo
