You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I’m fine if you decide this is WONTFIX, but I think it’s worth the trouble. This is specific to the launchd.plist created on macOS.
I believe that, security-wise, it’s better to have fewer services on a development machine listening to public requests. puma-dev -install binds to 0.0.0.0, and that opens up all of the services to any machine that can reach it over the network. I think the /status api makes it easy to enumerate the dev services, and then a malicious actor (or the company’s red team) can explore at will (and iirc I’ve seen a vuln in Sketch get turned into arbitrary file access as an internal example for why this can be bad).
I won’t go so far to ask that 127.0.0.1 become the default (although secure by default is arguably better), but IMO it’d be a really great option to provide.
I realize the nip.io feature relies on 0.0.0.0, and some people will definitely want to keep 0.0.0.0. However, providing documentation & an easy way to make this safer & more secure seems like a net win to me. If you’re willing to make a “breaking” change, requiring explicit action before allowing external access does seem reasonable to me.
I certainly know enough to edit the plist and unload/load it, but I think it’s the kind of thing most people won’t consider unless it’s mentioned in the readme and/or offered as a programmatic option. Especially if they’re regenerating the plist occasionally (for example #112).
Thanks for your work on this tool!
The text was updated successfully, but these errors were encountered:
I like the idea of adding this as an option. I understand a lot of people depend on the 0.0.0.0 for being to access puma from VMs or stuff like that, but I don't love that if I'm on a public Wi-Fi network, anyone can connect to my puma apps.
Adding something like -install-bind-localhost or similar sounds like a fine idea.
Re: making this the default behavior (and making the flag -install-bind-public or something), there's a slowly growing list of default behavior that I'd like to be able to make non-default. Prob good to start tracking a wishlist for 1.0.
What if there was a -listen-hosts flag, similar to -d, that allowed the user to specify what the HTTP server should listen on? I wrote about this some here; the gist is that running puma-dev in the foreground only listens on 127.0.0.1, without the ability to change where the socket is listening. Being able to specify what addresses are acceptable would be a huge boon.
I’m fine if you decide this is WONTFIX, but I think it’s worth the trouble. This is specific to the launchd.plist created on macOS.
I believe that, security-wise, it’s better to have fewer services on a development machine listening to public requests.
puma-dev -install
binds to0.0.0.0
, and that opens up all of the services to any machine that can reach it over the network. I think the/status
api makes it easy to enumerate the dev services, and then a malicious actor (or the company’s red team) can explore at will (and iirc I’ve seen a vuln in Sketch get turned into arbitrary file access as an internal example for why this can be bad).I won’t go so far to ask that
127.0.0.1
become the default (although secure by default is arguably better), but IMO it’d be a really great option to provide.I realize the nip.io feature relies on
0.0.0.0
, and some people will definitely want to keep0.0.0.0
. However, providing documentation & an easy way to make this safer & more secure seems like a net win to me. If you’re willing to make a “breaking” change, requiring explicit action before allowing external access does seem reasonable to me.I certainly know enough to edit the plist and unload/load it, but I think it’s the kind of thing most people won’t consider unless it’s mentioned in the readme and/or offered as a programmatic option. Especially if they’re regenerating the plist occasionally (for example #112).
Thanks for your work on this tool!
The text was updated successfully, but these errors were encountered: