-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Another of Werdna's contributions: page protections can now have an
expiration time added. The accepted input format is the same as for
custom block times.
While we've put it through its courses, it's possible there's still some
minor issues or corner cases, so give a shout if you notice anything awry!
There's also a Special:Protectedpages list, but it's not fully
functional yet. (As well as a few minor issues, as it's marked
'expensive' it won't show any results yet on the live site as the cache
is empty.)
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFtTBQwRnhpk1wk44RAgHmAJ9hToS3ahUyAmQDJQVi82OcQclyzQCfXglS
giSBn1AqMDj6wa74Wo0kLgU=
=2yE/
-----END PGP SIGNATURE-----
-----Original Message-----
From: wikitech-l-bounces(a)lists.wikimedia.org
[mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of
wikitech-l-request(a)lists.wikimedia.org
Sent: 25 January 2007 08:16
To: wikitech-l(a)lists.wikimedia.org
Subject: Wikitech-l Digest, Vol 42, Issue 81
Send Wikitech-l mailing list submissions to
wikitech-l(a)lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.wikimedia.org/mailman/listinfo/wikitech-l
or, via email, send a message with subject or body 'help' to
wikitech-l-request(a)lists.wikimedia.org
You can reach the person managing the list at
wikitech-l-owner(a)lists.wikimedia.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Wikitech-l digest..."
Today's Topics:
1. KILL THIS THREAD (was Re: License status of MW screenshots.)
(Brion Vibber)
2. Re: KILL THIS THREAD (was Re: License status of MW
screenshots.) (Jay R. Ashworth)
3. Re: License status of MW screenshots. (Ilmari Karonen)
4. Re: KILL THIS THREAD (was Re: License status of MW
screenshots.) (Ilmari Karonen)
5. Re: MD5 Password Encryption (Alphax (Wikipedia email))
6. Re: License status of MW screenshots. (Alphax (Wikipedia email))
7. Re: MD5 Password Encryption (Edward Z. Yang)
8. Re: [MediaWiki-CVS] SVN: [19651] trunk/phase3 (Brion Vibber)
9. Re: Extension request: Greenlist (David Gerard)
10. MediaWiki automated test run failure 2007-01-25 (brion(a)pobox.com)
----------------------------------------------------------------------
Message: 1
Date: Wed, 24 Jan 2007 16:23:54 -0800
From: Brion Vibber <brion(a)pobox.com>
Subject: [Wikitech-l] KILL THIS THREAD (was Re: License status of MW
screenshots.)
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Message-ID: <45B7F89A.4000704(a)pobox.com>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Guys, can we please take it off-list or find an amateur legal arguments
list to duke it out in?
Thanks.
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFt/iawRnhpk1wk44RAqT2AKCgVXry6xLIAJ3Ps6NTHL6rxt3NLwCcCQKR
XC9Ied1bM3Y7Lajh7DCMAjE=
=zgqL
-----END PGP SIGNATURE-----
------------------------------
Message: 2
Date: Wed, 24 Jan 2007 19:45:46 -0500
From: "Jay R. Ashworth" <jra(a)baylink.com>
Subject: Re: [Wikitech-l] KILL THIS THREAD (was Re: License status of
MW screenshots.)
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Message-ID: <20070125004546.GA10994(a)cgi.jachomes.com>
Content-Type: text/plain; charset=us-ascii
On Wed, Jan 24, 2007 at 04:23:54PM -0800, Brion Vibber wrote:
> Guys, can we please take it off-list or find an amateur legal arguments
> list to duke it out in?
O*kay*, dad. :-}
Cheers,
-- jra
--
Jay R. Ashworth
jra(a)baylink.com
Designer Baylink RFC
2100
Ashworth & Associates The Things I Think '87
e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647
1274
------------------------------
Message: 3
Date: Thu, 25 Jan 2007 03:37:05 +0200
From: Ilmari Karonen <nospam(a)vyznev.net>
Subject: Re: [Wikitech-l] License status of MW screenshots.
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Message-ID: <45B809C1.2080107(a)vyznev.net>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Jay R. Ashworth wrote:
> On Wed, Jan 24, 2007 at 05:45:51PM -0500, Anthony wrote:
>>> To use my example, above, my taking a photograph of an artist posing
>>> next to his painting does *not*, to me, seem to meet the description
>>> there, quoted from the statute, of a derivative work, as it's not
>>> *based* on the original painting: he could have been standing next to
>>> *anything*.
>>>
>> Whether or not it's a derivative work is largely irrelevant, because a
>> photograph of a painting definitely *is* a copy.
>
> Well, that's largely a strawman, since 3 lines earlier I made it clear
> that I was *not* discussing merely "a photograph of a painting" in the
> Bridgeman sense.
The way I see it, Bridgeman vs. Corel is pretty much irrelevant here. A
work can be subject to multiple copyright claims. Bridgeman is about
whether a person making a copy gets to claim copyright on it. The issue
we're discussing is whether the person who made the original gets to
enforce their copyright on the derivative work. The two issues are more
or less orthogonal -- all the four possible combinations can and do occur.
Examples:
1. Person A paints a picture. Person B scans it. Per Bridgeman, the
copyright on the scan belongs to person A only.
2. Person A paints a picture. Person B takes it to their studio and
photographs it in a carefully chosen artistic setting. The photograph
incorporates creative work by both A (the painting) and B (the scene it
is set in), and both thus have copyright on it.
3. Person A paints a picture and makes posters of it. Person B takes a
photo of a busy street where one lamppost in the background happens to
have one of A's posters glued to it. Since the inclusion of A's picture
in the photo is incidental and quite insignificant, it counts as fair
use and/or _de minimis_. Even if the photo technically counted as a
derivative work (which is a matter of definition), A would not be able
to enforce their copyright on it.
4. Person A paints a picture. Person be uses a spectrometer to analyze
a spot on the painting and to determine the chemical composition of the
paint there. Since the resulting dataset bears no traces of creativity
by either A or B, it is ineligible for copyright.
--
Ilmari Karonen
------------------------------
Message: 4
Date: Thu, 25 Jan 2007 03:38:45 +0200
From: Ilmari Karonen <nospam(a)vyznev.net>
Subject: Re: [Wikitech-l] KILL THIS THREAD (was Re: License status of
MW screenshots.)
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Message-ID: <45B80A25.6020901(a)vyznev.net>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Brion Vibber wrote:
>
> Guys, can we please take it off-list or find an amateur legal arguments
> list to duke it out in?
>
> Thanks.
Oops, sorry, didn't notice this sooner. Will stop.
--
Ilmari Karonen
------------------------------
Message: 5
Date: Thu, 25 Jan 2007 11:38:09 +1030
From: "Alphax (Wikipedia email)" <alphasigmax(a)gmail.com>
Subject: Re: [Wikitech-l] MD5 Password Encryption
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Message-ID: <45B802F9.6030500(a)gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Edward Z. Yang wrote:
> Aw, come on, why is there so much contention about such a simple issue?
> And yes, I did slip when I started talking about birthday attacks. Sorry
> about that.
>
I find it interesting that you're advocating moving away from MD5 in a
situation where the known collision weaknesses aren't relevant, yet you
personally are still using SHA1 (which was broken about two years ago)
in a situation which *is* susceptible to collision - and your signature
didn't verify on that message (<ep65i0$496$1(a)sea.gmane.org>).
--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP
Regardless of rel="nofollow" the current whitelist and blacklist
features which are used across languages anyway will still be needed.
Therefore, could I put in a request for a "greenlist" feature to allow
sysop approved links to be generated without rel="nofollow"?
If it is hard to do directly (and I cannot see an easy way), an
acceptable alternative is the creation of http://greenlist.wikipedia.org
under interwiki which autodiverts:
http://greenlist.wikipedia.org /first-string/second-string to
http:///first-string/second-string for any /first-string/ on a greenlist.
It seems to me inevitable that this feature will be wanted sooner or
later on en, and will be useful for other implementations so doing it
sooner rather than later is preferable...
BozMo.
http://en.wikipedia.org/wiki/User:BozMo
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
simetrical wrote:
> Incidentally, should we maybe use set_exception_handler()?
We do -- it's what prints the pretty backtraces for unhandled exceptions.
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFuFJxwRnhpk1wk44RAvNqAKCpA4mhvrMqQTuBpMVSVB5Eg+wbYACcD+Zl
usJ97tCgQc5jJe/8wTjhmNw=
=i5I+
-----END PGP SIGNATURE-----
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.10alpha (r19651).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
18 still FAILING test(s) :(
* URL-encoding in URL functions (single parameter)
* URL-encoding in URL functions (multiple parameters)
* TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)
* TODO: Link containing double-single-quotes '' (bug 4598)
* TODO: message transform: <noinclude> in transcluded template (bug 4926)
* TODO: message transform: <onlyinclude> in transcluded template (bug 4926)
* BUG 1887, part 2: A <math> with a thumbnail- math enabled
* TODO: HTML bullet list, unclosed tags (bug 5497)
* TODO: HTML ordered list, unclosed tags (bug 5497)
* TODO: HTML nested bullet list, open tags (bug 5497)
* TODO: HTML nested ordered list, open tags (bug 5497)
* TODO: Inline HTML vs wiki block nesting
* TODO: Mixing markup for italics and bold
* TODO: 5 quotes, code coverage +1 line
* TODO: dt/dd/dl test
* TODO: Images with the "|" character in the comment
* TODO: Parents of subpages, two levels up, without trailing slash or name.
* TODO: Parents of subpages, two levels up, with lots of extra trailing slashes.
Passed 489 of 507 tests (96.45%)... 18 tests failed!
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
If I am not mistaken (and I may very well be), MediaWiki still uses MD5s
to encrypt (well, technically hash, but it's named wfEncryptPassword(),
heh heh) user passwords.
function wfEncryptPassword( $userid, $password ) {
global $wgPasswordSalt;
$p = md5( $password);
if($wgPasswordSalt)
return md5( "{$userid}-{$p}" );
else
return $p;
}
If this is indeed the case, we should be considering migrating away from
MD5 to a more secure algorithm like SHA256. The breadth of attacks
against this hashing scheme have grown incredibly sophisticated, and
over where I consult, we generally discourage new developers from using
MD5 for any security related purposes (still makes a fine good checksum
though).
Migrating the hashes would probably prove to be tricky, but if we
implement appropriate hooks, with the addition of only one new field we
could easily "magically" update the fields once a user logs in, and the
system is (for one short request) in possession of the plaintext
password. The old algorithm could be supported indefinitely, but only
for old user accounts that haven't upgraded yet, all new accounts would
use the new hashing scheme. We could even rename the function into
something more accurate!
What say the developers?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFtWicqTO+fYacSNoRAmQEAJ45Laiqabiclzix0wZ8cN2Y8CuVZACffFUB
DYyZ9MjWOhFalNSY73bpM0w=
=9sel
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hashar wrote:
> This script pass through all users and change their skins from 'oldSkinName'
> to 'newSkinName'. There is NO validation about the new skin existence!
> Made on an original idea by Fooey (freenode)
I would strongly recommend generalizing this to update any given option,
rather than skins and nothing but skins.
- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFtokEwRnhpk1wk44RAnp7AJ48kw8YakW0Ac+10W3uuCw6dfY3iwCgkhMT
HNYpyZpIQdXI61m6ZFk92vw=
=pqyN
-----END PGP SIGNATURE-----
"Virgil Ierubino" <virgil.ierubino(a)gmail.com>
wrote in message
news:24dce9db0701211957k752c1b69oec2d75ffbb4e5a68@mail.gmail.com...
> On 1/22/07, Gerard Meijssen
<gerard.meijssen(a)gmail.com> wrote:
> > Personally, I'm intrigued. Virgil, could you elaborate on the purpose
> > of this project? In what ways can it help us (and who exactly is the
> > 'us' in this case :))?
>
> As explained already, an EBNF of Wikitext will allow for expansion of
> Wikitext easily as it's conforming to a standard, and a more efficient
> parser, etc. I'm not the expert in WHY it's good though, I just know it
is.
> And I know how to write EBNFs, and I can't work out how to code Wikitext's
> bullet points in EBNF - if EBNF can't handle Wikitext, then the efficient
> parsing and expansion won't be possible (as easily).
>
> Would very much appreciate help from anyone clued up as to how to proceed
if
> Wikitext can't be EBNFed, or who can show me that it, in fact, can.
>
> http://meta.wikimedia.org/wiki/Wikitext_Metasyntax
I missed the beginning of this thread for some reason.
Please also see http://www.mediawiki.org/wiki/Markup_spec and its sub-pages
for some work that has already been done in this area. It would be useful
if you could merge your new page on meta into this existing content.
- Mark Clements (HappyDog)
On 1/23/07, William Allen Simpson <william.allen.simpson(a)gmail.com> wrote:
[snip]
> Speaking to elements of the recent thread, I'd prefer SSL instead of
> home-grown challenge-response algorithms.
[snip]
On this subject... Wrapping the login site via SSL sounds like a
dandy idea, and it sidesteps the whole mess of cert issues if with SUL
we were to use a single login portal domain.
However, then we've just pushed the problem back to session cookie
theft. Sure, it would still be an improvement since a passive
attacker (at say Wikimania...) couldn't sit back and gather passwords,
but better still might be possible.
What the current industry best-practices with respect to binding
session data to a client's IP? Do web browsers switch IPs too often
for this to be acceptable (AOL?)?
At some point it might make sense to talk about all logged in user
sessions being SSLed... the overwhelming majority of the computational
load of SSL is the RSA stuff for signatures which would need to happen
once per login if we went the SUL login page behind SSL route.. After
that it's just symmetric crypto which isn't astoundingly expensive.
Were we to move logged in users into SSL all sorts of threats just go
away. Of course there is the little matter of plain squid not
supporting SSL offloading like some of the commercial reverse proxy /
acceleration solutions which would have to be resolved...
Is it possible to display, in list format, what talk pages have been most
recently updated? I have a fairly small group of people working on my wiki,
and it would be great to make it easy for everyone to navigate to the latest
discussions.
Alternatively, is it possible to make a link specify a recent changes
namespace? I.e. I put up a link in the toolbar called "Latest Discussions"
which linked to Special:Recentchanges&namespace=1 (I also tried the full
URL), but neither worked. As I'm a newb, I'm sure there's something I'm just
missing. Any ideas?
Emanuel
--
"The best journalism is the first draft of history."
- John Pilger
GWwiki: http://www.hackwurld.com/gwwiki