- 0 Posts
- 50 Comments
The “minimal” part is incorrect; it is a super complicated container. The number of moving parts don’t leave me with any confidence that I could keep it running or fix any issues going forwards.
Mainly for security. I was originally looking at CoreOS but I liked the additional improvements by the UBlue team. Since I only want it to run containers, it is a huge security benefit to be immutable and designed specifically for that workflow.
The Ignition file is super easy to do, even for just one server (substitute
dockerforpodmandepending which you have):Take a copy of the UCore butane file:
https://github.com/ublue-os/ucore/blob/main/examples/ucore-autorebase.butane
Update it with your SSH public key and a password hash by using this command:
# Get a password hash podman run -ti --rm quay.io/coreos/mkpasswd --method=yescryptThen host the butane file in a temporary local webserver:
# Convert Butane file to Ignition file podman run -i --rm quay.io/coreos/butane:release --pretty --strict < ucore-autorebase.butane > ignition.ign # Serve the Igition file using a temp webserver podman run -p 5080:80 -v "$PWD":/var/www/html php:7.2-apacheDuring UCore setup, type in the address of the hosted file, e.g.
http://your_ip_addr:5080/ignition.ignThat’s it - UCore configures everything else during setup.___
Rootless Podman :) It requires you to learn a little bit of new syntax, for example, the way you mount volumes and pass environment variables can be slightly different, but there’s nothing that hasn’t worked for me.
I’m using this on uBlue uCore, which I would also strongly recommend for security reasons.
9·12 days agoWonderful response, and I agree completely. It echoes the thoughts I’ve tried to convey to friends in their 20s, but much more eloquently than I have managed.
I switched and was very glad to do so. You increase your security and so far I haven’t seen any downside. Every container I’ve tried has worked without issues, even complex ones.
That wouldn’t stop page views from being counted.
You can’t know with certainty on Signal that the client and the server are actually keeping your messages encrypted at rest, you have to trust them.
With Matrix, if you self host, you are the one in control.
money corrupts
This is exactly the reason that Proton became a non-profit:
https://proton.me/blog/proton-non-profit-foundation
Swiss foundations and their board of trustees are legally obligated to act in accordance with the purpose for which they were established, which, in this case, is to defend Proton’s original mission. As the largest voting shareholder of Proton, no change of control can occur without the consent of the foundation, allowing it to block hostile takeovers of Proton, thereby ensuring permanent adherence to the mission.
6·4 months agoAdd in the local REST API as well if you want to easily interact with your notes programmatically:
They might be talking about posts like this (which I would love to have refuted, as this kind of info has so far kept me from using Docker significantly):
Containers are isolated from the host by default.
Are you certain about that? My understanding is that Docker containers are literally just processes running on the host (ideally rootless), but with no isolation in the way that VMs are isolated from the host.
If you have some links for further reading it would be great, as I have been extremely cautious with my Docker usage so far.
I haven’t found anything to refute this, but this post from 2017 states:
In 2017 alone, 434 linux kernel exploits were found, and as you have seen in this post, kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t sufficient.
If someone exploits a kernel bug inside a container, they exploited it on the host OS. If this exploit allows for code execution, it will be executed on the host OS, not inside the container.
If this exploit allows for arbitrary memory access, the attacker can change or read any data for any other container.
First of all, you can pay with crypto and use a burner email, but secondly, they don’t link searches to your payment or sign in. (Assuming of course you take their word for it, but that’s the same for every service that you do not host or compile yourself, and for which you’ve also read the entire source code yourself.)
I’m not saying people should use Kagi, I’m merely pointing out you can’t claim it’s “misleading and not private” without providing some sort of proof.
At best you can say you can’t verify for yourself that they are indeed private as they claim.
So all of your internet searches are tied to one kagi account?
Kagi states in their privacy policy, “To ensure your privacy and security, we don’t monitor, log or store your queries or associate them with your account”.
Of course you have to believe them, but that’s the same for every service that you do not host or compile yourself, and for which you’ve read the entire source code yourself.
Kagi isn’t private and it is misleading to advertise it as such.
What is your reasoning for this statement?
Going directly from Kagi’s own privacy policy, “To ensure your privacy and security, we don’t monitor, log or store your queries or associate them with your account”.
Of course you have to believe them, but that’s the same for every service that you do not host or compile yourself, and for which you’ve read the entire source code yourself.
If your sender sends an unencrypted message, yes Proton can see the plain text as would be expected. (Note, sending via TLS doesn’t count as an encrypted email.) However according to their many audits their process is to immediately encrypt with zero-knowledge encryption in such a way that only you can access.
If you can’t trust their published open source code and their multiple audits, then sure, you should look for alternate solutions.
mental outlaw video
For anyone else, it’s this video. I’m 5 minutes in and it’s talking about how SMTP isn’t encrypted so Proton can read unencrypted email. Yeah, no shit…
16·4 months agoCan we create a situation where brute force is unfeasible while using 6 digits PIN?
According to this comment from GrapheneOS, the latest Pixels and iPhones are not brute forceable with a 6+ digit PIN:
Pixel 6 and later or the latest iPhones are the only devices where a random 6 digit PIN can’t be brute forced in practice due to the secure element.
You can get USB-C to HDMI cables, you don’t need an adapter.