<ofrnxmr[m]> "--rpc-access-control-origins=*" <- this, and httpS or Tor

* or Tor Hidden Service

Right right, almost forgot :P, `--rpc-access-control-origins=*`

And need to use rpc over https or an onion

 

👀 hotshop.onrender.com/#/node-checker

"be https" :(

"know things" :'(

imagine using a non-encrypted traffic public monero node

on the nursing home wifi

don't use caddy btw

Please elaborate

it's shit, i've used it

bloated http server that runs as root

It doesn't run as root

You're doing something wrong

It's not shit, it's way better than nginx or apache

Also less bloated than nginx for sure

caddy is absolute shit

You don't even know how to install it :D

it does run as rooy

*root

It doesn't

Has anyone compiled the source code to run a node

During my compilation, got an error about a file, anyone know how to fix it ?

<Siren[m]> "Also less bloated than nginx for..." <- equating lemons to oranges

nginx is a proxy, reverse balancer, and a bunch of other stuff

while caddy is supposed to be a http server with https support

stunnel will work for a server that wants https

<Siren[m]> "It doesn't..." <- ahahahaha

<XMRPriest[m]> "During my compilation, got an..." <- Use gitian or depends build

Build instructions are meant for Ubuntu 18.04 or 20.04, not debian

<Siren[m]> "It doesn't..." <- bugs.freebsd.org/bugzilla/show_bug.cgi?id=254463

Hahaha

Haha

Quick glance over appears that deescalation is possible simply by not running as root, as you would any other go program

Disclaimer: I didnt read it, just scanned over quickly

You still need to bind to privileged ports

Can't do that without root+de-escalation

You can't serve tls over port 6969 after all

Seriously why not just use nginx? Is this a particular usecase?

xmrfn[m]: you can but why

Well he seemed to want an http server for some reason

oh I thought we were talking about adding https to monero nodes

yipes why add the attack surface

and attention / constant attacks

how is it an attack surface though?

aren't monerod nodes http

every port we parse is

well yes they do http

xmrfn[m]: true but https support with a reverse proxy is seen as http by the server

OIC, for https support

yeah

Ahoy

dero people have been shitting on xmr on twitter

why do you bother giving attention to trolls

They misinform users with FUD

Monero will never recover from it.

yeah, their outreach is limited but some people get taken in by it

I know. Crypto "investors" :/

It's a scam coin mostly fueled by speculation and they talk about liquidity lol

Monero's biggest problem is its association with Crypto

... which has come to by synonymous with NFTs, "staking", scams, and Bitcoin-which-nobody-uses-and-isn't-different-from-Venmo-or-ApplePay-anyway

s/by/be/

Yeah

As for https... TBH if the node is on a dedicated box, it's easier to go whole hog and serve it thru Tor

TOR has one problem though

It's very slow

That is one of its problems

Yeah

stunnel is very useful though

* very useful in case of https though

btw how do message edits appear on the irc

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?

<cockliuser[m]> "dero people have been shitting..." <- Who?

ugh, see, don't feed the trolls

Im joking

They blocked me

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

Hey I didn't know about stunnel -- yes that looks like the perfect tool for the job

Now they are waiting for us to respond, so they can call us bullies

<cockliuser[m]> "bugs.freebsd.org..." <- Ever used an init system?

03:52 < cockliuser[m]> stunnel is very useful though

03:52 < cockliuser[m]> * very useful in case of https though

03:52 < cockliuser[m]> btw how do message edits appear on the irc

like that, I guess

ofrnxmr[m]: Are you actually talking to Dero people?

<cockliuser[m]> "You can't serve tls over port 69..." <- Also wrong, you can

<cockliuser[m]> "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

And that's normal

<cockliuser[m]> "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

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.

<xmrfn[m]> "and attention / constant attacks" <- What do you think draws more attention? Monerod packets or HTTPS going over the network?

<Siren[m]> "Also wrong, you can" <- Also wrong, you can

Correction: You can serve tls over 6969 but no client will accept it

<Siren[m]> "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

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.

certificates can be managed by the letsencrypt utility

Yes they will once you tell them the port host:6969, that includes monero wallets.

> <@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

proxy, not a HTTP server, like stunnel or hitch would work but I'm sure he enjoys the certificate management feature.

> certificates can be managed by the letsencrypt utility

Let's encrypt is horrid

Siren[m]: I don't think it will be web compatible

Why not?

> <@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 <libera.ems.host/_matrix/media/v3/do…d920a487206e5ea3859a9ce839ba42842d5>)

Let's encrypt issues you certs? I guess you mean certbot?

There was a utility to automatically manage Let's Encrypt certs for Linux

don't remember the name tho

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.

Siren[m]: fair enough, but I'd rather not require a client to enter a port

Ok? Then serve over 443.

What's wrong? Your OS doesn't have caps?

Siren[m]: I'd rather not open another attack vector thank you

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.

* for your OS to run

<apotheon> "03:52 < cockliuser> stunnel is..." <- hitch-tls.org

* for your OS prefer things to run

* for your OS prefer binaries to run

Siren[m]: Yes it's access control, it's a workaround for something that shouldn't be an issue in the first place

cockliuser[m]: Sure like MacOS you can get rid of this cockblock and not have privileged ports at all

That's not the issue

The issue is that caddy can't bind to the port and de escalate

Ugh caddy doesn't need that

Your init system does that, it's better this way

<Siren[m]> "hitch-tls.org" <- hitch-tls.org

why use this over stunnel :)

Nevermind you do have caps freebsd.org/cgi/man.cgi?capsicum(4)

Siren[m]: I use OpenBSD :)

cockliuser[m]: Do you use the CLI wallet on OpenBSD?

I thought you send a link from the freebsd bug tracker

<cockliuser[m]> "bugs.freebsd.org..." <- Yes you did

cockliuser[m]: Also has caps

> <@cockliuser:matrix.org> hitch-tls.org

> why use this over stunnel :)

It works well.

Atleast not a Linux-like cap system

Openbsd does not have a Linux-like cap system

gm

> <@siren:kernal.eu> > <@cockliuser:matrix.org> hitch-tls.org

> why use this over stunnel :)

It works well.

stunnel works well too :)

cockliuser[m]: So you're telling me you run all of your services as root?

If that's the case caddy is the least of your problems

Siren[m]: So you're telling me you run all of your services as root?

what

lol

no, openbsd has much better privilege separation than linooox

there are plenty of programs that cannot de-escalate

Siren[m]: Services tend to run as limited service accounts.

apotheon: Your init system does that using an API called capabilities.

This guy is complaining why a program lacks the functionality to start as root and then de-escalate its own privileges later on

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.

Siren[m]: lots of programs do

especially servers

I guess I misread, and shouldn't tryto participate if I haven't eavesdropped from the beginning.

s/tryto/try to/

apotheon: capabilities is literally the name of a feature that allows init systems to get binaries to use low numbered ports

* numbered ports without root

I know about that feature.

Capabilities also refers to other things.

cockliuser[m]: named for example

<Siren[m]> "man7.org/linux/man-pages..." <- I'm referring to this

We know

but as I said, a program shouldn't rely on that

Should

named dns server

it drops all privileges other than bind

many other servers do so

there's no reason for caddy not to do so

there's no reason for caddy to do that because init systems do this

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".

On linux

jeebus, your manpage link got truncated by the Matrix bridge

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 caddyserver/caddy #528#issuecomment-639716588

hmm

more people refusing to write portable code

great

"the majority of people who use it only use it on the OS we support" <- self-fulfilling prophecy

apotheon: Seeing that freebsd bug tracker I'm convinced they're retarded

I don't care

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.

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.

Siren[m]: Seeing that freebsd bug tracker I'm convinced they're retarded

great attitude

apotheon: bugs.freebsd.org/bugzilla/show_bug.cgi?id=254463

they seriously live under a rock

haven't bothered to check caddy docs nor how other OS package it

would have given them a clue

Siren[m]: bugs.freebsd.org/bugzilla/show_bug.cgi?id=254463

what about this signals "lives under a rock"

you seriously have a problem with your caddy evangelism

> <@cockliuser:matrix.org> bugs.freebsd.org/bugzilla/show_bug.cgi?id=254463

>

> what about this signals "lives under a rock"

"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

Wow, that Caddy issue comment is kinda awful.

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.

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."

there's nothing to fix

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.

named isn't a normal server then according to you, it's "retarded"

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.

> <@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.

>

> named isn't a normal server then according to you, it's "retarded"

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.

Expecting a server to de-escalate isn't "retarded" in any sense

hm

The FreeBSD bug thread seems pretty straightforward.

Well guys the times have changed it looks like

Okay, so it looks like the problem is the usual problem with security capabilities:

No two OS kernels implement them the same way, and someone wrote nonportable code.

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

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.

cockliuser[m]: Sure, there's that, too.

fighting over webservers?

It'd be nice if everything used pledge and unveil, too.

(as long as we're wishing)

You know BSD devs are free to come over and implement the features they wish :D Same with caddy.

Nothing written in the past few years supports de-escalation unless it specifically targets BSDs. This is purely up to the developer.

Besides don't you have a firewall? Can't you simply forward the low priv port to 443?

Siren[m]: named is linux software

You're now making up FUD lol

08:35 < Siren[m]> You know BSD devs are free to come over and implement the features they wish :D Same with caddy.

Why?

It's the Linux world that suffers for lack of that functionality.

they want X feature, they can implement X feature

as simple as that

err

Why would OpenBSD devs want pledge and unveil on an OS they may not even use?

cockliuser[m]: emphasis on the **written in the past few years**

"they want X feature"

they already have it

on OpenBSD

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

Siren[m]: Setuid setgid is also used on linux a lot

A LOT

I'm not talking about pledge and unveil

apotheon: Well the BSD ecosystem is a dying, can't say the same about Linux

ahahaha

* a dying one, can't

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.

siren, cap isn't as secure as privilege dropping

With cap you still have the capability on the server

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.

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.

cockliuser[m]: With dropping you have no privileges left to the server

cockliuser: net.inet.ip.portrange.reservedhigh=0 or get a real OS

Siren[m]: . . . so thanks for finally mentioning you weren't replying to what I said when you replied nonspecifically after what I said.

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.

Stnby[m]: Imagine removing privileged ports entirely to run a bloated webserver

Can't

Security capabilities aren't a standard interface. They're just a standard set of toggles, implemented in a myriad of different ways.

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.

It's so inconstant that people argue about what even qualifies as a security capability.

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.

apotheon: Thought the message I sent right after saying that the BSD devs should implement some features themselves made it very clear. I said:

"Nothing written in the past few years supports **de-escalation** unless it specifically targets BSDs. This is purely up to the developer."

> <@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:

> "Nothing written in the past few years supports **de-escalation** unless it specifically targets BSDs. This is purely up to the developer."

Do you really think modern software doesn't use setuid?

Or setgid

Even programs that use cap drop the capability privilege

<apotheon> "Siren: You seem to have ignored..." <- I'm aware that capabilities are not standard, never said they were

<Siren[m]> "Nothing written in the past..." <- Citation or source?

Or did you pull it out the shitter :D

cockliuser[m]: Get a real OS even your shitty macos has no low port limitation

Stnby[m]: Privileged ports are standardized

<cockliuser[m]> "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.

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.

lol

did you read what you yourself said

<Siren[m]> "Nothing written in the past..." <- .

You don't understand how most setuid/setgid programs work with privileges do you

You're intentionally misinterpreting my messages. What I mean in there is that programs now mostly depend on the init system for resources.

this isn't about setuid/setgid

Siren[m]: A program on bsd can use the init system for that, that's not the point

cockliuser[m]: apparently it cannot, as it couldn't bind on 443 via init

You can with a superuser

Then drop privileges

cockliuser[m]: you should share this knowledge with the freebsd devs, I'm sure they would appreciate it /s

running something as superuser is more secure than allowing low ports and begging as a regular users?

s/users/user/

Siren[m]: The program needs to support it

cockliuser[m]: it doesn't in your case and it won't

Stnby[m]: Allowing a capability is not any more secure

my point is that software doesn't get written for BSD and they mostly don't do that anymore

cockliuser: Call yourself lucky that they even bothered to attempt to support FreeBSD

Siren[m]: You live under a rock then :)

Stnby[m]: That wasn't made for BSD, mr sperg

It's a general security feature

To run a daemon as root?

Stnby[m]: No, to drop privileges

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

After you drop privileges, the program is not root by any sense

And I am talking about Linux here

No one cares about your Free BSD

cockliuser[m]: What if it has done the damage before it decides to drop lol

Stnby[m]: And people wanted the webserver to support it. It doesn't without cap configuration

cockliuser[m]: Too bad for you

Stnby[m]: The source code is public

Siren[m]: you have 3 options instead of crying about your cuck license OS:

1. patch the program to add the said features that you need for compatibility

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).

3. get a better OS

Stnby[m]: The webserver is run as root by default

Go argue with them

08:57 < Stnby[m]> cockliuser[m]: Get a real OS even your shitty macos has no low port limitation

Caddy

No, we don't care

It seems odd to me to call a system that has security controls on high value ports "shitty" because of it.

cockliuser[m]: Your ass is public. Its apache2 licensed caddy we are talikng about and BSD does not force to publish your code either

Siren[m]: Obviously lmao

either implement the feature, the API or a patch for caddy and maintain it

you don't need to cry

that's what some linux distros do even, maintaining patched versions

cockliuser[m]: Lol imagine arguing for caps to return to "lol just run it as root"

it's a normal thing, again

Room temperature IQ argument

"implement [. . .] the API" = "throw out the current security capabilities system and replace it with the system from another OS"

wtf

Siren[m]: I don't and will never use caddy

Shit software doesn't deserve adoption

cockliuser[m]: I 100% agree

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.

One of the reasons why FreeBSD is pretty dead

Stnby[m]: we're not even talking about freebsd here

Are you on some bad lsd?

cockliuser[m]: ever seen a bsd conference? :))

yea

cockliuser[m]: The issue you are having is FreeBSD specific.

Stnby[m]: No, any os which doesn't support linux caps

caps are ultimately more secure than dropping privileges from root

Have you been reading the conversation?

or not

Once in a while. It did not seem to progress anywhere. And I am working at the same time as well

cockliuser[m]: yes but you have other options than crying to devs about a missing feature and calling it a bug

which it isn't

just roll your patch for it

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

or use a firewall like I said

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

With a cap you have the ability to bind to any privileged port at any time

cockliuser[m]: How often do you have the source code of a FreeBSD distro with its software bundle?

apotheon: then patch caddy or use a fw

especially because of a fundamental problem of security capabilities systems:

as simple as that

Stnby[m]: 0.0000001% of the time?

Stnby[m]: I'm not using FreeBSD ;)

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.

cockliuser[m]: even if I was, I wouldn't be running an unverified binary as root

Anyway I'm going to exit this, arguing with software maxis is worthless

Send them a MR they will probably add the setuid/setgid feature. It requires CGO so its debatable if they would merge it tho.

not worth it

It seems like 20-30min job to add this

CGO would break even more compatibility

but bsd people can do that

it's not that unusual to maintain their own patched version

even better if that's easy to add

Linux maxis are as bad as, if not worse compared to Bitcoin maxis

All you need is

C.setgid(C.__gid_t(gid))

C.setuid(C.__uid_t(uid))

And obviously error handling

* All you need is... (full message at <libera.ems.host/_matrix/media/v3/do…c7d3de75f743c2517fd135ce8ffe8e3529d>)

🫡

ut-oh, a "full message" link thing

apotheon: Salute emoji

I was talking about this:

09:30 < Stnby[m]> * All you need is... (full message at <libera.ems.host/_matrix/media/v3/do…c7d3de75f743c2517fd135ce8ffe8e3529d>)

Oh there is a wrapper around this already

apotheon: Oh that's a code snippet

okay

cool

Yeah use a syscall package, this way cgo is optional, which is a lot better

Hi, I was connected to a remote node using the command: set_daemon <host>:<port> trusted. The client output the following "Warning: connecting to a non-local daemon without SSL, passive adversaries will be able to spy on you." However, when I run the status command, the output was: "Refreshed 2805793/2805794, syncing, daemon RPC v3.10, SSL". So I'm confused. Was the connection between my wallet and the remote node, using SSL or not?

sorry, I think my post was chopped off, I'll shorten it and resend.

Hi, I was connected to a remote node using: set_daemon <host>:<port> trusted. The wallet output: "Warning: connecting to a non-local daemon without SSL, passive adversaries will be able to spy on you." However, when I ran "status", the output was: "Refreshed 2805793/2805794, syncing, daemon RPC v3.10, SSL". So I'm confused. Was the connection between my wallet and the remote node, using SSL or not?

I think it's because you didn't use https:// in the url

That's what I can gather from simplewallet.cpp

<Steven_M> "Hi, I was connected to a..." <- Try running set_daemon https://<host>:<port>

* Try running set_daemon https://\<host>:\<port>

cockliuser[m]: That worked perfectly, thanks so much! :-)