• 0 Posts
  • 47 Comments
Joined 1 year ago
cake
Cake day: June 19th, 2023

help-circle
  • Docker Swarm encryption doesn’t work for your use case. The documentation says that the secret is stored encrypted but can be decrypted by the swarm manager nodes and nodes running services that use the service, which both apply to your single node. If you’re not having to unlock Docker Compose on startup, that means that the encrypted value and the decryption key live next to each other on the same computer and anyone who has access to the encrypted secrets can also decrypt them.





  • Be careful with doing this. X-Real-IP and X-Forwarded-For are good for when the client is a trusted proxy, but can be easily faked if you don’t whitelist who’s allowed to use those headers. Somebody with IPv6 access could send “X-Real-IP: 127.0.0.1” or something and if the server believes it then you’ll see 127.0.0.1 in logs and depending on what you’re running the user may gain special permissions.

    Also be careful with the opposite problem. If your server doesn’t trust the proxy, it will show the VPS IP in logs, and if you’re running something like fail2ban you’ll end up blocking your VPS and then nobody will be able to connect over IPv4.



  • There’s a lot of wrong advice about this subject on this post. Forgejo, and any other Git forge server, have a completely different security model than regular SSH. All authenticated users run with the same PID and are restricted to accessing Git commands. It uses the secure shell protocol but it is not a shell. The threat model is different. Anybody can sign up for a GitHub or Codeberg account and they will be granted SSH access, but that access only allows them to push and pull Git data according to their account permissions.



  • Would it though? It’s just vans on tracks instead of roads.

    It’s not going to be more energy efficient with individually powered cabs. It’s not going to be more convenient unless your origin and destination are near a station. It’s not going to be more time efficient because of the extra distance getting to and from tracks and because you aren’t going to drive highway speeds in tiny self-balancing cars on old rails, especially when passing cars going the opposite direction. It’s not going to be more cost efficient because it’s more total moving parts requiring maintenance per person per trip.

    It sounds like they are solving the problem of turning around only for terminal stations. This might make sense for trains that carry many people, but if you’re making cars on tracks there is no good solution. If you need to spend money on a system that turns the cabs around, then you either spend more money installing those systems at most stations or you spend money maintaining cabs that are driving around empty. Either way, cars on roads are cheaper.

    They say it’s good for people who don’t want to wait for public transit, but they don’t say how this solves that problem. With public transit, you know when the train will be there. With this, unless they have a way for the cabs to wait at the station without blocking other cabs going the same direction, you have to wait for a cab to come and you can’t time your trip to the station around when the cab will be there. Maybe they have one? It would be a disaster if you wanted to get on from near the middle and needed to wait for either a cab that has already been vacated to come or for a cab to come all the way from the start of the track.