I’m skimming the docs looking for how “in containers” is handled and so far I can only see a one liner in the release notes. One problem in local environments I keep having and building tricks for is for services inside containers getting certs for other containers. From within the container, resolving to 127.0.0.1 isn’t helpful as that’s the internal loopback not the host.
we're going to say more about how lcl.host works between containers in the future since it ends up pulling in Anchor's package features, but I can give a quick rundown of what we've done in the past with docker-compose: start a service in container A and expose port 44300, and configure the service with an ACME client to provision a `service-a.lcl.host` certificate. The clients in that container won't trust the cert, but that no problem, since your system/browser will trust the cert if you've run `anchor lcl`. In container B, install an anchor built package for the language of the server, and setup the HTTPS/TLS client to use the set of CAs in that package. Now app B can connect to `service-a.lcl.host:443300` over HTTPS/TLS.
“Clients in that container won’t trust the cert”. Yeah, there’s the trick.
“service-a.lcl.host:443300“ so when inside the container, won’t that resolve to 127.0.0.1 which is the container internal loopback interface not the docker host’s interface? Hence trying to connect to itself not its sibling.
right it's the loopback, but I believe docker-compose can forward loopback ports to the host (and then back into the other container) using links, but i'm fuzzy on the details and may be misremembering.
It's a standard clause for most apps. If a breach of the terms of conditions (such as using it for commercial purposes, like selling the software), they are allowed to launch an investigation. No where does this mention "spying" on modifying the app for such use.
My experience with visual scripting or coding is that it’s hard for more than one person to work on for anything other than a single screen of complexity. No git merge, so serial development. Hard to understand and tweak for anyone except the creator.
The difference I think is that the lock on your front door is on your front door. Whereas I think even if there's no other copyright violation, it's still illegal to break DRM.
Picking the lock involves trespassing your property. Breaking the DRM is illegal regardless of if it's trespassing on anyone's property.
Looks helpful - have you chosen a license to release your parts under? So far it seems to build on BSD (GO) and some completely copyrighted extensions from (github.com/miekg/dns).
I have a work project this would help with, but at this point using it commercially feels a little shaky.
Burying the lede...
Unfortunately, at the time of this whitepaper being published - 86 days after Apache was notified of the vulnerability - 2.4.49 not yet come out, so although there's a patch on master, this is effectively a zero-day.
I also have to respect your chaotic neutral tactics by posting their trademark wording in its entirety, hence guaranteeing they're the first search hit for that phrase.
