#djbwares — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #djbwares, aggregated by home.social.
-
Well I've been doing my part for many years. (-:
http://jdebp.info/Softwares/djbwares/
No, I don't accept plagiarism machines. Sadly, that the plagiarism machines nick and distort this very codebase is one of the bad things that I know about them. I happened to search something a while back, and got a misrepresentation of me, obviously abusing my own code, generated by one of the 'AIs'.
@netbsd @rl_dane @bpl @jaypatelani @corvus @cmccullough @gmc
-
I wouldn't be at all surprised if the back-end database for their content DNS servers is dynamically populating, every few minutes, all of the A/AAAA resource record sets for all of *.archive.ubuntu.com. according to content HTTP server availability.
Indeed, #Canonical is putting a 10 minute TTL on the alias from uk.archive.ubuntu.com to gb.archive.ubuntu.com, just because that situation might change rapidly.
I have seen things in the DNS world. (-:
-
If 'go to' means first choice, where possible, then of course it is #httpd from #djbwares. Simple; static; secure; low resource usage; and I know exactly how it works.
One of the reasons that I maintain it is so that I can use it myself. (-:
http://jdebp.info/Softwares/djbwares/
It is running on #NetBSD for my public WWW site. But I have an internal WWW site where it runs on #FreeBSD.
Years ago, it was my own httpd and httppd, on OS/2. (-:
-
Does your system show stats about how many transactions connections serviced before they closed? Or, alternatively, what the lifetimes of established connections are?
I'm asking because I'm putting the occasional knob into the HTTP server in #djbwares and you've made me think about transaction caps and what's reasonable when one is under attack from an LLM scraper; when one really doesn't want the attacker to be able to hold existing connections open indefinitely.
-
So you're not interested in those who go the whole hog and run their own private root content DNS servers. (-:
http://jdebp.info/Softwares/djbwares/guide/dns-private-root.html
-
Scarily, Bing's bloody LLM seems to know exactly what the mechanism is 9 months after I put it in.
How the Hell has it found that out? I haven't even put it in the Guide. I did the search to see if I'd ever mentioned it.
Here's the Guide, which does tell you that you need redo.
http://jdebp.info/Softwares/djbwares/guide/building-from-source.html
And here's the mechanism. Perhaps Bing somehow matched the name of the variable.
https://github.com/jdebp/djbwares/blob/trunk/source/cc.do#L8
-
Actually, it's the same source tree just compressed differently, and multiply-redundant copies across the repository sites. There's only one set of source for everything.
It would actually be the same compression if everyone's pax supported bzip2. (-:
There's also a simple bypass mechanism if the GCC or clang desired aren't the ones found in PATH, for cross-compiling and whatnot. Someone here asked for it.
-
Well you should be done with that. It's about time. (-:
It's been a long time since the world was *anything like* that.
I've been actively maintaining #djbwares for 13 years. Erwin Hoffmann has been maintaining #djbdnscurve6 for I think 8 years.
We both provide source in one go, zero patching involved. I've provided Debian and FreeBSD binaries packages for years, too. djbdnscurve6 has been in pkgsrc since 2019.
Hell, even the kids just fork ndjbdns entirely now. Patches⁈ (-:
-
Sugar for AAAA records was done in 2025 by me. Felix von Leitner did it differently 25 years earlier, but I didn't like that it required two parallel toolsets and sets of record types. My way, it's just an IPv6 address in the same '+' records.
That's been available for a *long* time.
-
Anyway, who the Hell is this community that thinks that the original #djbdns is the be-all and end-all?
Let me know, and I'll show them #djbwares, where I've got a whole long list of things that have been improved, from IPv6 support through a non-hexdump way of doing SRV records to not letting ANY queries be amplification attack puppets.
-
An additional fun factor is that wildcards in #djbdns by design don't work like wildcards in BIND. The difference was much discussed a quarter of a century ago.
So any bug reports that assume that wildcards in djbdns databases are supposed to behave like they do in BIND's 'zone' files need to be checked for proper foundation.
And with RFC 4592 an even greater divergence then happened.
-
Since I was visiting the 'daemontools' account on #GitHub, I took a look at what the people who mistakenly thought that it was someone actually involved, have done.
Not much, fortunately.
One wheel reinvention that didn't even look at Bruce Guenter's daemontools-encore.
Only one thing worth following up on, in 13 years:
https://github.com/daemontools/daemontools/issues/8
The bugfix will be in #djbwares version 13 when it comes out. As noted, neither @ska's nor my #nosh reimplementations have this bug.
-
Not to be confused with #daemontools, a different (and older) piece of software entirely that is approaching 30 years old, still going, and probably really hard to perform a supply chain attack on.
-
I've updated #djbwares 10 to 12 on the WWW page.
Thank you for the reminder. I do need to get back to this.
-
Excellent.
Yes, the latest released versions are supposed to be a version behind the actual development source. I freeze the source, do a binaries release, and start a new development version.
So #redo latest binary release is 1.5, and #nosh is 1.41.
#djbwares is at version 12, with version 13 under development. I must have forgotten to update the WWW page.
-
Early results are not promising. I've had a handful of HEAD requests in the past day. Only 2 appear legitimate, in that they hit genuine page URLs. The others were attempts to exploit WordPress vulnerabilities.
-
It makes me think that there's one well-behaved 'bot drowned in a sea of ill-behaved ones.
I'm just instrumenting #djbwares httpd to log GET and HEAD differently. I wonder what I'll see.
-
At least one attacker who queries IDENT servers is using the ports straight out of the example in Wikipedia.
-
A truly universally portable #clockspeed is probably impossible. It has only recently become more than amd64-only. (AFAIAA, I'm the only one who has done the work to add another ISA.) Even then, it makes specific assumptions about the processor that aren't necessarily true (and which are called out in the manual, q.v.).
http://jdebp.info/Softwares/djbwares/guide/commands/clockspeed.xml
-
I wrote an IDENTD for OS/2 around the turn of the century.
I added one to #djbwares just recently to see what of this old stuff is even hit any more. IDENT was barely in use back then.
It's surprising to see that a GOPHER sever is (a) quickly jumped on when set up, (b) regularly mis-treated as speaking HTTP or SIP; whereas at the same time there are WWW robots that do not even recognize gopher: as a URL schema, and treat it as a relative URL.
-
I was amused to see that you actually had a thorough IDENT client, that checked for errors; instead of Bernstein's one that just counts the colons and assumes success.
Not that anyone with xyr head screwed on should be using IDENT for authentication.
http://jdebp.info/Softwares/djbwares/guide/commands/identd.xml
I suppose that I should give this tool the motto "I am root.". (-:
#s6networking #s6 #djbwares #ucspitcp #GuardiansOfTheGalaxy #IDENT
-
#djbwares 12 is out.
Not much new except for a fix for that C linkage bug, a bunch of code now taking void* instead of char*, and a new very trivial identd.
-
-
-
Now that version 11 is out, I can point to a copy of the Guide chapter that I was talking about.
http://jdebp.info/Softwares/djbwares/guide/dns-security.html
-
There are a much smaller number of people doing SVCB lookups, too. But, interestingly, they are doing them wrongly.
And with a direct correlation to some other abuses.
Which does make me think that, in an ironic twist, it is the bad actors running robot vulnerability probes and scrapers that are the early adopters of SVCB, here.
-
This does make you the second person in the world (if you picked up the source after I put it in yesterday) who can run
dnsqr https google.com
or even
dnsqr https jdebp.info
I didn't think that people were using this, it only having been accepted in November 2023, but I discovered a few lookups in my logs.