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

61–70 of 78 posts

Re: Go-Safeweb

#61

Post by kele »

ongy wrote: post #17
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.

That was the intention of that paragraph.

Re: Go-Safeweb

#62

Post by cyberpunk »

sofixa wrote: post #58
cyberpunk wrote: post #46

Earlier quoted context omitted.

At least in our org security let us know when it's time to patch various components and it's typically just a devops chore to bump a helm chart version and merge.. I don't really understand your point; You're trying to say managing a single helm release for istio is more effort than (in my case, for example) manually managing around 40 TLS certificates (and yes, we have an in-house PKI with our own CA that issues via…

Istio is a notorious pain to maintain, because it has a bunch of dependencies around Kube clusters, so you can't just helm install istio every time there's a new release.

That’s not my experience at all and I’ve run hundreds of clusters across multiple cloud providers and on bare metal.

You absolutely can helm upgrade istio, why not?

Can you give any actual examples of this?

Re: Go-Safeweb

#63

Post by jerf »

HumanOstrich wrote: post #25
warkdarrior wrote: post #4

Earlier quoted context omitted.

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.

Until you have an equivalent team of volunteers ready to maintain the project, I think it does matter.

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.

Re: Go-Safeweb

#64

Post by kevinmgranger »

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…

The policy(?) change came ever since "SSL added and removed here ;-)", right?

That's when I remember seeing a broader shift towards app-terminated TLS.

Re: Go-Safeweb

#65

Post by liveoneggs »

ongy wrote: post #45
cyberpunk wrote: post #18

Earlier quoted context omitted.

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

This might be me being daft, but I never quite understood the appeal of doing this with istio. OR also partially just due to the timing of when I started to care about things in k8s world. (Rather recently) My understanding of that model is that the services themselves still just do unauthenticated HTTP, this gets picked up on the client side by a sidecar, packed into mTLS/HTTPS, authed+unpacked on the server sidecar…

in the modern world extra network hops, novel userland network stacks, and additional cycles of decrypted/re-encrypting traffic make your apps go faster, not slower.

Re: Go-Safeweb

#66

Post by EvanHahn »

ssahoo wrote: post #5

This is basically the helmet of go?

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.

Re: Go-Safeweb

#67

Post by HumanOstrich »

jerf wrote: post #63
HumanOstrich wrote: post #25

Earlier quoted context omitted.

Until you have an equivalent team of volunteers ready to maintain the project, I think it does matter.

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…

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.

Re: Go-Safeweb

#68

Post by 9dev »

kortilla wrote: post #11
NhanH wrote: post #10

Earlier quoted context omitted.

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.

Do that for a bunch of different applications and you hit interesting issues. For example the Java TLS stack, which doesn’t accept a PEM certificate on its own, but needs the full certificate chain. Kibana, however, requires the full certificate chain including the root certificate, which isn’t usually a part of the certificate itself, and Elasticsearch complains about an invalid certificate if you point it to the same one.

So even for two apps from the same vendor, which are commonly deployed together, you need bespoke TLS file variants. Scale that to more applications, and you’ll find out the hard way that you are vastly underestimating the complexity of operating a software ecosystem.

Re: Go-Safeweb

#70

Post by thayne »

bayindirh wrote: post #41
thayne wrote: post #27

Earlier quoted context omitted.

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.

I don't think so. We run a horde of machines, and run plethora of services, which are custom and/or has a very narrow install base due to the niche they serve. 99% of them use system-wide PKI store for CA and their certificates, which is under /etc. All of them have configuration options for these folders, and have short certificate lives because of the operational regulations we have in place. At worst case, we dist…

> 99% of them use system-wide PKI store for CA and their certificates, which is under /etc.

Consider yourself lucky then.

For self-hosted third party software, I've seen requirements to provide it in an environment variable, upload it to a web form over plain http on localhost, specify an AWS secret service secret that contains it, put it in a specific location that is bind mounted into a container, create a custom image (both VM and container), etc.

Post reply on HN