Make the CI pipeline create a Docker image that contains Debian slim and the man pages installed.

On the other hand, it's Docker, so you know every blog will use their own base image.

Guys: Serve your blog via Docker itself. Docker image names are _already_ URLs. You could literally just have people do `docker pull myblog.com/recipes:latest` or `myblog.com/recipes:lasagna`.

Edit: and navigate like so: `docker image myblog.com/recipes` to list all recipes. God I love APIs.

And add search logic to the tag, so you don't need to know the name of the post, just the right word(s) to find it and let the "I'm feeling lucky" algorithm pick the right one :)

And then someone ports that back to regular Docker, and we get a whole new dimension of software supply chain security issues :).

I can't tell how much of this is sarcasm. Turning what started out as a problem of "How do you load arbitrary remote TROFF sources into man" into "throw docker at it" because someone suggested an intermediate solution of "apt" which introduces security issues and no one posed that there might be an alternative that obviates any need for containerization. I mean these two things could be further from each other on the scale of incredibly lightweight to massively heavyweight.

Or maybe this is a microcosm of why docker and kuberwhatever happens so much.

It's the nerd version of that Reddit pattern of organic comment chain, each reply adding e.g. a line of song - only with pushing an absurd idea to the limits.

I'll bite: with GP's take, docker-compose would make for a good webring/blogroll. Or use it as bookmarking system.

  cd blogs/cooking
  docker-compose up
  # 20 different recipe blogs available as man pages

Exactly this. Just having fun.

I can confirm that I was jesting when I said to use Docker here :^)

I thought we were just riffing, I wasn’t actually proposing this as a genuine technical solution. Just a fun thought experiment :)

It's probably more satire than anything else.

Weekend project: Docker pull blog posts over DNS

Docker is the example implementation of "containers do not contain". At least I would use podman.

How does HTTP(S) Same Origin policy work with local file:/// URLs?

TIL there's no `ls -al /use/share/man/** | man --html`; though it would be easy to build one with Python's http.server, or bottlepy, or bash,.

Prompt: An http server ( with bash and /dev/tcp/ ) that serves HTML versions of local manpages with linkification of URLs and references to other manpages

> How does HTTP(S) Same Origin policy work with local file:/// URLs?

It doesn't since file:/// is just a uri and not part of the http protocol

If I open an HTML copy of a manpage that contains JS from a file:/// URL, can it read other local files and send them to another server with img URLs?

If so, Isn't it thus probably better to run an HTTP server over a permissioned socket than to serve static HTML [manpages] from file URLs [in a [DEB] package]?

file:/// is always going to be local to the machine reading the URI. So if you're serving a page that has a file:/// uri in it and someone on another machine clicks on it, they wont be seeing the file (unless they happen to have the same path on their machine). If the goal is get them that file, then yes, it'll need to be served.

CVE-2019-11730: https://nvd.nist.gov/vuln/detail/CVE-2019-11730