81–90 of 100 posts
Kudos! This is great, I started working on a similar project but never had the discipline to sit through all the edge cases. Maybe I'll start building it on top of ferron! I would love to have a minimalistic DIY serverless platform where I can compile rust functions (or anything else, as long as it matches the type signature) to a .so, dynamically load the .so and run the code when a certain path is hit. You could ev…
Wishing the best for your concept too!
This has a good chance to succeed. Good luck.
I know it's not popular to care about these things these days, but please consider a different installation mechanism than curl piped into sudo bash. It's irresponsible and normalizes a practice that never should've happened.
I care about these things. But this is overblown. What’s your threat model here, you’re downloading a random thing from the internet and executing it. 99% of people are on single user machines, so root access doesn’t help, you’re screwed just by executing the thing if it’s malicious. Doing this is no worse than installing and running a random deb, or running npm install
So I have to connect my domain to your IP adres? Why there is perfectly fine HTTP auth method for let's encrypt. This is strange and not necessary.
Well, you're probably talking about the automatic TLS demo. People installing Ferron on their servers don't have to use this demo!
"Point a subdomain named ferrondemo of your domain name (for example, ferrondemo.example.com) to either: CNAME demo.ferron.sh or A 194.110.4.223"
This is really strange and make my Spidey sense tingle. If the goal is to just point your domain to this server it should not require DNS auth. Just HTTP is fine. DNS sure if you want optimize reverse proxy, because that would be also possible to do via http auth for every subdomain separately. If you just need some www server quickly pointing your domain to some other dude domain is not the way to go.
This feels weird.
Earlier quoted context omitted.
Well, you're probably talking about the automatic TLS demo. People installing Ferron on their servers don't have to use this demo!
No, I do not think so. In the linked page there is mention: "Point a subdomain named ferrondemo of your domain name (for example, ferrondemo.example.com) to either: CNAME demo.ferron.sh or A 194.110.4.223" This is really strange and make my Spidey sense tingle. If the goal is to just point your domain to this server it should not require DNS auth. Just HTTP is fine. DNS sure if you want optimize reverse proxy, becaus…
Yeah. But as I said before, people installing Ferron on their servers don't need to use this demo. Oh, and people using this demo don't need to install Ferron on their servers.
I just added two notices to this demo:
> Note: After completing the demo, it's recommended to delete the subdomain you have just created to prevent security issues.
> This demo setup is optional and exists only to demonstrate automatic TLS functionality. You do not need to point any subdomain to demo servers for normal use of Ferron.
Earlier quoted context omitted.
Can we stop with this nonsense already? If you trust them enough to run their server code, why wouldn't you trust them with the installation script?
Read how Tls works. Many people Can mitm. That’s why we sign applications
Earlier quoted context omitted.
I care about these things. But this is overblown. What’s your threat model here, you’re downloading a random thing from the internet and executing it. 99% of people are on single user machines, so root access doesn’t help, you’re screwed just by executing the thing if it’s malicious. Doing this is no worse than installing and running a random deb, or running npm install
It's not just a security thing. If you install something via curl|bash, how do you uninstall it? How do you update it? Do you know what it did to your machine? What config files it touched?
Earlier quoted context omitted.
It's not just a security thing. If you install something via curl|bash, how do you uninstall it? How do you update it? Do you know what it did to your machine? What config files it touched?
There's no guarantee that any install method is easily uninstallable, updateable, or cleanable either.
Earlier quoted context omitted.
It's not just a security thing. If you install something via curl|bash, how do you uninstall it? How do you update it? Do you know what it did to your machine? What config files it touched?
There's no guarantee that any install method is easily uninstallable, updateable, or cleanable either.
2. Actually, no, I will fight you on this: Unless you're actively trying to break them, docker, nix, flatpak, or any of their ilk will trivialize updates and give you guaranteed uninstallation and going full container will absolutely let you lock down exactly what an application is capable of touching or leaving behind (so, easy with podman/docker, varies with flatpak).
"It's written in Rust so it's memory safe!"