I am talking about the fork. It is operated by someone else.

The syncthing fork on f-droid is still an option. An issue has been opened on the github repo. Lets see what will happen with the fork

That was a rhetorical question towards the commenter since the discussion point was not understood.

The thing is, that you only have to share public keys and never private ones. So you can only phish public keys…

How would you sync or transfer a passkey across devices without transferring the private key?

Why do you think SSH-Keys are safe against phishing? I mean it is unlikely, that someone will just send the key per mail or upload it somewhere since most ppl using SSH-Keys are more knowledgeable.

When you now get an easy one click solution to transfer Passkeys from one Cloud provider to another it will get easier to trick a user to do that. Scenario: You get a mail from Microsoft that there is a thread and that you need to transfer your keys to their cloud.

With the ability to transfer passkeys, the attack vector phishing does not sound that far fetched. Tho i have not looked into the transfer process.

We will see i guess.

You generate a second one on the other device.

Not everyone throws their E-Mail at every Text field they see.

They moved to wayland 2 years ago. https://tails.net/news/test_5.8-beta1/#index2h1

The thing is, those poor design decisions have nothing to do with those features, i claim that every feature could be implemented without “holding the compose files hostage”.

Btw. dockge does support connecting to another docker dockge instance.

No, that would make no sense and is obviously not what i meant.

But you could separate the arr stack from things like pihole with a vm. For example you could pin one thread to that VM so you will not bottleneck your DNS when you are doing heavy loads on the rest of the system. This is just one example what can be done.

Just because you do not see a benefit, does not mean there is none.

Also, VMs are not “heavy” thanks to virtualization technology built into modern hardware, VMs are quite light on the system. Yes they still have overhead but its not like you are giving up big percentages of your potential performance, depending on the setup.

You talk like there is not in between containers and VMs. You can use both.

What exactly are you referring to? ZIL? ARC? L2ARC? And what docs? Have not found that call out in the official docs.

I use a consumer SSD for caching on ZFS now for over 2 years and do not have any issues with it. I have a 54 TB pool with tons of reads and writes and no issue with it.

smart reports 14% used.

You recall wrong. ECC is recommended for any server system but not necessary.

1. And? If you cannot trust then you should not use them when you want to do something that is private and should not get looked on.

2. And if there were signs of misuse of the trust, then they would get removed.

It is actually really easy to monitor thanks to CT.

Yes, there is countless examples of root CAs containing compromised CAs.

This incidence with digicert is not about a compromised CA it is about a flaw in their validation system. That is not what you claimed. Such flaws happen from time to time, lets encrypt had an issue a while back too.

Not exactly. They are pointing out that HTTPS assumes all is well if it sees a certificate from any “trusted” certificate authority. Browsers typically trust dozens of CAs (nearly 80 for Firefox) from jurisdictions all over the world. Anyone with sufficient access to any of them can forge a certificate.

Great thing, that you can remove them and only trust those you trust.

Also, HTTPS doesn’t cover all traffic like a properly configured VPN does.

Pls explain what https is not covered? The SNI on tbe first visit? A VPN just moves the “exit point” of your traffic. Now the Datacentef and VPN provider sees what you ISP saw.

it’s not difficult for a well positioned snooper (like an internet provider that has to answer to government) to follow your traffic on the net and deduce what you’re doing.

No. I never said otherwise. But they cannot spy on the traffic. And since the SNI is not encrypted anyway they do not even nerd to “follow the traffic”. But what sites you are visiting and what you are doing on them are 2 different things.

Yes, there is countless examples of root CAs containing compromised CAs.

Then pls proof that? Link to a recent article maybe?

You can read more about this learning about X.509.

Its the PKI thats broken, namely the root stores. Has been unreliable for many, many years. This is why packages are signed.

So you are basically saying that root CAs are unreliable or compromised?

The great thing is, that you can decide on your own which CAs you trust. Also please proof that those are actively malicious.

And no. That is not the reason that packages are signed, i am guessing you mean packages like on linux, packages contained in the installation repository. The reason is, that you build another chain of trust. Why would i trust a CA which issues certificates for domains with code distribution. That’s not their job.