Re: [Wikitech-l] Is assert() allowed?
My take on assertions, which I also tried to stick to in Wikibase, is as
follows:
* A failing assertion indicates a local error in the code or a bug in PHP;
They should not be used to check preconditions or validate input. That's what
InvalidArgumentException is for (and I wish type hints would trigger that, and
not a fatal error). Precondition checks can always fail, never trust the
caller. Assertions are things that should *always* be true.
* Use assertions to check postconditions (and perhaps invariants). That is, use
them to assert that the code in the method (and maybe class) that contains the
assert is correct. Do not use them to enforce caller behavior.
* Use boolean expressions in assertions, not strings. The speed advantage of
strings is not big, since the expression should be a very basic one anyway, and
strings are awkward to read, write, and, as mentioned before, potentially
dangerous, because they are eval()ed.
* The notion of bailing out on fatal errors is a misguided remnant from the
days when PHP didn't have exceptions. In my mind, assertions should just throw
an (usually unhandled) exception, like Java's AssertionError.
I think if we stick with this, assertions are potentially useful, and harmless
at worst. But if there is consensus that they should not be used anywhere, ever,
we'll remove them. I don't really see how the resulting boiler plate would be
cleaner or safer:
if ( $foo $bar ) {
throw new OMGWTFError();
}
-- daniel
Am 31.07.2013 00:28, schrieb Tim Starling:
On 31/07/13 07:28, Max Semenik wrote:
I remeber we discussed using asserts and decided they're a bad
idea for WMF-deployed code - yet I see
Warning: assert() [a href='function.assert'function.assert/a]:
Assertion failed in
/usr/local/apache/common-local/php-1.22wmf12/extensions/WikibaseDataModel/DataModel/Claim/Claims.php
on line 291
The original discussion is here:
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/59620
Judge for yourself.
-- Tim Starling
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Is assert() allowed?
Hi Tyler, good to see that since the last discussion of this topic, more people are in favor of allowing asserts :-) On Tue, Jul 30, 2013 at 06:45:37PM -0400, Tyler Romeo wrote: I think the real issue here is just that assertions sometimes aren't used correctly. I wholeheartedly agree. Best regards, Christian -- quelltextlich e.U. \\ Christian Aistleitner Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65aEmail: christ...@quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax:+43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --- signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Is assert() allowed?
Hi,
On Wed, Jul 31, 2013 at 10:36:56AM +0200, Daniel Kinzler wrote:
* Use boolean expressions in assertions, not strings.
I do not agree that this is best practice in PHP.
Execution time being only part of argument here. Among other arguments
are readability of the error message. When using strings, the error
message contains the condition of the failed assertion.
But as has been pointed out by other posts in this thread, correct
quotation of the string is obviously crucial.
The speed advantage of
strings is not big, since the expression should be a very basic one anyway,
[...]
They should?
In practice they typically are not. For example
assert( $this-indicesAreUpToDate() );
of WikibaseDataModel/DataModel/Claim/Claims.php boils down to nested
looping, if I read the code correctly. But (leaving the question aside
whether that part is misusing assertions) using complex predicates is
totally ok (and even useful) when putting them in strings, as the
expression would not get evaluated in production anyways.
* The notion of bailing out on fatal errors is a misguided remnant
from the days when PHP didn't have exceptions. In my mind, assertions
should just throw an (usually unhandled) exception
We could get that by adapting assert_options ...
, like Java's
AssertionError.
That comparison is ill suited. Java's AssertionError is a
java.lang.Error and not java.lang.Exception. And thereby it's clear
what the Java world thinks about catching assertion failures [1]:
An Error [...] indicates serious problems that a reasonable
application should not try to catch.
But then again… maybe that was what you meant by “usually unhandled”
anyways.
I don't really see how the resulting boiler plate would be
cleaner or safer:
if ( $foo $bar ) {
throw new OMGWTFError();
}
Totally! It looks even less clean to me, as after such guards only the
negated condition holds.
So (when not misusing them) asserts are a way to reduce complexity of
reading code.
Best regards,
Christian
[1] http://docs.oracle.com/javase/7/docs/api/java/lang/Error.html but
this intepretation stands since around Java 1.4 and has proven
useful.
--
quelltextlich e.U. \\ Christian Aistleitner
Companies' registry: 360296y in Linz
Christian Aistleitner
Gruendbergstrasze 65aEmail: christ...@quelltextlich.at
4040 Linz, Austria Phone: +43 732 / 26 95 63
Fax:+43 732 / 26 95 63
Homepage: http://quelltextlich.at/
---
signature.asc
Description: Digital signature
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Is assert() allowed?
On 31/07/13 18:36, Daniel Kinzler wrote:
Assertions are things that should *always* be true.
In my mind, assertions should just throw an (usually unhandled)
exception, like Java's AssertionError.
Indeed. In C, assert() will abort the program if it is enabled, which
is hard to miss. It is not comparable to the PHP assert() function.
I don't really see how the resulting boiler plate would be cleaner
or safer:
if ( $foo $bar ) { throw new OMGWTFError(); }
The reasons I don't like assert() are:
1. It doesn't throw an exception
2. It acts like eval()
We could have a library of PHPUnit-style assertion functions which
throw exceptions and don't act like eval(), I would be fine with that.
Maybe MWAssert::greaterThan( $foo, $bar ) or something.
-- Tim Starling
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Xmldatadumps-l] Suggested file format of new incremental dumps
For storing updateable indexes, Berkeley DB 4-5, GDBM, and higher-level options like SQLite are widely used. LevelDBhttps://code.google.com/p/leveldb/ is pretty cool too. I think that with the amount of data we're dealing with, it makes sense to have the file format under tight control. For example, saving a single byte on each revision means total savings of ~500 MB for enwiki. In any case, at this point it would be more work to switch to one of those than to keep using the format I created. For delta coding, there's xdelta3 http://xdelta.org/, open-vcdiffhttps://code.google.com/p/open-vcdiff/, and Git'shttp://stackoverflow.com/questions/9478023/is-the-git-binary-diff-algorithm-delta-storage-standardized delta https://github.com/git/git/blob/master/diff-delta.c codehttps://github.com/git/git/blob/master/patch-delta.c. (rzip http://rzip.samba.org//rsync are wicked awesome, but not as easy to just drop in as a library.) I'm certainly going to try to use some library for delta compression, because they seem to do pretty much exactly what's needed here. Thanks for the suggestions. Petr Onderka ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Is assert() allowed?
On Wed, Jul 31, 2013 at 7:42 AM, Tim Starling tstarl...@wikimedia.orgwrote: Indeed. In C, assert() will abort the program if it is enabled, which is hard to miss. It is not comparable to the PHP assert() function. ...except PHP's assert() *also* aborts the program if enabled. What am I missing here? The reasons I don't like assert() are: 1. It doesn't throw an exception 2. It acts like eval() We could have a library of PHPUnit-style assertion functions which throw exceptions and don't act like eval(), I would be fine with that. Maybe MWAssert::greaterThan( $foo, $bar ) or something. 1. It's fairly trivial to use assert_options() to make assertions throw exceptions if you really wanted to while developing. 2. Except it's not. Again, you're welcome to give an example where code provided as a string in an assertion is not exactly the same as having the code hardcoded. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Is assert() allowed?
$_GET[foo] = 'include( evil_file.php )'; assert( '$_GET[foo] == fluffy bunny rabbit' ); // This is fine assert( $_GET['foo'] == 'fluffy bunny rabbit' ); // But this is not Deliberately using a function which reduces the security of your application to relying on everyone choosing the correct type of quotes is definitely asking for trouble. --HM On 31 July 2013 13:19, Tyler Romeo tylerro...@gmail.com wrote: On Wed, Jul 31, 2013 at 7:42 AM, Tim Starling tstarl...@wikimedia.org wrote: Indeed. In C, assert() will abort the program if it is enabled, which is hard to miss. It is not comparable to the PHP assert() function. ...except PHP's assert() *also* aborts the program if enabled. What am I missing here? The reasons I don't like assert() are: 1. It doesn't throw an exception 2. It acts like eval() We could have a library of PHPUnit-style assertion functions which throw exceptions and don't act like eval(), I would be fine with that. Maybe MWAssert::greaterThan( $foo, $bar ) or something. 1. It's fairly trivial to use assert_options() to make assertions throw exceptions if you really wanted to while developing. 2. Except it's not. Again, you're welcome to give an example where code provided as a string in an assertion is not exactly the same as having the code hardcoded. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Is assert() allowed?
On Wed, Jul 31, 2013 at 8:38 AM, Happy Melon happy.melon.w...@gmail.comwrote: Deliberately using a function which reduces the security of your application to relying on everyone choosing the correct type of quotes is definitely asking for trouble. I don't see how this is an issue. htmlspecialchars() can cause an XSS vulnerability if you pass it the wrong ENT_ constant. Should we just stop using htmlspecialchars() in case developers pass the wrong constant? *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Is assert() allowed?
On 31 July 2013 15:01, Tyler Romeo tylerro...@gmail.com wrote: On Wed, Jul 31, 2013 at 8:38 AM, Happy Melon happy.melon.w...@gmail.com wrote: Deliberately using a function which reduces the security of your application to relying on everyone choosing the correct type of quotes is definitely asking for trouble. I don't see how this is an issue. htmlspecialchars() can cause an XSS vulnerability if you pass it the wrong ENT_ constant. Should we just stop using htmlspecialchars() in case developers pass the wrong constant? Yes, IMO, it should be abstracted away with a carefully-written wrapper function that bridges the semantic gap between I want to do some character conversions and I want to make this text safe to echo to the browser, but that's just the point. Of course there are plenty of language features you can point to that open up pitfalls; each one having its own severity and ease-of-discovery. htmlspecialchars() has a medium severity and very easy discovery, and it's a problem that's easy to eliminate by abstracting the call to ensure it's always given the proper arguments. My example was to disprove your point that assert() with string arguments is not as bad as eval(); it is, for exactly the same reasons. Of course it's possible to use eval() safely, just like any other construct, but general consensus is that eval()'s security holes are severe enough and difficult-to-spot enough to warrant strongly discouraging its use, and there is no reason not to treat assert()-with-string-args the same way. --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Is assert() allowed?
On Wed, Jul 31, 2013 at 10:24 AM, Happy Melon happy.melon.w...@gmail.comwrote: Yes, IMO, it should be abstracted away with a carefully-written wrapper function that bridges the semantic gap between I want to do some character conversions and I want to make this text safe to echo to the browser, but that's just the point. Of course there are plenty of language features you can point to that open up pitfalls; each one having its own severity and ease-of-discovery. htmlspecialchars() has a medium severity and very easy discovery, and it's a problem that's easy to eliminate by abstracting the call to ensure it's always given the proper arguments. My example was to disprove your point that assert() with string arguments is not as bad as eval(); it is, for exactly the same reasons. Of course it's possible to use eval() safely, just like any other construct, but general consensus is that eval()'s security holes are severe enough and difficult-to-spot enough to warrant strongly discouraging its use, and there is no reason not to treat assert()-with-string-args the same way. Then I guess I just have more faith in our code review. Nonetheless, assert() provides an important functionality in being able to allow code checks that do not incur a performance penalty in a production environment. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] gwtoolset : architecture design help
Metadata Set Repo - one of the goals of the project is to store Metadata Sets, such as XML under some type of version control. those Metadata Sets need to be accessible so that the extension can grab the content from it and process it. processing involves iterating over the entire Metadata Set and creating Jobs for the Job Queue which will upload each individual media file and metadata into a media file page using a Mediawiki template format, such as Artwork. some initial requirements • File sizes • can range from a few kilobytes to several megabytes. • max file-size is 100mb. • XML Schema - not required. • XML DTD - not required. • When metadata is in XML format, each record must consist of a single parent with many child • XML attribute lang= is the only one currently used and without user interaction • There is no need to display the Metadata sets in the wiki. • There is no need to edit the Metadata sets in the wiki. we initially developed the extension to store the files in the File: namespace, but we were told by the Foundation that we should use ContentHandler instead. unfortunately there is an issue with storing content 1mb in the db so we need to find another solution. 1. any suggestions? What I would suggest is a hybrid approach. The metadata file gets uploaded, and is stored using FileBackend class. (There's a couple extensions that store files without them being a file page. For example the Score extension stores the rendered files on the server, but its not attached to any file page). Once the xml file is on the server, use ContentHandler to make a new content type that stores a reference to the file [instead of the original file] (probably in the form of a mediawiki virtual file url). --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] (no subject)
Hey all, Mozilla made an announcement yesterday about a new framework called Minion: http://blog.mozilla.org/security/2013/07/30/introducing-minion/ https://github.com/mozilla/minion It's an automated security testing framework for use in testing web applications. I'm currently looking into how to use it. Would there be any interest in setting up such a framework for automated security testing of MediaWiki? *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] How's the SSL thing going?
Jimmy just tweeted this: https://twitter.com/jimmy_wales/status/362626509648834560 I think that's the first time I've seen him say fuck in a public communication ... Anyway, I expect people will ask us how the move to all-SSL is progressing. So, how is it going? (I've been telling people it's slowly moving along, we totally want this, it's just technical resources. But more details would be most useful!) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] (no subject)
On Wed, Jul 31, 2013 at 11:23 AM, Tyler Romeo tylerro...@gmail.com wrote: Hey all, Mozilla made an announcement yesterday about a new framework called Minion: http://blog.mozilla.org/security/2013/07/30/introducing-minion/ https://github.com/mozilla/minion It's an automated security testing framework for use in testing web applications. I'm currently looking into how to use it. Would there be any interest in setting up such a framework for automated security testing of MediaWiki? Looks interesting! Sounds like something for the QA list: https://lists.wikimedia.org/mailman/listinfo/qa ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] (no subject)
On Wed, Jul 31, 2013 at 11:23 AM, Tyler Romeo tylerro...@gmail.com wrote: Hey all, Mozilla made an announcement yesterday about a new framework called Minion: http://blog.mozilla.org/security/2013/07/30/introducing-minion/ https://github.com/mozilla/minion It's an automated security testing framework for use in testing web applications. I'm currently looking into how to use it. Would there be any interest in setting up such a framework for automated security testing of MediaWiki? I'm definitely interested in seeing if we can leverage something like this. I'm not sure where it would fit alongside our current automated testing, but I think it would be valuable to at least take a closer look. And it's nice to see they're supporting ZAP and skipfish, although unless they allow for more detailed configurations, both take ages to completely scan a MediaWiki install. If you get it running, please share your experience. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
Good question. There are two steps to this: 1) Move all logins to TLS 2) Move all logged in users to TLS The former was dependent on a bug with E:CentralAuth that was causing $wgSecureLogin to malfunction. I am not sure whether this bug was ever fixed (I remember seeing Chris submit a patch for it, but I think it was abandoned). Also, the discussion on https://bugzilla.wikimedia.org/show_bug.cgi?id=52283 is probably a blocker for enabled $wgSecureLogin (which would be a pre-requisite for either of the two above steps). *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Jul 31, 2013 at 2:36 PM, David Gerard dger...@gmail.com wrote: Jimmy just tweeted this: https://twitter.com/jimmy_wales/status/362626509648834560 I think that's the first time I've seen him say fuck in a public communication ... Anyway, I expect people will ask us how the move to all-SSL is progressing. So, how is it going? (I've been telling people it's slowly moving along, we totally want this, it's just technical resources. But more details would be most useful!) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MediaWiki Language Extension Bundle 2013.07 release
Hallo, I would like to announce the release of MediaWiki language extension bundle 2013.07 * https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2013.07.tar.bz2 * sha256sum: ca381ea1bc1f10c56df28353f91a25129c604ff11938b424833925e8716e2ff3 Quick links: * Installation instructions are at https://www.mediawiki.org/wiki/MLEB * Announcements of new releases will be posted to a mailing list: https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n * Report bugs to https://bugzilla.wikimedia.org * Talk with us at #mediawiki-i18n @ freenode Release notes for each extension are below. Amir E. Aharoni == Babel == Only localization updates. == cldr == No changes. == CleanChanges == Only localization updates. == LocalisationUpdate == Only localization updates. == Translate == ===Noteworthy changes=== Groups are sorted alphabetically in the export tab of Special:Translate. Support for Yandex Translate API v1.5. Edit summaries for automated edits are written in the content language (bug 52142). == UniversalLanguageSelector == ===Noteworthy changes=== The functions for web fonts loading were optimized to improve performance. The internals of loading translated message were changed from the original jquery.i18n implementation to allow loading messages from other domains (CORS). Languages code aliases are now used properly in the Common languages section. This allows, for example, proper display of Tagalog for users from the Philippines. The variable $wgULSNoImeSelectors was added to disable IME on elements by specifying jQuery selectors that match them. The CSS class 'uls-settings-trigger' can be added to any element so that clicking it will make the ULS appear. It is useful for documentation and examples. Web fonts are applied to the IME selector menu, too. ===Fonts=== Persian and Malayalam no longer have a default font. Added fonts for Canadian Syllabic, Urdu (non-default), Updated UnifrakturMaguntia font. ===Input methods=== LRM and RLM were added to the Hebrew input methods and the redundant he-kbd input method was removed. Danda was removed from the Marathi phonetic input method. A bug was fixed in Kannada, Tamil and Marathi input methods that didn't allow typing some characters. The Slovak input method was fixed according to the standard Slovak keyboard. The names of the Oriya input methods were updated. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
It was so obvious that int. agencies were doing that. It was discussed in past threads in the mailing list too. Also, I have read that SSL is not secure neither. So, bleh... 2013/7/31 David Gerard dger...@gmail.com Jimmy just tweeted this: https://twitter.com/jimmy_wales/status/362626509648834560 I think that's the first time I've seen him say fuck in a public communication ... Anyway, I expect people will ask us how the move to all-SSL is progressing. So, how is it going? (I've been telling people it's slowly moving along, we totally want this, it's just technical resources. But more details would be most useful!) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On 31 July 2013 19:36, David Gerard dger...@gmail.com wrote: Jimmy just tweeted this: https://twitter.com/jimmy_wales/status/362626509648834560 I think that's the first time I've seen him say fuck in a public communication ... And wow, this is the NSA slide that triggered it: https://image.guim.co.uk/sys-images/Guardian/Pix/audio/video/2013/7/31/1375269604628/KS8-001.jpg That's us there. Fuck these people. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On 31 July 2013 19:46, Emilio J. Rodríguez-Posada emi...@gmail.com wrote: Also, I have read that SSL is not secure neither. So, bleh... PFS. http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html Also, https://en.wikipedia.org/wiki/Nirvana_fallacy - this is somewhere we can in fact do better step by step - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On Wed, Jul 31, 2013 at 11:40 AM, Tyler Romeo tylerro...@gmail.com wrote: Good question. There are two steps to this: 1) Move all logins to TLS 2) Move all logged in users to TLS 3) Serve all traffic via HTTPS 4) With PFS and long HSTS timeouts The former was dependent on a bug with E:CentralAuth that was causing $wgSecureLogin to malfunction. I am not sure whether this bug was ever fixed (I remember seeing Chris submit a patch for it, but I think it was abandoned). The bug has been fixes as part of the new SUL code. Yay! Also, the discussion on https://bugzilla.wikimedia.org/show_bug.cgi?id=52283 is probably a blocker for enabled $wgSecureLogin (which would be a pre-requisite for either of the two above steps). As a few people noticed, we actually threw the switch on wgSecureLogin yesterday, at which point the UX people felt that experience wasn't ready, and it was reverted. This bug was one of the issues identified, where they felt the UX would actually harm the editor experience. We also have some scaling concerns, so ops is also working on making sure we have enough capacity on hand to handle major spikes after we enable this. Hopefully we'll tie up all the loose ends in the near future, and can try getting to step #1 again. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Jul 31, 2013 at 2:36 PM, David Gerard dger...@gmail.com wrote: Jimmy just tweeted this: https://twitter.com/jimmy_wales/status/362626509648834560 I think that's the first time I've seen him say fuck in a public communication ... Anyway, I expect people will ask us how the move to all-SSL is progressing. So, how is it going? (I've been telling people it's slowly moving along, we totally want this, it's just technical resources. But more details would be most useful!) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
Which kind of ignores the issue that encrypting with ssl doesn't do a lot against traffic analysis, when its publicly known how big the pages you're downloading are, and how many images/other assets they have on them. NSA certainly has the resources to do this if they want. If you can do this sort of thing: http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.html against google maps, I imagine it should be much simpler to do something like that for Wikipedia. (Our data has more variation in it, and the data is all publicly available) --bawolff On 7/31/13, Tyler Romeo tylerro...@gmail.com wrote: Good question. There are two steps to this: 1) Move all logins to TLS 2) Move all logged in users to TLS The former was dependent on a bug with E:CentralAuth that was causing $wgSecureLogin to malfunction. I am not sure whether this bug was ever fixed (I remember seeing Chris submit a patch for it, but I think it was abandoned). Also, the discussion on https://bugzilla.wikimedia.org/show_bug.cgi?id=52283 is probably a blocker for enabled $wgSecureLogin (which would be a pre-requisite for either of the two above steps). *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Jul 31, 2013 at 2:36 PM, David Gerard dger...@gmail.com wrote: Jimmy just tweeted this: https://twitter.com/jimmy_wales/status/362626509648834560 I think that's the first time I've seen him say fuck in a public communication ... Anyway, I expect people will ask us how the move to all-SSL is progressing. So, how is it going? (I've been telling people it's slowly moving along, we totally want this, it's just technical resources. But more details would be most useful!) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On Wed, Jul 31, 2013 at 2:50 PM, Chris Steipp cste...@wikimedia.org wrote: 3) Serve all traffic via HTTPS 4) With PFS and long HSTS timeouts Indeed. I need to be more optimistic. :) The bug has been fixes as part of the new SUL code. Yay! Nice! *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On Wed, Jul 31, 2013 at 11:55 AM, Brian Wolff bawo...@gmail.com wrote: Which kind of ignores the issue that encrypting with ssl doesn't do a lot against traffic analysis, when its publicly known how big the pages you're downloading are, and how many images/other assets they have on them. NSA certainly has the resources to do this if they want. If you can do this sort of thing: http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.html against google maps, I imagine it should be much simpler to do something like that for Wikipedia. (Our data has more variation in it, and the data is all publicly available) --bawolff Time to start adding a random amount of extra packets with each request? :) James Alexander Legal and Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On Jul 31, 2013, at 3:01 PM, James Alexander jalexan...@wikimedia.org wrote: Time to start adding a random amount of extra packets with each request? :) This is what freenet does, but I think supporting SPDY/HTTP 2.0 [1] will help in this regard as well, as it essentially pipelines requests (so you wouldn't be able to discern which packets were article body, for example). --Ken. [1] http://en.wikipedia.org/wiki/HTTP_2.0 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
Time to start adding a random amount of extra packets with each request? :) We would need to be very careful to not cause detectable entropy changes which is not trivial! Perhaps we promote the deployment of SPDY/QUIC which interleaves requests? ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Wed, Jul 31, 2013 at 12:01 PM, James Alexander jalexan...@wikimedia.orgwrote: On Wed, Jul 31, 2013 at 11:55 AM, Brian Wolff bawo...@gmail.com wrote: Which kind of ignores the issue that encrypting with ssl doesn't do a lot against traffic analysis, when its publicly known how big the pages you're downloading are, and how many images/other assets they have on them. NSA certainly has the resources to do this if they want. If you can do this sort of thing: http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.html against google maps, I imagine it should be much simpler to do something like that for Wikipedia. (Our data has more variation in it, and the data is all publicly available) --bawolff Time to start adding a random amount of extra packets with each request? :) James Alexander Legal and Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
Like dgerald said, let's not let the perfect distract us from the better. It will be impossible to 100% secure our visitors' traffic against an adversary with as many resources as the NSA. But we can secure our users against adversaries with fewer resources, and we can increase the cost of a successful attack so that casual snooping on everyone and every article isn't possible. Let's make the NSA use that expensive targetted 'trafficthief' program at the top of their pyramid, instead of letting them cheaply/casually sniff everything with xkeyscore. --scott -- (http://cscott.net) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
There was the lofty notion of including all images, CSS/JS/whatnot as CDATA elements in the page itself, for browsers that support it. That would get around the one issue, but still allow size-based fingerprinting, especially since most users will follow links within the site, so the search space gets much smaller. Random package size increase, as mentioned, might help there. Magnus On Wed, Jul 31, 2013 at 7:55 PM, Brian Wolff bawo...@gmail.com wrote: Which kind of ignores the issue that encrypting with ssl doesn't do a lot against traffic analysis, when its publicly known how big the pages you're downloading are, and how many images/other assets they have on them. NSA certainly has the resources to do this if they want. If you can do this sort of thing: http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.html against google maps, I imagine it should be much simpler to do something like that for Wikipedia. (Our data has more variation in it, and the data is all publicly available) --bawolff On 7/31/13, Tyler Romeo tylerro...@gmail.com wrote: Good question. There are two steps to this: 1) Move all logins to TLS 2) Move all logged in users to TLS The former was dependent on a bug with E:CentralAuth that was causing $wgSecureLogin to malfunction. I am not sure whether this bug was ever fixed (I remember seeing Chris submit a patch for it, but I think it was abandoned). Also, the discussion on https://bugzilla.wikimedia.org/show_bug.cgi?id=52283 is probably a blocker for enabled $wgSecureLogin (which would be a pre-requisite for either of the two above steps). *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Jul 31, 2013 at 2:36 PM, David Gerard dger...@gmail.com wrote: Jimmy just tweeted this: https://twitter.com/jimmy_wales/status/362626509648834560 I think that's the first time I've seen him say fuck in a public communication ... Anyway, I expect people will ask us how the move to all-SSL is progressing. So, how is it going? (I've been telling people it's slowly moving along, we totally want this, it's just technical resources. But more details would be most useful!) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- undefined ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
Just one question from a relatively non-technical person: What falls off the map if everything is done using SSL? Is this the protocol that would make it essentially impossible to read/edit Wikipedia using a normal internet connection from China? Risker On 31 July 2013 15:12, Magnus Manske magnusman...@googlemail.com wrote: There was the lofty notion of including all images, CSS/JS/whatnot as CDATA elements in the page itself, for browsers that support it. That would get around the one issue, but still allow size-based fingerprinting, especially since most users will follow links within the site, so the search space gets much smaller. Random package size increase, as mentioned, might help there. Magnus On Wed, Jul 31, 2013 at 7:55 PM, Brian Wolff bawo...@gmail.com wrote: Which kind of ignores the issue that encrypting with ssl doesn't do a lot against traffic analysis, when its publicly known how big the pages you're downloading are, and how many images/other assets they have on them. NSA certainly has the resources to do this if they want. If you can do this sort of thing: http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.html against google maps, I imagine it should be much simpler to do something like that for Wikipedia. (Our data has more variation in it, and the data is all publicly available) --bawolff On 7/31/13, Tyler Romeo tylerro...@gmail.com wrote: Good question. There are two steps to this: 1) Move all logins to TLS 2) Move all logged in users to TLS The former was dependent on a bug with E:CentralAuth that was causing $wgSecureLogin to malfunction. I am not sure whether this bug was ever fixed (I remember seeing Chris submit a patch for it, but I think it was abandoned). Also, the discussion on https://bugzilla.wikimedia.org/show_bug.cgi?id=52283 is probably a blocker for enabled $wgSecureLogin (which would be a pre-requisite for either of the two above steps). *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Jul 31, 2013 at 2:36 PM, David Gerard dger...@gmail.com wrote: Jimmy just tweeted this: https://twitter.com/jimmy_wales/status/362626509648834560 I think that's the first time I've seen him say fuck in a public communication ... Anyway, I expect people will ask us how the move to all-SSL is progressing. So, how is it going? (I've been telling people it's slowly moving along, we totally want this, it's just technical resources. But more details would be most useful!) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- undefined ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On Jul 31, 2013, at 3:12 PM, Magnus Manske magnusman...@googlemail.com wrote: There was the lofty notion of including all images, CSS/JS/whatnot as CDATA elements in the page itself, for browsers that support it. That would get around the one issue, but still allow size-based fingerprinting, especially since most users will follow links within the site, so the search space gets much smaller. Random package size increase, as mentioned, might help there. This is part of why support and rapid adoption of protocols that allow for multiplexing (SPDY/HTTP2.0) are important - they would make the fingerprinting process significantly more difficult. --Ken. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On 31 July 2013 19:48, David Gerard dger...@gmail.com wrote: PFS. http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html Keeping in mind that PFS is not actually perfect either: http://tonyarcieri.com/imperfect-forward-secrecy-the-coming-cryptocalypse - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
Oh - if anyone can authoritatively compose a WMF blog post on the state of the move to SSL (the move to logins and what happened there, the NSA slide, ongoing issues like browsers in China, etc), that would probably be a useful thing :-) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On Wed, Jul 31, 2013 at 1:06 PM, David Gerard dger...@gmail.com wrote: Oh - if anyone can authoritatively compose a WMF blog post on the state of the move to SSL (the move to logins and what happened there, the NSA slide, ongoing issues like browsers in China, etc), that would probably be a useful thing :-) I'll be posting blog posts each step of the way as we move to SSL. We have plans on SSL for anons by default, but there's no official roadmap for doing so. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] (no subject)
OK, so after a bit of trouble I managed to get it working on my Vagrant instance. Here's a brief summary of what I learned: * It uses a MongoDB backend with Python and Flask as a front-end * There are plugins that implement certain tests (e.g., nmap, skipfish) * Plans are combinations of plugins, basically a test plan * Sites are added into groups, and are then assigned plans * Finally, you run plans on the frontend and they're run by a celery job queue From the looks of it, I don't think this would be particularly useful for individual developers, because many of the tests require a full TLS setup and whatnot. What might be useful is to have a security instance running MediaWiki with a similar setup to the actual en-wiki, and then have Minion running on an instance and have it run the tests that way. Unfortunately, I don't know how we would manage users (since it doesn't have LDAP integration) or when we would run these tests (I'd imagine there wouldn't be a need to run them on every change). Thoughts? *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Jul 31, 2013 at 2:39 PM, Chris Steipp cste...@wikimedia.org wrote: On Wed, Jul 31, 2013 at 11:23 AM, Tyler Romeo tylerro...@gmail.com wrote: Hey all, Mozilla made an announcement yesterday about a new framework called Minion: http://blog.mozilla.org/security/2013/07/30/introducing-minion/ https://github.com/mozilla/minion It's an automated security testing framework for use in testing web applications. I'm currently looking into how to use it. Would there be any interest in setting up such a framework for automated security testing of MediaWiki? I'm definitely interested in seeing if we can leverage something like this. I'm not sure where it would fit alongside our current automated testing, but I think it would be valuable to at least take a closer look. And it's nice to see they're supporting ZAP and skipfish, although unless they allow for more detailed configurations, both take ages to completely scan a MediaWiki install. If you get it running, please share your experience. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
Oh - if anyone can authoritatively compose a WMF blog post on the state of the move to SSL (the move to logins and what happened there, the NSA slide, ongoing issues like browsers in China, etc), that would probably be a useful thing :-) I'll be posting blog posts each step of the way as we move to SSL. We have plans on SSL for anons by default, but there's no official roadmap for doing so. Something sooner than later might be good. Also have you guys read the presentation. A lot of this is very chilling I agree with Jimbo. We need to fix this as best we can. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On 07/31/2013 03:23 PM, Risker wrote: Just one question from a relatively non-technical person: What falls off the map if everything is done using SSL? Is this the protocol that would make it essentially impossible to read/edit Wikipedia using a normal internet connection from China? Risker Good question. I'm not aware of the current status, but Tim Starling said SSL connections to Wikipedia have been blocked in China (https://bugzilla.wikimedia.org/show_bug.cgi?id=47832#c16). Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
Like I've said before, the NSA spying on what users are reading is still the least of our concerns. We should focus on making sure passwords aren't sent over plaintext before attempting to evade a government-run international spy network. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Jul 31, 2013 at 4:32 PM, Matthew Flaschen mflasc...@wikimedia.orgwrote: On 07/31/2013 03:23 PM, Risker wrote: Just one question from a relatively non-technical person: What falls off the map if everything is done using SSL? Is this the protocol that would make it essentially impossible to read/edit Wikipedia using a normal internet connection from China? Risker Good question. I'm not aware of the current status, but Tim Starling said SSL connections to Wikipedia have been blocked in China (https://bugzilla.wikimedia.org/show_bug.cgi?id=47832#c16). Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
Can we enable full security mode (as an optional feature) geographically based on the most concerned governments, if the whole thing isn't going fast due to lack of resources? On Wed, Jul 31, 2013 at 11:35 PM, Tyler Romeo tylerro...@gmail.com wrote: Like I've said before, the NSA spying on what users are reading is still the least of our concerns. We should focus on making sure passwords aren't sent over plaintext before attempting to evade a government-run international spy network. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Jul 31, 2013 at 4:32 PM, Matthew Flaschen mflasc...@wikimedia.orgwrote: On 07/31/2013 03:23 PM, Risker wrote: Just one question from a relatively non-technical person: What falls off the map if everything is done using SSL? Is this the protocol that would make it essentially impossible to read/edit Wikipedia using a normal internet connection from China? Risker Good question. I'm not aware of the current status, but Tim Starling said SSL connections to Wikipedia have been blocked in China (https://bugzilla.wikimedia.org/show_bug.cgi?id=47832#c16). Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On Wed, Jul 31, 2013 at 1:39 PM, Paul Selitskas p.selits...@gmail.comwrote: Can we enable full security mode (as an optional feature) geographically based on the most concerned governments, if the whole thing isn't going fast due to lack of resources? No. That's in fact much, much harder. There's nothing stopping you (and anyone else who is concerned about their privacy) from using HTTPS Everywhere. We support HTTPS natively as is right now. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
Yes, that is exactly what I do. But Google, for instance, redirects me to HTTP, and if I've logged via HTTPS recently, I would have to log in once again via HTTP. It's very frustrating. Are there public statistics on HTTPS v. HTTP processed requests share for Wikimedia? Rough numbers? For inexperienced users yet concerned about privacy, there should be an HTTP/HTTPS switch in the Preferences page. We have one at the registration/log-in page, but I'd like MediaWiki to remember that I want to use HTTPS only. On Wed, Jul 31, 2013 at 11:50 PM, Ryan Lane rlan...@gmail.com wrote: On Wed, Jul 31, 2013 at 1:39 PM, Paul Selitskas p.selits...@gmail.com wrote: Can we enable full security mode (as an optional feature) geographically based on the most concerned governments, if the whole thing isn't going fast due to lack of resources? No. That's in fact much, much harder. There's nothing stopping you (and anyone else who is concerned about their privacy) from using HTTPS Everywhere. We support HTTPS natively as is right now. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] (no subject)
quote name=Tyler Romeo date=2013-07-31 time=16:21:50 -0400 What might be useful is to have a security instance running MediaWiki with a similar setup to the actual en-wiki, and then have Minion running on an instance and have it run the tests that way. Unfortunately, I don't know how we would manage users (since it doesn't have LDAP integration) or when we would run these tests (I'd imagine there wouldn't be a need to run them on every change). Tyler: mind reporting this as an enhancement bug in deployment-prep? Include things like what is needed to get it working etc. Might be something we could get running against the beta cluster, perhaps. Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
@Paul - Some links that might interest you. On Wed, Jul 31, 2013 at 4:56 PM, Paul Selitskas p.selits...@gmail.comwrote: But Google, for instance, redirects me to HTTP https://bugzilla.wikimedia.org/show_bug.cgi?id=51002 For inexperienced users yet concerned about privacy, there should be an HTTP/HTTPS switch in the Preferences page. We have one at the registration/log-in page, but I'd like MediaWiki to remember that I want to use HTTPS only. https://bugzilla.wikimedia.org/show_bug.cgi?id=52283 https://gerrit.wikimedia.org/r/47089 *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On Wed, Jul 31, 2013 at 8:56 PM, Paul Selitskas p.selits...@gmail.com wrote: Yes, that is exactly what I do. But Google, for instance, redirects me to HTTP, and if I've logged via HTTPS recently, I would have to log in once again via HTTP. It's very frustrating. I think you've misinterpreted. HTTPS Everywhere is a proper noun. https://www.eff.org/https-everywhere Are there public statistics on HTTPS v. HTTP processed requests share for Wikimedia? Rough numbers? I have no idea. For inexperienced users yet concerned about privacy, there should be an HTTP/HTTPS switch in the Preferences page. We have one at the registration/log-in page, but I'd like MediaWiki to remember that I want to use HTTPS only. That was considered but I believe the consensus was not to do that. Instead we will (eventually) force all logged in users to HTTPS as long as they're logged in. (So like your proposal except that the preference is hidden and always enabled for everyone) -Jeremy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] (no subject)
On Wed, Jul 31, 2013 at 5:00 PM, Greg Grossmeier g...@wikimedia.org wrote: Tyler: mind reporting this as an enhancement bug in deployment-prep? Include things like what is needed to get it working etc. Might be something we could get running against the beta cluster, perhaps. Sure thing: https://bugzilla.wikimedia.org/show_bug.cgi?id=52354 *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On 07/31/2013 04:35 PM, Tyler Romeo wrote: Like I've said before, the NSA spying on what users are reading is still the least of our concerns. We should focus on making sure passwords aren't sent over plaintext before attempting to evade a government-run international spy network. I'm not sure what that has to do with the the message you replied to. I completely support rolling out HTTPS where possible (I'm using HTTPS Everywhere already). I was agreeing that we need to be aware of Risker's concern (other people have mentioned it too, of course) that we not effectively lock out users in China and other countries that may block SSL. It's important to remember that people in China still can and do edit Wikipedias in other languages, too. This applies if we mandate secure login in such countries, too. As for government-run spy networks, we don't know what their full capabilities are. But there are plenty of benefits to rolling out SSL regardless, even just for privacy from the person at the other end of the coffee shop. Firesheep, anyone? Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On Wed, Jul 31, 2013 at 5:29 PM, Matthew Flaschen mflasc...@wikimedia.orgwrote: I'm not sure what that has to do with the the message you replied to. I completely support rolling out HTTPS where possible (I'm using HTTPS Everywhere already). Sorry I might have highlighted the wrong message when replying. I was referring to the discussion about how TLS doesn't entirely solve the problem and that we should start adding random packets in order to prevent traffic analysis. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On Wednesday, July 31, 2013, Ryan Lane wrote:
On Wed, Jul 31, 2013 at 1:06 PM, David Gerard
dger...@gmail.comjavascript:_e({}, 'cvml', 'dger...@gmail.com');
wrote:
Oh - if anyone can authoritatively compose a WMF blog post on the
state of the move to SSL (the move to logins and what happened there,
the NSA slide, ongoing issues like browsers in China, etc), that would
probably be a useful thing :-)
I'll be posting blog posts each step of the way as we move to SSL. We have
plans on SSL for anons by default, but there's no official roadmap for
doing so.
A follow up: I've started writing a blog post about this and hope to have
something postable by tomorrow.
- Ryan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
It would be useful to focus on the short term problem and solution; the coming
quantum computer factoring factory issue which will render large-prime crypto
less useful is still on the horizon.
The big threat is lack of basic HTTPS everywhere. The second is site key
security (ensuring the NSA never gets your private keys). The third is perfect
forward security with rapid key rotation.
George William Herbert
Sent from my iPhone
On Jul 31, 2013, at 2:45 PM, Ryan Lane rlan...@gmail.com wrote:
On Wednesday, July 31, 2013, Ryan Lane wrote:
On Wed, Jul 31, 2013 at 1:06 PM, David Gerard
dger...@gmail.comjavascript:_e({}, 'cvml', 'dger...@gmail.com');
wrote:
Oh - if anyone can authoritatively compose a WMF blog post on the
state of the move to SSL (the move to logins and what happened there,
the NSA slide, ongoing issues like browsers in China, etc), that would
probably be a useful thing :-)
I'll be posting blog posts each step of the way as we move to SSL. We have
plans on SSL for anons by default, but there's no official roadmap for
doing so.
A follow up: I've started writing a blog post about this and hope to have
something postable by tomorrow.
- Ryan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Is assert() allowed?
On 31/07/13 22:19, Tyler Romeo wrote: On Wed, Jul 31, 2013 at 7:42 AM, Tim Starling tstarl...@wikimedia.orgwrote: Indeed. In C, assert() will abort the program if it is enabled, which is hard to miss. It is not comparable to the PHP assert() function. ...except PHP's assert() *also* aborts the program if enabled. What am I missing here? The php.ini option assert.bail is 0 by default. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Is assert() allowed?
On Wed, Jul 31, 2013 at 7:28 PM, Tim Starling tstarl...@wikimedia.orgwrote: The php.ini option assert.bail is 0 by default. So? It's the same way in Java. You have to turn on assertions. It's kind of natural to assume that if assertions are off the won't cause fatal errors. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
Also, on a side note, Facebook *just* made HTTPS the default: https://www.facebook.com/notes/facebook-engineering/secure-browsing-by-default/10151590414803920 *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Jul 31, 2013 at 6:03 PM, Brian Wolff bawo...@gmail.com wrote: As for government-run spy networks, we don't know what their full capabilities are. But there are plenty of benefits to rolling out SSL regardless, even just for privacy from the person at the other end of the coffee shop. Firesheep, anyone? Matt Flaschen I agree that there's lots of benefits to ssl, and its something that we really should do. I just think we should be clear on our threat model, and not mislead people into thinking it will protect them from an entity with the resources of a state. SSL is too often banded about as being something which will totally prevent government type spying. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On Wed, Jul 31, 2013 at 5:22 PM, Tyler Romeo tylerro...@gmail.com wrote: Also, on a side note, Facebook *just* made HTTPS the default: https://www.facebook.com/notes/facebook-engineering/secure-browsing-by-default/10151590414803920 As an FYI - facebook, a site where every person is logged in and possibly seeing non-public content is very different than Wikimedia. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Jul 31, 2013 at 6:03 PM, Brian Wolff bawo...@gmail.com wrote: As for government-run spy networks, we don't know what their full capabilities are. But there are plenty of benefits to rolling out SSL regardless, even just for privacy from the person at the other end of the coffee shop. Firesheep, anyone? Matt Flaschen I agree that there's lots of benefits to ssl, and its something that we really should do. I just think we should be clear on our threat model, and not mislead people into thinking it will protect them from an entity with the resources of a state. SSL is too often banded about as being something which will totally prevent government type spying. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Is assert() allowed?
On 01/08/13 10:05, Tyler Romeo wrote: On Wed, Jul 31, 2013 at 7:28 PM, Tim Starling tstarl...@wikimedia.orgwrote: The php.ini option assert.bail is 0 by default. So? It's the same way in Java. You have to turn on assertions. It's kind of natural to assume that if assertions are off the won't cause fatal errors. It shouldn't be possible to switch them off, and they shouldn't be off by default. I covered this in the 2012 thread. If the error is serious and unexpected, and likely to cause undesirable behaviour, then it should throw an exception. Maybe we should just unconditionally call assert_options(ASSERT_CALLBACK, ...) from Setup.php and have the callback function throw an exception. But that would still leave the problem of acting like eval(), that's not configurable. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] unexpected error info in HTML
Hi, I noticed some pages we crawled containing error message like this; div id=mw-content-text lang=zh-CN dir=ltr class=mw-content-ltrp class=errorFailed to render property P373: Wikibase\LanguageWithConversion::factory: given languages do not have the same parent language/p But when I open the url in browser, there is no such message. And using index.php can also get normal content without error messages. Here are examples you can retry: bad $ wget 'http://zh.wikipedia.org/zh-cn/Google' good $ wget 'http://zh.wikipedia.org/w/index.php?title=Google' Looks like something is wrong on Wikipedia side, anything need to fix? Thanks -- Jiang BIAN This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On Wed, Jul 31, 2013 at 5:59 PM, George Herbert george.herb...@gmail.comwrote: The second is site key security (ensuring the NSA never gets your private keys). Who theoretically has access to the private keys (and/or the signing key) right now? The third is perfect forward security with rapid key rotation. Does rapid key rotation in any way make a MITM attack less detectable? Presumably the NSA would have no problem getting a fraudulent certificate signed by DigiCert. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On Wed, Jul 31, 2013 at 9:28 PM, Anthony wikim...@inbox.org wrote: On Wed, Jul 31, 2013 at 5:59 PM, George Herbert george.herb...@gmail.com wrote: The second is site key security (ensuring the NSA never gets your private keys). Who theoretically has access to the private keys (and/or the signing key) right now? People who have root at Wikimedia, which is Wikimedia's operations team and a few of the developers. The third is perfect forward security with rapid key rotation. Does rapid key rotation in any way make a MITM attack less detectable? Presumably the NSA would have no problem getting a fraudulent certificate signed by DigiCert. SSL Observatory would likely pick that up if it was done in any large scale. It's less detectable when done in a targeted way, but if that's the case, the person being targeted is already pretty screwed and we wouldn't likely be the site targeted. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On Thu, Aug 1, 2013 at 4:28 AM, Anthony wikim...@inbox.org wrote: On Wed, Jul 31, 2013 at 5:59 PM, George Herbert george.herb...@gmail.comwrote: The second is site key security (ensuring the NSA never gets your private keys). Who theoretically has access to the private keys (and/or the signing key) right now? The roots. https://meta.wikimedia.org/wiki/Sysadmins#List (was out of date last time I overhauled it, maybe it's being updated more regularly now) The third is perfect forward security with rapid key rotation. Does rapid key rotation in any way make a MITM attack less detectable? Presumably the NSA would have no problem getting a fraudulent certificate signed by DigiCert. I'm not seeing the relevance. And we have the SSL observatory (EFF) fwiw. We (society, standards making bodies, etc.) need to do more to reform the current SSL mafia system. (i.e. it should be easier for a vendor to remove a CA from a root store and we shouldn't have a situation where many dozens of orgs all have the ability to sign certs valid for any domain.) I'm not sure how much we (Wikimedia) can do about that though. -Jeremy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Is assert() allowed?
On Wed, Jul 31, 2013 at 10:47 PM, Tim Starling tstarl...@wikimedia.orgwrote: If the error is serious and unexpected, and likely to cause undesirable behaviour If this is the case, then you don't use assertions. You would use assertions for things that don't have major side effects on the program, but generally are logically unexpected. You use assertions for things that will only break during development. It's not like the designers of C and Java just blindly put in a way to disable assertions but not exceptions. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
