jamilbk

Here's the NIST link: https://nvd.nist.gov/vuln/detail/cve-2026-98432

Here are my notes so far after digging into this with Claude + defensive access:

1. Not just an MPTCP thing - any received IPv4 packet with options creates the problematic conditions.

2. Also appears that using NetLabel/CIPSO (SELinux or Smack with a CIPSOV4 mapping) creates the same conditions that a packet with IP options would. If you're using these, it might mean that dropping IPv4 packets with IP options might not fully mitigate.

3. At least for our test VMs in Azure (accelerated networking) I wasn't able to get any IPv4 packets with options through, from three different US-based ISPs. Unfortunately Microsoft publishes no docs on whether the fabric drops this or not, so YMMV.

We're using a simple XDP program to mitigate until a patched kernel is available (thanks @tptacek for the idea):

https://github.com/jamilbk/drop-ipv4-opt

Whipped something up: https://github.com/jamilbk/drop-ipv4-opt

I came here to make a similar comment. It seems like TigerBeetle was built for exactly the type of transactional processing this post is about?

We just invested a good amount of time restructuring our docs for Diátaxis. It was helpful, but I wouldn't take it as gospel. The important thing to remember is that each piece of content should be one of the four types.

If you're embarking upon a refactoring / rewriting journey for your docs, the only advice I'd share is to actually read the website beginning to end before starting. Especially this page: https://diataxis.fr/complex-hierarchies/. The guide is (unsurprisingly) very well written, and it's easy to internalize the concepts because they're repeated often.

Yeah, the weight floor can be hit or miss with regards to striking convos with strangers. Many of the people there want to make friends too, but many just want to focus on their workout.

Two related contexts that I've found to be much more friendly for this:

1. Climbing gyms, for reasons mentioned previously

2. The sauna! Actually very ideal for convos with strangers. Max overlap time is ~15 minutes, people are generally relaxed, no phones to distract and if it doesn't go well either party can always leave.

I remember yanking out the onstar unit in my 2015 silverado to physically disconnect the cell antenna. This was (is?) the only practical way to disable cellular in that vehicle.

Kudos to Rivian for making this a supported user privacy feature.

At Firezone we started with soft-deletes thinking it might be useful for an audit / compliance log and quickly ran into each of the problems described in this article. The real issue for us was migrations - having to maintain structure of deleted data alongside live data just didn't make sense, and undermined the point of an immutable audit trail.

We've switched to CDC using Postgres which emits into another (non-replicated) write-optimized table. The replication connection maintains a 'subject' variable to provide audit context for each INSERT/UPDATE/DELETE. So far, CDC has worked very well for us in this manner (Elixir / Postgrex).

I do think soft-deletes have their place in this world, maybe for user-facing "restore deleted" features. I don't think compliance or audit trails are the right place for them however.

I don't fully understand the complaints about enshittification of open source permissively licensed software.

If the source code is available for you to fork, modify, and maintain as you see fit, what's the complaining really about?

Yes, the established standard here is known collectively as Interactive Connectivity Establishment (ICE) [1] which WebRTC relies on -- there are a few good libraries out there that implement it and/or various elements of it [2] [3].

libp2p [4] may be what you're after if you want something geared more towards general purpose connectivity.

[1] https://datatracker.ietf.org/doc/html/rfc8445

[2] https://github.com/pion/webrtc

[3] https://github.com/algesten/str0m

[4] https://libp2p.io

PRs welcome! We may not have much bandwidth to help, but happy to review anything that comes along. We can discuss further perhaps on a GitHub issue so the rest of the Firezone team can offer input: https://github.com/firezone/probe/issues/new.

I've exposed `Android` as a support OS. Give it a shot now.

Noted! I'll update it to use the Unix instructions in that case. Thanks for the feedback!

Unfortunately the app wasn't designed to intake test results from runs that didn't originate from itself. We wanted to make it harder to submit fake results, and didn't want to add a lot of friction around user auth and such.

Great! Did the test report the block accurately for you?

We have a few intrepid users self-hosting the entire Firezone stack, but we don't have documentation to support it (yet), and wouldn't recommend it for production. It's something we'd like to write and maintain eventually, even if only for smaller / hobby deployments.

We do have a self-hosted community support channel on Discord if you are feeling adventurous: https://discord.gg/DY8gxpSgep

I would recommend starting here with a local development cluster:

https://github.com/firezone/firezone/blob/main/docs/CONTRIBU...

You can read more about how we came up with the current implementation here:

https://github.com/firezone/firezone/issues/3553

We didn't invent these techniques. Host candidates are part of standard ICE:

https://datatracker.ietf.org/doc/html/rfc8445#section-5.1.1....

Firezone's DNS-based routing is able to manage access to multiple services independently, even if they share the same IP address. So you could for example allow access to gitlab.company.com but not jira.company.com even if they were on the same webserver / loadbalancer.

It took a couple iterations to get it right - lots of fun edge cases involved. We ended up having to build automatic NAT64 and 46 for DNS resources to handle some of them. We wrote a post on how this works: https://www.firezone.dev/blog/how-dns-works-in-firezone

In terms of attributes for allowing access, we currently support time-based, country/region-based, auth method, and IP-based, with more planned: https://www.firezone.dev/kb/deploy/policies#conditional-acce...

We don't support full-tunnel yet, but it's just around the corner. Track this issue if you're interested in its progress: https://github.com/firezone/firezone/issues/2667

Thanks!

Erlang/OTP has so far been an excellent platform to build on for a product like Firezone. We chose it specifically for its reputation for powering soft realtime systems. Phoenix Channels are an added bonus that allow us to push all updates where they need to go, in just a few hundred lines of code.

We couldn't be happier with the stack choice.