Live data from Hacker News

Go-Safeweb

github.com

51–60 of 78 posts

Re: Go-Safeweb

#51
post #48

Earlier quoted context omitted.

Honestly, doing things on bare server and interacting with OS is easier because it involves less moving parts and everything is in a more accessible state. Containers are not bad per se, but cutting corners just because "this will run in a container, so they can just add another HTTPS terminator" is just carelessness IMHO. Because not all of us have homelabs at home to install an onion of services to run a simple ser…

Are you mad because everybody is down voting your 42133422 post to shit, so you're down voting everyone who replied you? Don't do that, because it will only give you more down votes. > it involves less moving parts Every sane person who experienced a few server updates will not put out claim like that. One day you ran `apt upgrade -y`, minutes later 30% of your clients PHP website somehow went down? "less moving part…

> Are you mad

No!?

> everybody is down voting your 42133422 post to shit

They can, we don't have to agree on everything.

> so you're down voting everyone who replied you?

You can't downvote replies to your own comments, plus I don't downvote people because they have a different view than mine. Heck, I don't downvote as a principle. As long as the comment needs a flag, too.

> No one is trying to solve a problem by wrapping HTTPS terminator with "another HTTPS terminator"

Ow. I say "people don't add https functionality to their code, because they expect it to be done elsewhere, and that's bad practice". Do you read what I have written?

> Why stop there, if you start from user's keyboard as a layer...

Can you just calm down?

> And VPN? Oh boy you'll probably be surprised that Docker has cross-node communication built right in (https://docs.docker.com/engine/network/drivers/overlay/), so you don't even need VPN to connect to your database.

Who said I use a VPN to connect to my database? I have a closed/dark network of hosts on different locations sitting behind a NATs forming a personal network. This is what that VPN is about.

> Alright, alright, please, just admit that currently containerization is not a technology you can correctly take advantage of, and then you go ahead and learn more about it. It will be an useful tool for you, as it did for many, I'm sure.

Alright, alright, please just admit that you didn't understood a single bit of my posts, and can't paint a picture of what I'm talking about, and then you go ahead and read it all again. It will be a useful exercise for you, as it did for many, I'm sure.

Now I need to clean my keyboard of this coffee, and need to handle my OpenStack cluster. Oh, boy...

Thank you.

:)

Re: Go-Safeweb

#52
post #32

Earlier quoted context omitted.

> 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. I'm not sure I follow. Docmost runs in a container, on a port which is configurable. By default, as all containers, that port is local to the container. The container orchestrator (be it docker CLI, docker-compose, Swarm, Nomad, Kubernetes, Podman) is th…

Let me try to explain myself clearer. First, any enterprise/homelab installation with significant resources is outside of my scope. I don't care about them. When you don't pay for the infra/power cost, all bets are off. You can install quadruple redundant 300 node K8S cluster sitting on two different data centers in different cities connected to their own power generation equipment for a simple docmost instance. I'm…

> Traefik? Too big for the job. Apache, doable but needs half an hour from get go.

What do you think Traefik is if you think Apache is OK? It's similar in size and footprint, just modern (you can point it directly to Docker or any number of sources and it auto configures itself). I've ran Traefik with Docker containers behind it on Raspberry Pi 3s, this isn't supercomputer territory.

> As long as I run it, it binds to 0.0.0.0. So, if I want to install it locally to my desktop, I still need to add a firewall in front of it, because whole LAN can see it, and no, I don't trust any devices on my network (not people, but the apps

https://stackoverflow.com/questions/22100587/docker-expose-a...

Come on, this took literally a few seconds to Google.

> This is my problem. I want batteries included solutions, which can adapt to my circumstances.

Which is it, batteries included or flexible? It's hard to be both, and funny you complain about that, Traefik is a perfect example of a tool that does both well.

> The services I use must be able to adaptable to my environment. This is how bare-metal services, daemons in UNIX world work

Ah, so you don't need systemd/an init and service system? Or libc? Or iptables/firewall? You just plop an app and everything magically works how you want it to?

I think you have fundamental knowledge gaps, and instead of trying to address them, or think about why would a project prefer to not reinvent the wheel everyone already has anyway, you prefer to rant that it wasn't like this in the good old days. Good old days with cgi-bin and php-fpm that needed a reverse proxy in front anyways, so nothing has changed other than an abundance of documentation and examples and flexibility.

Re: Go-Safeweb

#53

Earlier quoted context omitted.

Let me try to explain myself clearer. First, any enterprise/homelab installation with significant resources is outside of my scope. I don't care about them. When you don't pay for the infra/power cost, all bets are off. You can install quadruple redundant 300 node K8S cluster sitting on two different data centers in different cities connected to their own power generation equipment for a simple docmost instance. I'm…

> Think Raspi5/N100 NUC boxes as the target hardware. I don't think those would be negatively impacted by running Docker or Caddy. Isn't the performance cost of containers minimal these days? I had similar thoughts in the past, but when I looked up performance comparisons between running something on docker vs without a container, the resulting performance was practically identical.

IO performance is the most severely impacted, but it's still fine for most uses.

Re: Go-Safeweb

#54

Earlier quoted context omitted.

Let me try to explain myself clearer. First, any enterprise/homelab installation with significant resources is outside of my scope. I don't care about them. When you don't pay for the infra/power cost, all bets are off. You can install quadruple redundant 300 node K8S cluster sitting on two different data centers in different cities connected to their own power generation equipment for a simple docmost instance. I'm…

> Think Raspi5/N100 NUC boxes as the target hardware. I don't think those would be negatively impacted by running Docker or Caddy. Isn't the performance cost of containers minimal these days? I had similar thoughts in the past, but when I looked up performance comparisons between running something on docker vs without a container, the resulting performance was practically identical.

The problem is not containerization per se, I run containers both in my personal systems and at work. If you extremely optimize for compilers, the performance difference can be trimmed down to 2%. I think for most of us, it's 5%-6% band, and it's OK for non-loaded servers.

My qualm is about trimming fairly standard features and offloading it to somewhere else.

A single HTTP service + traefik (or Apache/NGINX reverse proxy) is heavier than a single HTTPS service. Plus adds more moving parts for smaller installations. f I was running an API farm, I can add all kinds of bells and whistles, and it'll be lighter overall, but this is not a valid reason for stripping fairly simple features from applications which will be used by small teams on small hardware.

Plus, this additional layers can sometimes conflict (A requires B, C required D, where B & D are same thing but either one can't accommodate A & C at the same time), requiring a completely new system to run the service, which is wasteful, from my perspective.

Re: Go-Safeweb

#55

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.

A team of 1 volunteer would already be equivalent to the resources that Google puts into this particular project.

Re: Go-Safeweb

#56

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 have use cases for both approaches (letting a reverse proxy handle TLS, letting the application listen on an external socket and handling TLS in the application). I find is is easier to configure an application with a reverse proxy in front when different paths require e.g. different cache-control response headers. At the end of the day I do not want to replicate all the logic that nginx (and others) already provid…

And implement cert reloading if your application reaches any kind of respectable uptime.

Re: Go-Safeweb

#57
post #19

Earlier quoted context omitted.

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

To be clear I meant something like Caddy, or nginx not a solution like cloudflare or GCP doing my TLS

once you outgrow a single machine, unsecured network connections become an issue again

Re: Go-Safeweb

#58
post #42

Earlier quoted context omitted.

> one time installing istio And never update it afterwards? > UDP I don’t really see how is relevant to a conversation on tls You might have UDP services alongside your TCP/HTTP behind TLS.

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.

Re: Go-Safeweb

#59

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.

What HTTPS/TLS related bits are you talking about? The code looks like it supports your use case. It has a "BehindProxy" setting:

https://github.com/google/go-safeweb/blob/c2d1215a6a2445915c...

Re: Go-Safeweb

#60
post #12

Earlier quoted context omitted.

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.

> as there's no guarantee it will be maintained As opposed to official projects like Allo, Wave, Reader, etc. that will?

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.

Post reply on HN