Very fixable but something about reading strategies for proper use of the phone makes me really angry. It’s on me to be on guard and suspicious at all times instead of using the phone to make calls and not thinking about it besides that. Every way I can communicate is out to get me!
Since the NTP client is usually just drifting towards the server time with clock skew maybe this would only manifest as doing this process a little slower. If latency was even a problem in the first place.
Finding things on the internet can be really hard without reddit. SEO spam has gotten really good at making Google searches useless unless you add “reddit” on the end. Then it’s exactly what you need.
I think the idea of using their new libTLS api alongside it was there early on. Adding "easier, foolproof api => even fewer bugs" to the mix. But that didn't seem to get much uptake.
These messages come in waves for me. Maybe it is strategy that if I get them constantly I'll tune them out but 5+ over the course of a couple days once a month might trick me? Occasionally they are very determined to get a response and will add in some level of urgency to the message. One memorable series of messages was that an old friend had come into town and would like to grab dinner after work. When I didn't respond to that I got several more messages that the sender and other friends were concerned that I hadn't responded but could still make the reservation they had. Eventually telling me they'd call for a wellness check or something if I didn't respond.
I found the beep on lost (in this case, "lost" but not in a malicious way) tags to be pretty quiet or just not distinctive. While taking care of a friends cat with an airtag in the collar I kept thinking I was hearing a car down the block or maybe my PC was making a strange sound. Even knowing about the behavior and expecting to hear a beep I didn't pick up on it for several days.
Not really the same thing but I'm blood type O- and do the "Power Red" donation at Red Cross events. I have two units of blood taken out and the red cells and plasma are separated so the plasma can be returned along with saline to make up the difference in volume. I don't notice much of a difference besides feeling a little cold since the saline is at room temperature. However in that case I believe I'd only have ~10% of my blood volume replaced with saline.
Would a local DoH server making going between different networks a little clunky? I have unbound handling dns at home but the old way lets the network define where to get dns information and/or allow for multiple options. Seems like Firefox doesn't have that flexibility yet.
The PROT_WRITE tweak is interesting. Being able to enforce a bit of Write XOR Execute behavior in Write OR Execute arenas is nifty. It took this change for me to read into W^X and exactly what it entailed because my naive understanding was that the new no-syscall-from-writeable-page behavior would be almost identical in effect to the strict W^X behavior.
Most of the LibreSSL changes were removing features or platform support so I don't know how many of their changes were desired or applicable to OpenSSL.
Microsoft dual signs at the moment with SHA1 and 2. SHA1 is used by older versions of Windows and SHA2 by newer versions. This flips a switch so older versions of Windows use SHA2 too.
We will support 1.3 once the standard is firmed up and finalized (i.e. ceases to be coopted by vendors making changes to allow for people to continue to run moribund middle boxes that can't recognize a new protocol on the wire) Since there is effectively nothing wrong with TLS 1.2 with a sanely chosen cipher suite today, we believe a clean careful implementation is more beneficial than early adoption.
So there's no rush on the part of the developers to support it. Skimming the commits on that git mirror we can see 1.3 related commits started hitting late last year.
My manager pointed out this to me shortly after the video blew up. As soon as he saw the video he suspected something was up but it took him less than half an hour after work that day to track down a shocking amount of information about the people involved and conclude it was a fake. He's absolutely sure it was fake top to bottom because Mark Rober would have to have seen and edit out evidence of fakery in the original video.
It's cool ROP attacks are being mitigated from two directions in OpenBSD. The amount of useful gadgets are being reduced by efforts detailed here AND gadget rich libraries are being relinked at boot or upgrade time. So even if a ROP attack can be found after the reduction in gadgets each machine will need a unique ROP chain.
I'm really liking OpenBSD as a router for those reasons but it's certainly more work intensive. I'd argue not that much but as soon as you start telling people to ssh into a box and fire up vi you've justifiably lost most people. Even technical people since OpenWrt offers all of the features with far less pain.
Unveil is programmatic so the developer can restrict the software to only perform expected behaviors. Like the earlier pledge(2) call OpenBSD introduced a few versions ago. A piece of software may have far more access to the filesystem than is needed. So it can be restricted to the handful of directories or files that it actually needs during execution. And it can progressively relinquish access as it runs and end up in a state where it can't access the filesystem at all.
OpenBSD's filesystem restriction utility is starting to be implemented in the base system. This first large commit from Theo de Raadt is intended to give an example of the intended usage of unveil(2).
I don't think the unveil(0,0) call to disable/ignore further calls is intuitive. But I'm not sure how you would improve on it beyond creating an unveil_disable() call.
Why isn't a basic version of proof of work a reasonable approximation of that for the time being? Ex. to provide a review you must also provide a value that when postpended to your review gives a hash containing some properties that scales with the number of reviews. This doesn't solve decentralized reputation at all but does prevent review bombing.
I appreciate OpenBSD. Among other things their focus on making APIs that are impossible to misuse and hacking down the scope of a problem to the bone result in a lot of interesting products. Basically if you have to consult anything beyond the man page for their stuff they've failed. Given those restrictions they tackle big problems with good results.
I worked at a distributor throughout college and the week a drug went generic was party time. The company would ship more of a recently genericized drug in that week than they had until that point. Dropping to ~25% the original price is the average but sometimes it would be 10% or less.
These kind of classes are structs with busy work attached. At work I feel a little guilty when I delete them over the course of refactoring but if no processing on the incoming and outgoing data is necessary then public fields are better in every way by being easier and simpler.
It's weirdly impressive that you still find wide, systemic misuse of random number generators in professional products. But maybe un-use is a better term for not using one where appropriate. In a Def Con talk Dan Kaminsky described it in a slide as "a drop will do ya". Where even a half assed attempted at using a csprng will result in something that will resist all but very well resourced attackers. Also see OpenBSD who have been banging this drum for probably 10-15 years now.
From discussions about this it seems like the consensus is that the nature of neutrinos would kill any attempt to make this method of communication scale. But boy it would cool to have straight line communication between any two points on earth no infrastructure required.
Even following the OpenBSD mailing lists I didn't realize all the anti ROP features they put into this release. The big idea is that popular attack surfaces are randomly relinked at boot/upgrade/run time. Now now the kernel, libc, libcrypto, and ld are unique to each machine. So instead of a single information leak giving away the whole game it gives away basically nothing. An attacker would need to chain many, many information leaks together to get anything useful so the bar is raised quite a bit.
Unless there is a strong mandate from the top to take time for maintaining and reviewing code I'd say absolutely. Even if those were in place I'd say a strong maybe. Ignoring competency some people just have wildly divergent ways to doing the same thing because of their background. Languages like Java and C++ allow for it because they allow you to do so much. So I agree with the basic tenant of Go that having one way to solve a problem is a huge win for code maintainability and readability. If the one way is clunky and kind of ugly I'm still down for it.
I appreciate the ruthless design choices behind Go. Crafting a language so there are as few ways as possible, and preferably one, to solve a problem must be beautiful at a large scale organization. In my experience java codebases in big companies are nightmare factories because of the freedom you get from more similar languages. The Go dream of having a single decent solution to a problem instead of 20 that range from bizarre to really clever sounds like heaven.
I wish I had more time to take a serious stab at learning it.