-
src
Read-only git conversion of OpenBSD's official CVS src repository. Pull requests not accepted - send diffs to the tech@ mailing list.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
Had a similar problem a couple years ago where I needed to use alternative DNS libraries to troubleshoot issues in a company's infrastructure.
Golang's rules for what implementation to use are found here: https://golang.org/pkg/net/#hdr-Name_Resolution
A really solid alternative DNS client implementation can be found here: https://github.com/miekg/dns. Real easy to read and vet compared to a few other libraries I ran into when working on this problem.
“changed it at some point” is not quite correct.
https://github.com/openbsd/src/blob/df930be708d50e9715f173ca...
Geez man, way to take things out of context. Let me fix your quote:
> Going through the libc is very unlikely to actually introduce vulnerabilities, especially if going through the lowest level function that directly wrap the syscall.
Sure, glibc has a bunch of bugs. But the lowest level of functions, that just wrap the syscalls, are very unlikely to have bugs. Here's the `read` implementation, for instance:
https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d...
All it does is delegate to the low-level syscall, with some extra handling around to handle async calls (which can be removed when compiling glibc yourself, but you're probably not doing this).
Here's clone:
https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d...
This one's written in asm, and you can't really simplify it all that much more.
All the functions that wrap the low-level syscalls are very hard to get wrong, really. Where the glibc bugs come from are the high-level functions, like pthread. But those can trivially be bypassed if necessary.
At least for rust, a librs would be hard to create due to the lack of a stable ABI. So even if you did a pure rust libstd (like the now defunct Steed[0]), you'd still need to either manually link that libc (breaking the mitigation), or rebuild your program each time the distro updates either libstd or the rust compiler.
I'm not sure what the situation for Go is. Assuming Go has proper support for dynamic loading and a stable ABI, it would be doable.
[0]: https://github.com/japaric/steed
This is a long standing issue in various open source projects that use Go, where they want to ship static binaries.
Most recently, this happened with Concourse and it's Fly binary: https://github.com/concourse/concourse/issues/3691
The developers don't want to use CGO, or when they do use CGO they disable the net part... and now stuff doesn't work.
Projects have to specifically build with cgo enabled on macOS, or else it fails.
I used lots of code from Musl, OpenBSD, and FreeBSD. I used Marco Paland's printf. I used LLVM compiler_rt. The list goes on. Then I stitched it all together so it goes faster and runs on all operating systems. See https://justine.lol/cosmopolitan/index.html and https://github.com/jart/cosmopolitan
The SYSCALL interface is a loose binding. The kernel can evolve all it wants internally. It can introduce new ABIs. Processes are also a loose binding. I think communicating with other tools via pipes and sockets is a fantastic model of cooperation. Same goes for vendoring with static linking. Does that mean I'm going to voluntarily load Linux distro DSOs into my address space? Never again. Programs that do that, won't have a future outside Docker containers.