[wp-hackers] Security at Wordpress

[Doug Stewart]

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

Elliotte Harold wrote:
> 
> So far they're small things that I need for my site. I see no chance any
> of these would be adopted into the core code base. Some of them
> shouldn't be.
> 

One of us is writing to the wrong list, then.  If they're general
purpose patches that would benefit the community at large, then submit
'em.  If they're not, then it would probably be best to keep the
situation as it was before this thread: with you making changes to your
own code and keeping quiet about it elsewhere, as the benefits are
effectively nil for anyone else.

> Forking is a core principle of open source development. One of the
> reasons we write open source (better yet, free) software is precisely so
> that developers who have different needs or who have different visions
> can explore different options.
> 

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

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

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.

> One problem I have with working on the main trunk is purely practical. I
> am much more productive when using a source code control system of some
> kind, be it CVS or Subversion. Since I'm not a committer on WordPress
> (nor would I expect to be one) writing anything more than a trivial
> patch, requires me to setup my own repository starting from the current
> head. Once I've done that, I'm 50% of the way to a fork anyhow.
> 

If that's your bailiwick, hey, go nuts. Local cvs repos are trivial to
set up and maintain (basically, running 'em as if they were RCS repos
for all intents and purposes), but if you want to go to the trouble of
setting up an SVN instance elsewhere and code wrangling others'
submissions, have fun.  Just don't whine that your asynchronously
developed patches haven't been magically backported to WP core.

'Course, this is all just my 0.0162377202 Euros.

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

iD8DBQFETN4eN50Q8DVvcvkRAsgsAJ9lVhMMRAwAu3eUGJICXIPvKhK/lACeLmA4
yBZFirIDObNfTzljqchk+eo=
=G+LM
-----END PGP SIGNATURE-----