Tag: opinions

Security Tools

There was this security announcement today: Another time a Symantec product does not what it’s supposed to and actually executes UPX-Packaged .EXE-Files to find out whether they conain malicious code or not.

This is certainly not the best way to accomplish that…

So this is anoter point why I’m no fan of security software in place of user education (and regular flaw-patching): Such software creates a false sense of security (“should I click here? Oh well.. I have my NAV running, so nothing’s going to happen”) and may even open bigger holes when itself is not secure.

As it stands now, a educated user without NAV that receives an email with a prepared UPX-packaged .exe will just delete the file and be happy.

An educated user with NAV will delete the file too, but before he can, NAV will have scanned the email and thus executed the malware. This is a case where the infection comes from the software supposed to be preventing it.

It’s just like with firewalls: Why installing a packet filter filtering unwanted packets to open ports when you can close the ports in the first place?

Security is (mostly) a social thing (not counting exploits which must/can be prevented by updating the affected software) that can be achieved best using social skills, not software-barriers (as software has flaws – education at least has the possibility of achieving its goals).

So I’m not bashing Symantec (for once), but security-software as such.

Apache 2

There was this discussion recently about whether Apache 2.0 should be recommended by the PHP guys or not.

While I find their warning a bit too harsh, I for myself still cannot run Apache 2 – though I’d really like to. So maybe it’s time to add my two cents:

Last march, I was going to newly set up our productive server. As the apache guys keep telling that Apache 2.0 is production ready, I first went with the new version of course. Here’s what did not work and finally forced me to go back to 1.3: It’s not about PHP at all: The two extensions I’m depending on (MySQL and PostgreSQL) are available in a threadsafe edition, so even one of the threaded MPMs would have worked. What killed my intentions was mod_perl.

Back then, when the comment-spam problem was not that a big one for me, I have been running gnegg.ch in a mod_perl environement which at that time was not setupable with Apache 2: mod_perl itself had an even bigger warning about not working well than PHP still has. And additionally, they’ve changed their API, so even if I’d been able to get it to work, there would have been no guarantees of getting MT to work with that new api.

Anyway: I’ve been willing to try it out, but libapreq, required by MT when running in mod_perl, was only available as an early preview too (still isn’t nowhere near production ready). My tries in installing it anyway lead to a flurry of SIGSEGVs in Apache when using MT. Judging from the Gentoo bugtracker this has not gotten better yet.

One of the strongest selling-points for Apache isn’t PHP. It’s mod_perl. And currently, it’s mod_perl that should have this big warning on its webpage. Mod_perl and not PHP (which works nicely under Apache 2 in an internal developement system).

And even when mod_perl gets fixed: As they have changed the API, many existing (and not longer maintained) packages using mod_perl (like Apache::MP3 for example) will possibly stop working after the switch to Apache 2.

As soon as the first guy comes here and posts that he/she’s gotten MT to work under mod_perl on Apache 2, I’m going to reconsider the switch. Not a second earlier.

Learning by example

After getting through with Head First Servlets & JSP, yesterday I bought Programming Jakarts Struts just outof pure interest. You never know when knowing those things may come in handy.

Currently I’m somewhere in chapter 3 and already know quite a lot of things about struts (that I really like the framework is one of them – I should really try to do something Servlet-ish in the future). Chapter 3, for those that don’t know the book, is an introduction to Struts by example of a very simple online banking application.

And this gets me to the point: I’m a very practical person and I despise of doing lots of theoretical stuff. Usually I come quite soon to a point where I lose my interest because the topic gets to theoretical.

This is why I learn best using examples.

When I have to learn some database structure, I usually don’t even try to learn from the documentation. I just look at how the database is built to learn how to use it. That way, I’m doing something practical while still learning how to do the right thing. Only whhen I’m not sure somewhere, I’m going to look at the documentation.

The same thing with meetings. As soon as it gets redundant, I almose immediately lose interest. My brain hungers for more, clear information. If there is some, it just sticks. I seldom take notes and I seldom forget important stuff – just as long as it’s non redundant and somewhat visual.

So, the chapter three of the Struts-book is the optimal way for me to learn something as it’s expaining things by dissecting a complete application. This way I always know the big picture and a practical goal (the application) which helps me greatly understand and memorize the details.

And all this is the reason I so much like doing what I do at our company. Our philosphy has always been to try something out, never to think of being unable to do something, every time saying yes to some request of a potentional customer.

That way, I can always be on the lookout for practical solutions. I can always learn by example (the project I’m currently working on). In the last five years it seldom happened that I had to do something I did before. It’s learning, trying, erring, trying again all the time.

And as this is how I work best, we never failed so far to actually deliver what we promised to. From my very first CGI-script (“CGI? Never did that… but it can’t be that difficult”) over streaming satellite TV over the internet to Linux powered barcode scanners: It always worked out. And it always will.

Web Programming with CSS

For the first time in a very long time, I’m able to use a completely de-table-ized design in pure XHTML and CSS for creating a little web-application in PHP.

While many people just quote less bandwidth usage and better maintainable HTML-Code as the big advantages of using pure CSS layouts, let me add another one: Extremely increased productivity for programmers bringing interactivity to the layout

It’s a real pleasure: Never was it so easy to just concentrate on the functionality. No layout-information creeping into the business logic because it’s the only way to get some stupid placeholder GIF into the layout. No more error-prone stitching together immense and complicated HTML-snippets. No more debugging what went wrong when building one of those complicated layout tables.

And of course: No more pulling out hears when having a look at the size of the generated HTML-Code

I’ve never been as productive in coding a web application than in this case where the HTML-code is clean and the design is where it belongs to: In the CSS (which I don’t have to touch (anymore – the whole thing happens to be written by myself – Richard isn’t that good in CSS yet))

If only all future projects would be CSS-only. It would make live so much easier…

Is that still POP3?

My mobile phone provider here is sunrise. I am subscribed to what they call “Onebox”, a unified messageing solution.

I did that because I have access to my voice mailbox via their web-interface which is much more comfortable (and cheaper) than to use the mobile phone.

Unfortunately, their interface does not allow forwarding those messages to another address. While they say they do, entering a forwarding-address actually forwards the emails sent to the sunrise mailbox, but the voice messages stay where they are.

Today I though about accessing the box via fetchmail and sending it to my regular mailbox.

While this turned out to work extremely well (even the simple notification flag gets cleard on my handset when the fetchmail job forwards the message), the protocol the server speaks is awfully strange. It’s supposed to be POP3 passing around RFC2822 messages, it’s actually something else… Just have a look:

pilif@galadriel ~ % telnet um.sunrise.ch pop3
Trying 212.161.159.6...
Connected to um.sunrise.ch.
Escape character is '^]'.
 1 +OK POP3 umsi3-c04d2.mysunrise.ch vUMSI v1.6.0.0 (UM2 Build 030408) server ready
 2 user [phonenumber]
 3 +OK User name accepted, password please
 4 pass [password]
 5 +OK Mailbox open, 1 messages
 6 stat
 7 +OK 1 192931
 8 retr 1
 9 +OK 1421099 octets
10 From: [calling number] <[calling number]@mysunrise.ch>
11 To: -                      <[phonenumber]@mysunrise.ch>
12 Date: 04 Oct 2004  09:29 +0200
13 Message-id: 0xe97d4b80-0x40-0x3735-0x50
14 Subject: Voice Message
15 Mime-Version: 1.0 (Voice Version 2.0)
16 Content-Type: multipart/voice-message;
17   boundary="2448314160_4000_141330_5000.04102004_0929"
18 Sensitivity: Normal
19 Importance: Normal
20 X-Priebity: 1 (Highest)
21 Content-Duration: 64
22 X-UMSI-Transferred: Server-Id="1"; Server-Type="INFINITY";
23     Profile="[phonenumber]@4:6";
24     Original-Message-UID="244831416 004 005 14133"

(I’ve added the line numbers myself)

Line 7: Oh nice. There’s a message and it’s about 188 KiB large

Line 9: Wait a minute… 1300 KiB? Didn’t they say otherwise in Line 7? Actually it’s the server decompressing the Voice message and converting it to WAV just after the retr

Line 13: Is that supposed to be a valid Message-ID? Don’t think so

Line 15: What’s that? That’s not a valid Mime-Version Header

Line 18+19: Are those really valid message headers?

Line 21: What the heck is “Priebity”? That’s not an english word.. Maybe they mean “Priority”?

Line 22: Is this a valid header?

I pity the developers of mail user agents: They must cope with such rubbish and in the end, they are blamed if they do not. It’s never the vendors of the brolen servers because those are not visible to the end users.

Different question: Why is it always closed source commercial software doing such stupid things? They get paid to create working software and what you see above is not what I’d call “working”.

When I’m writing software communicating with some other component not written by me, I follow the defined protocol to the character whether the software is going to be publically released or not. It’s just polite.

How journalism should not be done

I am subscribed to the german “Linux Magazin” (it’s articles are translated and published to the english “Linux Magazine”) and today I received their anniversary edition (10 years Linux Magazin).

With great interest, I read the article “Insel Hüpfer” on page 56 and later. It’s about the author telling his story of finding security holes in the setup of a big german hosting provider

The author goes into great details when describing what he did and full of pride he actually tells the reader the MySQL-Root password of one of the compromised servers:

Und dann entdeckte ich erstmals etwas Erfreuliches: Das Passwort für MySQL-Root lautet: xxxxxx. So sollte ein sicheres Passwort aussehen.

Which means in english: Finally, I discovered something good: The mysql root password is: xxxx. This is what a secure password should look like. In contrast to the article in the Linux Magazin, I am definitiely not naming the password here!

All this would not be worse enough for me to blog about here if only they would not have been so stupid to actually show the user the name of the provider!

While all URLs are left out and the article does not name the provider, they made two bad mistakes:

  1. On page 63, there is a screenshot of a compromised FAQ page. While they cleared out Mozillas the URL-field, they did not do that with the big visible title of the page containing the domain name in the top left corner. Additionally if they had grayed out the text, googling with the contents of the rest of the page would too have led me to the providers address
  2. On page 64, they have a screenshot displaying the URL of the compromised phpMyAdmin, graying out the domainname, but leaving the URL intact otherwise. Too bad that the name of the provider is no secret anymore (see above).

All this would not be so bad (it certainly is bad for the publisher of Linux Magazin as this will get them in trouble with the provider), it really is catastrophical that the provider has not changed the password printed in the article!

This means that any reader of the Linux Magazin (currently only subscribers – I really hope they stop further delivery of this issue) can access the MySQL-Databases of many customers of said provider!

Posting stories like this is really nice and is what gets you the readers actually, but if you do this, please take care not to publicly post compromised passwords that continue to be working when your edition goes to press. And don’t leave clues like URLs and other stuff that points to the victim in question! Please!

Vendor lock-in

But, as Tom Kyte points out in his latest book, Effective Oracle by Design (Oracle Press), database dependence should be your real goal because you maximize your investment in that technology. If you make generic access to Oracle, whether through ODBC or Perl’s DBI library, you’ll miss out on features other databases don’t have. What’s more, optimizing queries is different in each database.

Needless to say on what vendors webpage I’ve seen the article the quote is coming from. One thing you learn in the practical live is that it’s extremely difficult to switch databases one you begin using the proprietary features. And you will have to switch. Sooner or later. Be it unsufficient functionality (as I’ve seen it with MySQL. I am still cursing the day when I began using SETs) or vendors going out of service or even political reasons.

While I certainly see some value in using proprietary features, let me tell you: Use them with care. Always be on the lookout for the availability of different approaches to do the same thing. If there are none, don’t do it (don’t use SETs in MySQL for example).

And if you can only get the full performance out of your RDBMS by relying on proprietary features, don’t use the RDBMS at all as it’s quite obviously not the right system. Performance must be available without being forced to use proprietary features. At least without relying on features in the query language itself – optimizations in the backend are ok for me.

This is one of the reasons I don’t use oracle, by the way. The other being this ;-)

Refactoring – It’s worth it

Just shortly after complaining about not having time to do some refactoring, I reached a place in my code where it was absolutely impossible to add feature x without cleaning up the mess I created three years ago. And – what’s even better: I had the time do really fix it. Cleanly

What I did was to sit down and recreate the whole module in a new Delphi project. I knew what features I wanted to have when finished and I somewhat knew the interface I had to comply to. The latter proofed inpractical, so I did some modifications to the interface itself (the thing was hacky too). Redoing the whole module took about a week (it’s about downloading stuff, exctracting and then XML-parsing it – everything in a thread while still providing feedback to the main thread), but it was absolutely worth it:

  • The code is clean. And with clean I mean so clean that adding further features will still be clean, depite not being needed as the new framework I’ve created is extremely powerful.
  • The thing is fast. Twelve times faster than the old version. I’m processing 7000 datasets in just 20 seconds now (including time needed for downloading and decompressing) which took me four minutes before.
  • The thing is more usable. Status reporting to the end user went from nearly nothing to everything the user may need. And she can now cancel the process – of course.

A task fully worth of undertaking. I’ve not been that pleased with my code for quite some time now

Refactoring – If only I’d had time

Refactoring is a cool thing to do: You go back to the drawing-board and redesign some parts of your application so that they fit better to the new requirements building up over time. Sometime you take old code and restructure it, sometime you just rewrite the functionality in question (or even the whole application, but I don’t count this as refactoring any more)

Code always has the tendency to get messy over time as new requirements arise and must be implemented on the basis of existing code. Not even the most brilliant design can save your code. It’s impossible to know what you are going to do in the future with your code.

Let’s say you have an application that is about orders. Orders with ordersets that somehow get greated and then processed. Now let’s say you create quite an usable model of your order and ordersets. Very well. It’s nice, it’s clean and it works.

And now comes the customer and over the years new features are added, let’s call it an inventory mode. You notice that these new inventory records have quite a lot in common with your orders, so you reuse them, but add some features.

Now full stop! It already happened. Why on earth are you reusing the old code and “just adding features”? That’s not the way to go. The correct solution would be to abstract away the common parts of your order and inventory records to something like TProductContainer (using Delphi naming conventions here) which has two descendants TOrder and TInventoryRecord.

But this comes at a cost: It requires time. It requires quite some steps:

  1. Think of a useful abstraction (just naming it is not easy. My TProductContainer above is stupid).
  2. Create the Interface
  3. Implement the new subclasses
  4. Change the application where appropriate (and if it’s just changing declarations, it still sucks as it’s time consuming)
  5. Test the whole thing

Now try to convince the project-manager or even your customer that implementing the required feature can be done in x days, but you’d like to do it in x*2 days because that would be cleaner. The answer would be another question like: “If you do it in x days, will it work?”. You’ll have to answer “yes”, in the end. So you will be asked “if you do it in x*2 days, will it work better than in x days?” and you’d have to answer “No” as the whole sense in cleaning up messy code is to keep it running just the same.

So, in the end those things will accumulate until it cannot be put away any longer and the refactoring has to be done no matter what, just because implementing the feature uses x days plus y days just for understanding the mess you have created over time. y being 2x or so.

The mean thing is: The longer you wait doing the inevitable, the longer you will have to fix it, so in the end, it should always be the x*2 way – if only those noneducated people would understand.