I'd argue that there isn't one: you have to offer multiple choices. Auth through any TOTP app, Yubi key, pre-generated codes, mailing a physical code generator, etc.
Perhaps I'm ignorant, but I wonder why I haven't seen this aspect explored in post-apocalyptic media more. I mean, beyond the obvious fact that if we can "keep making computers" all of a sudden the apocalypse doesn't sound quite that bad, which would somewhat lower the stakes.
Sorry, I'm a bit confused. That link seem to state the opposite? The user is asking if 911 can still override the location settings on the phone, and the answer seems to be "yes."
Yeah, this one is tough. I tried doing today's puzzle and I immediately knew the full solution, so I guess the designer's dilemma is whether or not to allow Wheel of Fortune-style "I would like to give the full answer", and if so how to score it. Did you do as much "work" as somebody who solved all the puzzles? I would argue not, so it should probably be scored less, but how much?
You might not need to, but LLMs don't have perfect recall -- they're (variably) lossy by nature. Providing documentation is a pretty much universally accepted way to drastically improve their output.
It's often the limiting factor to getting started, though. Idiosyncratic interfaces and control methods make it really tedious to start learning from scratch.
Great. Time to replace half my home automation devices! This is not entirely unexpected, regardless of whether it was intentional or not, but it still hurts. Although I guess it means it might be easier to take control of existing devices without having to open them up and connect to the GPIOs.
This is not a remote exploit. It's not even a backdoor. It's just a bunch of undocumented interface commands that allow access to things like memory. To exploit any of this you need an attacker have physical access or get to run privileged software on the device. In both cases you'd already be totally screwed anyway. This is a clickbait nothingburger and that's the reason why it was presented at a random local conference. An actual backdoor that infects billions of wireless devices would have easily earned you a top presenter spot at a highly prestigious conference.
You're right! It looks like I misunderstood the report and the "hidden opcodes" are only accessible to the ESP32 itself, not to connected devices? The article is somewhat confusingly worded.
Well, in this case it seems like there already is an official Flatpak, but Fedora is overriding it with their own, which is of lower quality. The problem was already solved, unless Fedora is claiming that their Flatpak is better in some specific way.
From what I can tell reading the pagure.io thread (https://pagure.io/fedora-workstation/issue/463#comment-95541...) the claim from Fedora is that is that OBS is using an EOL qt. It's hard to follow exactly what the issues are with the Fedora flatpak but I can only assume they forcefully updated qt and that's what caused the issues (just a guess from the context).
There's a lot of interesting debate in the linked thread about Fedora giving leeway to "verified" flatpaks, or what they're calling "probably safe" apps that do not request too many permissions, so even if there are vulnerabilities in the source then due to the nature of flatpaks, they won't be able to cause much harm.
> the claim from Fedora is that is that OBS is using an EOL qt.
what's amazing with this is that if for instance OBS had written their own toolkit from scratch just for the app, which by a stroke of luck ended up being exactly the same code than the Qt version they're using and which solves the use case they have - maybe it would be OBSObject or OBSString instead of QObject / QString, then this entire issue would not exist as no one would think of saying that their implementation is "EOL" since it's part of their app even if the actual GUI implementation files may not have been touched for 5 years.
First, the risk is higher. When a vulnerability has a public patch, it means the nature of the vulnerability is also public. Sometimes there is even public exploit code. While attackers sometimes find their own vulnerabilities (zero-days), it makes their job a lot easier if they can just use an already-known vulnerability.
Second, if the code was part of the OBS project, then anyone reporting security bugs in the code would report them to OBS. OBS would then be able to quickly release a security update if they decided the issue warranted it. But since Qt is external, security bugs will be reported to Qt, and it’s unlikely anyone from OBS will hear about these reports. So there is no process for the project to respond with quick fixes even for severe issues. That is, unless they have someone watching the list of CVEs - but that seems unlikely.
Third, if the OBS project had written the code, then it would be reasonably likely that someone on the project knew the code well enough to properly maintain it over time. This isn’t always true. Sometimes projects are stuck with huge piles of code that nobody wants to touch, whose author has left the project, or perhaps just forgotten how it works. But it’s true more often than not. In contrast, most projects don’t engage with their dependencies’ source code to such an extent, especially not for something as huge as Qt.
Fourth, on a related note, vulnerabilities often come from newly written code. Probably the biggest reason for this is that security bugs often double as regular bugs, causing crashes or other issues for normal users. This isn’t true for all security bugs: a decent chunk of them have very specific triggering conditions that are essentially impossible to produce by accident. But it’s true for many. If OBS really had left the code untouched for 5 years, then that would probably be because the code worked pretty well. Maybe it’s legacy, maybe it’s not well-maintained, but if the issues it’s causing were really bad, someone would have gone in and fixed it. That in turn reduces the chance of security bugs somewhat. In reality, OBS actually is regularly updating Qt and thus pulling in new code that may not be well tested. (But not regularly enough to be up-to-date with security fixes.)
Fifth… at the risk of sounding entitled, it’s not just about the risk but also about the potential upside. If there are security bugs in OBS-specific code, that’s bad, but all the ways to improve the situation involve doing OBS-specific hard work. With Qt, there is already someone else doing the job of finding and fixing security vulnerabilities; OBS “only” has to pull in the fixes. In practice, of course, it’s more complicated than that. But if we have a system where it’s Hard to pull in security fixes that someone else has found, well, maybe that’s not OBS’s fault, but that does mean it’s a bad system. We should aspire to do better.
> First, the risk is higher. When a vulnerability has a public patch, it means the nature of the vulnerability is also public. Sometimes there is even public exploit code. While attackers sometimes find their own vulnerabilities (zero-days), it makes their job a lot easier if they can just use an already-known vulnerability.
but.. Qt is only used for the GUI in OBS. It's not doing anything network-related or processing any data stream coming from there, why would any security issue in Qt matter ? Only thing I can think of is a crafted system font causing an issue but if you have a crafted font running on your linux system you are already compromised way beyond repair
Who cares what they claim? Flatpak was invented specifically to route around finger wagging distro maintainers.
Fedora has OBS in their native repos. They can go apply all their opinions to that copy. And if they're as right as they think they are, I'm sure upstream will be happy to take their patches for inclusion in the next flathub release.
Is that all there is to it? That doesn't mesh with the separate claim that Fedora's RPM package of OBS is acceptable to upstream - surely that uses the same latest Qt that Fedora offers? Fedora 41 already ships the very latest Qt 6.8.2 release.
I think that using Mario as part of the sponsor read is possibly even worse from a legal/Nintendo perspective: you can't even try to make a good faith transformative use argument there. I also subjectively found it very icky. The project itself is very cool though.
reply