Arch Linux is not vulnerable to this specific attack, which requires sshd to be linked to liblzma. This link is provided by out-of-sshd patches, that Arch does not apply to their build.
The point here is there is uncertainty in all commits by Jia Tan, Arch’s focus is on this specific hack, but are there other vulnerabilities in the hundreds of commits to the git repo from the same author?
But as this article points out, liblzma is used in other crucial processes, and is generally trusted, often probably being run as root. The known bad actor contributed lots of code to xz that isn’t involved in the SSH backdoor. To assume it’s all innocuous would be truly foolish.
That may depend on the context and data but you may end the first job at T+28 (runtime of 28 hours) and the second at T+52 (28 hours as well, started at T+24).
If jobs must be executed one after another, then you absolutely create an infinite backlog.
At least according to the Github's language breakdown for https://github.com/Rust-for-Linux/linux, C is still 98.3% of the repository, and Rust is in the 0.1% of "others".
CAN Bus is more like a layer 2 bus, so it should not really bother with encryption, just like Ethernet doesn't provide it. It all comes from the layers above it, and there has been proposal to add encryption or authentication to CAN. The big issue is that in normal CAN you only have 8 bytes to work with.
This is kind of a nitpick, but Ethernet _does_ bother with encryption, at least in recent versions of its standards. Obviously Ethernet has a long history and this is all optional, but it's pretty straightforward to set up 802.1X / MACsec (+MKA) on a LAN in such a way that all traffic is encrypted at L2.
I've never heard of this being used with really low-power embedded stuff, but if you stretch your definition of embedded to the point where you include things running stripped down Linux, this is a pretty viable setup if you have those devices distributed across a LAN with a managed switch in the middle.
Well a lot of cars have a wireless charging pad available in the phone holder, so you just drop your phone there and it starts charging / connects to Android Auto.
Tbh, the charging pad is bad, if I would rely on it a lot, I would keep a cable in the car. I don't know why, but it heats up so much if you use it, that the iphone overheats and starts to throttle.
I also had some experience in that space, and my conclusion was that what was really hard is handling keep-alive correctly. Some mobile networks will very aggressively flush their NAT entries while other will be fine with a packet every hour or so. And sometimes the NAT timeout changes depending on the server's IP range. Building a solution that is both battery-optimal and that will keep the connection alive is pretty hard.
QUIC (or HTTP/3 with enough low-level control) sounds like a good fit: there is no NAT connection that has to stay alive, but the server can remember the handshake for a quick restart. Doesn't matter if you switch between wifi and LTE. When ever the app is told radio is now available, send a single UDP packet to request new notifications, server sends one of more UDP packets back in response.
Generally the same idea, yes. Your parent mentioned a key difference though: "and pattern matching." enums in Rust have much stronger language support.
But there are also differences, for example, errors must be absl::StatusCode, whereas enums in Rust allow for arbitrary error payloads.
Also don't discount ecosystem usage: everyone uses Result in Rust, abeseil isn't used by most things, and std::expected has its own issues (though I can appreciate how tough making those calls is) and only landed in C++23, so it's not as widely used as Result either.
Sibling comment mentioned pattern matching, but didn’t point out the important point that the rustc compiler makes sure all patterns matches are exhaustive.
To use a C example, if you add a new definition/variant to an enum, suddenly all switch statements over that enum will fail to compile (unless there is a default: branch).
This does eliminate a large swatch of logic errors, though by no means all.
I don't think so. According to [0], the passcode is used to protect filesystem encryption keys, meaning that without the code, you cannot decrypt your files. I don't know if pictures are stored encrypted, but I would assume so.
edit: apparently I might be wrong. [0] also says that for a while only Mail storage, was encrypted and the default changed in iOS 7. So if your iPhone is on iOS <= 6, you might be able to use that to gain access to the device and copy pictures. The tools at [1] might help.
You can also use third party libraries. I have written projects using ChibiOS and libopencm3 and their driver model was actually OK to use, although for most peripherals you still need the datasheet to understand the exact capabilities of the device.
