#publicfile — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #publicfile, aggregated by home.social.
-
Sounds a bit complex. (-:
Debian apt-ftparchive source actually makes checksum lists for source packages.
No handy equivalent in pkg repo, though.
It's not going to be high on the priority list. I could possibly modify the .do scripts to do something non-standard.
In the meantime, the HTTP Last-Modified: response header is right and the If-Modified-Since: request header is respected by Bernstein publicfile. For what that's worth.
-
I have only just discovered the X-Clacks-Overhead HTTP header.
To put it into #djbwares httpd properly, so that it is administrator-configurable *and* properly escapes the necessary metacharacters, is a fair amount of work.
So I'll probably make a to-do item out of it. But there's much more vital work to be done with things like making more things work with IPv6.
-
I made the mistake of starting to learn about GEMINI from its Frequently Asked Questions document.
It's not aimed at people like me, who already understand the benefits and tradeoffs of static content servers. So it drives lots of points home, repeatedly, that I already know.
It's apparently aimed at the same sort of monoculture Chrome+Apache Think for HTTP that parallels the old BIND Think and Sendmail Think that #qmail and #djbdns were up against years ago.
-
I made the mistake of starting to learn about GEMINI from its Frequently Asked Questions document.
It's not aimed at people like me, who already understand the benefits and tradeoffs of static content servers. So it drives lots of points home, repeatedly, that I already know.
It's apparently aimed at the same sort of monoculture Chrome+Apache Think for HTTP that parallels the old BIND Think and Sendmail Think that #qmail and #djbdns were up against years ago.
-
I made the mistake of starting to learn about GEMINI from its Frequently Asked Questions document.
It's not aimed at people like me, who already understand the benefits and tradeoffs of static content servers. So it drives lots of points home, repeatedly, that I already know.
It's apparently aimed at the same sort of monoculture Chrome+Apache Think for HTTP that parallels the old BIND Think and Sendmail Think that #qmail and #djbdns were up against years ago.
-
Yes, I have been musing about setting up a GEMINI server, especially as GOPHER doesn't really do virtual hosting and is thus a bit poor when it comes to the #publicfile content model.
I've pre-prepared a gemini6d service bundle, but an actual geminid server to go alongside httpd is still a to-do item.
I first learned of GEMINI's existence only a few days ago.
-
Static content? No uploading or any other form of modification?
If you need to upload, look elsewhere, such as indeed at the FreeBSD ftpd(8).
But if the requirement is just to *send out* stuff via FTP without the receiver having to log-in, with a server that runs sandboxed and not as the superuser, publicfile still fits the bill after all of these years.
https://jdebp.uk/Softwares/djbwares/
-
Right. That's done.
The existence of an OLDPROTO environment variable opts in to the old #publicfile behaviour. This will be in the next #djbwares release. The hardest part was writing the explanation in the #httpd manual page.
-
-
@cks That is a thought for the publicfile httpd to-do list: make 0.9 and 1.0 optional with a 1.1-only mode. None of libfetch, libcurl, or wget have defaulted to lower than 1.1 for nearly a decade, now. Might even be worth making 1.1-only the default, given the 14 years of anecdotal reports of the fall in 0.9 and 1.0 traffic to be found in a quick search. Hmmm.
-
You're on your own there.
The rest of the world, from https://owasp.org/www-community/attacks/Path_Traversal to CVE-2023-34096 through many other places along the way, calls this an attack.
You're trying to defend a bad implementation strategy based upon an erroneously perceived need for something that the world does not do. And somehow trying to make it Daniel J. Bernstein's fault for showing how to quite simply address the problem without reinventing wheels badly.
-
No. We're having this discussion because of the right things to learn; which is to let the filesystem do the name lookup of filesystem-like pathnames, to not reinvent that, and to prevent attacks of things like /../ and non-regular files.
/../ is not a "pattern" that can be relied upon when it reaches a server. It is an attack.
RFC 3986 explains how it is normalized away by clients, before server involvement.
-
Read what the SECURITY section says about dots again. M. Bernstein thought of all this. It also implements the Unix file hiding convention.
-
Existence says otherwise. It can be and is in #publicfile. Read the manual pages that I pointed to to see how it works.
-
Yes, one also has to take advantage of *all* that the operating system has to offer when it comes to pathname lookup. (-:
Bernstein #publicfile changes root to the content root directory and drops privileges. .. in URLs simply wouldn't escape, because the operating system's own name lookup wouldn't let them. There's no way for you to construct a URL that will get you my server's /etc/passwd , for example.
http://cr.yp.to/publicfile/httpd.html
http://jdebp.info/Softwares/djbwares/guide/commands/httpd.xml
-
I use #publicfile which relies upon the filesystem entirely, apart from an injection prevention mechanism that disallows dots at the starts of pathname components.
Symbolic links have been doing the job of host aliases for many years for me.
$ ls -dg /public/file/jdebp.uk
lrwxr-xr-x 1 wheel 10 Aug 1 2018 /public/file/jdebp.uk -> jdebp.info
$ -
It's entirely backwards to think that eliminating the filesystem is the lesson to learn here.
The lesson to learn here is that if one is presenting hierarchical CIS URLs then one should parse them like filesystem pathnames are parsed. /imgsomething must not ever be matched by /img in pathname lookup.
The best way to achieve this is not to re-invent filesystem pathname parsing badly yet again, but to let the filesystem parse the pathnames.
-
That's a straw man, though, because it was even in the original Bernstein doco that publicfile didn't read directories for security.
Always read the manual. (-:
-
On the contrary: HTTP/1.1 support, including persistent connections, was even in the Bernstein original, as was checking that the pathname was not a directory.
http://jdebp.info/Softwares/djbwares/guide/commands/httpd.xml
-
I haven't looked at the code of Bernstein's publicfile in a while, but I don't remember offhand any obvious problems with metadata race conditions.