[wp-hackers] Security at Wordpress

[Doug Stewart]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Elliotte Harold wrote:
> 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.
> 

Not quite the same thing.  You're a step removed in this case - your
analogy applies to WP and b2evolution forking off of b2.  We're not
talking about use cases here, nor are we talking about offering
specialized version of WP, we're arguing over a core admin procedure.

If you can find a group of people that want a php5-only version of
WordPress that only uses POST in the admin interface, well then, *BSD away!

> 
>> 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:
> 

Bollocks.  To quote you:

"Since WordPress is wisely published under the GPL, any changes I
publish in any hypothetical fork will be freely available to the core
developers if they decide to incorporate them. Certainly if I discover
any major bugs I'll report them to the core. However most of what I want
to do are changes that the core team have already explicitly rejected.
(e.g. cookie-free authentication, removing unsafe GETs, requiring PHP 5,
etc.) "

I reiterate: you won't submit code to Trac, because you feel that you'll
be ingored by the devs w/commit access (a valid concern, certainly,
since your development priorities don't line up with Matt & Ryan's).
Shy of someone on the WP side of things keeping track (no pun intended)
of your code repo and commit logs, how is that code supposed to migrate
its way into the WP codebase?

> 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.
> 

I disagree. If you can come up with a POST-based solution that fits into
the user-friendly format the WP team is trying to maintain (easy admin
email links, etc.), then I'm sure they'd love to see your code.  The
nonce solution is obviously a complex one that, to me, seems to be
making the most of a bad lot.

- --
- ----------
Doug Stewart
Systems Administrator/Web Applications Developer
Lockheed Martin Advanced Technology Labs
dstewart at atl.lmco.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org

iD8DBQFETOxsN50Q8DVvcvkRApgkAJ4noulrsmC2KJf1uLgIQSkypwKL8ACfWYuq
8CCHj8c3TpP35SMhzSV5m1k=
=gAAq
-----END PGP SIGNATURE-----