4 ms·

So: developer attempts to integrate into a global distributed system without a connection to the Internet and complains he can't get it working without extra st

So: developer attempts to integrate into a global distributed system without a connection to the Internet and complains he can't get it working without extra steps? Obviously there's two ways of doing this: you put everything online and then there's no extra steps, which the author doesn't want to do, or, if you want to do this offline, then extra steps are needed. Back in the day we used "dev environments" with tightly guarded ACLs. These days you can have things like Docker Compose locally or K8S clusters. It feels like the author has their own preconceived notions about how systems ought to be "isolated"[1], regardless of the use case, keeps fighting with their half-baked networking implementation and then denounces everything, ranging from HTTPS[2] to now ActivityPub as "broken". [1] - https://so.nwalsh.com/2024/01/06-isolation https://so.nwalsh.com/2024/01/06-isolation [2] - https://so.nwalsh.com/2023/12/31-https https://so.nwalsh.com/2023/12/31-https

umactually1 3y ago
Agree. It triggers me a little when folks complain about HTTPS. Nowadays you have a wealth of tools to trivialize TLS certificate tasks. Public TLS cert? LetsEncrypt + certbot (or any of the other zillion great ACME clients/libraries out there). Self-hosted PKI for private/test use? Smallstep CLI (https://smallstep.com/docs/step-cli/ https://smallstep.com/docs/step-cli/) is good. And honestly, the raw `openssl` commands to barf out a root selfsigned cert aren't that difficult and number as less than 5 shell invocations that you could have in your history or a bash function or something. Self-hosted PKI with extra steps that you already did because you have a Kubernetes cluster for some other reason? cert-manager will take care of pretty much everything. These days the "hardest" part is sneaking your CA chain into the appropriate browsers / services you're using/testing, but even that is a few moments of inconvenience at best.
- jeroenhd 3y ago
  Getting a CA into a Mastodon server is an adventure of its own. Setting up the CA isn't that hard even without smallstep (copy/paste three or four commands and you're good to start testing) but getting the CA working where it needs to work is a massive pain. Everything has a different certificate store, sometimes compiled into the binaries, and getting stuff talking to each other is a massive pain. For browsers, importing certificates comes down to just searching "certificate" in the settings. It's everything else that's broken, in my experience.
  - fuomag9 3y ago
    I agree. For example home assistant OS has a custom cert store that is reset on boot and there’s no way to make persistent modifications without recurring to hacks such as this one https://github.com/Athozs/hass-additional-ca https://github.com/Athozs/hass-additional-ca
    - plagiarist 3y ago
      Enraging on a tool that offers user login from a webpage. You should be able to add DNS records to your gateway and not have to deal with public CAs to access it by name with TLS.
  - shadowgovt 3y ago
    Yep. As a datapoint: I set up my own Mastodon server behind a Cloudflare tunnel and completed every step except the cert, eventually opting to just tell Cloudflare to ignore the cert config. The default solution doesn't work on a shared host where you don't have control over running your own services and opening your own ports, only serving static pages instead using a shared web server.
- nottorp 3y ago
  > Nowadays you have a wealth of tools to trivialize TLS certificate tasks. Trivialize what? You have to learn the tools. When you're paid for it or actually believe that signing everything is useful, you're willing to spend the time. In the original article it looks like the poster already went over their time budget by a lot without even getting to researching if these tools exist.
- layer8 3y ago
  The lack of a standard way to specify your trusted CAs on a system or network is one of the biggest hassles in that area. It’s typically all bespoke configuration, and often not well documented.
cobertos 3y ago
The principle the author is getting at is valid though. It should not be that hard to run tests. There should be easy escape hatches in systems to stand them up and tear down quickly so you can check your code against a reasonable "dummy" without having to reimplement the other side in your tests, as much ad possible. As you say, Docker would be great for that, as they say they use in your linked [1]. Did you read it? I wouldn't read too much into these posts. These are days apart and read more like inner-monologue from setting up systems. My process for implementing someone would probably fare the same. You wade through the cruft, complain about some things, but it gets done in the end and it's always nice to solve the pain points later.
- disruptiveink 3y ago
  Fair enough – there's nothing wrong with expecting systems to be able to be ran in dev mode suitable for running locally or within test containers, and that would be my expectation as well. As you say, the inner monologue writing style of "I have this server and this thing and tried this and also I don't like this" may have led me astray as it didn't feel particularly focused, so it wasn't super clear what the complaint actually was.
  - cobertos 3y ago
    Yeahh, understandable, I had to read the linked articles twice to form coherency. More time than I would have invested normally, I only did so after reading your comment xD Makes me wonder if inner-monologue type stuff is even useful to post to the internet (something ive wanted to post more off because it sucks less energy from writing motivation). Takes more effort to parse as a reader though...
- jddj 3y ago
  > implementing someone It does feel like this sometimes.
- shadowgovt 3y ago
  It's tricky. In practice, easy escape hatches tend to become ways people deploy to production with the safeties off. In the past, we would then throw up our hands and say "Well boo on them for making their system hackable; sounds like their problem." But when you factor in the damage that can be done on the internet with things like botnets, it becomes everyone's problem. So sometimes people refrain from adding the escape hatches because they intend to work in an ecosystem of "You must be at least this technically savvy to play."
stavros 3y ago
> developer attempts to integrate into a global distributed system without a connection to the Internet and complains he can't get it working without extra steps? No, he's not trying to integrate into a global distributed system without a connection to the internet. He's trying to test locally an app that will eventually integrate into a global distributed system. It's a valid complaint. If I have a local Mastodon server, and a local static website, why can't I just make the two talk without going through the public internet, or adding a self-signed CA to a bunch of trust stores? It seems to me like it wouldn't be hard to add a --dev flag to Mastodon that allowed you to forgo the TLS certs, and it would make testing much easier. He's not trying to
- knallfrosch 3y ago
  Mastodon is free and open-source. Go ahead and add the flag: https://github.com/mastodon/mastodon/blob/main/CONTRIBUTING.md https://github.com/mastodon/mastodon/blob/main/CONTRIBUTING....
  - stavros 3y ago
    I only care enough about this issue to post the above comment, thanks though.
  - fasterik 3y ago
    This seems to be a common response to people criticizing open source projects. Basically, any criticism can be dismissed by suggesting that the critic should just fix the problem instead of complaining about it. I don't see why someone shouldn't be able to point out technical flaws without spending the time and resources to fix it themselves.
- viraptor 3y ago
  > why can't I just make the two talk without going through the public internet, or adding a self-signed CA to a bunch of trust stores? Sure you can. Getting a valid, trusted certificate from a public entity doesn't mean that your service has to be public. Just get one and assign private IPs to the domain. I get the idea of not doing that if you want to be a purist about the isolated approach. But then you should be ready to implement something that others don't care about as much as you do.
paulgb 3y ago
> you put everything online and then there's no extra steps “put everything online” here is hand-waving the hard part. Most people are used to working in development environments that are not set up to serve inbound traffic from the public internet. There are security implications. In most of my past jobs, it wouldn’t have even been an option without violating IT policies.
layer8 3y ago
> you put everything online and then there's no extra steps It almost feels as if “online” is a centralized system.

umactually1 3y ago

Agree. It triggers me a little when folks complain about HTTPS. Nowadays you have a wealth of tools to trivialize TLS certificate tasks. Public TLS cert? LetsEncrypt + certbot (or any of the other zillion great ACME clients/libraries out there). Self-hosted PKI for private/test use? Smallstep CLI (https://smallstep.com/docs/step-cli/ https://smallstep.com/docs/step-cli/) is good. And honestly, the raw `openssl` commands to barf out a root selfsigned cert aren't that difficult and number as less than 5 shell invocations that you could have in your history or a bash function or something. Self-hosted PKI with extra steps that you already did because you have a Kubernetes cluster for some other reason? cert-manager will take care of pretty much everything. These days the "hardest" part is sneaking your CA chain into the appropriate browsers / services you're using/testing, but even that is a few moments of inconvenience at best.

jeroenhd 3y ago
Getting a CA into a Mastodon server is an adventure of its own. Setting up the CA isn't that hard even without smallstep (copy/paste three or four commands and you're good to start testing) but getting the CA working where it needs to work is a massive pain. Everything has a different certificate store, sometimes compiled into the binaries, and getting stuff talking to each other is a massive pain. For browsers, importing certificates comes down to just searching "certificate" in the settings. It's everything else that's broken, in my experience.
- fuomag9 3y ago
  I agree. For example home assistant OS has a custom cert store that is reset on boot and there’s no way to make persistent modifications without recurring to hacks such as this one https://github.com/Athozs/hass-additional-ca https://github.com/Athozs/hass-additional-ca
  - plagiarist 3y ago
    Enraging on a tool that offers user login from a webpage. You should be able to add DNS records to your gateway and not have to deal with public CAs to access it by name with TLS.
- shadowgovt 3y ago
  Yep. As a datapoint: I set up my own Mastodon server behind a Cloudflare tunnel and completed every step except the cert, eventually opting to just tell Cloudflare to ignore the cert config. The default solution doesn't work on a shared host where you don't have control over running your own services and opening your own ports, only serving static pages instead using a shared web server.
nottorp 3y ago
> Nowadays you have a wealth of tools to trivialize TLS certificate tasks. Trivialize what? You have to learn the tools. When you're paid for it or actually believe that signing everything is useful, you're willing to spend the time. In the original article it looks like the poster already went over their time budget by a lot without even getting to researching if these tools exist.
layer8 3y ago
The lack of a standard way to specify your trusted CAs on a system or network is one of the biggest hassles in that area. It’s typically all bespoke configuration, and often not well documented.

cobertos 3y ago

The principle the author is getting at is valid though. It should not be that hard to run tests. There should be easy escape hatches in systems to stand them up and tear down quickly so you can check your code against a reasonable "dummy" without having to reimplement the other side in your tests, as much ad possible. As you say, Docker would be great for that, as they say they use in your linked [1]. Did you read it? I wouldn't read too much into these posts. These are days apart and read more like inner-monologue from setting up systems. My process for implementing someone would probably fare the same. You wade through the cruft, complain about some things, but it gets done in the end and it's always nice to solve the pain points later.

disruptiveink 3y ago
Fair enough – there's nothing wrong with expecting systems to be able to be ran in dev mode suitable for running locally or within test containers, and that would be my expectation as well. As you say, the inner monologue writing style of "I have this server and this thing and tried this and also I don't like this" may have led me astray as it didn't feel particularly focused, so it wasn't super clear what the complaint actually was.
- cobertos 3y ago
  Yeahh, understandable, I had to read the linked articles twice to form coherency. More time than I would have invested normally, I only did so after reading your comment xD Makes me wonder if inner-monologue type stuff is even useful to post to the internet (something ive wanted to post more off because it sucks less energy from writing motivation). Takes more effort to parse as a reader though...
jddj 3y ago
> implementing someone It does feel like this sometimes.
shadowgovt 3y ago
It's tricky. In practice, easy escape hatches tend to become ways people deploy to production with the safeties off. In the past, we would then throw up our hands and say "Well boo on them for making their system hackable; sounds like their problem." But when you factor in the damage that can be done on the internet with things like botnets, it becomes everyone's problem. So sometimes people refrain from adding the escape hatches because they intend to work in an ecosystem of "You must be at least this technically savvy to play."

stavros 3y ago

> developer attempts to integrate into a global distributed system without a connection to the Internet and complains he can't get it working without extra steps? No, he's not trying to integrate into a global distributed system without a connection to the internet. He's trying to test locally an app that will eventually integrate into a global distributed system. It's a valid complaint. If I have a local Mastodon server, and a local static website, why can't I just make the two talk without going through the public internet, or adding a self-signed CA to a bunch of trust stores? It seems to me like it wouldn't be hard to add a --dev flag to Mastodon that allowed you to forgo the TLS certs, and it would make testing much easier. He's not trying to

knallfrosch 3y ago
Mastodon is free and open-source. Go ahead and add the flag: https://github.com/mastodon/mastodon/blob/main/CONTRIBUTING.md https://github.com/mastodon/mastodon/blob/main/CONTRIBUTING....
- stavros 3y ago
  I only care enough about this issue to post the above comment, thanks though.
- fasterik 3y ago
  This seems to be a common response to people criticizing open source projects. Basically, any criticism can be dismissed by suggesting that the critic should just fix the problem instead of complaining about it. I don't see why someone shouldn't be able to point out technical flaws without spending the time and resources to fix it themselves.
viraptor 3y ago
> why can't I just make the two talk without going through the public internet, or adding a self-signed CA to a bunch of trust stores? Sure you can. Getting a valid, trusted certificate from a public entity doesn't mean that your service has to be public. Just get one and assign private IPs to the domain. I get the idea of not doing that if you want to be a purist about the isolated approach. But then you should be ready to implement something that others don't care about as much as you do.

paulgb 3y ago

> you put everything online and then there's no extra steps “put everything online” here is hand-waving the hard part. Most people are used to working in development environments that are not set up to serve inbound traffic from the public internet. There are security implications. In most of my past jobs, it wouldn’t have even been an option without violating IT policies.

layer8 3y ago

> you put everything online and then there's no extra steps It almost feels as if “online” is a centralized system.