Perhyte

No idea about the Lemmy hosting bit, but I highly doubt that .com you got will renew at $1 going forward. Judging by this list it’ll most likely be $9+ after the first year.

At $1/year, the registrar you used is taking a loss because they pay more than that to the registry for it. They might be fine with that for the first year to get you in the door, but they’d presumably prefer to be profitable in the long term.

C and C++?

If you don’t mind using a gibberish .xyz domain, why not an 1.111B class? ([6-9 digits].xyz for $0.99/year)

Any chance you’ve defined the new networks as “internal”? (using docker network create --internal on the CLI or internal: true in your docker-compose.yaml).

Because the symptoms you’re describing (no connectivity to stuff outside the new network, including the wider Internet) sound exactly like you did, but didn’t realize what that option does…

It also means that ALL traffic incoming on a specific port of that VPS can only go to exactly ONE private wireguard peer. You could avoid both of these issues by having the reverse proxy on the VPS (which is why cloudflare works the way it does), but I prefer my https endpoint to be on my own trusted hardware.

For TLS-based protocols like HTTPS you can run a reverse proxy on the VPS that only looks at the SNI (server name indication) which does not require the private key to be present on the VPS. That way you can run all your HTTPS endpoints on the same port without issue even if the backend server depends on the host name.

This StackOverflow thread shows how to set that up for a few different reverse proxies.

They’ve checked in my code in their own repository, using an automated tool that keeps track of its origin so they can still check for updates. (The build tool knows to check this directory before trying to pull in dependencies from elsewhere)

One benefit to them is that their build won’t break if I decide to delete that specific repository (see also: the left-pad incident) or do silly things with version tags (deleting versions, or re-tagging a different commit with the same version number, that sort of thing).

But more relevantly for this thread, it also means that if I release a new version and they upgrade to it, the PR on their repository won’t just be incrementing a version number in go.mod and adding an unreadable hash to go.sum: the diff will show all the changes I’ve made since the version they previously used.

I may have slightly misremembered the license text (subsection 4c):

You must cause any modified files to carry prominent notices stating that You changed the files;

So I guess technically you only need to indicate that you have changed the files, not what you’ve changed in them. I suppose that’s less burdensome because it only needs to be done once per file at most.

I don’t think so, no.

Leaving aside the fact that I don’t want to do that:

They’ve quite sensibly vendored my library, so I’d have to hope they pull in updates without checking the code changes: since it’s such a tiny library (excluding tests but including fairly extensive comments, it’s less than 100 lines of quite readable code) I don’t think it’d be easy to get it past their code review system if I tried to sneak in enough code to take down entire companies.

Also, my GitHub account is tied to my real-world identity, so I’d probably be in a lot of trouble if I somehow succeeded.

For MIT, why do you care? That’s perfectly fine and explicitly allowed by the license. Same for Apache, but with a few extra requirements (like keeping a list of changes in the source code and preserving licensing information etc.).

As for how I know big corporations are using my code: the fact that a prominent project (publicly used by several tech giants) took a dependency on one of my tiny (permissively licensed) library packages is probably a clue.

[EDIT: removed now that the original is fixed]

If there happens to be some mental TLS handshake RCE that comes up, chances are they are all using the same underlying TLS library so all will be susceptible…

Among common reverse proxies, I know of at least two underlying TLS stacks being used:

• Nginx uses OpenSSL.
  • This is probably the one you thought everyone was using, as it’s essentially considered to be the “default” TLS stack.
• Caddy uses crypto/tls from the Go standard library (which has its own implementation, it’s not just a wrapper around OpenSSL).
  • This is in all likelihood also the case for Traefik (and any other Go-based reverse proxies), though I did not check.

This is probably the only type of rules violation that could be fixed by creating another account, so this was exactly my thought.

Then they probably wouldn’t say it was okay to make another alt though.

In a rather large part of the world (the solid green parts of that map).

This was my immediate suspicion as well, as soon as I read that it would leak for a GET but not a HEAD.

Somehow my .gitconfig seems to have grown by about 20 lines after reading this article. How mysterious…

Aurora is no longer maintained, but it still works just fine. It’s a Windows app, so not web-accessible or anything, but it’s free. It only contains the SRD content by default (probably for legal reasons), but there’s at least one publicly-accessible elements repository for it that you can find using your favorite search engine.

That domain currently hosts a “this domain may be for sale” page, but it’s been registered since 2005 so it’s definitely not because of this post.

Additionally, HTTPS if very easy to set up nowadays and the certificates are free¹.

¹: Assuming you have a public domain name, but for ActivityPub that’s already a requirement due to the push nature of the protocol.

Viaplay. In my country (the Netherlands) the only reason anyone’s heard of them (AFAIK) is that they have the rights to broadcast Formula 1 races here so they get a lot of signups at the start of the racing season, and a lot of cancellations at the end of that season.