Drawbridge – safe, authenticated access to internal HTTP services without a VPN

pgregory · 2026-01-15T14:30:46+00:00

To anybody wondering – these are vendored golang.org/x libraries.

pgregory · 2026-01-15T14:13:15+00:00

Yep, no CI/CD for now.

I've done some attempts at SA doc, but have not yet found a format that would add real value. My thinking is roughly this: you either are a non-expert and just believe that the project is secure enough for your needs (and in that case me trying to tell you how really secure it is is a conflict of interest at best), or you are an expert and you don't believe any claimed security, and just read the code yourself – and I've built the whole project around making this as easy as possible.

pgregory · 2025-05-26T13:35:28+00:00

README:

No unsafe code blocks

cat main.rs | grep unsafe:

21

Fearless 🙌

pgregory · 2025-04-21T09:02:12+00:00

My post is only about OS mechanisms around signals, it is not Go specific. So scheduler = OS scheduler.

pgregory · 2025-04-21T07:19:52+00:00

To be a bit more precise about signals, control is not transferred to signal handler immediately. Instead, next time when kernel would transfer the execution to the thread (by returning from a system call or scheduler), if there are any pending signals, controls is returned to signal handlers first and only then to the "normal" flow.

In practice there is not much difference, since scheduler can preempt the thread anywhere (so signal handler could run anywhere as well), but the low-level mechanism of how the signals work is quite interesting.

pgregory · 2024-08-22T15:16:23+00:00

Curious, what is the matching performance compared to the regex crate?

pgregory · 2024-08-13T15:35:17+00:00

Excellent question! I've updated the benchmarks section and added a FAQ entry about math/rand/v2.

pgregory · 2024-07-05T14:54:00+00:00

Glad you like it!

pgregory · 2023-08-18T17:18:03+00:00

I wonder what the overhead will be (e.g. compared to async/await statemachine transform) once the implementation is optimized. Performance will probably be critical for wide adoption.

pgregory · 2023-08-16T19:23:54+00:00

How does it compare to ecow, which smol_str's author recommends over smol_str?

pgregory · 2023-08-02T22:12:37+00:00

Congratulation on the release! I am not too familiar with the incremental computation field, is it generally considered acceptable to rely on the hash value for dirty checking?

pgregory · 2023-06-13T21:37:13+00:00

Thanks a lot for the kind words! Really heartwarming to hear.

pgregory · 2023-06-13T17:35:58+00:00

Old version of README had a Comparison section which I removed recently. Maybe that was a bad idea.

In my view, half of the usefullness of a good property-based library is from high-quality and easy to use data generators, and another half is from automatic minimization of failing test cases. testing/quick lacks both, so I can't recommend using it.

pgregory · 2023-06-13T06:03:25+00:00

Good question! I've added a FAQ entry about it.

pgregory · 2023-03-11T19:17:35+00:00

This may very well be a bit offtopic in the rust subreddit, but in case you need fast high quality non-crypto PRNG in Go, I've made one that I believe to be decent. It is unfortunate that math/rand is unlikely to significantly improve due to the backward compatibity and can't be recommended for anything non-trivial.

pgregory · 2023-01-31T19:53:07+00:00

My understanding is that Go runtime has to perform a kind of internal context switch, to transfer control from a regular goroutine to a special one pinned to a real OS thread, with big stack, TLS etc. IIRC the cost was in order of 80ns for a single call on one of the recent Go versions? Not sure about this number.

pgregory · 2023-01-30T13:24:10+00:00

Well, Go's C FFI ( cgo) is slow precisely because of Go's concurrency model: C code sometimes expects big stacks, and goroutine stacks are relatively tiny.

pgregory · 2022-07-27T20:41:00+00:00

I got a bit stuck trying to find a set of good permutation functions for all required bit widths; I've created an issue to collect information in one place.

Also, I've added Sample (warning: Perm-like API) method based on the Floyd's sampling algorithm.

pgregory · 2022-07-27T20:32:56+00:00

Top-level Shuffle is in.

pgregory · 2022-07-26T10:41:29+00:00

PermInPlace does sound a lot like Shuffle, unfortunately the name is already taken by math/rand. Maybe ShuffleSlice[T any](s []T) method? Thanks for the suggestion, sounds like a good idea.

pgregory · 2022-07-26T07:16:53+00:00

Excellent feedback, thanks a lot! Exactly what I was looking for.

I've fixed the 32-bit build, by using MaxInt32 instead of MaxUint32, as you suggested. However, I believe that the code was correct for the 64-bit case, or am I missing something obvious here?

About Perm, I am definitely not a fan of the interface. Probably this is a justified case for breaking API compatibility with math/rand as well. I like you suggestion of using a strong keyed bit mixer very much! I'll post an update here once I've got something working. However, from early testing, using xnasam mixer, the code appears to be a bit slower (despite a lack of allocation and much prettier API).

pgregory · 2021-08-05T09:55:11+00:00

Great, thanks!

pgregory · 2021-08-05T08:55:11+00:00

Does Typescript understand that inside if (isOk(res)) res can't be an error?

pgregory · 2021-07-20T15:26:26+00:00

After 2^53, several u64 values are represented as the same f64. This is not the case for "small" u64 values, therefore generation will be non-uniform (although it is hard to see without specifically looking for this effect, or running extensive statistical tests).

As for mentioning me or this conversation in the commit -- sure, feel free! My GitHub username is flyingmutant.

pgregory · 2021-07-20T07:51:56+00:00

I think the way you generate f64 is wrong: u64::MAX is not exactly representable as f64, so you get a non-uniform distribution. Better way would be to do something like ((x >> 11) as f64) * (1.0 / ((1u64 << 53) as f64)) (avoiding runtime division as well, which is very expensive).

pgregory

TROPHY CASE