pcpuser

I live in a major Indian city and 1 gig fiber up and down is $30. We've also got really good 4G/5G in most places. Also in the super remote areas WiMAX is (still) an option.

true dat

Literally the first thing I though of.

Just want to be the nth person to chime in and say the Google doc variant is the better read.

Ths only issue that non-human readable log storage has caused is the endless nagging on forums. Literally never been an issue besides.

What does "shopped around" mean? That's not a common or accepted idiom for code. Or not one I've come across anyway.

Also show me evidence of them "shopping around" code. I'll wait.

Care to share any evidence to back up the tall claim that systemd authors forced their code on anyone?

There's so much I disagree with in the beginning but the ending is what actually grinds my gears. You make it sound like systemd manufactured this monoculture somehow. This is also the point I've seen people throw in a comparison to some closed-source org with money to burn and questionable morals.

Systemd was chosen by distros and users across different communities because it solves hard problems better than the others. We can debate about why that is, but the maintainers of Systemd aren't running smear campaigns against other open source projects. Often systemd is the subject of such ire.

They chose to solve hard problems and people adopted it. It's not anything more sinister. It's definitely not an "un-auditable mess". It's written in well formatted C with structure, good tooling, and an open community. You can disagree with the ideology but that's open source for you.

Additionally and away from my point, I believe that Systemd won our because they chose to embrace some complexity to solve really hard problems. Let's not pretend that a modern "init" does only system initialisation by calling shell scripts and then disappearing.

Times change too. Microsoft does a ton of open source. They maintain an excellent immutable Linux distro. As always the true enemy is dogma and a cult-like adherence to it.

Agreed. I wonder how many people in this thread hating on systemd have actually tried to work with upstream. They are an extremely pleasant and welcoming community who are willing to work with you on the most trivial stuff.

Nah man you don't get it. They were "monetizing" Wayland. Whatever that means. It's certainly not because X is an insanely old and difficult to maintain codebase with questionable design decisions.

Google auth but you can run your OIDC provider if you're into that: https://tailscale.com/kb/1240/sso-custom-oidc.

So Tailscale has "extra dependencies" on Tailscale. Gotcha.

NAT busting, and no key management. What extra dependencies does Tailscale have?

That's definitely a limitation of your network. I don't see how ipv6 can shoulder any responsibility here.

You might find mitmproxy useful.

Except for the fact that chromium is a feeder project for a proprietary closed source work and so often bends to the will of that project.

Morally there's no equivalence here.

> 3) The overreliance on dbus turns the “the unix philosophy” ;) away. Text as a universal communication medium, everything is a file, etc

I prefer an introspectable, typed, and efficient communication protocol over streaming text because of the "Unix philosophy" whatever that may be.

Is the philosophy documented somewhere or is it just in our hearts? Because the Systemd Bus interface has great docs right here: https://www.freedesktop.org/software/systemd/man/latest/org....

Without replying to specific parts, I'd like to point out that you and others bring up parallels between Systemd and closed source proprietary software shops like Apple and Windows. I view this as bad faith because Systemd should be afforded the kindness (and obviously has the user freedoms) of a fully open source work.

There's nothing apple-esque about any of this. 'If you're unhappy fork it', is a common adage that is definitely applicable here.

So close once more lol

> 2. The CertificationRequestInfo value is signed with the subject entity's private key. (See Section 4.2.)

I wonder what this means? Hmm...

Please read this section carefully: https://datatracker.ietf.org/doc/html/rfc2986#section-3

The CSR contains the digital signature of the public key that is requesting the certificate. So you absolutely need the private key to create a CSR. How would you create a CSR with just a public key?

Again, completely off the mark here. To create any CSR, bifrost or not, you need the private key that the CSR represents.

> Creating a CSR creats my private key for the CSR...

Not really sure what's going on here tbh.

The UUID is "sent" to the server in the signed certificate. Not in the clear or over an app protocol like HTTP. There's no way to fake this UUID.

The HTTP header comparison at the end is so close but so far. The auth in the server is basically your tsv file.

You can't fake the UUID in mTLS because you need the actual private key to be present with the client when it makes a connection to the server. There's no way to fake this in TLS.

Which server is running plain HTTP? What credentials are transmitted over plaintext?

I'd suggest reading up a bit more about X.509 CSRs and Certificates before assuming that private credentials are being transmitted in the clear.

I appreciate the somewhat misguided feedback because you did point out that the rationale isn't clear enough. The rest of it is questionable though.

Yeah that part about deploying could use a lot more context.

The idea is that any client can go and get itself a certificate and talk to your application server.

All clients start off "un-verified" or "deactivated", until an operator comes around and verifies them by their UUIDs. Once they are trusted, they continue talking to your app servers but now they can access more privileged endpoints.

This access control is as simple as storing a trusted boolean alongside client UUIDs.

You could also deploy the CA inside an isolated network. Such as deploying it as Kubernetes service, so that only pods running inside the cluster can certify themselves.

It's a very simple (and cheaper) alternative to running AWS Private CA instances or hosting SmallStep's CA yourself.

I'll quote the second para:

The idea behind Bifrost is to provide clients a mechanism to create unique identities and register with a central authority, without having to provide sensitive information like passwords or API keys.