7 ms·

Go-Safeweb

188 points by jcbhmr 2y ago

caust1c 2y ago
[flagged]
- jonathanoliver 2y ago
  They should put it on all of their officially supported ones too! https://killedbygoogle.com/ https://killedbygoogle.com/
- warkdarrior 2y ago
  It's an open-source library (or collection of libraries) for Go HTTP servers. Apache license, so it does not matter if Google supports it or not.
  - HumanOstrich 2y ago
    Until you have an equivalent team of volunteers ready to maintain the project, I think it does matter.
    - azornathogron 2y ago
      A team of 1 volunteer would already be equivalent to the resources that Google puts into this particular project.
    - jerf 2y ago
      It's not really that sort of project. In principle, this is all stuff you should already be doing. But, statistically speaking, $YOU aren't. Even if they disappear today, you're probably still better off picking this up and starting with it as-is than you are with your current server. While I'm sure this is the sort of project that could benefit from ongoing improvements, it is also not going to decay away into utter uselessness if nobody commits to it in a week or two. I understand the need for projects to be maintained, but I think some people have been badly burned by the Javascript world, or possibly some other language environments, and don't realize that those environments aren't the norm, but one of the extrema. Go is quite possibly on the other extrema. It does not generally decay. Again, I'm not saying that means it's totes cool to pick up a security-based project with a last commit from seven years ago and just assume it's still cutting edge, but this sort of Go code doesn't require a dozen commits a month just to tread water.
      - HumanOstrich 2y ago
        As someone stuck in JavaScript hell, I think you have a great point. How nice it would be to not touch a project for a year, come back, and not have to rewrite it just to upgrade dependencies.
- kyrra 2y ago
  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.
  - L3viathan 2y ago
    > as there's no guarantee it will be maintained As opposed to official projects like Allo, Wave, Reader, etc. that will?
    - kyrra 2y ago
      I'm talking open source here. When it's funded, there will be people to help fix issues and put out new releases. This includes things like Go, Flutter/dart, k8s, and others. Yes, any of those could be defunded at any moment if it was no longer advantageous for Google to support it, but for now, they are getting support and new releases.
- sofixa 2y ago
  > Should google put this on all their products They have a few products you pay for and are thus supported (for consumers YouTube Premium, Google One which is Drive storage+support, for organisations Google Cloud, Google Workspace), but for everything else, yeah. Unless you pay for One, you get no support from them on the random free stuff like Keep or Maps - you get what you pay for (in reality much more than that, something like Maps is a massive effort everyone can use for free).
  - denysvitali 2y ago
    As a Google One customer, I can guarantee that you get no support from them either. The real support comes from talking with someone who works at Google and can direct you to the right team...
ssahoo 2y ago
This is basically the helmet of go?
- zeroq 2y ago
  I always thought that the "rubber" was a missed opportunity.
- EvanHahn 2y ago
  Helmet author here. This is a similar project, but not the same. Helmet covers HTTP response headers, and that's it. This project seems to have a wider scope, covering things like auth and error handling.
  - efilife 2y ago
    Your last comments were 10 months ago and 10 years ago. A rare occurence. HN at its finest
pushupentry1219 2y ago
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.
- bayindirh 2y ago
  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 infrastructure to run that small thing.
  - NhanH 2y ago
    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
    - kortilla 2y ago
      I think you’re vastly overestimating the complexity of pointing a TLS library to a CA.
      - thayne 2y ago
        For a single application, it's not too bad. When you have dozens of applications that all have different mechanisms to install a CA, rotate certs, etc. And some of those don't have a good way to automate rotating the certs, then it becomes a pain.
nox101 2y ago
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 appears (2) you get pwnd by an exploit because you used it wrong.
- ongy 2y ago
  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.
  - kele 2y ago
    That was the intention of that paragraph.
webprofusion 2y ago
Just use Caddy https://caddyserver.com/ https://caddyserver.com/
- jakereps 2y ago
  Isn’t that equivalent to saying “just use NGINX”? Caddy isn’t a library you use in your Go server code, it’s a separate reverse proxy, isn’t it? They solve separate things.
  - hu3 2y ago
    One could: import "github.com/mholt/caddy" https://medium.com/backendarmy/embedding-a-web-server-in-go-e116cbbdc936 https://medium.com/backendarmy/embedding-a-web-server-in-go-... Not sure if it's still the case.
asgr 2y ago
[flagged]
kittikitti 2y ago
The only reason this is noteworthy is that a bunch of big tech employees worked on it.

Go-Safeweb

188 points by jcbhmr 2y ago

caust1c 2y ago

[flagged]

jonathanoliver 2y ago
They should put it on all of their officially supported ones too! https://killedbygoogle.com/ https://killedbygoogle.com/
warkdarrior 2y ago
It's an open-source library (or collection of libraries) for Go HTTP servers. Apache license, so it does not matter if Google supports it or not.
- HumanOstrich 2y ago
  Until you have an equivalent team of volunteers ready to maintain the project, I think it does matter.
  - azornathogron 2y ago
    A team of 1 volunteer would already be equivalent to the resources that Google puts into this particular project.
  - jerf 2y ago
    It's not really that sort of project. In principle, this is all stuff you should already be doing. But, statistically speaking, $YOU aren't. Even if they disappear today, you're probably still better off picking this up and starting with it as-is than you are with your current server. While I'm sure this is the sort of project that could benefit from ongoing improvements, it is also not going to decay away into utter uselessness if nobody commits to it in a week or two. I understand the need for projects to be maintained, but I think some people have been badly burned by the Javascript world, or possibly some other language environments, and don't realize that those environments aren't the norm, but one of the extrema. Go is quite possibly on the other extrema. It does not generally decay. Again, I'm not saying that means it's totes cool to pick up a security-based project with a last commit from seven years ago and just assume it's still cutting edge, but this sort of Go code doesn't require a dozen commits a month just to tread water.
    - HumanOstrich 2y ago
      As someone stuck in JavaScript hell, I think you have a great point. How nice it would be to not touch a project for a year, come back, and not have to rewrite it just to upgrade dependencies.
kyrra 2y ago
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.
- L3viathan 2y ago
  > as there's no guarantee it will be maintained As opposed to official projects like Allo, Wave, Reader, etc. that will?
  - kyrra 2y ago
    I'm talking open source here. When it's funded, there will be people to help fix issues and put out new releases. This includes things like Go, Flutter/dart, k8s, and others. Yes, any of those could be defunded at any moment if it was no longer advantageous for Google to support it, but for now, they are getting support and new releases.
sofixa 2y ago
> Should google put this on all their products They have a few products you pay for and are thus supported (for consumers YouTube Premium, Google One which is Drive storage+support, for organisations Google Cloud, Google Workspace), but for everything else, yeah. Unless you pay for One, you get no support from them on the random free stuff like Keep or Maps - you get what you pay for (in reality much more than that, something like Maps is a massive effort everyone can use for free).
- denysvitali 2y ago
  As a Google One customer, I can guarantee that you get no support from them either. The real support comes from talking with someone who works at Google and can direct you to the right team...

ssahoo 2y ago

This is basically the helmet of go?

zeroq 2y ago
I always thought that the "rubber" was a missed opportunity.
EvanHahn 2y ago
Helmet author here. This is a similar project, but not the same. Helmet covers HTTP response headers, and that's it. This project seems to have a wider scope, covering things like auth and error handling.
- efilife 2y ago
  Your last comments were 10 months ago and 10 years ago. A rare occurence. HN at its finest

pushupentry1219 2y ago

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.

bayindirh 2y ago
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 infrastructure to run that small thing.
- NhanH 2y ago
  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
  - kortilla 2y ago
    I think you’re vastly overestimating the complexity of pointing a TLS library to a CA.
    - thayne 2y ago
      For a single application, it's not too bad. When you have dozens of applications that all have different mechanisms to install a CA, rotate certs, etc. And some of those don't have a good way to automate rotating the certs, then it becomes a pain.

nox101 2y ago

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 appears (2) you get pwnd by an exploit because you used it wrong.

ongy 2y ago
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.
- kele 2y ago
  That was the intention of that paragraph.

webprofusion 2y ago

Just use Caddy https://caddyserver.com/ https://caddyserver.com/

jakereps 2y ago
Isn’t that equivalent to saying “just use NGINX”? Caddy isn’t a library you use in your Go server code, it’s a separate reverse proxy, isn’t it? They solve separate things.
- hu3 2y ago
  One could: import "github.com/mholt/caddy" https://medium.com/backendarmy/embedding-a-web-server-in-go-e116cbbdc936 https://medium.com/backendarmy/embedding-a-web-server-in-go-... Not sure if it's still the case.

asgr 2y ago

[flagged]

kittikitti 2y ago

The only reason this is noteworthy is that a bunch of big tech employees worked on it.