Forem: Bob Matcuk

Examine SSL Cert

Bob Matcuk — Mon, 15 Feb 2021 18:09:33 +0000

Need to check when your SSL cert will expire?

openssl s_client -connect $SERVER:$PORT -servername $SERVER 2>/dev/null | openssl x509 -noout -dates

$PORT will likely be 443 - -servername is required if the server is hosting multiple websites.

Comparing package-lock Changes

Bob Matcuk — Mon, 31 Aug 2020 14:12:55 +0000

I recently updated some dependencies in a node project and some things broke. I wanted to get a list of every dependency (and dependencies of dependencies) that changed, so I came up with this little one-liner.

You'll see that I'm passing two "files" into diff via I/O redirection. I'm using git to retrieve the two files - the commit that updated the dependencies had a git hash of 735e8cd3c. So, the first file is 735e8cd3c^:package-lock.json (notice the caret - that means the parent commit of 735e8cd3c - ie, the version before I updated dependencies). The second file is 735e8cd3c:package-lock.json (no caret - ie, the version where I updated dependencies).

I then pipe each file into jq (jq '.dependencies | map_values(.version)') to extract the name and version of every package my project depends on (that includes dependencies of dependencies).

Finally, diff will tell me what changed.

diff <(git show 735e8cd3c^:package-lock.json | jq '.dependencies | map_values(.version)') <(git show 735e8cd3c:package-lock.json | jq '.dependencies | map_values(.version)')

iPad Sidecar Issues Over USB with VPN

Bob Matcuk — Mon, 03 Feb 2020 20:16:17 +0000

When I'm working away from home, I like to use my iPad as a second monitor using Apple's "sidecar" feature. However, I noticed that, if the wifi network isn't great, there can be some performance issues or disconnects. So, I wanted to use a USB cable instead.

This worked fine, until I switched on my company's VPN. Within seconds, sidecar disconnected with a cryptic error message. Any attempt to reconnect failed with odd behavior (I'd get an error in OSX, but a black screen would load on the iPad).

Turns out: VPN clients will disable IPv6 unless the VPN configuration has explicit support for IPv6. The reason for this is that a large majority of VPNs are not configured for IPv6, so any IPv6 traffic will bypass the VPN. If you're attempting to use the VPN to secure all of your internet traffic, this is a problem! All of your IPv6 traffic will "leak".

It also turns out that connecting your iPad via USB makes it appear as a virtual ethernet device, configured to use IPv6. So, connecting to the VPN disables IPv6 and sidecar can no longer communicate with the iPad.

However, I'm not using a VPN to secure all of my traffic—just the traffic to my company's network. All of that traffic is IPv4 anyway, so, this security feature is lost on me. Disabling it solves all my sidecar issues! Woo!

So, if you're in the same boat as me, trying to use sidecar with a VPN, try searching through your VPN client's settings or documentation for this feature and disable it. Here's how to do that with tunnelblick:

Click on tunnelblick's icon in the menu bar
Select "VPN Details"
Click on "Configurations" at the top
Select your VPN configuration from the left-hand side
Uncheck "Disable IPv6 unless the VPN server is accessed using IPv6"
You may need to restart the VPN?
Profit.

Debugging Rust with rust-lldb

Bob Matcuk — Mon, 20 Jan 2020 04:19:38 +0000

This is a quick and dirty primer to debugging rust applications with rust-lldb.

Start the Debugger

Assuming you are using cargo to build your executable, the first problem you'll run into is that you cannot debug target/debug/BIN; instead, you need to debug target/debug/deps/BIN-HASH where BIN is the name of your program, and HASH is a random hash... you'll probably have a ton of builds in the deps directory; just use the latest (something like ls -lt target/debug/deps/BIN-* should help you find the latest).

If you're trying to debug an example program, they'll live under target/debug/examples/BIN - no hash nonsense.

Ok, now you can start the debugger:

rust-lldb target/debug/deps/BIN-HASH -- arg1 arg2 ...

Where arg1 arg2 ... are command line arguments to your application. If your application needs no arguments you can just leave them off.

Breakpoints

You are now in the lldb debugger. You'll probably want to set some breakpoints before your program starts: you do that with the breakpoint set command (shorthand: b). There are lots of ways to set your breakpoint (specific file and line number, function name, etc). Type help breakpoint set to see documentation. The shorthand, b, actually accepts a simpler syntax from which it will guess the right thing to do. For example:

breakpoint set --name func
b func

These two commands will do the same thing. So will:

breakpoint set -f src/path/to/file.rs -l linenr
b src/path/to/file.rs:linenr

Run help b to see the simplified syntax.

You can see a list of your breakpoints with breakpoint list. There are additional things you can do with breakpoints: see help breakpoint.

Running

Once you've set your breakpoints, you can start the program with run (shortcut r). Execution will continue until a breakpoint is hit or the program ends (intentionally or not).

Examining Program State

Ok, so your program is running and it hits a breakpoint. Now what? You'll probably want to examine the state of your program to get an idea of what's going on. Here are some commands to get you started:

frame variable will show you all the variables in the current "frame"; ie, variables in scope.

expression <expr> (shortcut expr or just p) will execute <expr> and display the result. This can be used to examine the value of a variable or execute some code to see what the result is.

You may have noticed when execution first paused that a listing of your code is shown, pointing to the current line that execution paused on. You can get that listing back with list (shortcut l).

n will "step over" the current line, ie, the current line will execute and then the program will pause again.

s will "step into" the current line, ie, the innermost function will be called and execution will pause at the start of that function.

c will continue execution until another breakpoint is reached or the program exits.

Finally, if you're debugging a program that interops with another language (ffi), it might be useful to examine specific memory addresses. That can be done with x <addr>. This will show a hex-dump of memory at that address.

Some Other Helpful Things

If you would normally invoke your program by piping something into stdin (ie, cat file.txt | my-program), you won't be able to do that when running your program under rust-lldb. Instead, run rust-lldb with your program (ie, rust-lldb my-program) and then run:

settings set target.input-path <path-to-file>

Conclusion

This is just barely scratching the surface of debugging. lldb is very powerful; judicious use of help is encouraged. But hopefully this little primer will get you started!

Disabling GateKeeper (OSX) for a Single App

Bob Matcuk — Sat, 18 Jan 2020 16:12:12 +0000

If you have an app that won't run on OSX (you get an error about it being "damaged" and it suggests that you should delete it), you can disable GateKeeper for that app by running the following command in a terminal:

xattr -rd com.apple.quarantine "path/to/file"

Of course, before you go this route, make sure you trust the app! GateKeeper exists for a reason.