• 0 Posts
  • 26 Comments
Joined 3 years ago
cake
Cake day: November 28th, 2022

help-circle

    1. Software has bugs.
    2. Bugs which interface with and execute untrusted code are high risk.
    3. Browsers are obscenely large pieces of software, which connect a user’s system with random websites which execute JavaScript.

    Browsers are one of the most important things to update on your computer.

    We can talk about whether browsers should be as complicated as they are, but implying security updates are a intended as a vector of control is conspiricist thinking.

    The reason you don’t get security updates backported to your older release of choice is simple: it is so much work.

    Waterfox seems like a good choice, just don’t go around thinking that companies are making security updates in order to sneak in unwanted, they make security updates because they are terrified of being responsible for a major incident.





  • I was a “ironically” racist as a young teen, it took me till my early adulthood to realise that being ironically racist is just being racist, and the edgy “humour” that is made at others expense isn’t funny or clever, and is incompatible with the kind, empathetic person I wanted to be.

    Cringing at my teen self pushes me further into deprogramming myself from that shit, but I’m encouraged by the adage “if you don’t look at yourself from a decade ago and cringe, you wasted that decade”.



  • I wish.

    It was a bcachefs array with data replicas being a mix of 1,2 & 4 depending on what was most important, but thankfully I had the foresight to set metadata to be mirrored for all 4 drives.

    I didn’t get the good fortune of only having to do a resilver, but all I really had to do was fsck to remove references to non-existent nodes until the system would mount read-only, then back it up and rebuild it.

    NixOS did save my bacon re: being able to get back to work on the same system by morning.







  • No, I’m saying that when people run into strange bugs, sometimes they put together an issue (like the person behind cve-rs), and sometimes they quietly work around it because they’re busy.

    Seeing as I don’t often trawl through issues on the language git, neither really involve notifying me specifically.

    My lack of an anecdote does not equate to anecdotal evidence of no issue, just that I haven’t met every rust developer.


  • Yes, the problems rust is solving are already solved under different constraints. This is not a spicy take.

    The world isn’t clamoring to turn a go app into rust specifically for the memory safety they both enjoy.

    Systems applications are still almost exclusively written in C & C++, and they absolutely do run into memory bugs. All the time. I work with C almost exclusively for my day job (with shell and rust interspersed), and while tried and tested C programs have far fewer memory bugs than when they were first made, that means the bugs you do find are by their nature more painful to diagnose. Eliminating a whole class of problems in-language is absolutely worth the hype.



  • The code used in cve-rs is not that complicated, and it’s not out of the realm of possibility that somebody would use lifetimes like this if they had just enough knowledge to be dangerous.

    I’m as much a rust evangelist as the next guy, but part of having excellent guard rails is loudly pointing out subtle breakages that can cause hard to diagnose issues.


  • I’m sure the developers are competent, but the reason I care about the design decisions is the same reason the electric brakes on cars don’t interface with its infotainment system; the interface inherently creates opportunities for out of spec behaviour and even if the introduced risk is tiny, the consequence is so bad that it’s worth avoiding.

    If you have to have an airbag be controlled by software (ideally the mechanism is physical, like a pull tab), it should be an isolated real time device with monitoring your accelerometer and triggering the airbag be it’s only jobs. If it’s also waiting to hear back from another device about whether your subscription ran out before it starts checking, the risk of failure also has to consider that triggering device.

    It can be done perfectly, but it’s software so of course it has bugs.



  • Yes, but also from an implementation perspective: if I’m making code that might kill somebody if it fails, I want it to be as deterministic and simple as possible. Under no circumstances do I want it:

    1. checking an external authentication service.
    2. connected to the internet in any way.
    3. have multiple services which interact over an API. Hell, even FFIs would be in the “only if I have to” bucket.