pilif

The whole reason for returning a result enum would be so I don't forget to also check somewhere else whether something could possibly have gone wrong.

Especially when there is a specific result type.

The API looks like it's following best-practice, with a specific result type that also contains specific error information and yet, that's not enough and you still end up with edge-cases where things look like they're fine when they aren't.

My only tiny gripe is that with the first quirk the author who insists that his implementation is bug for bug compatible lists the other implementations behavior and explains that they are very different from the original.

And then they proceed with additional quirks where the supposedly bug-for-bug compatible implementation also is different in the same way as the first example in that it produces an error message rather than the quirky output.

Don’t get me wrong: errors rather than quirks is much better behavior, but then don’t claim to be bug-for-bug compatible, nor roast other implementations for doing the same thing.

You have $FRAMEWORK using $BUILD_SYSTEM and depending on $NODE_VERSION which is running on $OS_VERSION in $ARCHITECTURE.

Eventually, there will be a security flaw in $OS_VERSION which will force you do update the OS (which eventually will be a major OS update) and on which $NODE_VERSION might not run any more at which point you find out that $BUILD_SYSTEM doesn't run on newer node any more because it relied on a package that shipped some binary do do its thing and the source code of that binary doesn't compile on later GCC versions any more.

And now you're in deep-shit because of a very distant but yet super important security issue that brought your house of cards crumbling down.

This is not a theoretical issue either. I've seen this happen to applications with a JS frontend that was only as little as 5 years old. It was impossible to build any more and needed some serious changes because of underlying OS updates cascading up the stack.

The fewer dependencies you have and the smaller they are, the bigger is the chance that things keep running as you exchange parts of your stack when you're forced to and the bigger the chance that you will remember what you have to do to rebuild if disaster strikes.

I'm aware that for many people 5 years is a huge time span though and that you either start a new thing every year or two at which point none of this matters, or you're at the other extreme and run RHEL and are able to back-port security patches manually if the need arises at which point none of this matters either.

But if you're in the middle of the two extremes, then keeping up to date incrementally is super important and being able to do that quickly and easily is inversely proportional to the amount and size of dependencies.

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.

oh the jargon

> We're making progress by the minute

I better hope you do.

If not, everybody would be using OTP already.

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.

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.

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.

* it doesn't do a good enough job following renames (in cases where you would need to use `--follow` to `git log`. `git gui blame` does.

* while there is a "blame parent commit" feature, it's a bit hidden and it's super slow to provide the updated blame.

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.

This means that your app can load arbitrary updates from the server and execute them, for example based on some purchase not made in the AppStore.

This is all about keeping the 30% tax and only tangentially about security.

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

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...

So I believe, given the current state of knowledge, that all the projects that are not about building liblzma packages are not vulnerable and thus their postings about them not being vulnerable is noise.

But if all you use as the basis of the vulnerability analysis is the version constraint and what we currently know about the backdoor, then, unless you are a distro building a liblzma distro package, you will not be vulnerable no matter the version (which was my point 1)

1. the scope of the known backdoor is very constrained to only be inserted into native OS packages. As such, I don't think we need every other user of liblzma to post blog posts that they are not vulnerable independently of which version they embed. This is at best noise and at worst dangerous because

2. the bad actor has been submitting patches to liblzma for much longer than the 5.6 release and given the ingenuity of the attack, it's too early to claim that a project is not vulnerable to backdoors simply because there might already have been other "presents" left by the threat actor.

Given these two points, I really believe we should not be posting "hey we are not vulnerable" blog posts here because at best they are useless noise (nobody aside of debian or redhat and their downstreams is vulnerable) and at worst false assurances.

What's not allowed is telling the users that it's available for cheaper in other places. But you can charge as much as you want.

So this is a great way to get to use the same control as the rest of the OS uses without having to implement it yourself in CSS and JS. This means that as the OS changes, this control will adapt, including accessibility affordances like showing a 0 or 1 on the control to denote state.

I see why you don’t like the control, but this is what mobile OSes use (mainly because a checkbox the size required for a finger to hit comfortably would look ridiculous) and what users are now used to and what many websites in their mobile modes are emulating and not getting quite right.

Being able to have access to the native control is a huge benefit I think.

However, that only works with a /64 prefix and given that larger sites might want to have multiple subnets, that’s why most assignments are /56 or /48.

But still. If all assignments were /48s, that would still leave room for 281 trillion networks which even I believe is enough for the foreseeable future.

If the number space is so big, it makes sense to take advantage of it if that allows for other additional features (like SLAAC)

The incremental backup would be just the WAL segments excluding the base backup.

With this new feature, the WAL segments you need to store are much, much smaller.

I'm pretty sure you can claim that in a court. However, making an offline appointment with a hitman and then making them an offer and even making a first down payment for the service is probably difficult to explain away as parody.

And now only two weeks later, I get a very good explanation as to why, like often in crypto, intuition was wrong