01:05:41 "--rpc-access-control-origins=*" <- this, and httpS or Tor 01:05:46 * or Tor Hidden Service 01:08:39 Right right, almost forgot :P, `--rpc-access-control-origins=*` 01:08:39 And need to use rpc over https or an onion 01:08:39 01:09:29 👀 https://hotshop.onrender.com/#/node-checker 01:10:44 "be https" :( 01:11:00 "know things" :'( 01:11:46 https://caddyserver.com/docs/automatic-https 01:16:19 imagine using a non-encrypted traffic public monero node 01:16:44 on the nursing home wifi 02:23:49 don't use caddy btw 02:25:07 Please elaborate 02:27:35 it's shit, i've used it 02:27:48 bloated http server that runs as root 02:28:36 It doesn't run as root 02:28:42 You're doing something wrong 02:29:15 It's not shit, it's way better than nginx or apache 02:30:28 Also less bloated than nginx for sure 02:30:46 caddy is absolute shit 02:31:01 You don't even know how to install it :D 02:31:02 it does run as rooy 02:31:08 *root 02:31:11 It doesn't 02:31:32 Has anyone compiled the source code to run a node 02:31:53 * XMRPriest[m] uploaded an image: (3786KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/yAALTjbokyXzsxDNozljqbkJ/ima_85f8e52.jpeg > 02:32:11 During my compilation, got an error about a file, anyone know how to fix it ? 02:40:30 "Also less bloated than nginx for..." <- equating lemons to oranges 02:41:04 nginx is a proxy, reverse balancer, and a bunch of other stuff 02:41:33 while caddy is supposed to be a http server with https support 02:43:26 stunnel will work for a server that wants https 02:50:07 "It doesn't..." <- ahahahaha 02:51:09 "During my compilation, got an..." <- Use gitian or depends build 02:51:35 Build instructions are meant for Ubuntu 18.04 or 20.04, not debian 02:51:37 "It doesn't..." <- https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254463 02:51:46 Hahaha 02:53:45 Haha 02:53:53 https://github.com/caddyserver/caddy/issues/528#issuecomment-639716588 02:54:23 Quick glance over appears that deescalation is possible simply by not running as root, as you would any other go program 02:54:39 Disclaimer: I didnt read it, just scanned over quickly 02:57:31 You still need to bind to privileged ports 02:58:00 Can't do that without root+de-escalation 02:58:38 You can't serve tls over port 6969 after all 03:34:54 Seriously why not just use nginx? Is this a particular usecase? 03:35:05 xmrfn[m]: you can but why 03:35:31 Well he seemed to want an http server for some reason 03:36:03 oh I thought we were talking about adding https to monero nodes 03:36:23 yipes why add the attack surface 03:36:48 and attention / constant attacks 03:36:52 how is it an attack surface though? 03:37:10 aren't monerod nodes http 03:37:11 every port we parse is 03:37:38 well yes they do http 03:38:04 xmrfn[m]: true but https support with a reverse proxy is seen as http by the server 03:38:25 OIC, for https support 03:39:53 yeah 03:40:02 Ahoy 03:40:06 dero people have been shitting on xmr on twitter 03:40:26 why do you bother giving attention to trolls 03:40:54 They misinform users with FUD 03:41:00 Monero will never recover from it. 03:41:46 yeah, their outreach is limited but some people get taken in by it 03:42:03 I know. Crypto "investors" :/ 03:43:43 It's a scam coin mostly fueled by speculation and they talk about liquidity lol 03:44:23 Monero's biggest problem is its association with Crypto 03:45:44 ... which has come to by synonymous with NFTs, "staking", scams, and Bitcoin-which-nobody-uses-and-isn't-different-from-Venmo-or-ApplePay-anyway 03:45:59 s/by/be/ 03:49:48 Yeah 03:50:03 As for https... TBH if the node is on a dedicated box, it's easier to go whole hog and serve it thru Tor 03:50:38 TOR has one problem though 03:50:41 It's very slow 03:50:51 That is one of its problems 03:51:04 Yeah 03:52:13 stunnel is very useful though 03:52:26 * very useful in case of https though 03:52:46 btw how do message edits appear on the irc 03:53:02 OTOH if you're connecting to a Monero node, those are all known/discoverable IP addresses, and the information you exchange with them is 100% public, nothing personal to be gained. So HTTPS is buying you very little. Why encrypt the traffic? 03:53:58 "dero people have been shitting..." <- Who? 03:54:13 ugh, see, don't feed the trolls 03:54:52 Im joking 03:54:58 They blocked me 03:55:37 Captain and his goonies tried to pick a fight with me and got slapped by 19 different people, then stfu about monero for 6 months 03:55:43 Hey I didn't know about stunnel -- yes that looks like the perfect tool for the job 03:55:54 Now they are waiting for us to respond, so they can call us bullies 06:46:41 "https://bugs.freebsd.org/..." <- Ever used an init system? 06:47:34 * Siren[m] uploaded an image: (96KiB) < https://libera.ems.host/_matrix/media/v3/download/kernal.eu/yebFRwCTdHJPYtYhbUWcGfYY/image_20230123084650.png > 06:47:39 03:52 < cockliuser[m]> stunnel is very useful though 06:47:39 03:52 < cockliuser[m]> * very useful in case of https though 06:47:40 03:52 < cockliuser[m]> btw how do message edits appear on the irc 06:47:44 like that, I guess 06:49:00 ofrnxmr[m]: Are you actually talking to Dero people? 07:06:19 "You can't serve tls over port 69..." <- Also wrong, you can 07:06:40 "Can't do that without root+de-..." <- You gotta have an init system and it's now doing that for the rest of your services 07:06:54 And that's normal 07:15:25 "nginx is a proxy, reverse..." <- Both Caddy and Apache can proxy, reverse balance and do the bunch of other stuff. But yes I'm equating lemons to oranges. Nginx has some of its features made unavailable on purpose so you opt out for the paid version. If you don't want the paid version, you need to pull the nginx source + plugin source and take your time to compile and maintain those binaries. While xcaddy can do this in 07:15:25 seconds. Sure a terminating proxy, not a HTTP server, like stunnel or hitch would work but I'm sure he enjoys the certificate management feature. 07:22:24 "and attention / constant attacks" <- What do you think draws more attention? Monerod packets or HTTPS going over the network? 07:32:25 "Also wrong, you can" <- Also wrong, you can 07:32:25 Correction: You can serve tls over 6969 but no client will accept it 07:33:17 "Both Caddy and Apache can proxy,..." <- Both Caddy and Apache can proxy, reverse balance and do the bunch of other stuff. But yes I'm equating lemons to oranges. Nginx has some of its features made unavailable on purpose so you opt out for the paid version. If you don't want the paid version, you need to pull the nginx source + plugin source and take your time to compile and maintain those binaries. While xcaddy can do this 07:33:17 in seconds. Sure a terminating proxy, not a HTTP server, like stunnel or hitch would work but I'm sure he enjoys the certificate management feature. 07:33:17 certificates can be managed by the letsencrypt utility 07:33:17 Yes they will once you tell them the port https://host:6969, that includes monero wallets. 07:33:28 > <@cockliuser:matrix.org> Both Caddy and Apache can proxy, reverse balance and do the bunch of other stuff. But yes I'm equating lemons to oranges. Nginx has some of its features made unavailable on purpose so you opt out for the paid version. If you don't want the paid version, you need to pull the nginx source + plugin source and take your time to compile and maintain those binaries. While xcaddy can do this in seconds. Sure a terminating 07:33:28 proxy, not a HTTP server, like stunnel or hitch would work but I'm sure he enjoys the certificate management feature. 07:33:28 > certificates can be managed by the letsencrypt utility 07:33:28 Let's encrypt is horrid 07:34:24 Siren[m]: I don't think it will be web compatible 07:35:16 Why not? 07:35:32 https://monero.fail/?web_compatible=true 07:35:59 > <@siren:kernal.eu> > <@cockliuser:matrix.org> Both Caddy and Apache can proxy, reverse balance and do the bunch of other stuff. But yes I'm equating lemons to oranges. Nginx has some of its features made unavailable on purpose so you opt out for the paid version. If you don't want the paid version, you need to... (full message at ) 07:36:36 Let's encrypt issues you certs? I guess you mean certbot? 07:37:25 There was a utility to automatically manage Let's Encrypt certs for Linux 07:37:25 don't remember the name tho 07:38:04 Certbot is shit and you shouldn't use it. Acme.sh works better. But caddy cert handling works the best. You should avoid let's encrypt because of their stupid rate limits. ZeroSSL is way better and now most utilities default to it when issuing certs. 07:38:11 Siren[m]: fair enough, but I'd rather not require a client to enter a port 07:38:41 Ok? Then serve over 443. 07:39:01 What's wrong? Your OS doesn't have caps? 07:39:51 https://man7.org/linux/man-pages/man7/capabilities.7.html 07:41:38 Siren[m]: I'd rather not open another attack vector thank you 07:42:59 Lmao that's access control, not an attack vector. When people packaging things for your to run as root, I'd rather quit using that OS. 07:43:16 * for your OS to run 07:43:42 "03:52 < cockliuser> stunnel is..." <- https://hitch-tls.org/ 07:44:08 * for your OS prefer things to run 07:44:16 * for your OS prefer binaries to run 07:44:50 Siren[m]: Yes it's access control, it's a workaround for something that shouldn't be an issue in the first place 07:45:21 cockliuser[m]: Sure like MacOS you can get rid of this cockblock and not have privileged ports at all 07:45:46 That's not the issue 07:46:07 The issue is that caddy can't bind to the port and de escalate 07:46:32 Ugh caddy doesn't need that 07:46:57 Your init system does that, it's better this way 07:48:55 "https://hitch-tls.org/" <- https://hitch-tls.org/ 07:48:55 why use this over stunnel :) 07:49:18 Nevermind you do have caps https://www.freebsd.org/cgi/man.cgi?capsicum(4) 07:51:49 Siren[m]: I use OpenBSD :) 07:52:18 cockliuser[m]: Do you use the CLI wallet on OpenBSD? 07:52:19 I thought you send a link from the freebsd bug tracker 07:52:29 "https://bugs.freebsd.org/..." <- Yes you did 07:53:06 cockliuser[m]: Also has caps 07:54:03 > <@cockliuser:matrix.org> https://hitch-tls.org/ 07:54:03 > why use this over stunnel :) 07:54:03 It works well. 07:55:01 Atleast not a Linux-like cap system 07:55:43 Openbsd does not have a Linux-like cap system 07:56:36 gm 07:57:49 > <@siren:kernal.eu> > <@cockliuser:matrix.org> https://hitch-tls.org/ 07:57:50 > why use this over stunnel :) 07:57:50 It works well. 07:57:50 stunnel works well too :) 07:57:52 cockliuser[m]: So you're telling me you run all of your services as root? 07:58:09 If that's the case caddy is the least of your problems 07:59:48 Siren[m]: So you're telling me you run all of your services as root? 07:59:48 what 07:59:52 lol 08:00:22 no, openbsd has much better privilege separation than linooox 08:00:46 there are plenty of programs that cannot de-escalate 08:00:49 Siren[m]: Services tend to run as limited service accounts. 08:01:31 apotheon: Your init system does that using an API called capabilities. 08:02:06 This guy is complaining why a program lacks the functionality to start as root and then de-escalate its own privileges later on 08:02:12 There's more than one meaning of "capabilities" in a security permissions sense, and I only skimmed some of the discussion, so I wasn't sure what you meant. 08:02:31 Siren[m]: lots of programs do 08:02:39 especially servers 08:02:49 I guess I misread, and shouldn't tryto participate if I haven't eavesdropped from the beginning. 08:02:54 s/tryto/try to/ 08:03:16 apotheon: capabilities is literally the name of a feature that allows init systems to get binaries to use low numbered ports 08:03:20 * numbered ports without root 08:03:26 I know about that feature. 08:03:36 Capabilities also refers to other things. 08:03:38 cockliuser[m]: named for example 08:04:24 "https://man7.org/linux/man-pages..." <- I'm referring to this 08:04:34 We know 08:05:16 but as I said, a program shouldn't rely on that 08:05:21 Should 08:05:31 named dns server 08:05:43 it drops all privileges other than bind 08:06:42 many other servers do so 08:06:55 there's no reason for caddy not to do so 08:07:13 there's no reason for caddy to do that because init systems do this 08:07:22 There are also many, widely varied implementations of capability security of the form that most commonly comes to mind when I hear the term: NIST SP 800-53, "security capabilities". 08:07:36 On linux 08:07:43 jeebus, your manpage link got truncated by the Matrix bridge 08:08:50 cockliuser[m]: They don't need to care about adding that feature in just because of OpenBSD when the majority of users are on Linux. Also this is a Go program, fairly safe to run it as root. As the dev explained himself here https://github.com/caddyserver/caddy/issues/528#issuecomment-639716588 08:10:00 hmm 08:10:05 more people refusing to write portable code 08:10:07 great 08:10:34 "the majority of people who use it only use it on the OS we support" <- self-fulfilling prophecy 08:10:46 apotheon: Seeing that freebsd bug tracker I'm convinced they're retarded 08:11:11 I don't care 08:12:00 I'm not sure who you're calling "retarded", but I've never used Caddy and I don't currently run FreeBSD on anything, so . . . not sure what's up with that. 08:12:10 About caps, they have caps. I'm not sure if that allows them to allow access to high priv ports but if it doesn't that's again, retarded. They went out of their way to implement most of that. 08:12:11 Siren[m]: Seeing that freebsd bug tracker I'm convinced they're retarded 08:12:11 great attitude 08:13:39 apotheon: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254463 08:14:08 they seriously live under a rock 08:14:54 haven't bothered to check caddy docs nor how other OS package it 08:14:59 would have given them a clue 08:15:36 Siren[m]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254463 08:15:36 what about this signals "lives under a rock" 08:15:41 you seriously have a problem with your caddy evangelism 08:16:27 > <@cockliuser:matrix.org> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254463 08:16:27 > 08:16:27 > what about this signals "lives under a rock" 08:16:27 "that a webserver should bind to its privileged ports (80, 443) first and then drop privileges. So this is really an upstream bug that should be reported to caddy. I will go on and report it there." This is not a bug 08:16:32 Wow, that Caddy issue comment is kinda awful. 08:18:09 cockliuser[m]: I'm just explaining things. You pinged me about 3 times and didn't seem to know about how you should run caddy and some other things about how other web servers work. That's about it. 08:18:52 translation: "We won't fix it if it affects less than half the users, and we still won't if there isn't an actual exploit regardless of whether it's a real vulnerability, and even then we won't fix it unless you provide the fix." 08:19:15 there's nothing to fix 08:19:19 Siren[m]: I'm just explaining things. You pinged me about 3 times and didn't seem to know about how you should run caddy and some other things about how other web servers work. That's about it. 08:19:19 named isn't a normal server then according to you, it's "retarded" 08:19:40 Siren[m]: If that's true, then whatever, but the comment essentially means what I just said, so . . . it's still a fucking terrible comment. 08:21:12 > <@cockliuser:matrix.org> I'm just explaining things. You pinged me about 3 times and didn't seem to know about how you should run caddy and some other things about how other web servers work. That's about it. 08:21:12 > 08:21:12 > named isn't a normal server then according to you, it's "retarded" 08:21:12 While I prefer unbound, I was referring to the thread as retarded. Perhaps you should read it a bit more careful and stop shoving things onto my mouth. 08:22:01 Expecting a server to de-escalate isn't "retarded" in any sense 08:22:08 hm 08:22:18 The FreeBSD bug thread seems pretty straightforward. 08:22:19 Well guys the times have changed it looks like 08:24:28 Okay, so it looks like the problem is the usual problem with security capabilities: 08:24:48 No two OS kernels implement them the same way, and someone wrote nonportable code. 08:25:19 That's part of it, but also there's a difference between using capabilities and de-escalation. They can be used together for more security, but a standalone de-escalated server is more secure than a server with the bind capability 08:25:23 If that's not correct, it's because I'm not willing to spend too much time reading about this stuff to be sure, but that's how it looks. 08:26:26 cockliuser[m]: Sure, there's that, too. 08:27:31 fighting over webservers? 08:27:35 It'd be nice if everything used pledge and unveil, too. 08:27:47 (as long as we're wishing) 08:35:08 You know BSD devs are free to come over and implement the features they wish :D Same with caddy. 08:37:34 Nothing written in the past few years supports de-escalation unless it specifically targets BSDs. This is purely up to the developer. 08:39:30 Besides don't you have a firewall? Can't you simply forward the low priv port to 443? 08:39:55 Siren[m]: named is linux software 08:40:10 You're now making up FUD lol 08:40:25 08:35 < Siren[m]> You know BSD devs are free to come over and implement the features they wish :D Same with caddy. 08:40:28 Why? 08:40:45 It's the Linux world that suffers for lack of that functionality. 08:40:46 they want X feature, they can implement X feature 08:40:48 as simple as that 08:40:51 err 08:41:22 Why would OpenBSD devs want pledge and unveil on an OS they may not even use? 08:41:25 cockliuser[m]: emphasis on the **written in the past few years** 08:41:50 "they want X feature" 08:41:53 they already have it 08:41:55 on OpenBSD 08:42:01 apotheon: then they don't but if they really want de-escalation in a program where it isn't required, they should implement it themselves 08:42:02 Siren[m]: Setuid setgid is also used on linux a lot 08:42:15 A LOT 08:42:19 I'm not talking about pledge and unveil 08:43:14 apotheon: Well the BSD ecosystem is a dying, can't say the same about Linux 08:43:19 ahahaha 08:43:19 * a dying one, can't 08:43:22 Siren[m]: You're saying they should implement security capabilities, which they've already done, so someone else can do something they do in a non-portable manner rather than doing it in a portable manner. 08:44:11 siren, cap isn't as secure as privilege dropping 08:44:27 With cap you still have the capability on the server 08:44:34 apotheon: I'm saying that they should have looked up how to package it. It's meant to be used with capabilities. If they have that, they should use it. Otherwise they can use a firewall to forward the traffic. There's absolutely no need for caddy devs to implement this. 08:44:57 Siren[m]: You said it following what I said about pledge and unveil, did not specify to whom you were responding, and replied about eight minutes after I mentioned pledge and unveil so you had plenty of time to notice you should specify what you meant to address. 08:45:05 cockliuser[m]: With dropping you have no privileges left to the server 08:45:20 cockliuser: net.inet.ip.portrange.reservedhigh=0 or get a real OS 08:45:21 Siren[m]: . . . so thanks for finally mentioning you weren't replying to what I said when you replied nonspecifically after what I said. 08:46:12 Siren[m]: You seem to have ignored my earlier comment about how it's the same old problem as usual -- that every OS with a different kernel implements it differently. 08:46:19 Stnby[m]: Imagine removing privileged ports entirely to run a bloated webserver 08:46:23 Can't 08:46:46 Security capabilities aren't a standard interface. They're just a standard set of toggles, implemented in a myriad of different ways. 08:46:55 apotheon: While this discussion is mainly about de-escalation or caps. In general someone should implement the missing features that they want if it's niche enough. In the case of caddy, it is niche. 08:47:05 It's so inconstant that people argue about what even qualifies as a security capability. 08:48:54 cockliuser[m]: Imagine having a nick that resembles a cock looser who attempts to run software on his Free BSD VM on a shiny Macbook. 08:48:55 apotheon: Thought the message I sent right after saying that the BSD devs should implement some features themselves made it very clear. I said: 08:48:55 "Nothing written in the past few years supports **de-escalation** unless it specifically targets BSDs. This is purely up to the developer." 08:50:08 > <@siren:kernal.eu> Thought the message I sent right after saying that the BSD devs should implement some features themselves made it very clear. I said: 08:50:08 > "Nothing written in the past few years supports **de-escalation** unless it specifically targets BSDs. This is purely up to the developer." 08:50:08 Do you really think modern software doesn't use setuid? 08:50:10 Or setgid 08:50:32 Even programs that use cap drop the capability privilege 08:53:24 "Siren: You seem to have ignored..." <- I'm aware that capabilities are not standard, never said they were 08:55:40 "Nothing written in the past..." <- Citation or source? 08:55:59 Or did you pull it out the shitter :D 08:57:16 cockliuser[m]: Get a real OS even your shitty macos has no low port limitation 08:57:45 Stnby[m]: Privileged ports are standardized 09:07:19 "Citation or source?" <- Myself, working devops in a large infra (~2k servers) and none of the servers run BSD. I don't have time to dig for you but doing a small amount of research should tell you about the state of BSD. 09:07:40 Siren[m]: Myself, working devops in a large infra (~2k servers) and none of the servers run BSD. I don't have time to dig for you but doing a small amount of research should tell you about the state of BSD. 09:07:40 lol 09:07:53 did you read what you yourself said 09:08:25 "Nothing written in the past..." <- . 09:09:08 You don't understand how most setuid/setgid programs work with privileges do you 09:10:09 You're intentionally misinterpreting my messages. What I mean in there is that programs now mostly depend on the init system for resources. 09:10:28 this isn't about setuid/setgid 09:11:18 Siren[m]: A program on bsd can use the init system for that, that's not the point 09:11:48 cockliuser[m]: apparently it cannot, as it couldn't bind on 443 via init 09:12:06 You can with a superuser 09:12:12 Then drop privileges 09:12:46 cockliuser[m]: you should share this knowledge with the freebsd devs, I'm sure they would appreciate it /s 09:12:52 running something as superuser is more secure than allowing low ports and begging as a regular users? 09:12:58 s/users/user/ 09:13:07 Siren[m]: The program needs to support it 09:13:19 cockliuser[m]: it doesn't in your case and it won't 09:13:35 Stnby[m]: Allowing a capability is not any more secure 09:13:43 my point is that software doesn't get written for BSD and they mostly don't do that anymore 09:13:54 cockliuser: Call yourself lucky that they even bothered to attempt to support FreeBSD 09:14:05 Siren[m]: You live under a rock then :) 09:14:19 Stnby[m]: That wasn't made for BSD, mr sperg 09:14:35 It's a general security feature 09:14:48 To run a daemon as root? 09:15:05 Stnby[m]: No, to drop privileges 09:15:26 I call a security feature being able to run it as any user I want. It does not need to drop privileges if it does not even need them to begin with 09:15:28 After you drop privileges, the program is not root by any sense 09:15:35 And I am talking about Linux here 09:15:45 No one cares about your Free BSD 09:16:13 cockliuser[m]: What if it has done the damage before it decides to drop lol 09:16:17 Stnby[m]: And people wanted the webserver to support it. It doesn't without cap configuration 09:16:35 cockliuser[m]: Too bad for you 09:16:37 Stnby[m]: The source code is public 09:16:46 Siren[m]: you have 3 options instead of crying about your cuck license OS: 09:16:46 1. patch the program to add the said features that you need for compatibility 09:16:46 2. find a work around (you're not capable hence you didn't even know that it was possible to have SSL/TLS on a non standard port but I promise you that a firewall rule to forward traffic would work in your case). 09:16:46 3. get a better OS 09:17:00 Stnby[m]: The webserver is run as root by default 09:17:06 Go argue with them 09:17:16 08:57 < Stnby[m]> cockliuser[m]: Get a real OS even your shitty macos has no low port limitation 09:17:16 Caddy 09:17:25 No, we don't care 09:17:36 It seems odd to me to call a system that has security controls on high value ports "shitty" because of it. 09:17:36 cockliuser[m]: Your ass is public. Its apache2 licensed caddy we are talikng about and BSD does not force to publish your code either 09:17:47 Siren[m]: Obviously lmao 09:17:47 either implement the feature, the API or a patch for caddy and maintain it 09:18:09 you don't need to cry 09:18:13 that's what some linux distros do even, maintaining patched versions 09:18:16 cockliuser[m]: Lol imagine arguing for caps to return to "lol just run it as root" 09:18:18 it's a normal thing, again 09:18:31 Room temperature IQ argument 09:18:46 "implement [. . .] the API" = "throw out the current security capabilities system and replace it with the system from another OS" 09:18:49 wtf 09:20:19 Siren[m]: I don't and will never use caddy 09:20:38 Shit software doesn't deserve adoption 09:20:53 cockliuser[m]: I 100% agree 09:21:07 apotheon: you don't need to fully replace it, add a compatibility layer or just implement what's missing. even if you don't wanna deal with caps, you have the other two options. 09:21:17 One of the reasons why FreeBSD is pretty dead 09:21:46 Stnby[m]: we're not even talking about freebsd here 09:21:56 Are you on some bad lsd? 09:22:09 cockliuser[m]: ever seen a bsd conference? :)) 09:22:18 yea 09:22:25 cockliuser[m]: The issue you are having is FreeBSD specific. 09:22:58 Stnby[m]: No, any os which doesn't support linux caps 09:23:06 caps are ultimately more secure than dropping privileges from root 09:23:16 Have you been reading the conversation? 09:23:23 or not 09:24:03 Once in a while. It did not seem to progress anywhere. And I am working at the same time as well 09:24:20 cockliuser[m]: yes but you have other options than crying to devs about a missing feature and calling it a bug 09:24:22 which it isn't 09:24:31 just roll your patch for it 09:24:32 Stnby[m]: If you have the source code of a program, and you verify that it binds to the ports then drops privs, it's inherently much more secure than caps 09:24:37 or use a firewall like I said 09:24:46 Siren[m]: some people don't want 80 metric tons of extra stuff on top of a system that works fine when you actually use it 09:24:55 With a cap you have the ability to bind to any privileged port at any time 09:25:01 cockliuser[m]: How often do you have the source code of a FreeBSD distro with its software bundle? 09:25:01 apotheon: then patch caddy or use a fw 09:25:03 especially because of a fundamental problem of security capabilities systems: 09:25:05 as simple as that 09:25:09 Stnby[m]: 0.0000001% of the time? 09:25:27 Stnby[m]: I'm not using FreeBSD ;) 09:26:08 The whole idea of security capabilities is not specified in a way that requires any kind of ability to actually be sure that some similar operation with one can even be expressed the same way on another, so that an API wrapper is functionally impossible to fully implement. 09:27:18 cockliuser[m]: even if I was, I wouldn't be running an unverified binary as root 09:28:02 Anyway I'm going to exit this, arguing with software maxis is worthless 09:28:47 Send them a MR they will probably add the setuid/setgid feature. It requires CGO so its debatable if they would merge it tho. 09:29:05 not worth it 09:29:12 It seems like 20-30min job to add this 09:29:16 CGO would break even more compatibility 09:29:24 but bsd people can do that 09:29:36 it's not that unusual to maintain their own patched version 09:29:46 even better if that's easy to add 09:30:07 Linux maxis are as bad as, if not worse compared to Bitcoin maxis 09:30:07 All you need is 09:30:07 C.setgid(C.__gid_t(gid)) 09:30:07 C.setuid(C.__uid_t(uid)) 09:30:07 And obviously error handling 09:30:11 * All you need is... (full message at ) 09:30:16 🫡 09:32:21 ut-oh, a "full message" link thing 09:32:38 apotheon: Salute emoji 09:32:56 I was talking about this: 09:33:00 09:30 < Stnby[m]> * All you need is... (full message at ) 09:33:05