Security at Wordpress

classic Classic list List threaded Threaded
99 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Security at Wordpress

Brian Layman
Before I submit some new information, I would like to know who recieves the
emails that go to the Security address.

It will affect my submission.
_______________________________________________
Brian Layman
www.TheCodeCave.com
 


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Security at Wordpress

Abhay Kumar
> Before I submit some new information, I would like to know who recieves the
> emails that go to the Security address.
You can assume that Matt and Ryan get them. I'm not sure if anyone
else gets them as well.

It does not, however, go out to any of the public lists (like this one).

> It will affect my submission.
I'm not sure what you mean by this but if you would withhold
information, I think that would be somewhat antiproductive, wouldn't
it?

*shrug*

--
Abhay Kumar
http://abhaykumar.net/
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Security at Wordpress

Ryan Boren
In reply to this post by Brian Layman
Brian Layman wrote:
> Before I submit some new information, I would like to know who recieves the
> emails that go to the Security address.

Myself and Matt are on point and a few others on the contributing devs
list get the emails too.  We wade through all of the cranks and posers
and forward the stuff needing attention to other regular contributors.

Ryan
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

RE: Security at Wordpress

Brian Layman
>Myself and Matt are on point and a few others on the contributing devs
>list get the emails too.  We wade through all of the cranks and posers
>and forward the stuff needing attention to other regular contributors.

Thank you Ryan.

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

RE: Security at Wordpress

Brian Layman
In reply to this post by Abhay Kumar
> I'm not sure what you mean by this but if you would withhold
> information, I think that would be somewhat antiproductive, wouldn't
> it?

Yes, and that will be the point of my not going into a lot of detail.

I am very disturbed by what I've found and there are repercussions far
beyond WP.

I can say that openly because I'll be assumed to be a crank and braggart.

The nonce solution that Owen proposed will adequately protect WP from my
approach.  Therefore I don't have to give a "how-to tutorial" of an exploit
that could be adapted to attack any non-compiled, non-nonced, non-customized
web application out there.

With the problem already solved, I need only provide an example url that can
be used to demonstrates the current vulnerability and prove that updated
blogs are protected.

Sorry if that bothers anyone, but I'm not budging on this one.  I'll likely
disclose more to Matt as I at least have read his blog for that last couple
years a know at least a little about his presented character.  Then he can
judge beyond that.  No offense, but the rest of you are just names at this
point. :)  
_______________________________________________
Brian Layman
www.TheCodeCave.com
 

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Security at Wordpress

Elliotte Harold
Brian Layman wrote:

> The nonce solution that Owen proposed will adequately protect WP from my
> approach.  Therefore I don't have to give a "how-to tutorial" of an exploit
> that could be adapted to attack any non-compiled, non-nonced, non-customized
> web application out there.
>

If it's really that bad, I'd suggest you publish it because no one
person is going to be able to fix all the web apps out there.

However, I suspect what you've discovered is the well-known problem
where GET is used for operations with side effects, a common flaw in web
apps designed by people who don't understand HTTP. While not as widely
known as it should be (which is why further publicity would be a good
thing) it's hardly a new attack. It's certainly known to
web-app-attackers everywhere. Being quiet about it only helps the black
hats who already know.

--
Elliotte Rusty Harold  [hidden email]
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
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Security at Wordpress

Ryan Duff-2
Elliotte Harold wrote:

> Brian Layman wrote:
>
>> The nonce solution that Owen proposed will adequately protect WP from my
>> approach.  Therefore I don't have to give a "how-to tutorial" of an
>> exploit
>> that could be adapted to attack any non-compiled, non-nonced,
>> non-customized
>> web application out there.
>>
>
> If it's really that bad, I'd suggest you publish it because no one
> person is going to be able to fix all the web apps out there.
>
> However, I suspect what you've discovered is the well-known problem
> where GET is used for operations with side effects, a common flaw in web
> apps designed by people who don't understand HTTP. While not as widely
> known as it should be (which is why further publicity would be a good
> thing) it's hardly a new attack. It's certainly known to
> web-app-attackers everywhere. Being quiet about it only helps the black
> hats who already know.
>

Nobody here is trying to fix all the web apps. Just one. Seriously, are
you done hyping whatever was found?

--
Ryan Duff
http://ryanduff.net
AIM: ryancduff
irc.freenode.net #wordpress #plogger
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Security at Wordpress

Robert Deaton
In reply to this post by Elliotte Harold
On 4/21/06, Elliotte Harold <[hidden email]> wrote:
> However, I suspect what you've discovered is the well-known problem
> where GET is used for operations with side effects, a common flaw in web
> apps designed by people who don't understand HTTP.

I'd like to pipe in with one possible reason (and most likely the
actual reason) for why this hasn't already been done in WordPress, and
the check_admin_referer() function was added as a band-aid to this
wound.

Think about every area in the admin panel where it makes sense to use
a normal link instead of a form button to do things. Let's take the
manage posts page, where the Delete action is one that uses GET to
carry out an action. Now, let's think about a cross browser way to
make this link POST its data instead, without javascript, because we
have to be kind to those who disable javascript. Oh, yeah, we can make
a form with a submit button, but that doesn't match all the other
links to do things on the page, and it'd look completely wrong if we
changed everything to submit buttons. Oh wait, we can style that with
CSS? You're leaving a few browsers out. So now what do we have? An
ugly interface, which will surely raise more eyebrows, to fix a
problem that has a different solution.

As far as I'm concerned, until there is a solution that makes sense
for this problem, I'm fine with abusing the HTTP standard.


--
--Robert Deaton
http://somethingunpredictable.com

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Security at Wordpress

Mark Jaquith
On Apr 21, 2006, at 7:30 PM, Robert Deaton wrote:

> As far as I'm concerned, until there is a solution that makes sense
> for this problem, I'm fine with abusing the HTTP standard.

As long as you can live with the consequences (or better, know enough  
to code around them), I think they're a necessary evil (if violating  
the HTTP standard is "evil").
--
Mark Jaquith
http://txfx.net/


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Security at Wordpress

Elliotte Harold
In reply to this post by Robert Deaton
Robert Deaton wrote:

> Think about every area in the admin panel where it makes sense to use
> a normal link instead of a form button to do things. Let's take the
> manage posts page, where the Delete action is one that uses GET to
> carry out an action. Now, let's think about a cross browser way to
> make this link POST its data instead, without javascript, because we
> have to be kind to those who disable javascript. Oh, yeah, we can make
> a form with a submit button, but that doesn't match all the other
> links to do things on the page, and it'd look completely wrong if we
> changed everything to submit buttons. Oh wait, we can style that with
> CSS? You're leaving a few browsers out. So now what do we have? An
> ugly interface, which will surely raise more eyebrows, to fix a
> problem that has a different solution.

There's a very good reason to make the DELETE action look different. It
is not side-effect free, unlike a lot of the other actions. The user
should see a visual distinction that clues them in that something is
different about this action they're abut to take. Having delete look
different is a feature, not a bug.

> As far as I'm concerned, until there is a solution that makes sense
> for this problem, I'm fine with abusing the HTTP standard.

It sounds like you're happy living in a house that will fall down when
someone leans on the wrong corner as long as you get to paint the
molding in just the right shade of puce. Frankly I find that attitude
incomprehensible, though lord knows I've seen enough of it over the last
ten years, even before JavaScript and CSS were invented. Perhaps it's
just how we're wired. Some people focus on the external appearance and
some focus on the internal architecture, and neither will ever
understand or comprehend the other.

The best you can hope for is a decoupling of the internal architecture
from the external appearance so that one can be changed without
affecting or limiting the other. To a large extent that's what CSS and
XForms attempt to provide on the Web. Unfortunately we're not all the
way there yet.

For me at least, until we are, I'm much more concerned about getting the
architecture right to provide the security, scalability, and robustness
I want out of a web app. I can live with a site where the delete link
looks a tad funky. I can't live with a site where any contributor or
commenter can delete a post they don't like.

--
Elliotte Rusty Harold  [hidden email]
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
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Security at Wordpress

Robert Deaton
\On 4/22/06, Elliotte Harold <[hidden email]> wrote:
> Robert Deaton wrote:
> There's a very good reason to make the DELETE action look different. It
> is not side-effect free, unlike a lot of the other actions. The user
> should see a visual distinction that clues them in that something is
> different about this action they're abut to take. Having delete look
> different is a feature, not a bug.

The delete action does look different, in its text, that's how I
distinguish it, and that's how every other user distinguishes it.
Ruining a beautiful UI is a bug, not a feature. To a user, does a
submit form button alert you of something? To me, it makes me wonder
which form I'm submitting in the absence of any input fields. For my
grandma, which do you think will make her come ask me a question? Why
we're disregarding a paragraph of the HTTP standard, or why some of
these buttons look like form submits?

> > As far as I'm concerned, until there is a solution that makes sense
> > for this problem, I'm fine with abusing the HTTP standard.
>
> It sounds like you're happy living in a house that will fall down when
> someone leans on the wrong corner as long as you get to paint the
> molding in just the right shade of puce. Frankly I find that attitude
> incomprehensible, though lord knows I've seen enough of it over the last
> ten years, even before JavaScript and CSS were invented. Perhaps it's
> just how we're wired. Some people focus on the external appearance and
> some focus on the internal architecture, and neither will ever
> understand or comprehend the other.
I think you need to come down off the high and mighty horse here for a
second and look around you. I am not a UI artist, its probably one of
the worst things I do, I write code. I find it hard to believe someone
finds an attitude of ignoring a little part of a standard
"incomprehensible," because if everyone lived by every little
standard, where would we be today? I'm happy living in a house that I
have personally helped code the refortifications for, knowing that the
house is not going to fall down just because we're making changes on a
GET request, when there is no other way to do it properly and maintain
our interface.

> The best you can hope for is a decoupling of the internal architecture
> from the external appearance so that one can be changed without
> affecting or limiting the other. To a large extent that's what CSS and
> XForms attempt to provide on the Web. Unfortunately we're not all the
> way there yet.

And like every standard we wish was adopted in its entirety for the
web, its going to be another 3-6 years before everything is ready and
works.

>
> For me at least, until we are, I'm much more concerned about getting the
> architecture right to provide the security, scalability, and robustness
> I want out of a web app. I can live with a site where the delete link
> looks a tad funky. I can't live with a site where any contributor or
> commenter can delete a post they don't like.

And with the code that Owen, mdawaffe, and I put together in the nice
nonces patch you see on trac, they won't be able to. Just because the
action is GET, doesn't mean it can't be secured, and this is part of
my reasoning for helping. You might be able to look with a god ugly
admin panel, but the hundreds of thousands of users who moved to WP
from some other blogging software would quickly move right back the
moment the admin interface looks like someone smeered a forms all over
where they don't belong. Normally, I'd agree with you, I'm an
architecture designer, I hate UI, but this is common sense.

If you're concerned about the security, I suggest you have a take at
the nonces patch on trac (and the forthcoming patches to change a few
things around). If you're concerned about the scalability, we've
already thought about that, thus the idea of computational nonces.

--
--Robert Deaton
http://somethingunpredictable.com

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Security at Wordpress

Alex King-3
In reply to this post by Mark Jaquith
It's not even a violation, it's merely choosing not to follow a  
recommendation. SHOULD != MUST.

Cheers,
--Alex King

Personal             Business               FeedLounge
http://alexking.org  http://kingdesign.net  http://feedlounge.com


On Apr 22, 2006, at 1:37 AM, Mark Jaquith wrote:

> On Apr 21, 2006, at 7:30 PM, Robert Deaton wrote:
>
>> As far as I'm concerned, until there is a solution that makes sense
>> for this problem, I'm fine with abusing the HTTP standard.
>
> As long as you can live with the consequences (or better, know  
> enough to code around them), I think they're a necessary evil (if  
> violating the HTTP standard is "evil").

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Security at Wordpress

Robert Deaton
On 4/22/06, Alex King <[hidden email]> wrote:
> It's not even a violation, it's merely choosing not to follow a
> recommendation. SHOULD != MUST.

Even better, now I really see no reason to change the current
behavior, if it is properly protected as code is being written to do.

--
--Robert Deaton
http://somethingunpredictable.com

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Security at Wordpress

Elliotte Harold
In reply to this post by Robert Deaton
Robert Deaton wrote:

> I think you need to come down off the high and mighty horse here for a
> second and look around you. I am not a UI artist, its probably one of
> the worst things I do, I write code. I find it hard to believe someone
> finds an attitude of ignoring a little part of a standard
> "incomprehensible," because if everyone lived by every little
> standard, where would we be today?

This is a not a little part of the HTTP standard. It is a major part of
the foundation. Throwing away the side-effect free nature of GET is like
  throwing away natural selection in biology. It's that critical.

> I'm happy living in a house that I
> have personally helped code the refortifications for, knowing that the
> house is not going to fall down just because we're making changes on a
> GET request, when there is no other way to do it properly and maintain
> our interface.

I am not at all convinced that the proposed fix will work. I think there
are more problems waiting to be found, and you're going to find them
sooner rather than later. Even if you get lucky and paper over the
problems with band-aids as they arise, you'll eventually be left with a
confusing mess of unmaintainable kludges that no one really understands.
There's no other possible result when you deliberately work against the
nature of your underlying protocol (HTTP).

> And with the code that Owen, mdawaffe, and I put together in the nice
> nonces patch you see on trac, they won't be able to. Just because the
> action is GET, doesn't mean it can't be secured, and this is part of
> my reasoning for helping.

It's not simply a question of security. There are other bugs and
problems waiting to bite. Caches, load balancers, web accelerators, and
more all depend on the side-effect free nature of GET. Even if you get
security right (and I'm not sure you have) there's a lot more to worry
about.

> You might be able to look with a god ugly
> admin panel, but the hundreds of thousands of users who moved to WP
> from some other blogging software would quickly move right back the
> moment the admin interface looks like someone smeered a forms all over
> where they don't belong. Normally, I'd agree with you, I'm an
> architecture designer, I hate UI, but this is common sense.

It's a lot easier to repaint a house than to rebuild its framework. I'm
not in the least bit convinced that a proper system that used POST for
non-idempotent side effect causing operations has to look bad. In fact,
I believe it can look perfectly dine. It might look different, but there
are many existence proofs that such sites are readable and usable. Web
surfers are not in the least bit confused by the metaphor of pressing a
button to take an action.

Oh, one more thing: there is one major development barreling down the
road getting ready to smack WordPress's current architecture upside the
head. Within a year, APP is going to be a sine qua non for blog
publishing; and that's totally dependent on a proper implementation of
GET, POST, PUT, and DELETE. The more right WordPress gets with HTTP now
the easier it's going to be to support APP in the near future. Of course
WordPress doesn't have to support APP. It doesn't even support Atom 1.0
yet. But if that's the road it takes, users are going to jump ship no
matter how pretty the UI looks. They won't even see the UI most of the
time, because they'll be editing in a rich client application that
requires APP on the server.

--
Elliotte Rusty Harold  [hidden email]
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
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Security at Wordpress

John Joseph Bachir-2

On Sat, 22 Apr 2006, Elliotte Harold wrote:

> Within a year, APP is going to be a sine qua non for blog publishing; and
> that's totally dependent on a proper implementation of GET, POST, PUT, and
> DELETE. The more right WordPress gets with HTTP now the easier it's going to
> be to support APP in the near future. Of course WordPress doesn't have to
> support APP. It doesn't even support Atom 1.0 yet. But if that's the road it
> takes, users are going to jump ship no matter how pretty the UI looks. They
> won't even see the UI most of the time, because they'll be editing in a rich
> client application that requires APP on the server.

What's APP? (i could't find it on wikipedia, therefore, it does not exist.
q.e.d.)


John
----
aim/yim/msn/jabber.org: johnjosephbachir
713.494.2704
irc://irc.freenode.net/lyceum
http://lyceum.ibiblio.org/
http://blog.johnjosephbachir.org/

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Security at Wordpress

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

John Joseph Bachir wrote:

>
> On Sat, 22 Apr 2006, Elliotte Harold wrote:
>
>> Within a year, APP is going to be a sine qua non for blog publishing;
>> and that's totally dependent on a proper implementation of GET, POST,
>> PUT, and DELETE. The more right WordPress gets with HTTP now the
>> easier it's going to be to support APP in the near future. Of course
>> WordPress doesn't have to support APP. It doesn't even support Atom
>> 1.0 yet. But if that's the road it takes, users are going to jump ship
>> no matter how pretty the UI looks. They won't even see the UI most of
>> the time, because they'll be editing in a rich client application that
>> requires APP on the server.
>
> What's APP? (i could't find it on wikipedia, therefore, it does not
> exist. q.e.d.)

I believe he means Atom Publishing Protocol [1,2]

At least thats all i could find that made sense in the context of his mail.

[1] http://www.ietf.org/html.charters/atompub-charter.html
[2] http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt

westi
- --
Peter Westwood
http://blog.ftwr.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFESof2VPRdzag0AcURAt7pAJ9CjxETKmIFH5w9B/znNupyEO2gKgCfXhTw
hvZtb1e4WMzlEyabkfNDQMg=
=7FgA
-----END PGP SIGNATURE-----

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: POST vs. THE WORLD

Matt Mullenweg
In reply to this post by Elliotte Harold
Elliotte Harold wrote:
> This is a not a little part of the HTTP standard. It is a major part of
> the foundation. Throwing away the side-effect free nature of GET is like
>  throwing away natural selection in biology. It's that critical.

Most apps on the web break this, and they seem to be doing fine. As are we.

> It's not simply a question of security. There are other bugs and
> problems waiting to bite. Caches, load balancers, web accelerators, and
> more all depend on the side-effect free nature of GET.

No they don't. When they don't recognize how GET is used outside of
ivory towers, there has been a huge outcry and they've been fixed, as
with the Google Web Accelerator.

> Oh, one more thing: there is one major development barreling down the
> road getting ready to smack WordPress's current architecture upside the
> head. Within a year, APP is going to be a sine qua non for blog
> publishing; and that's totally dependent on a proper implementation of
> GET, POST, PUT, and DELETE.

Something I think will hinder its adoption, if it remains so enamored
with HTTP verbs. There was recently a discussion about relaxing the
restrictions to allow most APP functionality through POST, though I
didn't follow where that ended up.

(Tangent.) There has been a disturbing disconnect the past year or so
between the real world and people writing standards and languages.
Trading convenience and backward compatibility for academic perfection
is the reason things like PHP5 and XHTML 1.1 have been abject failures
in the marketplace. (Single-digit adoption rates.)

> The more right WordPress gets with HTTP now
> the easier it's going to be to support APP in the near future.

I don't see any connection.

BTW, it has already been demonstrated that switching everything to POST
would not solve the problem as completely as secure nonces would as you
can still cross-domain submit forms. Therefore it would be a lot of work
that would, at best, please a few pedants and bring us into SHOULD
compliance with a 7+ year old standard no one else supports either.

--
Matt Mullenweg
  http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Security at Wordpress

Elliotte Harold
In reply to this post by Peter Westwood
Peter Westwood wrote:

> I believe he means Atom Publishing Protocol [1,2]
>

Correct. Sorry. My bad. I should have spelled that out.

--
Elliotte Rusty Harold  [hidden email]
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
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Security at Wordpress

Owen Winkler
In reply to this post by Elliotte Harold
Elliotte Harold wrote:
> I am not at all convinced that the proposed fix will work.

You are welcome to produce code that you feel will work better.

WordPress has always been a "put up or shut up" environment.  If you
feel that you can produce more satisfying code for the WordPress
userbase, we'll adopt it when when that proves to be true.

I think your mission is folly, but who knows?  Users might actually
enjoy crappy-looking UI if you are able to explain to them why it's
better, though you're not doing much convincing here.

All of this academic discussion at the expense of productivity is a
bore.  I think people understand the issues pretty well now.  Let's move on.

Owen
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Security at Wordpress

Andrew Krespanis
On 4/23/06, Owen Winkler <[hidden email]> wrote:
> Users might actually enjoy crappy-looking UI if you are able to explain to them why it's
> better, though you're not doing much convincing here.

The "ugly UI" reason for avoiding POST is as silly as the "MD5 vs.
dictionary" reason for wanting to use a more processor intensive hash
for nonces.

form.btn {display:inline}

Done. Can we move away from that excuse now or am I going to have to
do a full html mockup with <input>s inplace of all action-performing
links to prove my point?

I'm not siding with anyone here regarding GET vs. POST, merely
pointing out this UI excuse is lame. All modern browsers now support
styling of form elements (even Safari and Opera; though they're user
options) and regardless, a standard HTML form button is just a text
string with a border and background... it's not the end of the world
people! :P

-Andrew

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
12345