Just make two plans and switch, when one of them is exhausted.

Yes, I hear that is what people do. Annoying though.

Not sure where gp lives. But most banks here restrict you to 4 digits as the password. So basically a PIN. If you are lucky, you get 6 digits or even letters. But be careful: if you use “fancy letters” (symbols, umlauts, …) you risk locking your account: you will be able to set this password, but the actual login form won’t allow you to enter it. Banks here are highly regulated, so don’t hope for competent competition.

They mitigate the obvious security thread with mandatory 2fa (actually mandated by regulation). Some use this as an opportunity to push their apps: no separate 2fa method, but only integrated in their bloated app, that checks for rooted devices and only supports the newest OS.

It’s quite hard to find out in advance, what 2fa methods with which fees each bank actually requires. I remember that some of them had funny ideas, what a customer should be billed for 2fa SMS. I think it was 50 cents per SMS.

If you have the time, could you please post the list of plugins you are using?

That’s true. On the other hand, Apple isn’t some kind of Borg like swarm intelligence. While Apple’s upper management doesn’t want back doors in their products, someone in middle management might have come to a different opinion.

That’s a good start. In the long run probably three things are necessary:

1) wiring critical software in a language that protects better against such exploits. Might be Rust, Go, perhaps also C# and Nim.

2) Making reproducible builds the norm, that start from the original source code repositories (e.g., based on a Git hash)

3) making maintainers more resilient against social attacks. This means more appreciation, less demands, and zero tolerance against abuse. If the maintainer can be pressured, I am at risk.

The last one is probably the most difficult.

You are right, it took quite some time. On the other hand, it looks like the legitimate part of contributing to xz was only a part time job for the attacker. The rest of the time, they either worked on the exploits, or in other things, like infiltrating other projects using a different handle.

Basically I can imagine the attackers being a well organized group, using work sharing and pipelining. Some members of the group would be preparing exploits, some would infiltrate projects and some would make sure not to get caught. And since infiltrating takes time, they would make sure to have multiple projects in the pipeline, seine in the early contributor stage, some in the social pressure stage, and some in the exploiting stage.

Expecting liability coverage for source code people publish for free on their own time has very strong implications on free speech, freedom of arts, and freedom of science. I don’t think this is possible in a liberal society.

On the other hand, you can already buy software, where the vendor takes some kind of liability: just buy Windows, AIX, or one of the commercial Linux offerings. Same for software libraries: there are commercial offerings that come with (limited) liability from the vendor. It’s even possible to create software to stronger standards. But outside of some very specific industries (aerospace, automotive, nuclear, defense, …) there doesn’t seem to be a market for that.

I think there were some open PRs from that account, that got scrubbed from the account after the back door in xz was discovered. But probably nothing got merged.

Is it possible to retrieve the old branches?

My suggestion: Put your SSH behind WireGuard and/or behind a jump host (with only port forwarding allowed, no shell). If you don’t have a separate host, use a Docker container.

If you use a jump host, consider a different OS (e.g., BSD vs Linux). Remember this analogy with slices of Swiss cheese used during the pandemics? If one slice has a hole, the next slice hopefully won’t have a hole on the same position. The more slices you have, the better for you.

Although for remote management, you don’t want to have too many “slices” you have to manage and that can fail.

Using a jump host could help, only allowing port forwarding. Ideally it would be heavily monitored and create a new instance for every connection (e.g., inside a container).

The attacker would then be stuck inside the jump host and would have to probe where to connect next. This hopefully would then trigger an alert, causing some suspicion.

A shared instance would allow the attacker to just wait for another connection and then follow its traces, without risking triggering an alert by probing.

The ideal jump host would allow to freeze the running ssh process on an alert, either with a snapshot (VM based) or checkpointing (container based), so it can be analyzed later.