[wp-hackers] Security at Wordpress

[Elliotte Harold]

Doug Stewart wrote:

> No, it isn't a core principle, it's a beneficial side-effect.  Open
> Source development leverages network effects incurred by numerous
> developers having access to the underlying code.  As is the case in most
> well-designed network topologies, barriers (in this case, unresponsive
> devs unwilling to commit code volunteered by others) are circumvented
> and routed around, usually through forks.  I would argue that this is a
> non-ideal solution in most cases (the ideal being that everyone
> contributes to the same codebase, making it stronger in the aggregate).
> 

That ideal assumes people want the same thing. Sometimes different 
groups have different needs, and require different products to satisfy 
those needs. One system cannot be everything to every one. NetBSD, 
FreeBSD, and OpenBSD are good examples. They are different projects with 
different motivations and criteria. If you want portability pick NetBSD. 
  If you want security pick OpenBSD. If you want performance on X86, 
pick FreeBSD. Three different products forked form the same code base 
because different people have different needs and criteria for choosing 
an OS.


> This selfishly (on your part) forces the devs to keep track of your
> fork, as well as every other WP-related fork out there.  You've turned
> core WP development into an ineffecient "pull" model instead of the
> preferred "push" one.  The fact of the matter is that you claim to have
> coded around the very subject of this extremely long thread, thus you
> MUST have code that accomplishes such.  Go to Trac, submit a .diff
> attached to a ticket and then let the chips fall where they may.  To
> huffily reply that it's the duty of the WP devs to come looking for your
> code is the height of arrogance, once again IMNSHO.

Point of order: I've claimed no such thing. I have described a 
reasonable prophylatic measure that can be taken within the current code 
base to protect yourself from the two attacks discovered so far. Simply:

1. Don't allow img elements in comments
2. Don't give 3rd parties contributor rights
3. Don't follow 3rd party links from the comment moderation page.

So far, none of this requires a patch; but this is all a kludge we'd 
rather not have to take. It should be possible to give third parties 
contributor rights. It should be safe to follow 3rd party links from the 
admin pages. Making this safe requires changing the code.

The core team seems to want to implement a complex nonce based solution. 
I suspect there's a simpler, more robust solution using POST instead of 
GET. Whether I write the code to implement that solution depends on a 
variety of factors. However when the core team has been quite clear that 
they do not intend to accept a POST solution no matter what, then 
patches are not an option. There's no point in wasting my time and 
theirs cluttering TRAC with patches they've already said they'll reject. 
If they change their minds, I'll submit what I write; but given the 
current situation, the question is not patch or don't patch. The 
question is fork or do nothing.

-- 
Elliotte Rusty Harold  elharo at metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim