jamilbk

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.

Are you referring to the macOS client app? It's built in Swift with an FFI bridge to the Rust-powered connectivity layer. Source is here: https://github.com/firezone/firezone/tree/main/swift/apple

Appreciate the feedback! Will certainly plan to take the product demos up a notch going forward.

Thanks for the support!

This is a fairly common scenario and one that we had in mind when building the NAT traversal implementation. The short answer is that you wouldn't need to sign out of Firezone when in the office -- the connection should hairpin off the nearest common router and go directly to the SMB share in this case.

Ah yes, don't get me started on all the fun edge cases involved in supporting cross platform network stacks and all their subtle tunnel API differences :-)

We're trying to stay focused on keeping policies easy to define and manage so that access management is... manageable as you scale. That and the fact data doesn't go through the cloud / intermediary have been a couple of the reasons customers say they prefer us.

Definitely an exciting space to be building in!

I may not be fully understanding the question, but I think you may be referring to DNS-based resources? Those will allow you to manage access to an app or service by its DNS name (wildcards supported). You can also use IP or CIDR resources as well of course.

In terms of scalability, are you referring to throughput or simply the complexity of policy management as the number of resources grows?

For simple access needs, in Firezone you would likely configure a CIDR resource and grant the Everyone group access to it, which mimics the setup of a traditional VPN. It is a couple extra clicks, though.

Thanks! We're similar to Twingate in how we model resources, but our policy system has optional conditions you can apply to restrict access further, which works a bit differently. We expect to continue building in that area over time. We also use WireGuard as a transport while I believe Twingate operates over QUIC.

Good question! The main difference is how access is managed. Instead of configuring ACLs, you define policies which are a 1:1 mapping between a user group (manually created or synced from your IdP) and the resource you want to allow access for. Another difference is how our load balancing / failover system works - it's automatic across all the Gateways in a particular Site.

From the diff introducing the bug [1], the issue according to the analysis is that the function was refactored from this:

  void
  sigdie(const char *fmt,...)
  {
  #ifdef DO_LOG_SAFE_IN_SIGHAND
   va_list args;
  
   va_start(args, fmt);
   do_log(SYSLOG_LEVEL_FATAL, fmt, args);
   va_end(args);
  #endif
   _exit(1);
  }

  void
  sshsigdie(const char *file, const char *func, int line, const char *fmt, ...)
  {
   va_list args;
  
   va_start(args, fmt);
   sshlogv(file, func, line, 0, SYSLOG_LEVEL_FATAL, fmt, args);
   va_end(args);
   _exit(1);
  }

What could have prevented this? More eyes on the pull request? It's wild that software nearly the entire world relies on for secure access is maintained by seemingly just two people [2].

[1] https://github.com/openssh/openssh-portable/commit/752250caa...

[2] https://github.com/openssh/openssh-portable/graphs/contribut...

The article provides a very detailed exploration of all of the fun challenges you can face designing FFIs with Rust, but there's a good chance you can "get away" with simpler approaches if you think ahead a bit.

In our case, we call into Rust from Kotlin using JNI [0] and Swift using swift-bridge [1]. Thankfully our use case for the FFI [2] is for non-performance-critical calls and the data structures are fairly simple, so we just serialize objects with JSON.

No major issues so far.

One thing I am surprised hasn't been mentioned so far is Mozilla's UniFFI [3] which seems to solve some of the issues brought up in the article. We plan to switch to that once our FFI requirements become more complex.

[0] https://docs.rs/jni/latest/jni/

[1] https://github.com/chinedufn/swift-bridge

[2] https://www.firezone.dev/kb/architecture/tech-stack#client-a...

[3] https://github.com/mozilla/uniffi-rs

I hope this will allow running NetworkExtensions in VMs as well. As it stands today, it's only possible to run NetworkExtensions on physical Apple hardware, making it a pain to apply any modern CI-based workflow to them.

The author's conclusion to question of "are timing attacks viable?" seems to be... it depends on the nature of the language or library. Are most devs going to understand these nuances though?

In the time it takes to research the timing behavior of your runtime, you could have reached for a constant-time comparison instead.

Similarly, in the time it takes you to reach the conclusion the comparison you're using isn't vulnerable, you could have reached for a secure compare instead.

I'm not convinced this post makes a compelling case against the best practice of always using a secure compare for secret strings.

Just a quick note -- 1.0 goes a little further and rotates the WireGuard keys upon each auth session, so the private key never leaves the tunnel process memory. You need the Firezone client for that, though.

That's neat!

But how is everyone testing their Swift codebases? We've found the story around testing to be... lacking. The [docs](https://developer.apple.com/documentation/xctest) on the subject are pretty bare and don't offer strategies for mocks, stubs, reporting, code coverage, etc.

And good luck if your app uses a Network Extension... those must be tested on a live physical device due to the signing restrictions!

On that note, does anyone know of a good physical device CI service that supports both iOS and macOS devices?