I have had quite a few people and companies here in the Portland-area ask about OpenID and how they can implement it on their site. The people I talked with always wanted to just do it right then and there.
In the spirit of just-getting-it-done, I’d like to announce the first (of what I hope are many) Mash Pit: OpenID events. The goal is to have a time for application developers and site operators to be able to talk with people active in the OpenID community to help them actually hack through what it would take implement OpenID on their site. We’re using the Mash Pit model because we want to encourage as much hacking as possible.
You can read more about the first event in Portland, OR here:
When: Wednesday, January 17th, 2007 – 4pm until we’re done
Where: Portland, OR – JanRain world headquarters
Why: Because people keep asking to learn more about OpenID so we figured we do them one better and show them.
Who: You! And anybody that wants to learn more about OpenID.
RSVP: Please let us know if you’ll be attending so we can have enough grub on hand!
Anybody is welcome to come … Also, feel free to start your own Mash Pit: OpenID events in your own cities … Don’t be shy about reaching out to the email@example.com mailing list to find OpenID brainiacs to help with your event … I’m pretty sure you can talk David Recordon into a visit to just about anywhere …
Thanks everybody and hope to see you in Portland on 1/17!
“PHP security holes have a name — quite often it was Stefan Esser who found and reported them. Now Esser has quit the PHP security team. He feels that his attempt to make PHP safer “from the inside” is futile. Basic security issues are not addressed sufficiently by the developers. Zeev Suraski, Zend’s CTO of course disagrees and urges Stefan to work with the PHP development team instead of working against it. But given the number of remote code execution holes in PHP apps this year, Esser might have a point. And he plans to continue his quest for security holes in PHP. Only that from now on, he will publish them after reasonable time — regardless if a patch is available or not.”
Zeev Suraski wrote in to protest: “I’m quoted as if I ‘point fingers at inexperienced developers,’ and of course, there’s no link to that — because it’s not true! The two issues — security problems in Web apps written in PHP, and security problems in PHP itself — are two distinct issues. Nobody, including myself, is saying that there are no security problems in PHP — not unlike pretty much any other piece of software. Nobody, I think, argues the fact that there have been many more security problems at the application level, then there were at the language level. I never replied to Stefan’s accusations of security problems in PHP saying ‘that’s bull, it’s all the developers’ fault,’ and I have no intention to do it in the future.”
PHP is a powerful and flexible tool. This power and flexibility comes from PHP being a very thin framework sitting on top of dozens of distinct 3rd-party libraries. Each of these libraries have their own unique input data characteristics. Data that may be safe to pass to one library may not be safe to pass to another.
A recent Web Worm known as NeverEverSanity exposed a mistake in the input validation in the popular phpBB message board application. Their highlighting code didn’t account for double-urlencoded input correctly. Without proper input validation of untrusted user data combined with any of the PHP calls that can execute code or write to the filesystem you create a potential security problem. Despite some confusion regarding the timing of some unrelated PHP security fixes and the NeverEverSanity worm, the worm didn’t actually have anything to do with a security problem in PHP….
Looks like a really good time for the PHP Security Consortium to be created.
I mean with members like:
- Ammar Ibrahim
- Andi Gutmans
- Ben Ramsey
- Christian Wenz
- Daniel Kushner
- Ivan Ristic
- Marcus Whitney
- Paul Reinheimer
how could they go wrong… good luck guys.