Heads up: the next version of Site.js (alongside a complete ground-up rewrite of automatic TLS via Let’s Encrypt certificates and Hugo integration) will move from using setcap to disabling privileged ports on Linux.
Privileged ports are basically security theatre as we’re living in 2020 not 1970 and Site.js is for individuals, not corporate behemoths who might still be running NFS on their networks. macOS removed them in Mojave.
Details (with links to relevant reading): https://source.small-tech.org/site.js/app/-/issues/169
@aral Ok hold up...
I'm a fan of chaos in general, but:
I'm confused by this - is the goal to just get rid of the whole "run the web on port 80 and 443, use whatever you want?"
Because you already CAN.
Of course, you won't get past most ISP's, corporate networks, and you won't be found by search engines _easily._ And I have no problem with that. It works already this way.
So... what's the point of this... entire thread?
Make it so you can run it more easily on the ports that are already "well known?"
That's not how it's phrased. It's phrased as if it were "a problem that you can't bind to port 80, because security blah blah." Again: run your service on WHATEVER PORT YOU WANT. Of course, putting it below port 1024 is going to need root because of STANDARDS (not security) and because then people can FIND YOU.
@Truck he knows that. This is about running on well-known ports, but without setcap (which causes other issues, documented in the link above)
@aral lot of good points in the issue. Thanks!
@aral Just added that to my sysctl.conf.
net.ipv4.ip_unprivileged_port_start also apparently applies to ipv6, because Linux.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!