#Google is working on a new libc implementation, hoping to include it in #llvm: https://lists.llvm.org/pipermail/llvm-dev/2019-June/133269.html
Boom! LLVM 8.0.0 update has hit the tree! ☺️ #OpenBSD -current
RT @mjg59: “Do not take programming advice or security advice or, actually, any kind of advice from this man”
2.5.14: 2019-06-20:: Redirect segfault to a graceful exit. Tired of meaningless fuzzer bugs.
Someone reported a …. out of bounds read leading to a null pointer deref. https://gitlab.com/esr/gif2png/issues/5#note_183639541
“this program is not expected to be able to deal with arbitrarily broken input”
oh yes good thing that the only time someone might want to convert a gif to a png is with wholly trusted input
RISC-V formal spec public review at https://github.com/riscv/ISA_Formal_Spec_Public_Review/blob/master/README.md#when-and-how-to-provide-feedback-and-what-happens-next - discuss at https://freepo.st/freepost.cgi/post/1r85ut9jvl #freepost
@cperciva: I just figured out how to safely and portably close a file descriptor in a multithreaded process without running into problems with EINTR. It only took me ~7.5 years after writing this blog post: https://www.daemonology.net/blog/2011-12-17-POSIX-close-is-broken.html 1/
@cperciva: Run once: 1. Create a socket pair s. 2. Write a random cookie into s. To close(fd), wrapped in a mutex: 1. dup2(s, fd) until it succeeds or fails with !EINTR. 2. close(fd). 3. If we got EINTR, recv(fd, MSG_PEEK). 4. If we read the random cookie, goto 2. 2/
@cperciva: The first trick here is that unlike close(), dup2() has well-defined semantics in POSIX with respect to EINTR: It's atomic, so there's no way for another thread to accidentally reuse the same descriptor # between the implied close and reopen. 3/
@cperciva: The second trick here is that while we can use dup2 to guarantee that the original descriptor was safely closed, we now need to close the duplicate -- but we can distinguish between "EINTR and closed" and "EINTR and still open" by seeing if MSG_PEEK returns our magic cookie. 4/
@cperciva: If we're on a perverse OS where close(fd) can successfully close the descriptor and still return -1 / EINTR, and another thread wins a race and reuses that descriptor, there's still no way we'll see our random cookie, so we won't make the mistake of trying to close it again. 5/
@cperciva: I'm not sure that I would recommend this approach to anyone -- but it's nice to know that closing a file descriptor in a multithreaded process is in fact possible.
HBO Chernobyl views
I’m going to go against the current on this one because I think HBO’s Chernobyl does a disservice to the truth.
I watched it twice through, taking notes, and my main gripe is how the complexity of the accident has been turned into two main “baddies”, American-style: the people in charge and the Soviet state.
This is not about pronouncing their innocence but about the way the portrayal over-emphasises them as “baddies”. This necessity to create “real baddies” avoids…
"...dogs’ faces are structured for complex expression in a way that wolves’ aren’t, thanks to a special pair of muscles framing their eyes. these muscles are responsible for that “adopt me” look that dogs can pull by raising their inner eyebrows. it’s the first biological evidence scientists have found that domesticated dogs might have evolved a specialized ability used expressly to communicate better with humans."
Turns out it's hard to use modern cryptography libraries with safe APIs once you get just ankle deep in this stuff. The only one that actually lets you get all pieces working together is good old #OpenSSL (or good new #LibreSSL if you will).
% egrep -wR "(BigNum|EcGroup|EcPoint)" . | wc -l
Wish it was approaching 0.
Here is another #OpenBSD athn(4) diff which I would appreciate test reports for: https://marc.info/?l=openbsd-tech&m=156024805719957&w=2
Bonsoir, j'ai fait une tarte à la rhubarbe.
Interested in #Coreboot? Fancy hardware-oriented development? We are looking for you!
An aspiring software engineer. Mastodon fan. I speak for myself.
Exclusive or something