Pinochle 2.0 (or how to manage cards in a GUI)

Your JoeDog’s Pinochle contains a bug. Under yet-to-be-determined circumstances, some cards won’t render. It’s not clear why. No exceptions are thrown; the cards just silently disappear. It only happens on startup. If you have cards when the game begins, you’ll have cards when it ends.

The game was written in java and we used the Overlap Layout to help manage the presentation of the hands. It was easy to implement but it led to some design gymnastics. For example, each player had a reference to the JPanel on which his cards were positioned. We suspect this is associated with the disappearances.

Rather than fight this design any further, Your JoeDog decided to rework the architecture. He wanted the GUI to be as dumb as possible. A thread runs in the background and it just paints cards on the table. That thread runs in an endless loop. It asks the model, “What am I painting? Where am I putting it?” The GUI — or View, in MVC parlance — also listens for mouse events. When the user clicky-clicks, it sends coordinates to the model to determine if a card was clicked. If a card was selected, the controller determines what should become of that.

To make this system work, Your JoeDog needed a way to track the coordinates of the cards. It was then that he stumbled upon JGameGrid. The author, Aegidius Plüss, treats each game piece as an Actor. Each actor contains a Location object which holds its positional coordinates. Your JoeDog didn’t steal the entire GameGrid but he did incorporate that notion into his pinochle game. When the View thread asks “What am I painting?” The model hands it a list of cards. When it needs to know “Where am I putting it?” It just asks each card. 

Version 2.0 should be available shortly. 

Parse The Version Number With Ant

“The best programmers are all alike; every shitty programmer is shitty in his own special way.” –Anna Karenina

Earlier Your JoeDog mentioned a trait of good programmers. They model data so each element is stored in only one location. This principle is known as a Single Source of Truth. To illustrate that principle, he pointed to siege’s version numbering. The number had to be available in both the program and its helper scripts. In order to uphold SSoT, he stored the number in version.c and parsed that file with a helper script.

Here’s an astonishing fact: not everyone loves the C programming language. Some of you are Java weenies! Fear not, weenies, for you we have another example.

Same problem, different language. We want to store the version number in one location but it must be available for two mechanisms. The first mechanism is the program itself. That’s important, right? It helps answer the question “Which fscking version am I running?” The other mechanism is ant. When we build our jar file we’d like to add the version number to its name, i.e., pinochle-1.0.7.jar.

Let’s examine this is closer detail after the jump.

Continue reading Parse The Version Number With Ant

DRY Programming

“The best programmers are all alike; every shitty programmer is shitty in his own special way.” –Anna Karenina

Today we are going to discuss one of the most important traits of a good programmer: He’s DRY, which is an acronym for “Don’t Repeat Yourself.” This principle is also referred to as Single Source of Truth. DRY programmers rarely use a clipboard. Their data is structured so that every piece of information is represented exactly once.

DRY code is easy to maintain. When a data element is stored exactly once, a single edit changes its value throughout the system. As soon as this principle is violated, maintenance becomes a bitch. For you bean counters out there — you guys who thought cheap programmers would save you money — that means expensive.

“I thought I changed that!” You did. The last programmer typed the same thing multiple times. “Where are the other instances?” I have no idea. “What did he call them?” God only knows. “There’s 50,000 lines of code across twenty files.” Well then you better start searching …  “FSCK!”

The best programmers adhere to this principle no matter what. It doesn’t matter if the same piece of information is needed by two separate tool kits. They use one piece of data and parse it with two separate languages. Let me give you an example.

When you download siege, you get a tarball named siege-3.1.0.tar.gz When you run siege –version, it displays the version number. In one case, the number is interpreted by C code, in the other it’s interpreted by a shell script. No matter, in both cases it’s sourced inside a single file. You can find it in src/version.c

So while it would have been easy to type “3.1.0” in the C file and paste that value inside, Your JoeDog would have to update it twice with every release. You know how often he’d miss one of those two edits? Every stinkin’ release.

In order to adhere to the DRY principle, he made the configure script parse a string in version.c  That string looks like this:

const char *version_string = "3.1.0";

And Your JoeDog parsed the number in like this:

VERSION=`sed -ne 's/.*version_string.*"(.*)";/1/p' ${srcdir}/src/version.c`

NOTE the use of ${srcdir}; one copy of everything, people.

Look, I know some of you are going to be like “fsck that guy. I’ll copy and paste to my heart’s content.” That’s fine as long as you are now and will always be the only maintainer of your code. But if you expect another human to work that code and if you insist on being WET (We Enjoy Typing), then you’re a bad programmer. Hey — somebody had to say it.

Now That’s Underhanded

The Underhanded C Contest challenges participants to write straightforward and clearly written code which doesn’t perform its intended purpose. Winning entries should easily pass inspection by other programmers so they can be added to the code base in order to execute their intended purpose which is to miscount votes, shave money from transactions or pass along information to another party, etc.

Some of the techniques used in this year’s contest include the use of K&R style function declarations to circumvent type checks, #include statements that change the package structure, swapping user space #define with system ones and a misleadingly long loop execution.

The winning entry leveraged the __isleap() function in time.h. Because that function is actually a macro it expands into an expression when a user defined macro is invoked multiple times. The winning author placed a subtle bug in that macro which plausibly turns the year into a 0 and writes past a buffer thereby performs the author’s intended purpose: to leak information to the outside world.

[Karen Pease: The Underhanded C Contest Winner]

Millions of Cookies, Cookies For Me

cookiemonsterA couple weeks ago, a reader notified Your JoeDog of a problem with siege’s cookie handling. When the server sets a cookie that’s already stored, siege won’t update its expiration time. A JoeDog Fellow told him, “That’s a paddlin’.” The last cookie in, is the next cookie out.

The investigation took Your JoeDog into cookie.c, a file he hasn’t touched in years. “This code is awful,” he said. “Who wrote this shit? … Hmm, some guy named Jeff Fulmer, et al. If I ever meet that guy, I’ll tell him a thing or two.”

As an ethnic German with a tendency to over engineer — well, um — everything,  Your JoeDog decided to completely overhaul cookie handling. Why change two lines when you can rewrite everything, amirite? The file cookie.c now contains a COOKIE object with getters and setters, cookies.c is a cookie list object which houses all cookies in memory. Cookies will persist in $HOME/.cookies but the details are still being considered.

Here’s the thing. Siege isn’t a browser, it’s many browsers. We store cookies at the thread level. Each thread gets its own list of cookies. To distinguish them, we used pthread_self(), which is a long long int like 140018384393984 or something. Technically it’s not a long long int, it’s a pthread_t, but you get the point. The next time you fire up siege, its threads will have different IDs so we need a convenient way to associate stored cookies with new thread IDs.

Furthermore, there’s no guarantee that your next run will have the same number of simulated users. We need to consider how to handle that situation. If you have 50 stored cookies and you run 60 new users, should we stop assigning cookies at 50 or do we start repeating them starting with cookie 1 to user 51? Inquiring minds want to know. I want to know.

The new code is not yet in version control. If you want a copy, let us know. We can create a beta branch or send you a tar ball. Happy hacking.

NOTE: Your JoeDog refers to cookie and cookies as objects because they are. Yes, siege is written in C rather than C++ but you can write objects in C just fine thankyouverymuch. An object is simply a thing which references itself. To achieve this in C, you just pass a reference to the object as an argument.

I Am What I Am

#include <stdio.h>
int main(){int a[]={74,117,115,116,32,97,110,111,116,104,101,114,32,67,
32,104,97,99,107,101,114,10};int *b=a;for(;*b>0;printf(%c,*(b++)));}

Block IP Addresses With, um, block

Last night we told you that ISIS assholes were attacking America and its WordPress blogs. Have no fear, kids. In the War Against Internet Dickbags, Your JoeDog is here to help. Whenever he’s attacked by these people, i.e., all the time, he grabs their IP addresses from the logs and blocks their asses. He feeds those addresses to a script called block which, um, blocks them.

The script is just a convenience which makes your life easier. iptables does the heavy lifting. If you’re running a linux system — and why aren’t you? — then you probably have iptables.

Let’s block some dickwads now! (Continued after the jump)

Continue reading Block IP Addresses With, um, block

WordPress Vulnerability: wp-super-cache

spaghetti-codeWhenever someone says “PHP sucks!” Your JoeDog assumes they got that impression from WordPress. It uses inline programming tags that mix logic with content. Whenever you do that, the result is always a nice heaping mound of spaghetti code.

PHP doesn’t have to be coded this way. The there are plenty of nice frameworks which support model-view-controller. Your JoeDog uses WordPress because he likes it as a blogging platform. He blogs on this site more often than he codes it; a cost-benefit analysis leads him to WordPress.

He also opens himself to vulnerabilities. Oh, look! Here’s another one now: Persistent XSS in WP-Super-Cache. Your JoeDog uses that module. What’s wrong with it?

Using this vulnerability, an attacker using a carefully crafted query could insert malicious scripts to the plugin’s cached file listing page. As this page requires a valid nonce in order to be displayed, a successful exploitation would require the site’s administrator to have a look at that particular section, manually.

Fortunately, the fix is already out. If you’re also using wp-super-cache, make sure you’re running version 1.1.4. This is a dangerous vulnerability which is easy to exploit. Get up to date or get out of the game.

NOTE: Your JoeDog considers PHP a rather elegant language. It’s many bad implementations and design decisions that make it seem like Suck.

Zombie Bugs

From Nibble Sec we get one of those stories that makes roll our eyes. Actually, it makes us shake our heads but Your JoeDog refuses to type ‘SMH.’ Wait a second – you just typed it! Shaddup.

A four-year-old Adobe bug (CVE-2011-2461) is back from the dead. The flaw puts flash users at risk of having their sessions hijacked. But this bug was patched by Adobe back in November 2011 — why are we talking about it now?

Static libraries! If an app was compiled using the vulnerable SDK, then it still contains the vulnerable code unless it’s recompiled with a patched SDK.

Here’s how it works: Static libraries contain subroutines which are compiled into the executable. In this case, bad binary code was copied into the app. To fix the bug, you need to recompile the app so good code gets copied into it.

Really? Yes. Really.

“I have nothing to do today.” –Nobody in IT, ever.

Easter Not-so-nice-time

Is Big Software cracking down on programmers who insert Easter Eggs into their code?

“Are they going away? Indeed they are,” says Dr Diomidis Spinellis, a Greek computer science academic and author of The Elements of Computing Style.

“As programming becomes more corporate, more official, one cannot appear to have code that is not officially sanctioned,” he says.

Easter eggs have not undergone the same levels of scrutiny of the rest of the code, he says, and there may be vulnerabilities attached to them.

“They still happen, but they’re less likely to be little bits of code, more likely to be hidden in documentation or code comments,” adds Brendan Quinn, a software architect in London.

“Actual executable stuff hidden in code is something that people are trying to eliminate. With varied success around the industry.”

The argument goes if a manufacturer can’t stop developers from sneaking in benign undocumented features in, how can you be sure they’ve not inserted a backdoor, too.

Your JoeDog doesn’t hide Easter Eggs inside his code. It’s open source. To find them, all you’d have to do is read….

[Business Insider: Twenty-two Easter Eggs]

[BBC News: The End of the Easter Egg?]