IAm_A_Complete_Idiot @ IAm_A_Complete_Idiot @sh.itjust.works

Posts

0

Comments

63

Joined

2 yr. ago

The point is to minimize privilege to the least possible - not to make it impossible to create higher privileged containers. If a container doesn't need to get direct raw hardware access, manage low ports on the host network, etc. then why should I give it root and let it be able to do those things? Mapping it to a user, controlling what resources it has access to, and restricting it's capabilities means that in the event that my container gets compromised, my entire host isn't necessarily screwed.

We're not saying "sudo shouldn't be able to run as root" but that "by default things shouldn't be run with sudo - and you need a compelling reason to swap over when you do"

How would rust fare any better then a tracing GC? Realistically I'd expect them to use more memory, and also have worse determinism in memory management - but I fail to really see a case where rust would prevent memory leaks and GC languages wouldn't.

There's built in functions to leak memory that are perfectly safe. You can also do one really trivially by making a reference count cycle. https://doc.rust-lang.org/book/ch15-06-reference-cycles.html

Rust only prevents memory unsafety - and memory leaks are perfectly safe. It's use after frees, double frees, etc. It prevents.

Rust doesn't guarantee the lack of memory leaks anymore then java/C++ does, so sadly not sure if it would help here. :)

Only for it's child processes, e.g. call a bash script with a modified PATH. Still problematic though.

...I suppose they could also modify your .bashrc equivalent.

This is about PKI. An HTTPS server has a TLS cert, and that TLS cert is signed by / created by a certificate authority (or CA). When you connect to a service over HTTPS, a TLS handshake happens. The handshake starts by the client asking a server to setup a session, and the server hands back it's certificate. This certificate can be used to encrypt traffic, but not decrypt it. The client makes sure the certificate is signed by a CA it trusts (such as let's encrypt).

Once the client has this certificate, it sends a key to the server in encrypted form, and the server decrypts it. They both now use this key to communicate.

The MITM server can't compromise the session because: If it swaps the certificate (or in other words, the encryption key the server sent), that key won't be trusted because it isn't signed by a CA the client trusts.

If the MITM tries to send its own shared key signed by the servers certificate - it doesn't really matter since it can't read the clients messages anyways to get the shared key from the client. If it forwards it, then you effectively have two separate https sessions with their own keys, and the server will treat them as distinct.

In this context it actually means that you can take the source code, and get the exact same binary artifact as another build. It means that you can verify (or have someone else verify) that the released binary is actually built from the source code it says it is, by comparing their hashes. You can "reproduce" a bit for bit copy of the released binaries.

Yeah. There's reasoning for why they do it on their docs, but the reasoning iirc is kanidm is a security critical resource, and it aims to not even allow any kind of insecure configuration. Even on the local network. All traffic to and from kanidm should be encrypted with TLS. I think they let you use self signed certs though?

Kanidm doesn't require a CA, it just requires a cert for serving https (and it enforces https - it refuses to even serve over HTTP). I think that was just the OP not quite understanding the conceptual ideas at play.

Kanidm wants to directly have access to the letsencrypt cert. It refuses to even serve over HTTP, or put any traffic over it since that could allow potentially bad configurations. It has a really stringent policy surrounding how opinionated it is about security.

While part of me agrees, I will say most ecosystems have some glaring flaws in them. Python's lack of lock files in particular is something that annoys me to no end. Having to use poetry, pipenv, or whatever else people are using now to get around it sucks. Python's lack of being able to use multiple versions of the same library is also a thing... but not something I've found issues with personally.

I'm not going to say cargo is some mind blowing system cause I really don't think it's innovative, at all - but I do think it's far better than most ecosystems just due to benefits of hindsight. Having an opinionated, simple build system that does all the right things out of the box is valuable, and I can't think of any mainstream language that really hits that mark otherwise.

Also, it's worth noting that cargo is a fairly good package manager all things considered. It has a native lock file format, unlike requirements.txt. Running code that's built with cargo typically just works with cargo build. No futzing around with special build commands for your specific build tooling like in js. I can't speak for maven since I've only used it a little bit and never used it enough to be comfortable with it... but cargo just doesn't really have many major paper cuts.

Admittedly, cargo isn't really special - it's just a classic package manager that learned from the hindsight of its predecessors. It's all minor improvements if any. There's actually innovative build tooling out there: things like buck2, nix, etc. But those are an entirely different ball game.

See if you can find a book on python, and work through it a bit. Sit down with him once you know some and try making something basic with turtle or the likes. Your goal is to keep his interest up and not make it a "studying" thing. For a kid the most important part is that he needs to be able to see results of what he's making. Drawing simple shapes, cool patterns, etc. in python is a nice way to start and it can teach all the basic initial things he needs to know.

There's also simple robot kits for kids that could be fun to play with, which he could eventually move on to basic electronics to after from.

W.r.t. safe browsing, I'd try blocking egregiously bad stuff with some DNS blocker that you either buy or host using something like pihole. Use it to block ads and well known "bad" domain names. Also have a conversation about it. (I'm not sure how much this helps here considering he's 8... but better then nothing.)

The last bit isn't strictly true - there's ways to trace such tasks by generating IDs and associating it per task / request / whatever, letting you associate messages together even in a concurrent environment. You can't just blindly print but there's libraries and the like to help you do it.

Right, but when there's third parties involved which you may not trust (which is almost always going to be the case when talking to users not on your server), e2e's benefit starts becoming a lot more enticing. And while you have a point on out of band key sharing being annoying, it makes sense as a default - especially when content is going across servers. Content should be secure with an opt-out rather than insecure with an opt-in. The latter is just more error prone.

Also: while it's not friction free, apps like signal have shown that you can get verified e2e to be usable for the general population.

I don't think the SATA acronym is right...

The point of federation means your content doesn't only stay on your server. The person you're talking too can be on a different one and their admin can see them too. Also, I wouldn't want to be able to access content from any user - it's a "no trust needed" thing.

Idk about everyone else but I was fine with the specs. A basic Linux machine that can hook up to the network and run simple python scripts was plenty for a ton of use cases. They didn't need to be desktop competitors. The market didn't need to be small form factor high performance machines, and I'd argue it wasn't.

Yeah, and Linux still doesn't have a good answer to AD for managing suites of end user machines. Linux has a lot going for it - but windows isn't strictly inferior or anything.

Honestly, the entire AD suite with auth and everything else built in is genuinely a good product. And if what you want is supported by Microsoft, their other services are decent as well.

Instances aren't banning other instances for federation with communities they dislike. Instances ban other instances for hosting content they dislike. The benefit of starting an instance is you choose who to federate with.