Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go-Safeweb

github.com

Post reply on HN
Print view View original

11–20 of 78 posts

Re: Go-Safeweb

#11

Post by kortilla »

NhanH wrote: post #10
bayindirh wrote: post #9

Earlier quoted context omitted.

While I understand the sentiment, this makes bare installations too hard. A big project not handling HTTPS themselves (like docmost), adds tons of complexity on the server side. Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc. That leads to resource inflation when I just want to use a small VM for that single task. Now, instead I deploy a whole infrastr…

Handling https in the project also adds tons of complexity in the long run though: tls/ssl library versions, cert handling. Instead of having one way to deal with all of them (at the proxy layer, or sometimes at network layer), I have to deal with individual software way of managing those

I think you’re vastly overestimating the complexity of pointing a TLS library to a CA.

Re: Go-Safeweb

#12

Post by kyrra »

caust1c wrote: post #2

[flagged]

Any projects that does not have official headcount gets that tag line. Even some projects that are funded internally, may get that moniker externally as there's no guarantee it will be maintained.

Most of the time these are projects that individual engineers go through the pain of open sourcing.

Re: Go-Safeweb

#13

Post by yjftsjthsd-h »

bayindirh wrote: post #9
pushupentry1219 wrote: post #6

Not sure how I feel about the HTTPS/TLS related bits. These days anything I write in Go uses plain HTTP, and the TLS is done by a reverse proxy of some variety that does some other stuff with the traffic too including security headers, routing for different paths to different services, etc. I never run a go web application "bare", public facing, and manually supplying cert files.

While I understand the sentiment, this makes bare installations too hard. A big project not handling HTTPS themselves (like docmost), adds tons of complexity on the server side. Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc. That leads to resource inflation when I just want to use a small VM for that single task. Now, instead I deploy a whole infrastr…

> Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc.

Why? I've run plenty of normal non-containerized apps that bind localhost:1234 and then are reverse proxied by nginx or caddy or whatever.

(I agree that you would need a reverse proxy, I think that's kinda the point, it's the container thing I don't get)

Re: Go-Safeweb

#14

Post by rjh29 »

yjftsjthsd-h wrote: post #13
bayindirh wrote: post #9

Earlier quoted context omitted.

While I understand the sentiment, this makes bare installations too hard. A big project not handling HTTPS themselves (like docmost), adds tons of complexity on the server side. Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc. That leads to resource inflation when I just want to use a small VM for that single task. Now, instead I deploy a whole infrastr…

> Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc. Why? I've run plenty of normal non-containerized apps that bind localhost:1234 and then are reverse proxied by nginx or caddy or whatever. (I agree that you would need a reverse proxy, I think that's kinda the point, it's the container thing I don't get)

Global vs local variables.

Re: Go-Safeweb

#15

Post by ongy »

pushupentry1219 wrote: post #6

Not sure how I feel about the HTTPS/TLS related bits. These days anything I write in Go uses plain HTTP, and the TLS is done by a reverse proxy of some variety that does some other stuff with the traffic too including security headers, routing for different paths to different services, etc. I never run a go web application "bare", public facing, and manually supplying cert files.

I suspect this is partially from google's internal 0 trust cluster networking.

I.e. even if the communication is entirely between components inside a k8s (or borg) cluster, it should be authenticated and encrypted.

In this model, there may be a reverse proxy at the edge of the cluster, but the communication between this service and the internal services wouls still be https. With systems like cert-manager it's also incredibly easy to supply every in-cluster process with a certificate form the cluster-internal CA.

-- Googler, not related to this project

Re: Go-Safeweb

#16

Post by [deleted] »

bayindirh wrote: post #9
pushupentry1219 wrote: post #6

Not sure how I feel about the HTTPS/TLS related bits. These days anything I write in Go uses plain HTTP, and the TLS is done by a reverse proxy of some variety that does some other stuff with the traffic too including security headers, routing for different paths to different services, etc. I never run a go web application "bare", public facing, and manually supplying cert files.

While I understand the sentiment, this makes bare installations too hard. A big project not handling HTTPS themselves (like docmost), adds tons of complexity on the server side. Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc. That leads to resource inflation when I just want to use a small VM for that single task. Now, instead I deploy a whole infrastr…

[deleted]

Re: Go-Safeweb

#17

Post by ongy »

nox101 wrote: post #7

What does this mean? > NG1: Safe API Completeness > Creating safe APIs for all the corner cases might result in a bloated codebased. Our experience shows that this isn’t necessary. To me "Safe API" means it's hard to use the API incorrectly. I see lots of poorly designed APIs where it's easy to use the API incorrectly and then you don't know you've used it incorrectly until (1) the edge case you weren't aware of appe…

My reading is that it's supposed to provide an API that's safe to use, but might not allow to do everything technically possible within the HTTP spec.

Re: Go-Safeweb

#18

Post by cyberpunk »

ongy wrote: post #15
pushupentry1219 wrote: post #6

Not sure how I feel about the HTTPS/TLS related bits. These days anything I write in Go uses plain HTTP, and the TLS is done by a reverse proxy of some variety that does some other stuff with the traffic too including security headers, routing for different paths to different services, etc. I never run a go web application "bare", public facing, and manually supplying cert files.

I suspect this is partially from google's internal 0 trust cluster networking. I.e. even if the communication is entirely between components inside a k8s (or borg) cluster, it should be authenticated and encrypted. In this model, there may be a reverse proxy at the edge of the cluster, but the communication between this service and the internal services wouls still be https. With systems like cert-manager it's also i…

Why wouldn’t you use istio or cilium for this?

Re: Go-Safeweb

#19

Post by effdee »

pushupentry1219 wrote: post #6

Not sure how I feel about the HTTPS/TLS related bits. These days anything I write in Go uses plain HTTP, and the TLS is done by a reverse proxy of some variety that does some other stuff with the traffic too including security headers, routing for different paths to different services, etc. I never run a go web application "bare", public facing, and manually supplying cert files.

The phrase "SSL added and removed here" from an NSA slide comes to mind.

Re: Go-Safeweb

#20

Post by bayindirh »

yjftsjthsd-h wrote: post #13
bayindirh wrote: post #9

Earlier quoted context omitted.

While I understand the sentiment, this makes bare installations too hard. A big project not handling HTTPS themselves (like docmost), adds tons of complexity on the server side. Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc. That leads to resource inflation when I just want to use a small VM for that single task. Now, instead I deploy a whole infrastr…

> Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc. Why? I've run plenty of normal non-containerized apps that bind localhost:1234 and then are reverse proxied by nginx or caddy or whatever. (I agree that you would need a reverse proxy, I think that's kinda the point, it's the container thing I don't get)

Because some of the applications are "container native" and do not support configuration of IP/Port binding. Why? UNIX philosophy and working traditions be damned.

Exhibit A: Docmost: https://docmost.com/docs/self-hosting/environment-variables

I can understand the reverse proxy, but I want to run thing on a small VPS or a Raspberry Pi, etc. I want to use minimum resources so I can run more things per server.

If this thing was being installed at work, I can build a great wall in front of it, but for personal things, I rather have less moving parts, and just deploy and forget the thing.

Post reply on HN