geggo98

> Look at France, they have nuclear and they have energy security. Look at Germany and how foolish they were to deprecate all nuclear stations.

They both depend on Russia, one for liquid gas the other for nuclear fuel [1]. They are quite similar on energy security.

[1]: https://en.wikipedia.org/wiki/Nuclear_fuel_cycle_in_France#U...

I have no insights in Swedish politics. His actions could be really bad, or mean nothing at all. Without proper context, it’s hard to say.

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

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.

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.

Actually you have a point. A collection of shell scripts (like the classical init systems) have obviously a smaller attack surface. In this case the attacker used some integration code with systemd to attack the ssh daemon. So sshd without systemd integration is safe against this specific attack.

In general, I’m not convinced that systemd makes things less secure. I have the suspicion that the attacker would just have used a different vector, if there was no systemd integration. After all it looks like the attacker was also trying to integrate exploits in owner libraries, like zstd.

Still I would appreciate it, if systemd developers would find a better protection against supply chain attacks.

Unix pipes have built in back pressure. A very simplified view, assuming blocking calls and single threads: if the process on the left side of the pipe produces data too fast and fills up the buffer, the operating system won’t give it any additional CPU cycles, until the program on the right side of the pipe caught up with reading and freed up the buffer.

Things become more complicated when multi-threading and / or asynchronous IO gets involved. If the producer on the left side of the pipe has multiple threads, e.g., one writer thread and multiple worker threads, producing data for the writer thread. Then it has to invent its own signaling between the different threads, to avoid throwing away data, when its internal buffers fill up. This is effectively a kind of back pressure.

In your example with the lever and the parser: if the lexer is multi threaded, you either need unlimited buffer for the tokens or some signaling for the threads, to slow down when the parser cannot keep up. This example is a bit artificial, since most languages don’t allow parallel lexers. But with parallel compilers and one (incremental) linker, this becomes more realistic.

From the screenshots it looks like there is an activation limit, with a maximum of four devices. Reading the license, I could not confirm this. Is there a limit, and if, what is the maximum?

While you are here: the Node.js syntax highlights on you QuickStart docs seems to be broken. Tested with Safari and Chrome on a recent macOS. That’s not a huge issue, but makes it a bit harder to grasp what’s going on and how the Dagger SDK actually works.

> But I have been told “video off” is passive aggressive so I don’t know how much longer I can pull this off.

“Video off” is often necessary, because your laptop runs low on battery, or has run too hot. Sometimes your Wi-Fi might just be bad, forcing you to audio only. A colleague of mine could not turn on video while the Anti virus was running, or the PC would get overloaded (hint: it was running all the time, as mandated by the security guidelines).

You might also not feel well with being watched because of personal reasons. And since it’s personal, it would not be the other person’s business.

If you are at home, video might interfere with other people’s privacy. Just think about the neighbor sunbathing while visible from your window. Don’t want to risk streaming things to work that are not safe for work.

> Pension: Germany has a pyramid scheme and it collapsed a while back.

The system did just fine, but was plundered by politics. During the German reunification, the people from the former Eastern Germany were added to the public pension fund without ever having anything payed in. This drastically increased the amount of recipients without bringing in additional money.

Politics decided that. They also decided to not put any tax money in the pension pool to re-balance it.

No matter how you design a pension fund: If you bring in an additional country as recipients without any additional capital, that pension fund won't survive.

[1]: https://www.bpb.de/politik/innenpolitik/rentenpolitik/290963...

The blog post you mentions brings two arguments: first the database would require looking. Second the database would need tradeoffs between reading (polling) and writing (adding and removing to the queue).

The original article handles the first argument: Postgres doesn't need polling. Instead it provides a notify mechanism, that informs the application when the table changed (something was added or removed from the queue) via the SQL NOTIFY statement.

For the second point it also provides a solution: since optimization for reading is not needed anymore with the NOTIFY statement, the trade-off like different: we now need an efficient way to write. For this the article provides an efficient update statement with special lock behavior. This helps to make writes efficient, too.

It looks like both points from the blog post you linked are handled in the original article.

To my understanding this plan should include the spouse and any number of kids up to the age of of 23 (age limit for the kids, not for the spouse of course). Dental care and eye care might be a bit limited in these kinds of plans. This means that you have to pay extra if you want more then the medical necessary minimum.

In the Cassandra case, you would not write the persistent data in the Docker image (that's the part of the file system mounted as a layered file system, using AUFS or OverlayFS). Instead, you would write it in a volume. For a local volume, that's just a part of the "normal" file system (Ext4, XFS, ...) exposed to the Docker container through a bind mount.

Volumes are quite stable and reliable when based on a stable file system.

So while you could lose the container due to the but describe, you would not lose the persistent data.

It's best practice not to write to the Docker image at all during runtime (no log files, no PID file, etc), but to write only to volumes or tmpfs mounts. I'm a little bit suspicious about the crashes you described: are you sure you followed that best practice?

There is no blame on you. There is no way you can provide a configuration that will be secure on every server.

My recommendation: add a big warning message that there is at least one known security hole and many unknown ones in the server code and it is up to the just to secure their server properly.

Then fix the demo code but leave the warning there.

It's always up to the developers to check the system they build for security problems. They could use the best frameworks in the world and copy thoro reviewed example code. The end result might still have huge security problems.