I spent a good chunk of my week really deeply focused at work, and it’s difficult to share details of that without a ton of extra context. So this week’s retro is mostly focused on what’s been on my mind and what I’ve learned this week.

For my American readers, I hope you’ve finished your taxes. If not, finish reading this and then hop to it. Or don’t, I’m not your dad.

Increasing interactivity

I have a few things I’ve been thinking about for my site and figured I’d share the ideas in case anyone wanted to encourage or discourage me either way.

Self-hosting a Q&A application?

I’ve seen a bunch of folks using ngl for a Q&A service, usually sharing the results on social media. I think this app is pretty cool and I wondered if it would be interesting to host my own variation of it. A simple form where folks can submit questions (or answer questions I pose), on my own site. Like a contact form but with much less baggage than a contact form typically carries.

I think if I were to further explore this idea, I’d have to also consider anti-spam measures – I currently don’t have any forms or other interactivity on this website, so I haven’t needed anti-spam yet. But it seems like mCaptcha could be a good option if I want to provide captcha-like protection without embedding third parties like Google or Cloudflare into my site.

Newsletter?

Should I offer an option to sign up for a newsletter, so you can get emails of my posts? I realize far more people have email inboxes than have RSS readers. I’ve looked into hosting my own newsletter software a bit and listmonk seems like one of the best options, but would probably require a fair bit of manual steps to send out emails, and it has a few edges that I don’t particularly like.

An alternative would be to use hosted newsletter services like beehiiv or Buttondown. I’ve seen a lot of people I respect using Buttondown, it seems like it has a lot of the features I would want, and I love their transparency and their privacy stance. But I also just really like being able to host my own stuff and not asking people to give up their info to third parties.

Cursed Docker Compose Technique

I discovered a cool, but maybe a little cursed, thing you can do with docker compose this week. Consider the following directory structure.

For historical business reasons, each app in this directory is it’s own separate git repository. Merging the git repos isn’t very tenable for one reason or another.

app1 is your primary application, and it has some database services and stuff that you stand up when you are developing locally. But you also need to launch app2 and app3 in order to accurately do development locally. You have a docker-compose.yml in your app1 already, so when you’re in that project you can just run docker compose up and it brings up all your dependencies. Except app2 and app3. You have to open new terminals and start those services separately.

Annoying.

version: "3.9"

services:
  app1:
    build:
      context: .
      dockerfile: ./Dockerfile
    ports:
      - "127.0.0.1:8001:8001"
    depends_on:
      - db

  db:
    image: postgres:latest
    expose: 5432
    environment:
      POSTGRES_PASSWORD: "password"

It turns out you can go up directories inside of a docker-compose.yml file. Assuming app2 runs on port 8002, and app3 runs on port 8003, we can modify our compose file like so:

version: "3.9"

services:
  app1:
    build:
      context: .
      dockerfile: ./Dockerfile
    ports:
      - "127.0.0.1:8001:8001"
    depends_on:
      - db

  app2:
    build:
      context: ../app2/  # a little path traversal, as a treat.
      dockerfile: ../app2/Dockerfile
    ports:
      - "127.0.0.1:8002:8002"

  app3:
    build:
      context: ../app3/  # a little path traversal, as a treat.
      dockerfile: ../app3/Dockerfile
    ports:
      - "127.0.0.1:8003:8003"

  db:
    image: postgres:latest
    expose:
      - 5432
    environment:
      POSTGRES_PASSWORD: "hunter2"

Now we can run docker compose up and our applications in other repositories can also be built and launched with the one command. You can also bind mount the respective directories into these compose services so that you can get hot reloading when you change files in any of the 3 repos. The only requirement is that developers place the repositories next to each other – most developers I know already do this.

This is a pretty cool feature that I didn’t know about, but that will help our team at work more easily work in multiple repositories that are all pretty tightly coupled. I would recommend using profiles to not start up these services unless you opt-in, though – the goal is to make it easy to have one command that stands it all up, not necessarily to force everyone to run all services all the time when developing locally.

I’m glad I figured this out when I did, because I was on the verge of doing some really cursed symlink stuff to try to create one master compose file that would allow any developer to run docker compose up and have our entire application stack running locally with no other commands. This is way easier.

Building my own dev tunnel service

I spent a good portion of my week working on, and writing about, an unexpected project where I decided I wanted to build my own dev tunnel service. Think ngrok, Tailscale Funnel, Microsoft DevTunnel, and probably a dozen other services.

But I took a different approach, bodging together some interesting features of nginx, openssh, and a little bit of bash to glue things together. Check it out if you’d like to build your own dev tunnel and maybe learn something along the way.

What I’m Reading

The Bezzle

By Cory Doctorow

ISBN: 978-1-250-86587-8
Learn More

---

I’ve only just started this book after wrapping up The Internet Con. I am excited to dive in, though, as I really enjoyed Red Team Blues. Martin Hench is a fun character and I enjoy the mix of things that mirror reality and the fictional elements.

Interesting Links

• Load Balancing - An incredibly well done walkthrough of how load balancing works, complete with very useful visualizations and a playground so you can test out the different algorithms.
• Incomplete List of Mistakes in the Design of CSS - A list of mistakes that the CSS Working Group has outlined about mistakes made in the design of CSS. Doubles as a useful first stop if you’re wondering why something doesn’t behave the way you expect in CSS.
• Front-end development’s identity crisis - This was the first article I read from Elly and I thought it was really good - so much so that I spent a fair bit of time browsing her site afterwards.
• Honest Security - I was reminded of Honest Security this week. Produced by Jason Meller of Kolide, it is a guide for honest endpoint security. I demo’d Kolide a couple years ago and liked it. We didn’t end up going with it, but I really like this idea of Honest Security.
• Starting Up Security - I’ve been thinking about potentially working on a project for a new business owner to quickly get aligned with best practices, and I was reminded of this collection of essays by Ryan McGeehan.
• getsops/sops - I haven’t used this yet but as I’ve been slowly exploring the NixOS world, the way sops appears to work seems really useful for managing secrets. I’m curious if I can combine the age key support with age-plugin-yubikey to have hardware backed secret decryption.
• Magical, not magic - This is just a link to the tenets of Svelte. I’ve never used it, and am not really interested in using it. But I thought this line between magical and magic was a useful distinction to make, in a wonderful succint manner.
• Domain Name Industry Brief Quarterly Report (2023Q4) - I’d never heard of DNIB before and thought this was a really cool report around the general makeup of the internet’s domain name ecosystem. I’m really interested in domain names, so this was a cool discovery.

Upcoming Projects

• BSides Las Vegas Talk - I am wrapping up the outline for a talk idea that I’d like to submit to BSides Las Vegas. (Due: 2024-04-21)
• OWASP Global AppSec Training - I am toying with the idea of submitting a training around docker and dependency management. (Due: 2024-05-06)
• Defcon 32 Call for Artists - I have a set list put together and have been practicing. I need to put together a few more things and I’ll be ready to submit. (Due: 2024-06-01)
• Defcon 32 Call For Soundtrack - I recently wrapped up recording a new song, “Oh Dade”, produced by Mikal kHill. It still needs to be mixed and some finishing touches added, then I will be submitting it. If it’s accepted, it will debut on the Defcon soundtrack. If it’s not accepted, I will release it the same day I find out it’s not accepted. (Due: 2024-06-01)