A couple weeks ago I read an article about a guy who set up a caching DNS server for his home network on a Raspberry Pi. The main thrust of the article was, “Hey, checkitout, Cloudflare has a public DNS at 18.104.22.168 and they pinky-swear promise not to write down what IP address originated the resolution request for wombatporn.com or even overthrowthegovernment.com,” but it did get me thinking about the Pi.
Until reading that article, I thought of the Pi as being a cool (I guess) thing if you wanted to build a robot (to do some dumb thing that I don’t wanna do) or if you wanted to let people on the Internet control your irrigation system (what could possibly go wrong?) but that was just my misunderstanding. The cool thing about the Pi is that it’s a super low-power actual computer running an actual operating system that you can use, and it costs hardly anything.
So, I bought a Pi Zero-W and installed bind on it. Ever since the FCC decided that it’s okay for ISPs to provide different service levels to sites based on their whim, I’ve been thinking about how that really hoses applications that depend on the network being always on. So that got me thinking about store-and-forward and periodic connections to the Internet (psst, there’s this awesome thing called “mosh” that’s pretty cool) and inevitably that raises other questions like, “Who’s looking at your traffic,” and, “What if you don’t want your hotel to be providing all your packets to GCHQ?”
Well, I thought and poked and installed OpenVPN on the Pi and, third time around*, got a configuration that lets my laptop connect. However, it doesn’t seem to route traffic properly (at all) and I was never a network engineer. This is going to be a heck of a learning experience.
* It turns out that the micro-USB port on the Pi Zero-W doesn’t actually work. I tried several different connectors on it and nope, keyboard and mouse didn’t work. So I got to do a complete headless setup and spend an afternoon debugging that. Then, the first time around with OpenVPN, the server would start up and then immediately shut down again. Then, the server would start up but the client’s certificate somehow didn’t match what the server expected, so the connection would fail. Regenerate the client, turn off some options in the server, and finally it all connects, but the Internet isn’t reachable over the tunnel. Well, maybe it’ll be better when I’m not on the network I’m tunneling to.
Unless you are a programmer, it mostly isn’t. Yet. However, if you are a programmer or if you want to send and receive secure messages, then it is kind of interesting. One interesting thing (for programmers) is that it gives you free encrypted git repos. That’s rad. Also, if you want to start sharing the repo with someone, that’s pretty easy, too. Another really neat-o thing is that you can send an encrypted message to a keybase user without having to figure out how to install PGP, how to integrate it with your email client, or how to look up your recipient’s PGP key. That’s pretty cool.
Today I received the April newsletter from JetBrains, wherein they provide links to a bunch of Java news. Most of it is stuff that isn’t immediately interesting to me, but this time there was a swell one-two punch. One, Java 10 is out and Java 11 has been announced (what? 9 just came out, like, a few days ago, right?). Two, JavaFX is gonna be deprecated and won’t even ship with Java 11, so if you want to build a GUI app with Java you’d better dig out all your old broken-ass Swing/AWT tools and get happy about that.
Hey, JetBrains? Would it be too much to ask you to build a nice Maven packaging plugin for your interface builder stuff, and while you’re at it, can you update your UI builder plugin so it works, again? Sheesh.
A five hour flight is enough time to write several unit tests. So, yesterday I started working on the band sets for 2019 and I wrote tests and new library functions and fixed a latent bug in an old library function. And now we’re in Hawaii!
Today I learned a couple of things that they don’t tell you in the official documentation or on Stack Overflow. If you want to display some information in a table and that information updates and you want to display those updates, then you have to hook things up the hard way, and not the way everyone tells you to do it.
Continue reading “TableColumn and ObservableValue”
Several days and a lot of testing later, I think I have the answer: don’t try to build a play-by-email service in Google AppEngine. The limitations imposed by the environment make it a bad place to do a lot of email traffic that requires anything other than text/plain or text/html. Because Google has defined javax.mail.Transport to use the AppEngine mail service, you can’t choose to connect to a different SMTP host; if you specify an external SMTP server (such as SendGrid or Pobox) in the Session, Google’s Transport implementation ignores it and still uses the AppEngine mail service. When you try to use a web API to send your message through SendGrid, that screws up the MIME headers and your message won’t validate (if it’s even readable) at the receiver’s end.
That said, I have finally figured out how to prepare and send a PGP signed MIME message such that it arrives and validates properly. Since nobody else has written that down on the web (that I could find), I’ll detail the recipe here.
Continue reading “More MIME Tricks”
I’ve been working on adding play-by-email support to my turn-based game server. The first problem I hit was that the PGP signatures on the server’s messages were invalid when I checked them on my email client. This led to lots of debugging and unit tests in my crypto utility. That’s not really wasted effort, but it also wasn’t the problem.
It turns out that even though the RFC limit on line length is 1000 characters and there are well-known implementation limits that are only slightly lower, there exists somewhere in the chain from Google AppEngine to Apple Mail some chunk of code that inserts newlines into lines that are much shorter. I didn’t do exhaustive testing, but it seems to happen before 80. The perfectly valid signatures were being rendered invalid because somebody was altering the message after the server signed it and handed it off to the transport agent.
The solution I chose was to use WordUtils from commons-text and to wrap the message at 70 characters before signing. This seems to work. It’s just kind of dumb that it’s necessary, but it’s a good reminder that the thing in your inbox may not actually be the thing sent to you by whomever, and that PGP signing your messages is a good idea even if you don’t encrypt them.
Xcode sucks. That’s why.
This evening I thought, “Hmm, maybe for my next project I’ll see about writing an iOS client for my turn based game server.” So I started looking at a Swift tutorial (the language irritates me so far, but that’s just because so far all the syntactic sugar is solving problems I don’t actually have) and it didn’t seem too difficult. So then I went looking for a PGP library that would work with Swift, and I found one.
So then I cloned the project to my Mac and tried to build it. Build failed. Why? Well, it turns out that I needed to install a utility called
xcpretty. No idea why, but that was easily solved. Then the build failed again. Why? Because some $@%! Ruby script wouldn’t execute. (Ruby? WTF? I thought this was an Objective C or maybe Swift compiler!) So then I had to get all comfortable looking for what Ruby wanted. Three scenes of Thor: Ragnarok later, I figured out to
gem install xcodeproj and now the build goes a bit farther, but now I’ve got another cryptic error message about how the link failed because the linker couldn’t find the
OpenPGP ObjectivePGP framework. The framework that the project is supposed to build.
You know what happens if I have a project open in IDEA and it’s missing a dependency? The missing dependency is underlined in red and the IDE will pop open a window where I could locate the missing thing. You know what happens in Eclipse, with the same situation? Same thing. MPW? Xcode? Nah. Apple’s developer tools reckon that it’s enough just to say, “Nah, that didn’t work.” User-hostile and user-abusive interface.
Last post I wrote about wanting to write a text-only Twitter client. So, now I’ve done that. It’s not 100% functional and there are still aspects of JavaFX UI that I’m wrestling with (getting buttons to line up the way I want seems to be way harder than it ought to be), but I reckon the application’s ready for people to try out. Currently I’m only building a MacOS installer, but if you’re interested and you want to give it a whirl, you can grab it at https://keybase.pub/sbeitzel/. I’m calling it “TwitterCrank”, since it’s sort of a Twitter client for cranky people (me). Things it does: read your feed, posts tweets, reply to tweets, retweet tweets. Things it doesn’t do (yet): handle direct messages. Things it doesn’t do (and won’t): display inline images, autoplay video, insert promoted tweets in your feed.
I’ve started developing a text-only client for Twitter. The impulse came from getting fed up with all the auto-playing promoted tweets that were clogging my timeline. I looked around and found a library to handle all the Twitter API calls and started coding. The example code was all a bit bare-bones, but mostly it was straightforward. The one thing so far that I think could use a bit more explanation is the login process, and that’s the point of this post.Continue reading “OAuth, twitter4j, and JavaFX”