71–80 of 96 posts
Hey, I just decided to run a DNS server and a couple of web services on my lan from a raspberry pi over the weekend. I used Nginx for the reverse proxy so all of the services could be addressable without port numbers. It was very easy to set up, it's funny how when you learn something new, you start seeing it all over the place.
What's the easiest way to install the newest nginx in Ubuntu 24? PPA or something?
Does this mean we don’t need to use certbot?
Currently it supports only HTTP-01 challenges (no wildcards, must be reachable).
Earlier quoted context omitted.
People like bragging/advertising about their language of choice. Maybe others who like the language will get interested in collaborating, or employers who need developers for that language might get in contact with them. Also, unsafe rust is still safer than C.
> Also, unsafe rust is still safer than C. I highly doubt that, and developers of Rust have confirmed here on HN that when it comes to unsafe code within a codebase, it is not just the unsafe blocks that are affected, the whole codebase is affected by that.
The main practical difference is that Rust pushes you away from UB whereas C tends to push you into it; signed integer overflow is default-UB in C, while Rust makes you go out of your way to get UB integer overflow. Furthermore, the general design philosophy of Rust is that you build "safe abstractions" which might require unsafe to implement, but the interface should be impossible to use in a way which doesn't cause any UB. It's definitely questionable how many people actually adhere to those rules--some people are just going to slap the unsafe keyword on things to make the code compile--but it's still a pretty far distance from C, where the language tends to make building abstractions of any kind, let alone safe ones, difficult.
What took them so long? Honest question. I'd expect nginx to have this years ago. Is that so hard to implement for some reason?
What does this offer to you vs using a tool such as certbot/cert-manager, and then just referencing the path in nginx?
Earlier quoted context omitted.
That's okay, next step is to fold both nginx and the acme client into systemd.
Okay but hear me out If we teach systemd socket activation to do TLS handshakes we can completely offload TLS encryption to the kernel (and network devices) and you get all of this for free. It's actually not a crazy idea in the world of kTLS to centralize TLS handshaking into systems
Linux seems to offer such facilities, too. I never use it to my knowledge, though (might be that some app used it in background?) https://lwn.net/Articles/892216/
Be aware, nginx is developed by a Russian.
https://www.themoscowtimes.com/2019/12/13/russia-nginx-fsb-r...
Earlier quoted context omitted.
Okay but hear me out If we teach systemd socket activation to do TLS handshakes we can completely offload TLS encryption to the kernel (and network devices) and you get all of this for free. It's actually not a crazy idea in the world of kTLS to centralize TLS handshaking into systems
Oh, I remember my Solaris fanboys praising Kernel-Level TLS as it reduced context switching by a lot. I believe they even had a patched openssl making this transparent to openssl based applications. Linux seems to offer such facilities, too. I never use it to my knowledge, though (might be that some app used it in background?) https://lwn.net/Articles/892216/
(fun to walk down through the trees and the silicon desert of despair, to the land of the ROM, where things can never change)
This idea we seem to have moved towards where every applications ALSO includes their own ACME support really annoys me actually. I much prefer the idea that there's well written clients who's job it is to do the ACME handling. Is my Postfix mailserver soon going to have an ACME shoehorned in? I've already seen GitHub issues for AdGuardHome (a DNS server that supports blocklists) to have an ACME client built in, thank…
I’m of the opposite opinion, really: Automatic TLS certificate requests are just an implementation detail of software able to advertise as accepting encrypted connections. Similarly many applications include an OAuth client that automatically takes care of requesting access tokens and refreshing them automatically, all using a discovery URI and client credentials. Lots of apps should support this automatically, with…
Instead, it would make more sense for TLS to be handled centrally by a known and trusted implementation, which proxies the communication with each backend. This is a common architecture we've used for decades. It's flexible, more secure, keeps complexity compartmentalized, and is much easier to manage.
Earlier quoted context omitted.
> Also, unsafe rust is still safer than C. I highly doubt that, and developers of Rust have confirmed here on HN that when it comes to unsafe code within a codebase, it is not just the unsafe blocks that are affected, the whole codebase is affected by that.
Unsafe rust still enforces many of rust's rules. The only powers you get with unsafe rust are de-refrencing raw pointers, calling unsafe traits / functions, and the ability to access or modify mutable statics. You can read more about this here. https://doc.rust-lang.org/nomicon/what-unsafe-does.html Unsafe rust is definitely safer than normal C. All the unsafe keyword really means is that the compiler cannot verify t…