When determining whether a certificate has been revoked, is an Error<T> really more desirable than a segfault? Would you even expect a "is certificate revoked" function to return an Error<T>?
> is an Error<T> really more desirable than a segfault?
It's only by happy coincidence that it manifests cleanly as a segfault. In the C language, dereferencing NULL causes undefined behaviour, so all manner of peculiar things can happen. This isn't just theoretical nit-picking, it can happen with real code:
The code in question [1] does indeed return Result<(), Error>. This makes sense - more than one thing can go wrong during the verification, and the details can be important in some situations.
In Rust, the signature of the function would be along the lines of `-> Result<whatever, Error>` and you'd have no choice but to handle the Error case of the Result or to panic. Either way, not a segfault.
> Would you even expect a "is certificate revoked" function to return an Error<T>?
Depends on how it's doing the check. If it has to fetch the CRL from the CRLdp or do OCSP with the OSCP AIA, like CAPI does, then it definitely has to have an error for when certificate revocation status is not available.
Honestly, even if I provide the cert & CRL, it should probably be able to throw an error if either one has invalid ASN.1 encoding or such.
You have no choice in rust. It wont compile unless you handle all error conditions.
You get Result< Data T, Error>. And you have to handle Error condition (usually kick it up stack, but it has to be handled somewhere) for it to compile.
What rust wouldn't prevent you from is forgetting to check for revocation, or doing it wrong.
On the flip side, palm recognition allows you to use infrared-based vein biometrics, which requires special lighting conditions. I don't think this is currently feasible for fingerprints.
You can already authorize an arbitrary third party Android app to act as an app store, the only thing stopping you is your own decision making. Can't do that with iOS. You can even build your own AOSP device from scratch if you feel like, and it would be completely compatible with everything in the Android ecosystem (assuming you did a good job). If one party is making an effort to support open software lifecycles, while another is actively trying to inhibit them, isn't it the government's job to step in and correct? If not, why do we even put up with government in the first place?
> You can already authorize an arbitrary third party Android app to act as an app store
Apps installed with it cannot auto update without rooting your device. Rooting breaks many things (on purpose). Defeats much of reason for store vs side loading.
> and it would be completely compatible with everything in the Android ecosystem
Definitely not. You would never pass "safetynet" anti-root checks. An alarming number of Android apps no longer run on AOSP. Only on Android devices unaltered and locked at bootloader level. Google recently upgraded these root checks to be "unbreakable" by using TrustZone.
Android started out much more open, but big G is slowly choking it off. Having the core OS open source is pointless if nothing runs on it. And we're slowly getting there
Well, that only happens if Apple is deemed a monopoly. A non-monopoly can do whatever it wants with its store. It will take years for anything to happen, look how long it took Microsoft back in the 90s.
The judge is already leaning in the direction of monopoly, she sees no competition (and deliberate acts to block competition) to the App Store on the iPhone itself. Quoting her comments to Apple's counsel:
"There is no competition. The question is, without competition, where does the 30 percent (App Store commission) come from? Why isn't it 10? 20? How is the consumer benefiting from, you (Apple) get to say what you want it to be?" she asked.
The actual trial is not gonna happen any time soon, this is only for an emergency injunction to stop Apple from cutting Epic access to Apple Development tools. Watching the whole thing it's likely Fortnite will be off the App Store for the time being, and Epic will be able to continue to support Unreal Engine.
The major companies in Silicon Valley are already facing legislative scrutiny right now (Tim Apple testified in front of Congress a couple weeks ago and looked shocked at the revelations being thrown at him —I am guessing he will be firing a whole lot of people who must have known about that stuff, but forgot to mention it during their briefings). In addition, there are publicly announced anti-trust investigations underway by the Exexutive branch in US, EU, Russia and beyond. Sure there will be fines for past deeds, but they can shut it all down by allowing users to shop at any app store they want.
It can happen if Congress passes a law and the President signs it.
I love how the intellectually dishonest Apple workers downvote. As I said, this should apply to all systems that electronically attempt to “corner the market” on an unsuspecting public, for example non-critical apps running on your car’s infotainment screen, your refrigerator, digital picture frames, thermostats, ... Let the manufacturers do what they want, so long as they allow users to do what they want after they’ve forked over their cash.
OnePlus has had their own proprietary charger game running for quite a while now. It's likely related to that. The Switch uses stock USB-C Power Delivery, so Macbook and Pixel chargers would be fine.
Specific to BIOS images, `binwalk` is probably a better choice than `strings.` There's often data in LZMA streams or otherwise compressed, and chances are you're gonna binwalk your image at some point if you want to modify it.
Also, specific to Intel powered motherboards newer than a certain generation, the image should show as an "Intel PCH File Descriptor" or something if you run `file` against it. Don't use this as an integrity check though, `file` is just looking at an Intel-specific header at the beginning of the ROM file.
From an attacker's perspective, taking into account that people are generally worse with reusing pins than passwords, why would this make a difference in how hard it is to compromise a device. Also, how many combinations will this provide?
