Shawn Webb#HardenedBSD goal for this weekend: Radicle-ify our auto-sync.
This is now completed, pending one last verification after the next cron run in 55-ish minutes.
Verification complete with a successful result!
My next project will be a #Radicle orchestrator process that can mirror our repos to third-party resource (like our read-only presence on GitHub).
While I find #Rust easy to read, I haven't written much #Rustlang code yet. This will be a good exercise in learning Rust. :-)
The main idea is to implement bunches of features in this orchestrator (the first being the aforementioned repo mirroring support.) The next feature will likely be per-commit emails and issue/patch notifications via #Pushover.
I was hoping to start on the orchestrator today, but I'm being hit hard by vertigo, nausea, and a migraine today.
Perhaps I'll just prepare the #HardenedBSD 16-CURRENT build server to start building the hardened/current/pledge branch on a quarterly basis.
Yes, that means this feature branch will be testable (and usable?) by the general public.
Next month starts the new quarter. I'll likely propose a Call For Testing (CFT) to the community after the first official build completes.
Bryan Steele 
@lattera Do you have a link to a patch/commit or a previous discussion somewhere to look at?
I don't know what Radicle is supposed to be, but it's making me lose interest real quick.. 
@brynet we only have this link: https://radicle.network/nodes/rad.hardenedbsd.org/rad:z2HLHXgL1xevBNQsf8BmQW7MpJmtm/tree/hardened%2Fcurrent%2Fpledge
Our server is indeed pretty slow, so it might take a few attempts (spread those attempts out with 3-5 minute intervals, please).
@lattera It's not an issue of it it being 'slow', I can't search or find interesting commits, how is anyone reviewing this? 
@brynet just to make sure you have connectivity to our infrastructure, can you try browsing to: https://installers.hardenedbsd.org/
@lattera Yes, it's not an issue of connectivity to radicle, although that isn't great either, it's basic usability.. is it really expected workflow for someone wanting to review changes without cloning the entire repository? I mean, that's fine.. but it's a bit unclear where I should be looking.. 
@brynet I'm trying to work out the reason why you're having issues with the web UI. I wanted to isolate whether the problem was with the Radicle seed VM, with our main nginx VM, or an issue with the links (ISPs) between you and me.
What do the following domains resolve to?
installers.hardenedbsd.orgrad.hardenedbsd.orgYou should only see DNS A records. If you see DNS AAAA records, I need to prune those.
If you cannot reach https://installers.hardenedbsd.org/ then the issue is with an ISP between you and me. The reason being is that https://rad.hardenedbsd.org/ is the same web server as https://installers.hardenedbsd.org/.
If you can reach https://installers.hardenedbsd.org/ that means there's something wrong with our Radicle integration.
The idea (currently--I cannot speak for the project's future) is that Radicle's webUI is read-only. Folks can view the source code, issues, and patches via the webUI.
Users wishing to open new issues or patches, or comment on existing ones, will need Radicle installed on their system. They would need to use the Radicle CLI.
@lattera 
Yes Shawn, I can connect to those domains. I'm trying to review the pledge implementation you posted about, and am failing to find a commit diff to review. I cannot find the commit though the infuriating radicle webUI you've linked. I an not trying to open a new issue or comment on anything...
Yes Shawn, I can connect to those domains. I'm trying to review the pledge implementation you posted about, and am failing to find a commit diff to review. I cannot find the commit though the infuriating radicle webUI you've linked. I an not trying to open a new issue or comment on anything...@brynet oh, in this case, there isn't a way to diff between branches in the webUI (to my knowledge--I might be mistaken).
You can view issues and patches, along with the discussions on them, via the webUI. That view is read-only.
Currently, the pledge branch (hardened/current/pledge) is not a "patch"--just a different branch. When the time is right, we'll convert this feature branch into a patch that can be reviewed via the webUI.
In order to generate a diff between hardened/current/master (our primary development branch) and the hardened/current/pledge branch yourself, you would need to have the src repo downloaded on your end and generate the diff with git diff hardened/current/master hardened/current/pledge)
Alternatively, I could generate that diff for you and upload it to https://hardenedbsd.org/~shawn/ .
@lattera Ah. So that answers my question, there is no way to compare between branches, or search for commits, or grep the source tree.. okay, thanks.
A patch would be convenient, but I was only curious.. if the plan is to open an issue with the final patch for review later, I can wait until then.
@brynet Sorry it took so long to get to that conclusion. I was thrown off by the screenshot you provided, which showed a connection failure (
could not connect to rad.hardenedbsd.org) to our webUI. I originally thought you were unable to reach our infrastructure because of that.@brynet command used to generate this diff:
$ git diff -U100 rad/hardened/current/master rad/hardened/current/pledge`
https://hardenedbsd.org/~shawn/2026-06-15_pledge-01.patch.taxt
@lattera Why is this interface being called pledge? It's more like nicm@'s original prototype for tame(2), which pledge(2) superseded.
+int
+pledge(const uint64_t mask)
It's incompatible with OpenBSD pledge(2) which is already used in software today.
https://man.openbsd.org/pledge
If you're going to change the arguments, you might as well change the public name.
@brynet it's not my code. I haven't reviewed it just yet. But, this was originally written many years ago. IIRC, the function prototype for pledge() changed between then and now. (My memory is somewhat faulty and I might be misremembering.)
I do know there are some crucial differences, like persistence across the execve(2) boundary.
@lattera pledge(2) always used const char *promises, never a bitmask. That was tame(2). The second argument has changed since introduced in 5.9, but it was unused.
There are indeed quite a lot of differences in this, besides some overlap in promise names, it doesn't implement OpenBSD's pledge.
At the very least, it would be nice to avoid a similar situation to NetBSD's infamously incompatible strnvis(3).
https://github.com/openbgpd-portable/openbgpd-portable/commit/9aa445a
Bring in a check for broken strnvis on NetBSD and FreeBSD from portab… · openbgpd-portable/openbgpd-portable@9aa445a
…le openssh Explicitly test for broken strnvis. NetBSD added an strnvis and unfortunately made it incompatible with the existing one in OpenBSD and Linux's libbsd (the former having e...
@brynet I'd need to dig through years-old irc logs, but I think the thought was along the lines of:
We still need to map FreeBSD-specific syscalls to pledges. To make the initial development process quicker, a simple bitmask was used. Once the implementation matures, we would implement it as int pledge(const char *, const char *);
The original developer didn't want to spend too much time with string parsing while we figure out syscall to pledge mappings.