Late yesterday afternoon the PSR-9 and PSR-10 drafts were moved into master on the php-fig/standards repository, moving them along to the next step and to get the wider perspective of the main PHP-FIG group’s opinions on it.

What are PSR-9 and PSR-10, you ask? Here’s a brief summary so far:

At the end of last year (2014) Lukas Smith made a proposal to the PHP-FIG group for a standard that would make reporting security issues with PHP projects and libraries a much more structured thing. The general idea is that a standardized document (or documents?) in a project’s repository would provide information about current and past security issues in a well-defined structure that could have some automated tooling around it. Much discussion was had around what the proposal actually entailed and how it would integrate with the goals of the PHP-FIG process. As work progressed on it, a few others besides Lukas came on-board to help flesh out the standard and work out the kinks, including myself.

It wasn’t long before we realized that, while having a standardized method for reporting vulnerabilities was good there also needed to be a way to discover this documentation for a given project (more than just a “look for this file” kind of thing). So, the original PSR-9 was split, giving us the security advisory reporting standard (PSR-9) and the security disclosure workflow (PSR-10) to make discovery of the reports easier. Both PSRs have received the votes needed for entrance and consideration and, as I mentioned, work is moving forward on them in the wider PHP-FIG group.

So, what are the standards? Well, I’m not going to just copy and paste from the documents (you can find those here if you’re interested) but I will give a quick overview of what they contain and their goals.

Note: these standards are by no means complete so this information is a bit subject to change. I just wanted to share their current state though.

PSR-9

The main goal of the PSR-9 standard is to provide structure around the documentation a project provides to the wider community around security vulnerabilities that have been found (and fixed) and those that are still pending. The idea is that any given user could look at the document and have a security-centric view into where the project currently stands. Right now, with the exception of those participating in the security-advisories database, most projects make it a bit of a run around to try to figure out what issues have come up and what problems have been fixed. Sometimes it’s reported in the Changelog, other times it’s in the mailing lists and other times you just have to know what to search for in the project’s issue tracker to get the list. This PSR-9 aims to eliminate a lot of this hassle and give a single source for the information.

The security-advisories database has provided a great start around this same kind of information but with PSR-9 the burden of reporting this information falls on the project, not a single source. We’re not aiming to replace that database by any means, though. We just want to empower the projects to share the information in a vetted, well-defined way. The PSR-9 proposal provides a lot more context around the security issues too.

This information includes:

• An entry for each vulnerability that includes a short summary, published date, link to more information and a unique reference ID
• CWE and/or CVE information, if possible (not all vulnerabilities are reported as CVEs)
• What versions the issue affects
• Current status of the issue
• A description of the remediation if resolved
• A low/medium/high severity rating based on the impact to the project’s users

We discussed the versioning of this resource (multiple files) so new vulnerabilities could be added and a “history” of sorts could be tracked over time but nixed that idea in favor of a single file that would just evolve over time. A lot of this vulnerability metadata is similar to information currently reported by other projects, so it’s not too far of a stretch to see this dropped into a structured, easy to find document. Speaking of which, this brings me to the next proposal…

PSR-10

Where PSR-9 is about the structured vulnerability list, PSR-10 is about the discovery of said document. As we worked through the original PSR-9 ideas, we found that reporting the vulnerabilities was one thing and having a structured way to access the documentation was another. One is more about the concrete thing, the document, and the other is more around process.

The PSR-10 proposal isn’t quite as fleshed out at the moment, but there are a few main points that give us a starting place:

• The document that represents the data for a project’s PSR-9 disclosure should live somewhere the project can directly reference it, such as the project’s website or other documentation page. This is the ideal place as it removes ambiguity around which version of the document is the “master”.
• Projects may opt to have the source in their version control system with the caveat that it should be publicly facing (not require a checkout) and that the “master” branch should be visibly documented.
• Projects would be allowed to split up the information by the version number of the release but, as this can get much more confusing quickly, it would need to be well documented

We discussed just having the document in the version controlled repository of the project, but this leads to other issues including the definition of which branch is the “master” for the document and how to deal with private repositories (remember, the goal is public disclosure). Ultimately is was worked out that a public-facing resource was the best option. One suggestion includes a custom “link” tag with a relation value of “php-vuln-disclosures” to help with automated discovery.

We’re all excited about these two standards moving forward and look forward to the feedback the wider PHP-FIG group can provide around them. Things will be developing a bit more quickly now (it was slow going mainly because of holidays and other personal issues around the end of the year) and our hopes are that these two standards can evolve and be worked out as soon as possible.

Keep an eye on the proposals as they evolve. I’d love to get any feedback on them or suggestions based on your own experiences that would help make things even better.

Seems as though I got tagged by Matt Turland with this whole “Seven Things” viral blog entry stuff. Gotta keep it alive, so here’s my seven things:

• My degree is in art – yes, that’s right…further proof that no matter that you get your degree in, you can find something out there that makes you truly happy to do. I loved my classes and I still love art (I consider a trip to a museum for the day time well spent) and I’m always on the lookout for great design, not just in web sites but in the art world as a whole. Oh, and I hated normal history back in school but for some reason art history was completely different – I couldn’t get enough.
• Back in high school, at one point I could play six different instruments – while my main instrument was the trumpet, I could also play: trombone, tuba, french horn, clarinet and saxophone. I was in the band at my school and I managed a “free period” during a class time one year which I used to teach myself the other instruments. I also helped the drums come up with cadences for our marching band, though I only played the marching bass so I’m not sure that really counts 🙂
• PHPDeveloper.org started out as a weekly thing – when I first started the site back in college, I didn’t know nearly as much about the PHP community (or the people in it) as I do now. I picked up on a few things and made a post about them when I could. If you want to see how far the site has come, ask archive.org to show you the past. Hmm, not exactly sure when I made the switch from blue to red… The original machine it was hosted on sat in my dorm room – an old 486DX/100 (a Compaq I think?) and I used the ods.org dynamic domain service to map it to the domain.
• My wife and I met on Match.com – Yup, that’s right…we could be on one of those cheesy commercials. I had moved back to Dallas after finishing at school and she moved down from New York (she’s originally from Houston, though) and posted her profile out there. She’d gone on a few dates but hadn’t had much luck. Oddly enough, when we hooked up (she told me this later) I was her “last shot” on the site – if it didn’t work with us, she would close her account. I guess I fooled her enough and one thing led to another and we’re here, married with our little kiddo.
• I have an unhealthy fascination with pens – I can’t help it, I’m a pen snob. Not quite sure where it came from (maybe all those art classes) but there’s very particular requirements that I have for the pens that I use. It’s not about the price, either. Some of those costly pens don’t write worth crap anyway. I’m a fan of the fine point – the finer the better, at the largest 0.5 – and I love nothing more than the scratch that they make on paper. If you’re going to use anything larger than a 0.5, you might as well just use a magic marker. They look about the same. One of my current favorites is the Parker Jotter though the Uni-Ball pens come in a close second.
• Theres an art geek living inside of me – ever since I can remember, I’ve always been an art fan. I used to enjoy the field trips to the museums and liked learning about the different artists and styles. When I went to college and got to indulge in all of that, it was great. I’m still that way even though its a bit more limited these days. I still paint (though not as much as I’d like to) and like to sketch when I can. I’m also an architecture nut – my dad and I had an extra afternoon in Phoenix so I dragged him out to see Taliesin (one of Frank Lloyd Wright’s residences and art school) where we took the full tour. FLW is one of my favorite architects followed closely by I.M.Pei (what can I say, I’m a modernist). I enjoy architecture so much that, after I lost my first job out of college, I came *this* close to leaving the whole programming thing behind and going to architecture school. I was offered the job I’m currently in pretty quickly, though. I still try to make trips when I can down to the Dallas Museum of Art and the museums over in Ft. Worth (like the Kimball and the Modern).
• I’m an early riser – Seems like this is more and more of a rarity these days (especially in the industry I’m in) but I have no problem getting up before the sun is up and doing things. I currently get up for work at 5:30am and am in the office by 6:15-6:30am working away. Partly I do it so I can leave the office a little earlier, but I also do it because that’s the only time that its easy to get things done. There’s less people up (slackers – hehe) so there’s more time to relax or write posts for PHPDeveloper.org or read or whatever. I just grab a cup of coffee and enjoy the time to myself for a bit. So, all of you late sleepers out there – keep on late sleeping! I’ll be the one enjoying the peaceful sunrise, warm coffee in hand.

So, here’s the hard part – I’m not sure who else has been tagged for this, but I’m supposed to choose a few other people and pass the virus, er theme on to them – here goes:

• Chris Hartjes – CakePHP wizard and creator of the excellent Framework Apocolypse tshirt
• Timothy Boronczyk – creator of the uberpastebinsite Pasteninja
• Daniel Cousineau – fellow Texan and all around party animal
• Jason Ragsdale – local PHPer who, oddly enough, I only really taked to the first time at the Microsoft Web Developer’s Summit despite him being majorly involved with the Dallas PHP Users Group
• Paul Jones – head honcho behind the Solar PHP framework project
• Alison Gianotto – just because I like to give her a hard time

And, of course, the rules to pass on:

• Link your original tagger(s), and list these rules on your blog.
• Share seven facts about yourself in the post – some random, some wierd.
• Tag seven people at the end of your post by leaving their names and the links to their blogs.
• Let them know they’ve been tagged by leaving a comment on their blogs and/or Twitter.

So, the latest issue of php|architect is out (Sept. 2005) and my article is in it. It was a last minute inclusion as a result of a conversation with Marco, but I think it turned out well. Unfortunately, I can’t reproduce the contents of the article here to share them with you all. The topic was trackbacks – what they are, why they are, who uses them, and are they really needed.

In the research that I did for the piece, I dove into the technology, halfway expecting to find some little hidden gem of a protocol that could really be used and extended in some fun ways. Unfortunately, all I found was a technology that seemed to be a “one hit wonder” in the blog world. For those that aren’t sure what I’m talking about when I say “trackbacks”, think of most of the blogs out there (like this one) that have those separate URLs for their trackbacks on their post. The key here is that distinct URL – with it, someone posting on their own blog that has to do with the info on the first blog can zip a little “hey, thanks for the information! I linked to you!” on the original blog. They can help for things like finding the original source of information, and are a handy, simple way to link between pages/blogs with similar information. That’s about where it ends, though. The protocol they use is really nothing more than a glorified HTTP call, and they can be submitted by anyone. There’s no built in security model, no filtering – not much of anything built into the spec. Several pieces of software (like WordPress) have taken steps to try to curb some of the issues with trackbacks, but, in the end, it’s almost not worth it.

Look at trackback spam, for example. In my research, I plugged the word “trackbacks” into google in an attempt to get any and every kind of information on the subject. What did I find? Mostly links to blog posts on various sites that talk about turning off trackbacks. As most people have found, a lot of times, it’s more trouble than it’s worth to leave them on. They usually occupy the same area that the comments for a post reside in, so they clutter things up immensely when someone abuses them. It’s the same kind of situation as comment spam, except a lot harder to catch.

So, if you asked my opinion on trackbacks and their future on the internet (and more specifically blogs), it wouldn’t be a positive one…that is, unless someone out there can give me a good, valid use for them…

Time for a “misguided projects” rant – better buckle up, it’s going to be all over the place.

We’ve all been there – working happily away on our project with the timelines in place, thinking that things are going to be just fine and dandy. Then, the malevolent spirit of feature creep (let’s call him Steve) comes in, sneaks into the safety that is your cube, and shakes things up a bit. Steve’s only goal is to come in and make you freak out. No, Steve doesn’t have to be a person, but he’s all too real for too many developers out there. They come into the project, look over the spec, and think to themselves “this doesn’t look so bad…I can just use this here and that there”. They place the sheet back on the table, look around at all of the other happy faces and think maybe, just maybe, this time things will be different.

Well, not if Steve has anything to say about it. No, I’m not talking about a specific situation here – I’m just blowing off some steam. Between dealing with other companies/other developers that just don’t understand your deadlines and having a Steve on your back, development just isn’t something to be taken lightly.

Have you ever started working on something, gotten about 30 minutes to an hour into it and realised that there was a much better way to do it? Sure, some people immediately jump to the “well, you should have planned more” argument, but sometimes, that’s just not good enough. There’s those out there that will tell you that there’s only “One Best Way” to do things when it comes to web programming (or just programming in general). So, who else out there wants to help me prove them wrong? Sure, there are best practices and all, but that doesn’t mean that there’s no room for flexibility. Too many developers are loosing that touch, it seems – they look at code, see that it’s a pretty dang good way to do things, and just keep using it over and over until something better comes along. Does this mean that you should rework every bit of code that you come across to make it better? Of course, not – that can only lead to a wee bit of insanity (and possibly a visit from Steve).

Instead, look at what you’re working with – whether it’s your own code or someone elses, and see if there are any glaring mistakes. Unfortunately, a lot of the PHP code that’s out on the repositories (save the stuff that people charge for…well, okay, some of that too) is “newbie code”. Not all of them are new to the language, but unless you get a little further on in development years, there’s just some things that you miss. No, I don’t have a particular list in mind of “Top 10 Newbie PHP Mistakes” (maybe I should make one), but most of the more seasoned developers out there know what I mean.

Maybe we should start a list in the comments….hmm….any takers?

*whew* okay – that’s enough for now. Sorry for my meandering mind, it takes me for rides too sometimes. Anyway, if you have any comments or want to contribute to the “Top 10” idea, leave some comments below…

Alright, well – I’m going to give this a try and see how useful it really is. I figure that being able to express things here (without having to worry too much that people won’t think it’s news) will be a nice change. There’s been a lot going on in the PHP community – really the web as a whole – and having more of an open forum to express some ideas about it all will be a nice change of pace.

Posting the news on PHPDeveloper every day (well, okay, maybe not every day, but I try) is almost like having a second job. Thankfully, my current employer seems okay with the fact that I spend 30-45 minutes in the morning gathering and posting news. I finally wised up to the benefits of having an aggregator do a lot of the work for me (previously, I’d just be visiting each and every site), though there are still some sites that are stubborn about the whole “RSS revolution” that’s been going around. It’s all in how you think about it, really – whether you’re protective of the content on your site, or whether you want it to be out there in every way, shape, and form for your users. I love all of the new uses that have come around with RSS – everything from the podcasting that’s taken over to the simple ability to make a search results page something you can feed into an RSS aggregator and see when there are new results for that search. It’s customiztion on a whole new level.

And where does PHP fit into all of this? Well, now, more than ever, PHP is proving that it can scale and adapt to whatever the community throws at it. I even found a PEAR class today that takes an MP3 file and converts it into a viable torrent file – perfect for the podcasters out there that are looking for possible ways to reduce bandwidth issues. And with things like PEAR 1.4 on the way and the power behind PHP5, things are changing dramatically.

I’ve seen the other side of things as well with my operating of the AjaxDeveloper.org site – highlighting more of the client-side of things, talking about Ajax and related issues, but not necessarily sticking to them. I’m enjoying seeing the other side of things as well, and I get more of a feeling of being on the forefront of something that has the possibility to change the way the web works. Of course, it all needs something to provide the power on the backend, and that’s where PHP comes in. Flexible, simple to use, and running with years of development behind it, it really does seem to be the answer to a lot of developer’s prayers. One part PHP + one part Ajax = quite a few of the “Web 2.0” applications that I see coming out…

Anyway, I suppose that’s enough for this first entry – let me know what you think, both of this blog and of PHPDeveloper.org (and AjaxDeveloper.org if you’ve been there too).