Security Enhancements and Fixes in PHP 5.3.2:

• Improved LCG entropy. (Rasmus, Samy Kamkar)
• Fixed safe_mode validation inside tempnam() when the directory path does not end with a /). (Martin Jansen)
• Fixed a possible open_basedir/safe_mode bypass in the session extension identified by Grzegorz Stachowiak. (Ilia)

Key Bug Fixes in PHP 5.3.2 include:

• Added support for SHA-256 and SHA-512 to php’s crypt.
• Added protection for $_SESSION from interrupt corruption and improved “session.save_path” check.
• Fixed bug #51059 (crypt crashes when invalid salt are given).
• Fixed bug #50940 Custom content-length set incorrectly in Apache sapis.
• Fixed bug #50847 (strip_tags() removes all tags greater then 1023 bytes long).
• Fixed bug #50723 (Bug in garbage collector causes crash).
• Fixed bug #50661 (DOMDocument::loadXML does not allow UTF-16).
• Fixed bug #50632 (filter_input() does not return default value if the variable does not exist).
• Fixed bug #50540 (Crash while running ldap_next_reference test cases).
• Fixed bug #49851 (http wrapper breaks on 1024 char long headers).
• Over 60 other bug fixes.

Other nice improvements with this version include an (almost) up-to-date PCRE library (PHP 5.3.2 includes PCRE 8.00 with the latest version being 8.01) for regular expressions and a number of nice improvements to the filter extension both of which I use very regularly.

Do you, dear reader, keep up-to-date with PHP 5.3 (or 5.2) or are you stuck with steadily aging versions due to restrictive hosting providers?

Original Comment (#112314)

Hi Christian, thank you for the article. I would like to share a few comments if I may.

You seem to create the interface (ICrypter) almost without considering why an interface might be necessary. The article skirts around the reasons why an interface might be handy, instead preferring to mention that any class which implements a given interface must adhere to it (other than, “there will be an error!”). It is far outside the realm of a simple blog comment to delve into this subject so I can only suggest that readers take it upon themselves to build their own understanding of interfaces in general and in PHP. There is a lot of great information out there (for a recent insight into the subject, see http://www.brandonsavage.net/why-interfaces-rock/ ).

The article doesn’t state anywhere (though it will be mightily obvious when a reader tries to use the code) that MCrypt is required. Readers, see http://php.net/mcrypt.requirements and http://mcrypt.sourceforge.net/

With regards to the list of “supported algorithms from php.net” it would have been nice to have a source cited for reference. See http://php.net/mcrypt.ciphers

The remarks about Base64 encoding/decoding values seems a little odd. Why would you automatically want to do this? Your argument is that the encrypted value might not be URL-safe but that is only an issue if the encrypted value is being placed in an URL. If you do need to use the encrypted value in an URL then it would make more sent to encode the value only when it needs to be. Base64 is not the only available option for making such a value URL-safe (the functions urlencode and http_build_query to name a few).

It also puzzles me that you use the trim function on the Base64-encoded value since there will not be any whitespace present to be trimmed! The same goes for trimming the decrypted value since there may be important whitespace which really should not be trimmed.

The article itself does not elude to why this helper class might be useful. Your comments state there will be a follow-up article with a more practical demonstration but sure it would have been nice to include a very brief situation and code example where this type of encryption/decryption is of particular benefit.

I guess that is enough writing for a blog comment! Congratulations on publishing your first article on Nettuts+ and I look forward to your next ones.

The above is my comment, copied verbatim (with the links manually added since WordPress didn’t want to do that). Someone probably just missed by comment in the queue, so whether it appears on the Nettuts+ site or not remains to be seen. Either way the full comment is available here for reference.

Edit: between publishing this (at 8:22pm) and now (10:45pm) the comment got approved and is up on the Nettuts+ website. Guess I was just slightly too quick out of the blocks in republishing it here.

The great thing about the article is that its author (Glen Stansberry) considers each item in the list as rare and thought them noteworthy enough to write an article stating that we really should know about them (cf. rare tags that we shouldn’t know about!). I’m going to just come out with it, any HTML author worth their salt should be familiar with the vocabulary of the language. If the items posted in the article come as a surprise to you, perhaps it’s time to sit down and take a look at the specifications of your chosen HTML set (HTML 4.01, HTML 5, XHTML 1.0 and so on) which may not be particularly light reading but you don’t have to absorb everything in one go.

Note that this blog post uses the word tag and element for what might appear to be the same thing. However the tag is used to mark the start/end of an element. Given <p>Hello world.</p>, the opening tag is <p>, the closing tag is </p> and the paragraph element is everything including the opening and closing tags. On to the article itself: I’ll take some key points and give my own thoughts.

cite

All of us will be familiar with the <blockquote> tag, but did you know about <blockquote>’s little brother <cite>? <cite> allows you to define the text inside of the element as a reference.

Glen gets this right in his example since the cite element is meant to be used as a reference to the title of some work—not a person, animal, etc..

Good Example

Bad Example

optgroup

Glen says that, “The <optgroup> tag is a great way to add a little definition between groups of options inside a select box“. More concisely, I’d say that the optgroup simply groups options. The example given by Glen is not a correct usage of this element. The optgroup should be wrapping the options within the group, not merely placed before them as some kind of divider.

acronym

According to Glen the acronym element is, “a way to define or further explain a group of words.” Not true. The acronym element does what it says on the box: it is for acronyms (those being words formed from the initial letters of a name, e.g., NASA and laser). As for Glen’s example, “Twitter” is not an acronym of “Founded in 2006“.

address

This section of the article is a little vague and neglects to point out that the address element isn’t for marking up just any address. Its intended use is to provide contact information for the document (or a section of it). The contact information can be an email address, another web document, a postal address and so on. It is not intended to mark up any old address or contact details, just contact information for the current page/section.

ins and del

These elements are pretty straight-forward, they mark changes to a document. To make these elements useful, use their datetime attribute to denote the date and time when the changes took place.

label

Personally, without any evidence to back this up, I really don’t think that the label element is “one of the most forgotten” elements. It would be really disheartening if it was underused (to the point of being forgotten!). Almost every form that I mark up has thorough use of labels attached to the various input elements, I just figured everyone else also used them all of the time. Do you?

fieldset

This “nifty little attribute” (don’t you mean element?) groups fields into discrete sets—again pretty straight forward. However the example offered in the article isn’t particularly useful as there are a number of problems with it: e.g., the form element needs an action attribute and label elements should be used for the radio buttons and their associated text labels. Really, what’s the point of saying, “hey, you should know about this element!” and proceeding to give a bad example of using it?

abbr

This tag is itself an abbreviation and is intended to denote exactly that. For example, Mr.. Again, I’m not sure where Glen gets the impression that this element is rarely used (perhaps he can link me to his source(s)); perhaps underused, yes I’ll admit, but rare?

rel

This article is about HTML tags but here is an attribute which Glen considers, extremely useful. The article approaches this from the perspective of using the attribute as a hook for JavaScript and completely neglects to mention their perhaps wider use on link elements (to point to alternate, stylesheets, etc.) or in navigation (prev, next, nofollow).

wbr

I don’t think I have ever used the wbr element out in the wild having never had the need to specify a point at which some text may wrap where it otherwise wouldn’t. Will there be a spate of people rushing out to push this element into their documents? I doubt it. Glen also points to a page on quirksmode about the wbr tag showing that there’s not (at the time of writing) a single cross-browser way of implementing this kind of behaviour.

Others?

There are probably a bunch of other even more rare HTML tags that you should really know about (but perhaps will never or only rarely use): things like dfn, kbd, samp, var, to name a few.

P.S. Feel free to write your own “Comments on “Comments on “10 Rare HTML Tags You Really Should Know”"” because I’ve undoubtedly made my own mistakes above.

Starting off with a 43 byte image produced in image editor GIMP, he describes the process of removing bytes that aren’t particularly necessary with reference to the GIF specification. The end result is a working, fully transparent GIF image in only 37 bytes with two further size reductions producing a fixed colour (35 bytes) and an “I’m feeling lucky” colour (26 bytes).

Since it’s a Sunday, and I had nothing better to do, I also figured it was about time to delve into the guts of GIF images and see if I could come to the same conclusions that Paul had with regards to putting GIF on a diet.

Starting with a 43 byte, single-pixel, transparent GIF exported from Photoshop (sorry no GIMP installed on here) I followed the same process as Paul. Because I’m a PHP coder, that made sense to me to do the byte tweaking—sure a hex editor would do fine, but PHP is my chosen tool. Sure enough, thanks to the great instructions I was able to reproduce exactly the same results as Paul found and more importantly, now I know precisely how GIF images are constructed which is something I didn’t know (other than a basic idea of there being a header, image data, etc.) before today.

I also arrived at the same conclusion as Paul, after much byte-pushing and shoving. 26 bytes is as small as things are going to get (until someone more brainy than the both of us shares their own findings).

On the transparent GIF, Paul said, “So there you go, the tiniest transparent GIF possible (if you can make one smaller, let me know).” It’s not much but I did manage to eek out an extra byte from the 37 byte transparent image by removing one byte out of the LZW compressed image data portion of the file.

So there you go, the tiniest transparent GIF possible at 36 bytes. (Again, like Paul, do let me know if you can make one smaller!).

Another interesting tidbit gleaned from this experimentation is that the transparent image can be any pixel size up to 65535 square and still remain at the 36 bytes. Quite what one would do with a 4,294,836,225 pixel transparent GIF, I’m not sure.

If, for any reason, you want to get a hand on those 36 little bytes, here they are in two formats:

1. Hex Bytes:
   47 49 46 38 39 61 01 00 01
   00 00 00 00 21 f9 04 01 00
   00 00 00 2c 00 00 00 00 01
   00 01 00 00 01 01 01 00 3b
2. GIF Image: download here (it’s not much to look at!)

Anyhow, that’s enough frivolity for a Sunday evening. Back to watching the wildlife documentary on TV.

Nothing much at all has changed under the covers (literally, nothing) but the site has had a bit of a colourful facelift. Gone is the old, stark black on white super-minimal theme (though maybe not gone forever) and in is a shiny, new springy (not bouncy, in the flavour of Spring) landscape.

First, I’m no artist! That said, it was fun playing around in Photoshop all day instead of the usual code-editor. The drawing was done pretty much only with basic fills & vector masks so in theory it could be scaled up to any size. Being much more at home in Illustrator, it’s certainly nice to be able to do everything in vector: Pen tool, vector shapes, fills, layer styles, etc. beats pixel-pushing, for me at least.

For the inevitable time, somewhere down the line, when I change the theme again, here’s a wee screenshot of what it looks like.

Screenshot of Spring Theme at cowburn.info

Anyhow, tatty-bye for now.

There are a number of improvements which I’ll be making over the coming hours, days, weeks (or however long it takes) but they’ll be minor and you probably won’t notice.

Expect a little more regular updating (hah, me, regular updates, seriously?!) with various tidbits of PHP goodness and probably some more general webby nonsense, that’s the plan at least. Oh and if anyone is looking to hire a PHP developer then feel free to get in touch with me at [my first name]@[this domain] (peter, cowburn.info… you got that?). A bientôt !