Nostr notes by Tim Chase

might want to let @npub1ysc…ffqw know about the ...

2026-02-21T15:13:32Z

In reply to nevent1q…7lp5
_________________________

might want to let The Real Grunfink (npub1ysc…ffqw) know about the snac-crashing-on-OpenBSD issue…it might be a matter of compiler build-time arguments inaccurately choosing the target architecture.

I don't comprehend businesses entrusting their entire online ...

2025-09-16T00:00:17Z

I don't comprehend businesses entrusting their entire online presence to the big social-media companies.

Yes, I drove past your new restaurant today and would love to learn more! But you don't have an actual web-page for basic things like menu, hours, pricing, or contact info? Like the sort of thing you could obtain for <$10/year on a cheap hosting service?

Sure, I suppose I'll open your Instagram page in a Private Browsing window. Oh, wait, IG will only show me 2–3 screenfuls of posts before requiring me to log in? We'll just close the window instead.

I suppose I could try your Facebook page instead in a different Private Browsing window. Hmm, a whole 2 pages of past posts before it requires me to log in to view more. *closes window*

Sorry, I was interested, but not *that* interested. Here's wishing your new business the best of luck… 😕

I have a private git repo that I sync around for my personal ...

2025-05-07T00:24:29Z

In reply to nevent1q…fx2r
_________________________

I have a private git repo that I sync around for my personal files, including my remind(1) files, my ledger(1) finances, notes.txt, etc.

I have repo-storage on several machines, and git is configured to push to all of them for multiple copies.

I too find the "X is secure" claim a bit hard to accept ...

2025-05-04T12:23:06Z

In reply to nevent1q…2vlr
_________________________

I too find the "X is secure" claim a bit hard to accept at face value.

But the OpenBSD folks do seem to take it as a mindset, willingly making sweeping changes even if they have notable costs.

Doing certain checks or defaulting to not using SMT? It may cost performance, but they're willing.

Adding code to pretty much all the base utilities to limit what they can access with pledge(2)/unveil(2) or using privsep for services? yeah, it too is a cost, but they eat it.

Ripping out risky/complex things or setting breaking defaults (dropping broken cipher suites from default ssh settings) or raising loud warnings (e.g. trying to use rand(3) in C) instead of coddling bad code? Sure, it sacrifices some backwards compatibility, but it reduces complexity (the enemy of security) and prevents exploits in those areas.

So while secure-vs-not-secure is hard to label, they at least have a track record of making hard decisions that favor a security-mindset.

though they're lines of code that have been vetted for ...

2025-01-11T12:57:12Z

In reply to nevent1q…fy7p
_________________________

though they're lines of code that have been vetted for decades and (with the exception of fzf in this case) are POSIX, already existing on the system. The cost of those lines has already been paid before you even type a command.

Yes, fzf might bring in thousands of additional lines of code, but it's a single source, tested by many users for many years—not quite the decades of POSIX shell+utils, but still around notably longer than this random Github project release in the last week. Who knows about those Golang libraries and how many have been used, and of those how many have actually had any sort of security eye cast over them?

And at least with bash (rather than sh), I could have largely used `select` in the shell rather than fzf for the "pick a subset of these" in another couple lines. Or even just using `grep -n` with `read` in POSIX shell, in a similar number of lines.