I'm coming out of reading this a bit dismayed as I really thought that the `if let` (to use the swift conventions) pattern would finally be a good and reliable solution for these silent errors.
And at the same time, reading the code in question and putting myself into the position of a person writing the code, I would totally have thought that I'm handling the "is there a global scope" case, totally forgetting that the same check is also checking the "is the global scope a `WorkerGlobalScope`" condition but mixing both checks into a single return value.
And here we are with the code happily chugging along and (for all intents and purposes) causing data corruption (by causing network requests to not be logged and not respect policy).
And here I was thinking that `if let` is fixing exactly this problem while also providing the best ergonomics.
So here we are back to the drawing board, ready for the next pattern which will compromise on ergonomics in some as-yet unknown way in the future.
I think conversion rate and support cost associated with 2FA-OTP are worse enough for SMS to still be worth it, especially as a phone number also gives you a good marketing ability and a reasonably unique identifier for a user.
That is what everyone dances around in these discussions. It doesn't matter if it is a good second factor because it is an excellent user tracking identifier and that is what they were really after. Twitter and facebook both lied about only using these numbers for security and then almost immediately put them to use for advertising purposes. We only know about it because they were big enough to sue, I'm sure every crappy site that gets the number sells it. As a bonus, it also allows them to dump a lot of the infrastructure and support problems onto some one other than themselves.
The biggest problem with SMS-2FA in my opinion is a lot of places are setup so it isn't even a second factor. I can often reset my password just through email so it just seems like throwing a threadbare blanket marked security over the top of a user tracking scam.
True, but where's the difference between downloading a binary and executing it vs. downloading a script and executing that which will then download a binary and execute it?
In both cases, you trust the publisher and in both cases the publisher gets equal access to your machine.
Oh - you mean you're downloading the source code, then audit it, then compile it and only then you run it?
That's super great. That has saved you from the xz backdoor and all other supply chain attacks and will be of great help to you in the future. Let's hope no backdoor ever slips past your code review.
> where's the difference between downloading a binary and executing it vs. downloading a script and executing
The difference is that the attack vector of the shell script is an easier target.
If someone was to be malicious; they could manipulate the script and inject some sort of payload in disguise. It's an easier vector to damage than say an compiled package. One that's less prone to being detected in that the script could go for days undetected.
With the executable you can compare the checksum and with the whole package compiled it is less prone and more tricky to alter.
Unless that script is under monitoring 24/7, I'm going for binary but they don't support BSD anyway.
If I were to serve a targeted exploit like this, I would certainly hide it in the binary and have the binary determine whether it's running in the targeted environment and then run the payload.
It's much, much easier to hide a malicious payload in a binary than an easily auditable shell-script. And it's much easier to make a decision of whether the payload should be enabled or not if you are already running on the local machine.
If you don't trust a publisher, you really can't run anything of theirs. Shell script or, especially, binary.
Well, it can actually check if it’s being downloaded from the browser or from the shell (user-agent), so unless you are downloading it and running the downloaded script, it might still spoof what will get executed. Also, it can itself download other scripts.
See, I wouldn't. I would go for the script to either inject the payload to the package or inject to the host.
Even if it's auditable, how many people are actually verifying the shell script before hand?
You've just been given a command to download and execute.
And the potential of having lots of users downloading a shell script has a quicker attack path than users downloading the package. You have custom repos, holding their own distro packages for the software.
Of the three distros I know to more detailed extents, Debian, Arch and RedHat, none of those make it easy to install and keep updated a third-party package through the built-in package manager.
In all cases, signatures and repositories need to be configured, often requiring both root access and usage of the CLI and in all cases much harder than running an installer script (which might be doing exactly these steps).
To achieve easy means of installing using distro package managers means including the application in the distro itself, but now it's beholden to the distro's software update policies and thus stuck on that specific version for years or even decades.
That is not what a v0.something of an end-user centric desktop application wants for themselves.
Sublime Merge is cough sublimely good at performing 3-way merges.
I don't like it as much as a generic git frontend (nothing beats the command line once you're used to it, but for 3-way merges, it's absolutely perfect and I have yet to see anything better.
Another very good tool for 3-way merges is meld, but the macOS port (where I do most of my development work on) is not very good, mostly because the GTK macOS port isn't very good.
I tried Meld for 3-way merges and while it seemed ok I prefer P4Merge. It's free, but not open source. If I'm using Jetbrains tools though, I'll always use the built in merge tool as it's the most intuitive to use in my experience.
Maybe they improved, I actually haven’t tried for years. I mostly would click blame on a line in sublime text and leave it at that. I just never felt smerge was good at digging around history. Maybe I’ll give it another try
Well, it's about bypassing App Review and other static security analysis, undocumented apis, etc. I think there's a fairly strong case here that it's about more than just protecting revenue (which it is also!)
Given the sandboxing and the security architecture of iOS, my conjecture is that apps could be perfectly safe even in light of the use of undocumented APIs (calls to which can be and are obfuscated even in today's setup) and accidental security flaws (which can and still do exist even in today's setup).
Would they? Apple Pay and Google pay are just proxies for the actual cards, so if a play does not accept a type of card, that will also be true for the virtual card presented by Apple Pay.
I agree about PayPal, but they charge their own fees and abstract the source of the money away completely. Presumably they have a better deal with Amex
Checking the box is not enough. You also need to provide an API key for iTerm do be able to do any kind of uploads to OpenAI.
If your auditor does not believe that with the checkbox unchecked and no API key provided, iTerm will not talk to OpenAI, how do they believe any other software you run does not secretly upload stuff to OpenAI?
What's different between a piece of software claiming to not support OpenAI at all vs. one that claims to support OpenAI if the user provides an API key in light of the possibility that both might be lying (if that's an auditors concern)
With iTerm your auditors at least get to check the source code...
And at the same time, reading the code in question and putting myself into the position of a person writing the code, I would totally have thought that I'm handling the "is there a global scope" case, totally forgetting that the same check is also checking the "is the global scope a `WorkerGlobalScope`" condition but mixing both checks into a single return value.
And here we are with the code happily chugging along and (for all intents and purposes) causing data corruption (by causing network requests to not be logged and not respect policy).
And here I was thinking that `if let` is fixing exactly this problem while also providing the best ergonomics.
So here we are back to the drawing board, ready for the next pattern which will compromise on ergonomics in some as-yet unknown way in the future.