I go to download irssi, and I find out that you're as guilty as anyone. I don't believe for a second that there are no holes, but a team of ten programmers working for a year couldn't be sure. Here's why:
First off, you use autoconf, which means I can't even figure out what your dependencies are in any general manner. This means there isn't just one program - there is one program per configuration option combination multipled by the number of platforms irssi runs on. I have no way of verifying what interfaces you're running against, and you haven't specified what standard you wrote to, if any, so I can't check the validity of the way you use those interfaces. If I had to guess, I'd say you probably wrote to the Linux man pages, which is to say, to no standard at all.
Second, you ignore common and important things like putting function return values on the line before the function name so that ^functionname is a valid regular expression to find a function name, thus making it essentially not worth my time to even try to read your code at a system level, thus making it impossible to understand, and thus making an audit insanely difficult. I could run indent, but indent has bugs that almost any sizable body of code tends to bring out, causing subtle or not so subtle errors.
Third, you use the evil and much reviled camel case, which, while it may be pleasant in textbooks, is a vile curse upon those of us who actually read code on a monitor in a reasonable font size. It literally hurts.
Fourth, while your code is "modular," there is no overview document specifying what does what, what the interfaces between the pieces look like, and so on. I could spend more time than this program is worth just trying to gather up that information.
Fifth, there's stuff written in Finnish. Sorry, but while many Finnish speaking people are good programmers, most good programmers are not Finnish speaking people.
Sixth, you use perl. Once you include perl, you can forget about a security audit; perl itself is unauditable, no matter what anyone tells you, which means that anything written in perl is of questionable security no matter how good the author is.
Seventh, you have gratuitous fluff like "themes." While kiddies may love this, the code complexity it creates is useless to bother reading for audit. Programs should either be inconsequential with respect to security or else they should not contain fluff features.
Eighth, even you are forced to admit on your web page that you cannot verify that your code works given a hostile server. Whether this is protocol related or your fault I am not certain, but I am certain that if it is not secure against a hostile server and it uses plaintext, then it is not secure in any meaningful sense no matter what you have done. Therefore, an audit is somewhat senseless.
Ninth, your program is loaded up with GNU library dependencies. Since those libraries are about as well written as my colon is odor-free, your program is insecure. There is no point in ferreting out errors in your code when it is linked against such a horrid mess of bad code anyway; after I was done, the result, even if I did my work perfectly, which is of course not possible, would be an insecure program.
Tenth, your documentation is out of date. Once again, this makes it harder to actually learn about your program. Fortunately, this is little matter since it is so inadequate that even were it up to date, it would be of little use.
Eleventh, it is an irc client. Therefore, it is insecure:)
'God dammit, your posts make me hard.' --LilDebbie