From: Peter Pentchev
Date: 23:30 on 15 Jan 2008
Subject: Checking for... wha?
--0OAP2g/MAC+5xKAE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Just something I stumbled upon in an oldish version of an almost
well-known cryptographic hashing library:
[roam@straylight /no/matter]$ ./configure --lots-of-silly-args
{snip messages seen so often they've already turned to white noise}
checking for ... no
checking size of ... 0
{snip more}
Oh. Okay. If you say I ain't got no '' on my system, then it must
be true. I can live with that. I think.
No harm done, actually; it was just a typo that was removed in the next
version.
G'luck,
Peter
--=20
Peter Pentchev roam@xxxxxxx.xxx roam@xxxxx.xx roam@xxxxxxx.xxx
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
Do you think anybody has ever had *precisely this thought* before?
--0OAP2g/MAC+5xKAE
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
iD8DBQFHjUIe7Ri2jRYZRVMRAgQ9AKDEL29cPOwTHtXkHAickiPtjwtH2wCgm9sx
pPfA2+99fNmG/IclB5fu6o8=
=8JcQ
-----END PGP SIGNATURE-----
--0OAP2g/MAC+5xKAE--
From: Peter Pentchev
Date: 13:20 on 26 Jul 2007
Subject: cPanel on RHEL
--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Just one of the little ways, too many to actually list, that cPanel's
"let's just go in and replace all the system with our kludgly workalikes"
policy infuriates me sometimes.
[roam@web ~]> ls -l /usr/sbin/httpd
lrwxrwxrwx 1 root root 31 Apr 18 2006 /usr/sbin/httpd -> /usr/local/apach=
e/bin/apachectl
[roam@web ~]>
Okay, so it's replaced httpd with something... else...
[roam@web ~]> sudo apachectl graceful
apachectl: Configuration syntax error, will not run "graceful":
usage: /usr/sbin/httpd (start|stop|restart|fullstatus|status|graceful|confi=
gtest|help)
start - start httpd
startssl - start httpd with SSL enabled
stop - stop httpd
restart - restart httpd if running by sending a SIGHUP or start if
not running
fullstatus - dump a full status screen; requires lynx and mod_status enabled
status - dump a short status screen; requires lynx and mod_status enabl=
ed
graceful - do a graceful restart by sending a SIGUSR1 or start if not run=
ning
configtest - do a configuration syntax test
help - this screen
[roam@web ~]>
Uhm. Like. Wha?
Just on a whim:
[roam@web ~]> sudo httpd graceful
/usr/sbin/httpd graceful: httpd gracefully restarted
[roam@web ~]>
Okay... fine... or something... but... but... but...
[roam@web ~]> ls -l /usr/sbin/apachectl
-rwxr-xr-x 1 root root 3719 Aug 31 2005 /usr/sbin/apachectl
[roam@web ~]>
This one was not even replaced. Yet it *thinks* it's called "httpd",
and it doesn't want to acknowledge one of the options it has itself
advertised (cue Smylers's recent DenyHosts rant). While the thing
that calls itself "httpd" does apachectl's job Just Fuckin' Fine.
A maze of twisty little passages, all alike.
G'luck,
Peter
--=20
Peter Pentchev roam@xxxxxxx.xxx roam@xxxxx.xx roam@xxxxxxx.xxx
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
Thit sentence is not self-referential because "thit" is not a word.
--FCuugMFkClbJLl1L
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
iD8DBQFGqJGk7Ri2jRYZRVMRAj4bAKDF07KqpdMAtYKAT2ZvS4YJV6HWRwCff5L4
tCGKPRcKFAZ7HC5kc4tIS84=
=Fy3q
-----END PGP SIGNATURE-----
--FCuugMFkClbJLl1L--
From: Peter Pentchev Date: 16:05 on 14 May 2007 Subject: Remote Desktop, Windows Logon, or something entirely different --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Soooo... So, I'm messing around with a Java applet for creating XML digital signatures using X.509 certs stored on a smartcard accessed via a USB smartcard reader. Yes, I know that this sentence alone contains enough triggers for about three weeks of continuous hate... but wait, there's more! Two hours ago, Something Happens(tm), and the Java cryptography whachamacallit suddenly decides that actually communicating with the lowly smartcard is way beneath its dignity. Off we go, blaming the JCA, the applet, the browser, the command-line JRE, the PKCS11 library, the reader itself... All kinds of documentation gets pulled out from long-lost websites, dusted off, and read. All kinds of tweaks are applied to all kinds of tweakable things. All kinds of small furry animals meet a grisly fate. After two hours of chasing wild geese and other predators, I stumble upon http://blogs.msdn.com/oldnewthing/archive/2006/11/20/1109013.aspx =2E.. Inspiration hits. Hard. Right between the eyes. =2E.. No, I'm not trying to log in with the smartcard. I won't try to log in with the smartcard in the foreseeable future. I don't even want to think about logging in with the smartcard. But still, if: 1. somebody tries to log in using Remote Desktop, and 2. there is a smartcard reader attached, and 3. there is a smartcard in the smartcard reader, =2E..then the Windows logon system hides the reader from all other libraries and applications and claims it as its own, to love and to cherish, till the power supply do them part. Turn computer off, remove reader, turn computer on, plug reader back in. See applet. See applet run. Run, applet, run. Two. Bloody. Hours. Right now, I wish I had a kzin to challenge. It would have been easier on the unlucky coworkers that just happened to be near my desk five minutes ago. Off on a bloody rampage, Peter --=20 Peter Pentchev roam@xxxxxxx.xxx roam@xxxxx.xx roam@xxxxxxx.xxx PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence every third, but it still comprehensible. --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGSHqy7Ri2jRYZRVMRArjrAJ48VBJgvS4oXfijp1uM5TDWgL5CjgCggJ+D U3Qja0lxqQZ2ouSwsrdhpHg= =ULRZ -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl--
From: Peter Pentchev Date: 21:20 on 19 Aug 2006 Subject: Encryption done the Perfectly Wrong Way(tm) --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [okay, apologies in advance - or, come to think of it, I'm here, so no apologies are needed; anyway, this will not be a real software hate, more like a software design hate; still, I think it counts as mind-software hate, so there] Dear Wossname[0], For about four months now, you've been subjecting me and the company I work for to a kind of Chinese water torture - first, telling us that the next version of your system[1] will require some sort of user authentication[2], and then dropping tiny pieces of information, all different, all ever so slightly incompatible with each other, at the maddening rate of about once every lunar month. So we will need to supply a plain-text username and an encrypted password for each query to your product[2]. Now. Let me tell you some things about the way I understand cryptography[3]. 1. Picking an encryption algorithm should not take three weeks. 2. When an algorithm is finally chosen, telling us "use 3DES" would suffice; sending us a three-page listing of Visual Basic code *without* actually mentioning the algorithm's name - except in two lines of code instantiating a CryptoAPI object - is... a bit verbose. 3. Picking an encryption key and an IV should be left to the customers who will actually use the product, *not* referred back to the software vendor. 4. Picking an encryption key and an IV should not take three weeks. 5. Telling us that the encryption key and the IV will not be needed, since you're changing the algorithm, two weeks before our deadline, is a bit... unexpected[4]. 6. Sending us a two-page document (the first page describing the full data path and exchange procedures, the second page describing the actual encryption algorithm) might have been a Good Thing(tm), were it not for the minor mishap of misspelling "algorithm" as "logarithm" in all three places it's mentioned. 7.... Okay. I am at a bit of a loss here. A loss for words. Although a full day - and a half - has passed since we received said two-page document, I still have not completely come to terms with my inner self as to how I *ought* to feel about it, and how I *do* feel about it. Suffice it to say that, after working on this project for an year and a half now, I honestly, sincerely thought that no communication from The Other Side could actually surprise me any more. This document managed to surprise, nay, confuzzle, nay, completely befuddle me for all of two minutes; then I started laughing hysterically, and sometimes I still do. So... let's try this again. 7.... Nope. More hysterical laughter. Just one last time... 7. All the communication with your software so far has involved specifying a character set. Thus, you understand character sets - or, well, or at least you are barely aware of their existence. Also, you understand character set conversion - or, well, or at least you are barely aware of its existence, too. So... if you want the password - only the password, not the username - to be represented in EBCDIC[5], you might have put more than one single passing mention in said document. But hold on, that's not really the hysterical laughter-inducing part. 8. A Caesar substitution does not count as industrial-strength encryption in my book. Yes. Ohhhhhh yes. Ahem. Yep. I know it's hard for you to believe what I just said, but... Taking the numeric code (in EBCDIC, as previously mentioned) of a letter, subtracting it from a constant number, then subtracting the result from *another* constant number, is indeed equivalent to adding a third constant number to the original numeric code of the letter. So when you say we have to do this for each particular letter of the password, you are effectively describing a Caesar substitution. Okay, so it's in EBCDIC; okay, so the offset puts the result well outside of the normal alphanumeric range in EBCDIC; okay, so the result will not look like letters or numbers at all. WHAT THE HELL DOES IT MATTER?! It's still a Caesar subtitution. It's still security through obscurity. It's still not suited AT ALL for this particular software system! And... yes. I'll still do it. I'll write the code, I'll integrate it into our part of the system, and I'll deliver it on time. I'll do this with one, and only one, purpose in mind. To get our part of the system deployed at our customer's site on time, so then you can first wallow, then drown in the slew of bug reports that will first come to us, then be analyzed, and finally duly reflected to land on your desk. I think I need a drink now. Over and out[6], Peter[7] [0] I'm not actually sure I even *want* to know your name. Bearing in mind the existence of certain books and rituals, the world might even be a much safer place for you if were I were to never, ever, ever learn it. For the present, it is enough for me that you think you write software and that you have managed to drag enough people down into this delusion. [1] A big, steamin' piece of s... s... software, that a client of ours has at the core of their services, and that I and a couple of cow-orkers have to write an interface module for. Come to think of it, I may have mentioned it before in this place - and when I may have mentioned it, I may have concluded my mentioning with a hope never to hear about it again. Unfortunately, things didn't quite turn out that way. [2] "Each message will contain a plain-text username and an encrypted password. Well, okay, not at once - there will be a transition period when some messages will work the old way, without the username and password. Yep, only some messages - there are some important ones that will require authentication at once. Yes, this is one of them. No, not this one. No, not this one either. No, we cannot give you the full list yet. Oh, well, some messages will not require authentication even after the full deployment. No, not this one. No, not this one either. Yes, of *course* that one will work without authentication. No, we cannot give you *that* full list either. What? Of *course* we know which messages will require authentication and which ones won't - we just can't tell you yet. Yep, that's our version and we're stickin' to it." [3] Not all that well, of course. I think most people here will wholeheartedly agree that teaching does not necessarily imply understanding, especially so in Academentia, so my being on a team teaching a university-level network and software security course would be completely irrelevant. [4] Well, okay, it *should have been* unexpected. In this case... to be honest, I wasn't a bit surprised. The surprise came later - read on. [5] Aye, mates, you heard that right! Yep. I've been aware of EBCDIC for the past fifteen to seventeen years. I've been aware of it pretty much in the same way I've been aware of the Enigma and Bombe encryption gadgets - in a fun piece of trivia sort of way - I've known what it was, I've known where and when it was used first, I've known where and when it was widespread, I've had at my disposal conversion tools that I could use any time I had a couple of minutes with nothing to do and, just for the fun of it, I could convert a piece of text from ASCII to EBCDIC and back, just to see what comes out... But I've never - never - NEVER even imagined that I could ever actually *come across* it in any kind of Real Life(tm) and Real Job(tm). Oh, the sweet delusions of youth. [6] Normally I conclude my e-mail communication with a "G'luck", but in this particular case... [7] The careful reader might note that I've taken the time to edit my work e-mail address out of this e-mail's signature, just to state even more clearly that this is a purely personal opinion and in no way affiliated with any legal or physical entity except for the dozen or so selves dancing around inside my mind. --=20 Peter Pentchev roam@xxxxxxx.xxx roam@xxxxxxx.xxx PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 When you are not looking at it, this sentence is in Spanish. --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE53Kc7Ri2jRYZRVMRAmETAJ4jgFqaImJPXq4q++rwN3yvCS8u1wCgif+X UmxHtsAOGP7kyV8pxlp6JyY= =N131 -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR--
From: Peter Pentchev Date: 08:40 on 17 Feb 2006 Subject: Core Banking Systems --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear Great Big Smelly Piece of S... S... Software, that shall remain unnamed not to protect the guilty, not even to protect the innocent, but merely because if I have to once more utter, write, or type its German-sounding name, its three-letter acronym, or its trade name that brings up associations of both physics and topology, I *will* be violently sick all over the desk and the floor, and the cleaning lady has done absolutely nothing to deserve the extra amount of work. We have known each other for a full year now. We've been through good times and bad times - or, at least, that's how the saying goes, while actually it feels more like bad times and worse times, and I'm kinda reminded of the English joke about the doctor's son who, when asked for the comparative and superlative degree of "bad", promptly answered "bad, worse, dead". Some people might say that such intimacy over the course of an year is grounds for a nice, healthy, long-standing relationship. Some people might go steal an H-bomb, drop it into the crater of an active volcano, watch the blast from a respectful distance, then briskly walk over to the gap of the newly-formed crater, and do a double somersault - backwards - into the hot, spicy, bubbling, radioactive lava. How do I hate you? Let me count the ways... Way the First - Message Queueing. Okay, so you're based on a well-thought-out, industry standard, fully buzzword-compliant message queueing architecture from a certain bluish software and hardware company. So far, so good. But did you really *need* to take the concept of message queues, turn it inside out, marvel at the shiny bits inside, *then* turn it upside down, shake it violently, and run with it? Did you really, really have to define a separate queue model for pretty much every single query (oh, excuse me, those are not queries, those are not even messages, those are *processes* now), then squeal, throw a hissy fit, roll over and die each time somebody sends you a message with the wrong queue model? And oh, certainly, every now and then some part of you decides to send a reply on the *wrong* dynamic queue, then just sits and waits until Somebody(tm) comes along and fetches the message that nobody expects to be there - in the meantime, refusing to process any further messages, since "nobody fetched the response of the previous one yet". What's that you're saying? Timeouts? Ah, sure, there are timeouts - and pretty much reasonable timeouts, too - reasonable for your friendly neighbourhood planetologist, I mean! Way the Second - Error Reporting. Security measures? Oh, of course you've implemented security measures, no question about it! Like... let me tell you a story of many moons ago, painful as it is for me to even remember... So we're on site, fighting with said core banking system for the finishing touches of the pilot project. Suddenly, with absolutely NOTHING changed on our end, the system stops responding to our queries. Yep, we send a message, we send another one, we send fifteen different kinds of queries that worked, like, what, two minutes ago - and just like with the Fab Four, "No Reply". For two hours - two whole goddam hours - we work with the bank's IT guys, trying to diagnose all sorts of problems - all the way from network connectivity through protocols up to the system being up in the first place, which it obviously is, since no one at the bank is running around in panic and tearing his hair out - no one but us, I mean. Finally, one of the IT junkies comes up with a bright idea: "What account are you trying to use? THAT one?! Oh, it was just a temporary one, it expired today!" "Er, what?! Why didn't you tell us that two hours ago?" "I just thought of it..." "Uhm, wasn't it in the logs or something?" "Logs? What logs? It doesn't log this kind of problem anywhere, it just drops your query on the floor." Uhm. Whiskey Tango Foxtrot, over?! Now I'm not exactly what you'd call an omniscient security guru or anything, but... Correct me if I'm wrong, but if the core banking system receives - via the bank's internal network, no less - a query with the wrong auth credentials, there are two, and only two, plausible explanations: - something is misconfigured on the bank's internal network, and the bloody administrator freakin' needs to know about it - NOW! - somebody is trying something nasty ON THE BANK'S INTERNAL NETWORK, and the bloody administrator freakin' needs to know about it - NOW! What am I missing? Please tell me, what the hell am I missing? Way the Third - Fragility... or Reversibility... or Something So our application has to report the last 15 transactions on the customer's account. There's a query - uh, 'scuse me, a process - that returns the full information about the transactions on the account for a given time period, 60 at a time. We run it, fetch 'em all, the use the last 15. Of course, a Corporate Customer comes in with many, many transacions per day, and the "fetch 'em all" strategy leads to a wee bit of waiting on the line. Fine, so the query we are using has a "direction" parameter that lets us fetch the transactions going back in time. Clickety-click - ten lines changed in the code, a *single character* changed in the query sent to the core banking system. Half an hour of testing, everybody goes home happy. The next morning, five frantic phone calls in as many minutes: "We are missing transactions! We are not reporting transactions! We can see the transactions on our system, but your app does not show them!" Nah, impossible, innit? Well, let's humor them, let's go over and check. Yep, our app is missing transactions all right. An hour and a half later, after I've made each and every test known to humanity and then some, I go back to the bank's IT department, and, in exasperation, ask them, "Look, I *know* this sounds silly, but I just have to cover everything now... have you heard about any problems with such-and-such query when going back in time?" "Oh, of course! That's a known problem - you're not actually using it, are you now?" Must... not... explode... Must... not... climb... walls... Must... not... bring... walls... down... A single-character change in the query. Reverse the order that the results are returned in. Get a whole different batch of results. Yep, not only were some transactions missing, the banking system actually made up a couple of new ones, just to keep us giggling happily until the straitjackets are cut to size! Way the Fourth... oh, well, nevermind, I *really* could go on like this all day - nay, all week, if I have to - but there just ain't enough sedatives in the world, not even of the triple-distilled variety, to help me up afterwards! So, Dear Great Big Smelly Piece of S... S... Software! There was a certain Monk in a certain Monastery who came up with the idea that there is indeed a Biblical way of expressing the sentiment usually dished out as a four-letter acronym that starts with an 'F', ends with a 'D', and somewhere in the middle there's an 'O' and an 'A'; the Biblical quote in question was "Go forth and multiply!" Well, if "multiply" is extended to cover "do not, under any circumstances, create ANY ADDITIONAL COPIES of yourself, but simply use a high-power charge to create many, many disjoint small parts of you, all subtly different"... then by all means, dear core banking system, do kindly go forth and multiply! And no, I do *not* need to know when this happens - for if I never, ever hear anything about you again, it will have been an year too late! Loping off to scream, leap out of the long grass, and rip soft bits off small furry animals, Peter --=20 Peter Pentchev roam@xxxxxxx.xxx roam@xxxxx.xx roam@xxxxxxx.xxx PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3? --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (FreeBSD) iD8DBQFD9Yvt7Ri2jRYZRVMRArMlAJ9JZk8InMjT6CIY2iGUecPNf4fBmQCgtMfU On5sxWls/aSCBhbdBe5zjmI= =RdHV -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J--
Generated at 10:28 on 16 Apr 2008 by mariachi