• Be me.
• Apply for job listing that requires Python experience.
• /home/tootsweet/python_projects/python_genius.py
• Called and invited to team interview.
• Arrive dressed like perfect corporate cog, leather binder in hand.
• “Do you know C#?”
• Listing never mentioned C#.
• Me: “No.”
• “We’re switching from Python to C#.”
• Didn’t get the job.

Later worked with former employees of $aforementioned_employer. They have a terrible habit of hiring in droves, only to lay off half their workforce every few years.

Nice code golf challenge.

The kind who spends more time compiling than using my system.

Wait, where’s Gentoo?

Just some examples of things I’ve printed or plan to. Ones marked with an asterisk (*) at the end are ones I largely or entirely designed myself or plan to largely or entirely design myself. Ones marked with a plus (+) are ones that are half completed. Minuses (-) are ones I haven’t started yet but intend to.

• Wall mounts for Nintendo Switch components (dock, controllers, Joycon charger, etc.) Definite space saver. *
• Wall mount for a Raspberry-Pi-based NAS solution. *
• Parts to augment a computer chassis wall mount for my ridiculously-large chassis. (Yes, there’s a bit of a pattern there.) *
• A custom Raspberry Pi case that mounts nicely and nondestructively to my desk.
• A custom adapter for my drill that let me run the drain in my washing machine when the motor was broken. *
• A custom plate to cover my nightstand clock face so it doesn’t shine in my eyes all night. *
• A custom die for a Sizzix Die Cutting Machine for quilting use. (That one took a lot of work.) *
• A custom tool for precisely bending 16mm steel strapping (which I’d sharpened into a blade) in service to the custom die just above. *
• Custom yarn bowls for my crafty mother. *
• Custom stitch markers for my crafty mother. *
• Custom barrel buttons for my crafty mother. *
• A couple of custom mounts for SAD lamps. *
• Custom shelving for a bathroom. *
• Custom mods for some wire shelving in the same bathroom. *
• Custom mount for a reflector mirror to let me see more with the security camera on my front porch. *
• A tool for straightening 3D-printing filament. *
• Spacers for mounting a peg board on the wall.
• I also had a folding door that broke and got kinda janky. I had a few extra of those peg board spacers, and they turned out coincidentally to be exactly the right size to properly shore up that door.
• Custom shelving for DVDs/Blurays and video games. *+
• A custom shelf-drawer for my mousepad. *-
• A custom 3D printed mechanical keyboard… once I’m done writing the program for rapidly prototyping 3D-printed keyboards. *+

I’m sure I’m forgetting a bunch. And the above is only the useful things and excluding the mostly art/fun items.

I have in mind to do more 3D-printing of tools. I don’t have much specifically in mind. But that custom steel strapping bender is pretty cool. Also, some of what I mentioned above is available on my Thingiverse.

This whole article is hokey.

But assuming permissive licenses lead copyleft licenses, I think it’s unfortunate.

I had a friend who wasn’t very technical who had some issue where he couldn’t boot into his OS (Windows) and bought a new computer, but wanted the files off the old computer. So he asked me for help. I remember bringing a Knoppix live CD (remember Knoppix?) And when I was there, I realized I had a severe lack of general networking equipment. (I didn’t have a switch, so I couldn’t plug both computers into the network so they could communicate with each other and the internet.)

So I started up the old computer in Knoppix, plugged it into the network, and installed a bunch of networking packages like a DHCP server and such. And then I used the Ethernet cable to plug the two computers into each other, letting the Knoppix box give the new Windows machine its IP. And then I installed Putty on the Windows machine and used it to SCP the files from the old machine to the new one.

The whole thing went way smoother than I’d have expected, never having attempted that before. But I felt like such a hacker that day. Lol.

Honestly, sensible.

“If it works, it ain’t stupid.” ;)

Huh. Only 11 days on the Raspberry Pi I’m using as a “desktop system” right now. (Arch Linux Arm, btw… though Arch Linux Arm sucks now-a-days.)

Let’s check my RPi-based NAS:

[tootsweet@mynasserver ~]$ uptime
 19:56:07 up 212 days, 18:43,  4 users,  load average: 0.16, 0.04, 0.01

Also not as long as I’d have guessed.

And then if you still can’t scroll up/down to read the rest of the article, look for and disable any overflow:hidden; or position: fixed in the CSS. It’ll probably be on the <html> or <body> tag, or on something pretty “high level” just under the <body> tag or no more than a couple of levels of hierarchy beneath.

Nobody’s said “this is going to be my year” in many many years.

If you’re a software engineer, memorizing an ASCII table (particularly the hex numbers of each character code) is definitely helpful. If for no other reason than so that you can read things that are randomly written in binary without having to consult a table.

Something not really otherwise terribly useful that nonetheless helped me keep my sanity: learn how to convert to base64 in your head. At work, we had really boring 8-hours-a-day training for a couple of weeks. To pass the time, I came up with random strings to base64 encode in my head. “Hat is 48 61 7a. The first six bits are 010010 which in base64 is an S. The next six bits would be 000110 which in base64 is G.” Etc. I’d write down the base64 strings character by character as I derived them and then check my results for errors when I got back to my desk.

How to convert various units of measurement. (Including between imperial and metric.)

2.54 centimeters in an inch. Degrees Fahrenheit is nine fifths of degrees Celsius plus 32. Stuff like that.

deleted by creator

Java, Postgres mostly but also LDAP and random in-house-written RESTful services, almost 20 years.

• The objects we store in the Postgres database are very “hierarchical” in nature, with one top-level object and lots of child/grandchild/great-grandchild objects. (We asked for a Mongo database but the infra team at the time said "make do with Postgres.)
• As I mentioned, some of that hierarchy is in LDAP or RESTful services, not in Postgres, so we needed something capable of dealing with multiple storage backends that would stitch the objects together as necessary. So the “ORM” needed to have backends for multiple backend systems.
• We knew clients would need a vast number of different queries. So we made a RESTful endpoint that gave the full power of the ORM to (authorized) clients. If they needed different data, we’d be like “change your query like this” and they didn’t have to wait on us.
• Early in the project, we consciously designed an extensible JSON representation of our hierarchical objects. That is what’s returned from the aforementioned RESTful endpoint.
• However, we also created a “shortcuts” system to allow us to “balance” how much of the logic lived on the server vs in the client. (It can mix and match. Like “apply this shortcut, but also filter this way and paginate” or whatever.)
• We made the API of the ORM such that it could both be used to query from the database/LDAP/RESTful systems, or be used as a client SDK for the aforementioned RESTful query endpoint that the application exposed.
• It’s both “more than an ORM” (querying from non-database sort of backends) and not fully an ORM (read only, doesn’t handle schema evolution.) But it’s fair to say it’s more “an ORM” than “not an ORM”.
• The implementation of the Postgres backend part of it is heavily inspired by Django’s ORM.

We couldn’t have pressed Hibernate into this use case. It doesn’t really deal with hierarchical data and sure as hell doesn’t know how to query from LDAP. I don’t know that anything existed at the time (nor am I sure anything exists now) that would fulfill our use case.

And the alternative to what we built was a massive, unmaintainable DAO with ridiculous numbers of individual queries in it that would have to be modified or added to endlessly every time someone needed to filter a bit differently or whatever.

This was a developed-in-house e-commerce web application at a major e-retailer. So fortunately that monstrosity of a cookie-handling mess was only ever used by one company.

You know what, though? Talking about this reminds me of another story about the same e-commerce application.

After a customer placed an order on this e-commerce site, the company’s fraud department had to evaluate the order to make sure it wasn’t fraudulently placed. (As in, with a credit card not owned or authorized for use by the purchaser.) Once that was done, the order had to be communicated to a worker at the warehouse so they could pack the right items into a box, put on a shipping label, and set the box aside to be picked up by the UPS truck which would come once a day near the end of the day.

The application used by the fraud department and the application that displayed new orders to warehouse workers was one and the same application. Whether a user had fraud-evaluating powers or pack-items-in-boxes powers just depended on what permissions their particular user had. (That may have been decided by LDAP groups. I don’t remember for sure.)

Meanwhile, the e-commerce site offered gift cards for sale online. The gift card would be shipped to the customer. And there was a box where you could write a message associated with the gift card. So, for instance, someone could buy a gift card to be sent to their nephew’s address or whatever and include a little note like “Happy Birthday. Don’t spend it all at once.” or whatever. And the fraud/pick-and-pack application would display all details of the order including any messages associated with the gift cards.

Well, I found a stored cross-site scripting vulnerability where if you put <script>...</script> tags with some JavaScript in the gift card message box and completed the order, the JavaScript would execute any time someone viewed the details page for the order in the fraud/pick-and-pack application. And of course, the JavaScript could do within that application just about anything the user could do with their given permissions.

The main danger was that a malicious actor with sufficient knowledge of how our fraud application worked could place an order fraudulently with someone else’s credit card and include in the order a gift card with a malicious JavaScript payload in the message box, and then that malicious JavaScript could automatically mark the order “a-ok, no fraud here” when a fraud department worker loaded the order details page, letting the order be fulfilled without any actual fraud review.

The fix was pretty simple. Just stick a <c:out>...</c:out> in the appropriate place in the fraud/pick-and-pack application code. But it was an interesting example of a vulnerability in a not-customer-facing application that could none-the-less be exploited by any public customer/user without any particular special access.

If you’re interested in one more interesting story about the same e-commerce application, see this comment I made a while ago.

Never roll your own ORM

I’ve done this. Probably 10 years ago. Even today, I maintain the same application that has the ORM in it that I designed. If I could go back in time and do something else, I’d do the same thing again. Honest to god. For my use case, I feel it was warranted. It was risky, but it worked out surprisingly well.

Java webapp. Customer facing. E-commerce application, so in PCI scope and dealt with credit card info and such.

There was one specific cookie that stored some site-wide preference for the customer. (Why not just put that preference in the database associated with the user? Because that would make too much sense is why.)

But the way they encoded the data to go into the cookie? Take the data, use the Java serialization framework (which is like Python’s “Pickle” or Go’s “Gob”) to turn that into a string. But that string has binary data in it and raw binary data is kindof weird to put in a cookie, so you base64 encode the result. (The base64 encoding was the only sane step in the whole process.) Then you do the reverse when you receive the cookie back from the browser. (And no, there was no signature check or anything.)

The thing about the Java serialization framework, though is that decoding back into Java objects runs arbitrary object constructors and such. As in, arbitrary code execution. And there’s no checking in the deserialization part of the Java serialization framework until your code tries to cast the object to whatever type you’re expecting. And by that point, the arbitrary code execution has already happened. In short, this left a gaping vulnerability that could easily have been used to extremely ill effect, like a payment information breach or some such.

So all a malicious user had to do to run arbitrary code on our application server was serialize something, base64 encode it, and then send it to our servers as a cookie value. (Insert nail biting here.)

When we found out that there was a severe vulnerability, I got the task of closing the hole. But the existing cookies had to continue to be honored. The boss wasn’t ok with just not honoring the old cookies and developing a new cookie format that didn’t involve the Java serialization framework.

So I went and learned enough about the internal workings of how the Java serialization framework turned a Java value into a binary blob to write custom code that worked for only the subset of the Java serialization format that we absolutely needed for this use case and no more. And my custom code did not allow for arbitrary code execution. It was weird and gross and I made sure to leave a great big comment talking about why we’d do such a thing. But it closed the vulnerability while still honoring all the existing cookies, making it so that customers didn’t lose the preference they’d set. I was proud of it, even though it was weird and gross.

The value that was serialized to put into the cookie? A single Java int. Not a big POJO of any sort. Just a single solitary integer. They could just as well have “serialized” it using base-10 rather than using the Java serialization framework plus base64.

Star Trek: Voyager. I was raised on that shit. Not objectively the “best” Star Trek. (Far from the worst, though.) But it’s the one that’s most nostalgic and, indeed, “cozy” for me.