IMO

After a somewhat long sabbatical, I'm energized about rebooting the Telaen Project.

Partly, this is due to jaguNET migrating to using Dovecot for both POP3 and IMAP, and the realization that an upgraded webmail system would be the perfect compliment. Now for sure, Telaen is a great PHP-based webmail system, and, in fact, has served (from what I can tell) as inspiration and source for numerous other webmail systems as well (such as T-Dah Webmail, for example), but I had let it lay fallow for quite awhile and, well, it's showing its age. And to be honest, except for some of the larger, and more complex and dependency-ridden offerings out there, it seems that no real PHP webmail packages are being actively developed.

So, I've gone ahead and create the telean_1.x branch and master on the git repo will be the source of Telaen 2.0 development. In no particular order, I plan the 2.0 version including the following:

• Removal of PHP4 support and baselining PHP5.3 at a minimum.
• Faster indexing by utilizing sqlite3 instead of PHP arrays
• Better and more complete IMAP interaction
• Better SPAM handling, especially related to auto-population of the Telaen internal SPAM folder (right now, if the user creates a real, IMAP SPAM folder, Telaen gets awfully confused)

Over the last several weeks, much copy has been created over the lack of civility in various communities: Open Source, gaming, etc...

Now, I'm not a gamer, but I am a person seriously involved in the FOSS community, and I see some parallels between the issues involving all of these communities, and I have some thoughts and possible insights to share.

First of all, what I see is a significant lack of civility. Not only in what is being said, but also in how it is being said and, almost most unsettling of all, that if there is a way for someone's statements to be misconstrued in the most unattractive/unpopular/controversial fashion possible,  that's the way it will be seen (in other words: the other party doesn't receive the benefit of the doubt: you must prove that you are not an asshole; it's not assumed that you aren't).

Now certainly the anonymity of mailing lists, twitter, etc all help in that, but mostly, IMO at least, it's also due to people forgetting that there is a real live human being behind that Email address or twitter handle

The second issue I see is that there is no longer a desire to have a discussion or a conversation, per se, but rather it's a contest, a war, in which the sole desire is to win, and make the other side lose. In doing so, we don't listen, instead we are planning and plotting our response. And, because winning at all costs is important, the ends justifies the means. If we have to create strawmen, well, as long as we win (or, at least, they lose), that's OK. Of course, in matters that we have deep feelings and concerns for, it's hard to keep emotions out of it. After all, if someone calls my kids stupid, I will "fight" to ensure that no one walks away with the mistaken impression that somehow that position is correct, or right, or warranted. But very few things are really that personal, we just make them so.

Closely related to the strawmen method noted above, is that in most discussions other "baggage" (for lack of a better term) is brought in. This baggage is only remotely related to the discussion at hand, but it is a powerful, polarizing artifact, and serves to either focus the discussion on that issue or, most of the time, implies that being for one position implies being against another (which you would not agree to at all). For example, in a recent "discussion", I noted that "actions have consequences". Certainly this is something that we can all agree with, right? After all, our legal system is based on it, parents instill this concept to their children, religions are based on it, etc... But, that simple statement somehow implied that I was OK with "blaming the victim". So instead of simply seeing and understanding what I said, instead a position was forced upon me, a position that I would never take. And I had to prove that I was not a "victim blamer".

It is sad when activities which started off as, and are supposed to be, fun and enjoyable degrade into "contests" and battles in which people have to "expect" harassment, ridicule, threats, etc. All these technologies were supposed to bring us together, not provide ammunition and resources for dipwads  and psychopaths to destroy one's happiness and life. If you are involved in a community, it is your responsibility to make sure that poisonous people are not allowed. That's why I am so proud of the communities we've created at Apache, after all, our unofficial motto is Community Before Code. We aren't perfect, to be sure, but I think we have some insights that other communities could benefit from.

Reading over http://paste.lisp.org/display/143864, I am surprised just how wrong the entire post is.

The gist of the post is that the Shellshock bug is not bash's fault, but rather, in this argument, the fault of Apache and other facing programs in not "sanitizing" the environment before it gets into bash's hands.

Sweet Sassy Molassy! What kind of horse-sh*t is that?

As "proof" of this argument, pjb uses the tired old excuse: "It's not a bug, it's a feature", noting that bash's execution of commands "hidden" in environment variables is documented; But then we get the best line of all:

The implementation detail of using an environment variable whose value starts with "() {" and which may contain further commands after the function definition is not documented, but could still be considered a feature 

As far as outlandish statements, this one takes the cake. Somehow, Apache and other programs should sanitize magical, undocumented features and their failure to do so is the problem, not that this magic is undocumented as well as fraught with issues in and of itself.

Let's recall that if any other Bourne-type shell, or, in fact, any real POSIX-compliant shell (which bash claims to be), were being used in the exact situation that bash was being used, there would be no vulnerability. None. Nada. Zero. Replace with ksh, zsh, dash, ... and you'd be perfectly fine. No vulnerability and CGI would work just fine. And also let's recall, again focusing on Apache (and all web servers, in fact; It's not just Apache is affected by this vulnerability but any web server, such as nginx, etc...), the CGI specification specifically makes it clear that environment variables are exactly where the parameters of the client's request lives.

Also, let's consider this: A shell is where the unwashed public interfaces with the OS. If there is ANY place where you don't want undocumented magic, especially in executing random code in an undocumented fashion, it AIN'T the shell. And finally, the default shell is also run by the start-up scripts themselves, again meaning that you want that shell to have as few undocumented bugs... *cough* *cough*, sorry "features" as possible, and certainly not one's that could possible run things behind your back.

Yes, this bug, this vulnerability is certainly bash's, no doubt at all. But it also goes without saying that if bash was not the default shell (/bin/sh) on Linux and OSX, that this would have been a weaker vulnerability. Maybe that was, and is, the main takeaway here. Maybe it is time for the default shell on Linux to "return" to the old Bourne shell or, at least, dash.

UPDATED: Sept 29, 2014 with current OSX Bash patch

First of all, when this was first found, we were looking for a cool name... It was found.

Anyway, as noted here [https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/]  the shellshock vulnerability is pretty nasty. What's interesting is that, in general, the *BSD variants aren't as vulnerable as *NIX platforms, simply because the default shell on BSD is still the Bourne shell (the "real" sh) and not Bash itself (On Linux and OSX, for example, /bin/sh is either a copy or link to /bin/bash).

Even so, BSD systems are not immune by any stretch of the imagination, since one attack vector is via web-servers and CGI, and it's likely that there are numerous CGI scripts that require/use Bash. So no matter what, patch your systems.

Continue reading "Shellshock"

With all the buzz around iOS 8, I decided to take the plunge. I went ahead and upgraded an iPad2, iPad Mini and iPad Retina. I didn't upgrade any iPhones.

Why?

I'm not crazy! I need my iPhone to work! 

Anyway, so after several days of using iOS 8 on these devices, I can come up with a singular conclusion: It Is Dog Slow.

I mean really, frustratingly slow. Like I could use a stop-watch to time how long it takes apps to open (even those specifically upgraded for "iOS 8 compatibility" or to get back to the home screen when the Home button is pressed. Once in the apps, things are better, but no app at all feels peppier under iOS 8, except for maybe Safari.

Plus, a lot of apps, like Scribd, don't even open up and just die. 

Continue reading "iOS 8"