DEV Community: Amayo Clinton

[Boost]

Amayo Clinton — Mon, 20 Jul 2026 15:45:41 +0000

Emma Bostian ✨

Jul 9 '19

101 Tips For Being A Great Programmer (& Human)

#career

3366

202

13 min read

Nostr, Explained for Developers — A Deep Dive

Amayo Clinton — Sun, 19 Jul 2026 19:41:16 +0000

If you've spent any time in the Bitcoin or decentralized-social corners of the internet
lately, you've probably seen the word Nostr thrown around next to terms like "zaps,"
"relays," "npub," and "NIP-whatever." Most explainers stop at the surface — "it's
decentralized Twitter." That's true, but it undersells what's actually going on and
skips the parts that matter if you're a developer deciding whether to build on it.

This post goes deeper: the protocol's actual wire format, why it was designed the way it
was, how it compares to the alternatives that came before it, what real production
systems look like on top of it, and where the sharp edges are. By the end you should be
able to read the spec yourself and know exactly where to start building.

What Nostr actually is and isn't
The problem it was designed to solve
The protocol, piece by piece: keys, events, relays, clients
How the wire protocol actually works (REQ / EVENT / CLOSE)
NIPs: the extension system that lets the protocol grow
Zaps: the feature that makes Nostr different from everything before it
Nostr vs. ActivityPub vs. Bluesky's AT Protocol
What real production apps look like on this stack
The honest tradeoffs and open problems
Getting started: a minimal working example
Where this is heading

1. What Nostr actually is and isn't

Nostr stands for Notes and Other Stuff Transmitted by Relays. It
was first sketched out by a pseudonymous developer known as fiatjaf in late 2020, with the
explicit goal of being "the simplest possible thing that works" — a deliberate reaction
to how complex and heavyweight ActivityPub (the protocol behind Mastodon) had become.

What it is: an open protocol specification — not a company, not a single app, not a
blockchain, not a token. There's no Nostr Inc. to shut down and no central server to
subpoena, because there isn't one. It's closer in spirit to email (SMTP) or the web
(HTTP) than to a product — a shared format that many independent implementations agree
to speak.

What it isn't: a blockchain. This trips people up constantly because of how tightly it's
associated with Bitcoin. There's no consensus mechanism, no mining, no global ledger of
truth. Events aren't "mined" — they're just signed and broadcast. The only place Bitcoin
actually enters the picture is optional: the Lightning Network is used for in-protocol
payments (zaps), and secp256k1 — the same elliptic curve Bitcoin uses for keys — happens
to be the curve Nostr identities are built on, mostly because it's fast, well-audited,
and developers building in this space already had tooling for it.

2. The problem it was designed to solve

Every centralized social platform, no matter how well-intentioned, has the same structural
weakness: your identity, your social graph, and your content all live inside one
company's database, under one company's rules. If that company suspends you, changes its
algorithm, sells to a new owner, or shuts down entirely, everything you built there is
gone — not because you did anything wrong, but because you never actually owned any of
it. You were a tenant.

Mastodon and the wider Fediverse tried to fix this with federation — instead of one
company, thousands of independently run servers, each running the ActivityPub protocol,
talking to each other. This is a real improvement, but it only partially solves the
problem: your identity is still tied to whichever server you signed up on
(@you@mastodon.social). If that specific server's admin bans you, or the server shuts
down, you lose your handle, your followers, and your post history, even though the wider
network survives. You've traded one company for one admin.

Nostr's answer is to go one layer deeper: separate identity from hosting
entirely, so that neither a company nor a single server admin can hold your identity
hostage.

3. The protocol, piece by piece

3.1 Identity is a keypair, not an account

There is no sign-up flow on Nostr in the traditional sense. "Creating an account" means
generating a standard secp256k1 keypair, client-side, with no server involved at all:

nsec (private key) — the thing that lets you sign events. Never uploaded anywhere in plaintext, never sent to a server, ever.
npub (public key) — your identity, in a human-shareable, Bech32-encoded format. This is you, across every Nostr app that exists, forever, unless you choose to generate a new one.

Because no company or server issues this identity, none of them can revoke it. If you
stop trusting one client, you install a different one, log in with the same key, and your
followers, your post history, and your profile are all instantly there — not because
they were "migrated," but because they were never tied to that app in the first place.
This is structurally impossible to replicate on Twitter, Instagram, or Discord, where
your identity is a row in a database you don't have access to.

3.2 Content is a signed event — and that's the entire data model

This is the part that genuinely surprises people the first time they read the spec:
there is exactly one data structure in Nostr. A post, a profile update, a like, a direct
message, a long-form article, a Lightning payment receipt — all of them are the same
JSON shape:

{
  "id": "5c83da777af...",
  "pubkey": "91cf9...f857",
  "created_at": 1721390400,
  "kind": 1,
  "tags": [
    ["p", "some-other-pubkey-being-replied-to"],
    ["e", "id-of-the-note-being-replied-to"]
  ],
  "content": "hello, nostr",
  "sig": "908a15e4f8de..."
}

Breaking that down:

id — a SHA-256 hash of the serialized event data. This means the ID isn't assigned by a server; it's a deterministic fingerprint of the content itself. Change one character of the content and you get an entirely different ID.
pubkey — the author's public key, in hex.
created_at — a Unix timestamp, set by the client, not the server.
kind — an integer that tells every relay and client what type of event this is. This single field is what lets the protocol stay generic while supporting wildly different features — more on this below.
tags — an array of arrays, used for references, replies, mentions, hashtags, and metadata specific to that event kind. This is the protocol's extensibility escape hatch: instead of adding new top-level fields for every feature, features are expressed through tags.
content — the actual payload, usually a string (sometimes itself JSON, sometimes encrypted, depending on the kind).
sig — a Schnorr signature over the event ID, produced with the author's private key. Anyone, anywhere, can verify this signature using nothing but the public key and the event data — no server round-trip required.

That signature is the whole trust model. A relay could be hostile, compromised, or run by
someone with terrible intentions, and it still can't forge a post from you or alter
your existing posts without breaking the signature — any client that checks it will
immediately reject a tampered event.

3.3 Kinds: the field that does all the work

The kind number is genuinely the most important design decision in the whole protocol.
A few of the most widely used:

Kind	Meaning
0	Profile metadata (display name, avatar URL, NIP-05, etc.)
1	Short text note — the "tweet"
3	Contact list — who you follow
4	Encrypted DM (legacy, deprecated — see NIP-17 below)
5	Deletion request
6	Repost
7	Reaction (like, or an arbitrary emoji/vote)
1063	File metadata
9734 / 9735	Zap request / zap receipt
30023	Long-form article
39000-39009	Group metadata (NIP-29)

Kinds are grouped into ranges with different storage semantics — some are "regular"
(every event is kept forever), some are "replaceable" (only the newest event per
pubkey+kind is retained, useful for things like profile metadata that shouldn't
accumulate history), and some are "ephemeral" (not stored at all, just relayed live,
useful for typing indicators or presence). This range-based convention means a relay can
implement sensible storage behavior for a brand-new kind it's never seen before, just by
checking which numeric range it falls into.

3.4 Relays are dumb pipes, not authorities

A relay is nothing more than a WebSocket server that stores events and answers queries
for them. That's the entire job description. Critically, a relay has no special power
over your identity — it can refuse to store your events (rate limiting, spam filtering,
an outright ban from that specific relay), but it cannot delete your account, because
there was never an account for it to control in the first place. Your identity lives in
your keypair, not in any relay's database.

In practice, clients publish the same event to several relays simultaneously — typically
somewhere between three and ten. If one relay goes offline permanently, or bans you, or
turns out to be run by someone acting in bad faith, your content and identity survive
intact on every other relay you published to. This redundancy is the actual mechanism
that makes the network censorship-resistant — not any single relay's goodwill, but the
fact that no single relay is a point of failure.

3.5 Clients are interchangeable, by construction

Damus, Primal, Amethyst, Ditto, YakiHonne, Iris, Coracle — these are all independently
built apps, often by teams that have never talked to each other, reading and writing the
exact same event format from the exact same relays. Switch from one to another mid-day
and your followers, your posts, your DMs, and your Lightning wallet connection all show
up automatically, because none of it was ever app-specific data — it's just events on
relays, addressed by your pubkey.

4. How the wire protocol actually works

It's worth seeing the raw mechanics once, because it demystifies a lot of what "Nostr
app" actually means under the hood. Everything happens over a WebSocket connection to a
relay, using a small set of message types.

Publishing an event — the client sends:

["EVENT", { ...the signed event object... }]

The relay responds with an OK message confirming whether it accepted or rejected the
event (and why, if rejected — e.g. rate-limited, invalid signature, blocked pubkey).

Requesting events — the client sends a subscription request with a filter:

["REQ", "subscription-id-1", { "kinds": [1], "authors": ["91cf9...f857"], "limit": 20 }]

The relay streams back matching events as EVENT messages tagged with that subscription
ID, followed by an EOSE ("end of stored events") message once it's sent everything it
currently has — after which the subscription stays open and the relay pushes any new
matching events live, in real time, as they arrive. This is how a Nostr feed actually
updates without polling: it's a long-lived subscription over an open socket.

Closing a subscription:

["CLOSE", "subscription-id-1"]

That's genuinely most of the protocol's mechanical surface. Everything more advanced —
groups, zaps, encrypted DMs — is built by defining new event kinds and tag conventions on
top of this same three-message exchange, not by adding new wire-level message types.

5. NIPs: the extension system

The base spec, NIP-01, only defines the event format and the REQ/EVENT/CLOSE
exchange above. Everything else is an optional extension called a NIP — a "Nostr
Implementation Possibility," numbered and published in a public GitHub repository.
Clients and relays adopt whichever NIPs make sense for what they're building; nothing is
mandatory. This keeps the core protocol genuinely tiny — you can read NIP-01 in about ten
minutes — while letting the surrounding ecosystem grow features without ever breaking
backward compatibility, since old clients simply ignore kinds and tags they don't
recognize.

A few of the most consequential NIPs in production today:

NIP-05 — maps a human-readable identifier (formatted like an email address, e.g. alice@example.com) to a pubkey via a .well-known DNS lookup, so users see something more recognizable than a wall of hex characters, and so impersonation is at least partially mitigated.
NIP-17 / NIP-44 — properly encrypted, metadata-minimizing direct messages, using a "gift wrap" scheme that hides even who's talking to whom. This replaced the earlier NIP-04, which encrypted message content but left sender, recipient, and timing fully visible to any relay — a real privacy hole for anything called an "encrypted" DM.
NIP-23 — long-form content: real articles with titles, summaries, and Markdown bodies, rather than short notes.
NIP-25 — reactions: likes, and by extension arbitrary up/down-style voting, since the content field can hold any string, not just an emoji.
NIP-29 — relay-based groups: the closest thing Nostr has to a "server" in the Discord sense, with defined admin/moderator roles, membership lists, and channels, with permission checks enforced by the relay hosting the group rather than trusted from the client.
NIP-42 — relay authentication, needed for any access-gated or private content.
NIP-46 — remote signing (often called a "bunker"): lets an app request a signature from a separate signer application, so the app itself never has direct access to your raw private key.
NIP-57 — zaps, covered in detail next.

Anyone can draft a NIP. Adoption is entirely organic — a NIP "succeeds" not because a
governing body approves it, but because enough clients and relays independently decide
it's worth implementing, the same evolutionary pressure that determines which HTTP
headers or email extensions become universal over time.

6. Zaps: the feature that makes Nostr different from everything before it

ActivityPub solved federation over a decade ago. What it never solved — what no prior
open social protocol solved — is native monetization. There's no built-in way to pay a
creator inside ActivityPub itself; every attempt bolts on a separate payment processor,
subscription platform, or ad network sitting outside the protocol.

Nostr's answer, defined in NIP-57, is called a zap: a Lightning Network payment
wrapped inside a signed Nostr event and attached directly to the specific post or profile
it's paying. Mechanically, it works like this:

You tap "zap" on a post. Your client constructs a kind: 9734 zap request event, referencing the post being zapped, and sends it to the recipient's configured Lightning address.
That Lightning address returns a BOLT11 invoice.
Your wallet pays the invoice over the Lightning Network.
The recipient's Lightning service provider publishes a kind: 9735 zap receipt event back to the relays, cryptographically proving the payment happened and linking it to the original post.
Every client that renders that post can now display the zap total, because the proof of payment lives in the same event graph as the content itself.

The significant part isn't the mechanism — it's that the payment and the social action
happen in the same protocol layer, with no ad network, no platform fee, and no separate
payment processor mediating the relationship between creator and audience. This is the
specific reason Bitcoin-native developers gravitate toward Nostr rather than other
decentralized-social efforts: the social graph and the payment rail are literally the
same underlying system, not two separate products stitched together.

7. Nostr vs. ActivityPub vs. Bluesky's AT Protocol

Three protocols regularly get compared, so it's worth being precise about how they differ:

	Nostr	ActivityPub (Mastodon)	AT Protocol (Bluesky)
Identity	Cryptographic keypair, held by the user	Handle tied to a specific server (`@you@server`)	DID (decentralized identifier), can be self-hosted or provider-hosted
Hosting model	Any relay, freely swappable	Federated servers, admin-controlled	"Personal Data Servers," designed for portability
Moving providers	Trivial — same key, any client/relay	Difficult — handle and history are server-bound	Supported by design, but less battle-tested
Native payments	Yes — zaps (NIP-57), Lightning-native	No	No
Protocol complexity	Deliberately minimal	Comparatively heavyweight (inherited from ActivityStreams)	Moderate, with a stronger emphasis on algorithmic feeds
Governance	No formal body; NIPs adopted organically	W3C standard, more formal process	Steered primarily by Bluesky PBC

None of these is strictly "better" in the abstract — they optimize for different things.
ActivityPub optimizes for federation between admin-run communities. AT Protocol optimizes
for algorithmic feed flexibility with portability as a design goal. Nostr optimizes for
minimal trust surface and puts a payment rail directly into the protocol. Which one a
given project should build on depends entirely on which of those properties actually
matters for the problem being solved.

8. What real production apps look like on this stack

It helps to look at two projects that made very different architectural choices on top
of the exact same protocol:

Ditto is a self-hostable community server, written in Deno/TypeScript with Postgres
for indexing. Rather than building a new UI from scratch, it implements Mastodon's REST
API on top of Nostr events — so any existing Mastodon-compatible client can point at a
Ditto instance and just work, while the actual data underneath is portable Nostr events
rather than server-locked ActivityPub records. It's aimed squarely at admins who want to
run their own community without the deplatforming risk that comes with depending on one
company's infrastructure.

YakiHonne took the opposite approach: rather than being self-hosted infrastructure,
it's a polished client app (web, iOS, Android) with its own relay network built in
strfry (C++), optimized for long-form publishing and creator monetization, with a
built-in Lightning/Cashu wallet baked directly into the app. It also introduced Smart
Widgets — interactive mini-apps encoded as Nostr events — pushing the protocol beyond
static posts into small embedded applications.

Both are legitimate, production-grade approaches to the same underlying protocol, which
is the point: Nostr isn't a single app you either use or don't, it's a substrate that
different teams build genuinely different products on top of — the same way SMTP
underlies both a self-hosted mail server and Gmail.

9. The honest tradeoffs and open problems

Decentralization isn't free, and a fair explainer has to say so plainly.

Discovery is unsolved. No company curates a global feed, which is exactly the point, but it also means good content discovery has to be engineered by each client independently, and most haven't fully cracked it yet.
Moderation is per-relay, not global. A relay can reject spam or abusive content on itself, but there's no way to remove something from the network entirely — it may still exist on other relays. This is a deliberate consequence of the trust model, and it means building real abuse-handling tooling is squarely the responsibility of anyone running a relay or client, not something you inherit for free.
Key management has no safety net. There's no "forgot password" flow. Lose your nsec and you've lost that identity permanently, unless the specific client you used built its own backup/recovery scheme on top of the base protocol.
No global consensus on state. Things like a reaction count or a vote total are only ever a view assembled from whichever relays your client happened to query — not a single canonical number the way a centralized database would give you. Two different clients can legitimately show two different totals for the same post.
Spam resistance is still maturing. Because publishing an event is nearly free, relays rely on rate limiting, proof-of-work stamps (NIP-13), paid relays, or allowlists to keep spam manageable — there's no single dominant solution yet.

None of these are protocol bugs exactly — they're the direct, unavoidable tradeoff for
not having a company sitting in the middle making those decisions on your behalf.
Building well on Nostr means designing around these constraints explicitly, rather than
assuming the platform-style guarantees a centralized backend would otherwise give you for
free.

10. Getting started: a minimal working example

If you want to see the protocol in action, here's the shortest path from zero to a
published event using nostr-tools (JavaScript/TypeScript):

import { generateSecretKey, getPublicKey, finalizeEvent } from 'nostr-tools/pure';
import { Relay } from 'nostr-tools/relay';

// 1. Generate a keypair (this is your "sign up")
const sk = generateSecretKey();
const pk = getPublicKey(sk);

// 2. Construct and sign an event
const event = finalizeEvent({
  kind: 1,
  created_at: Math.floor(Date.now() / 1000),
  tags: [],
  content: 'hello, nostr',
}, sk);

// 3. Publish it to a relay
const relay = await Relay.connect('wss://relay.damus.io');
await relay.publish(event);
console.log('Published as', pk);

That's a complete, working Nostr client in about a dozen lines — no server, no signup
form, no API key. For anything user-facing, you'd swap step 1 for a NIP-07 browser
extension (like Alby or nos2x) or a NIP-46 remote signer, so the app itself never
touches the raw private key at all — a meaningful security practice, not just a nicety.

Other useful entry points depending on your stack:

nostr-tools (JS/TS) — the most widely used client-side library
go-nostr (Go) — solid choice for relay-side or backend infrastructure
nostr-sdk (Rust) — used by several higher-performance clients and relay implementations
The NIPs repository on GitHub — the actual living spec, genuinely readable in an afternoon since the core protocol is small by design

11. Where this is heading

The protocol's minimalism is also its growth strategy: because NIP-01 barely changes, the
surface area for breaking compatibility stays small, while the NIP process lets the
ecosystem experiment quickly at the edges — group chat, long-form publishing, Lightning
payments, and interactive widgets have all been added this way without a single rewrite
of the base spec. That's a genuinely different development model from most protocols,
which tend to accumulate complexity in the core spec itself over time.

The honest way to think about where Nostr fits: it's not trying to replace every social
platform overnight. It's a substrate — a shared identity and event layer — that lets
independent developers build interoperable products without needing anyone's permission
or API key to do it. Whether that ends up mattering at large scale is still an open
question the ecosystem is actively answering in public, one NIP and one client at a time.

If you're building on Nostr and want to compare notes on relay architecture, NIP-29
groups, or Lightning/Cashu integration, drop a comment below — always interested in what
people are actually shipping on this stack.

12 GitHub Actions Workflows That Will Quietly Save Your DevOps Team Hours Every Week

Amayo Clinton — Sun, 19 Jul 2026 18:35:11 +0000

If your team is still manually running tests, tagging releases, or nudging people about stale PRs — you're leaving a lot of free automation on the table. GitHub Actions has matured into a genuinely capable automation layer that goes way beyond "run tests on push," and most teams only scratch the surface of it.

This is a practical rundown of automation patterns that actually pull weight in production, organized by the problem they solve rather than as a generic feature list. Copy-paste, adapt, ship.

1. CI/CD That Actually Gates Deployments

The baseline pattern everyone starts with, but worth doing properly: don't just run tests — make deployment conditional on them passing, and separate build/test from deploy into distinct jobs so you get clean status checks on PRs.

name: CI/CD Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm test

  deploy:
    needs: build-and-test
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh

Trade-off worth knowing: npm ci instead of npm install in CI — it's stricter (fails if package-lock.json is out of sync) and faster since it skips dependency resolution. Small change, meaningfully more reliable builds.

2. Linting and Static Analysis as a Required Check

Catching style and correctness issues before a human reviewer has to. The key move here isn't just running the linter — it's making it a required status check in your branch protection rules so it can't be merged around.

name: Lint
on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npx eslint . --max-warnings=0

--max-warnings=0 is doing a lot of work there — without it, warnings pile up silently and the check stays green forever.

3. Stale Issue/PR Triage

Backlogs rot. Automating the "is this still relevant?" nudge keeps your issue tracker honest without anyone having to manually sweep it.

name: Stale Triage
on:
  schedule:
    - cron: '0 0 * * *'

jobs:
  stale:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/stale@v9
        with:
          days-before-stale: 30
          days-before-close: 7
          exempt-issue-labels: 'pinned,security'
          stale-issue-message: >
            This issue hasn't seen activity in 30 days and will close in 7
            days if there's no update.

Pro tip: always carve out an exempt-issue-labels list. Nothing kills trust in this automation faster than a security issue auto-closing because nobody commented in a month.

4. Dependency Updates Without the Manual Review Bottleneck

Dependabot (or Renovate) opens the PRs. The real automation win is safely auto-merging the low-risk ones — patch/minor bumps that pass CI — while still gating major version bumps for human review.

name: Dependabot Auto-Merge
on: pull_request

permissions:
  pull-requests: write
  contents: write

jobs:
  auto-merge:
    if: github.actor == 'dependabot[bot]'
    runs-on: ubuntu-latest
    steps:
      - uses: dependabot/fetch-metadata@v2
        id: metadata
      - if: steps.metadata.outputs.update-type != 'version-update:semver-major'
        run: gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Don't skip this detail: gate on update-type. Blanket auto-merging everything Dependabot opens, including majors, is how you wake up to a broken build from an unannounced breaking change.

5. Secret Scanning and Dependency Vulnerability Checks

This is the one teams skip until it bites them. Two layers worth running on every push: scanning for accidentally committed secrets, and auditing dependencies for known CVEs.

name: Security Checks
on: [push]

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Scan for secrets
        uses: trufflesecurity/trufflehog@main
        with:
          extra_args: --only-verified
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm audit --audit-level=high

--audit-level=high matters here — running npm audit with no threshold means low-severity noise eventually gets ignored entirely, and then so does everything else.

6. Release Automation with Auto-Generated Changelogs

Manually writing release notes for every tag is exactly the kind of toil automation exists to kill. release-drafter builds a changelog from merged PR titles/labels as you go, so cutting a release is a one-click action instead of an afternoon.

name: Release
on:
  push:
    tags: ['v*']

jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v4
      - run: |
          gh release create "${{ github.ref_name }}" \
            --title "Release ${{ github.ref_name }}" \
            --generate-notes
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

--generate-notes is a built-in GitHub CLI feature now — no third-party action required for basic changelog generation from PR history.

7. Infrastructure as Code: Plan on PR, Apply on Merge

The pattern that matters here isn't "run Terraform in CI" — it's separating plan and apply so reviewers can see exactly what infrastructure change they're approving before it happens.

name: Terraform
on:
  pull_request:
  push:
    branches: [main]

jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init
      - run: terraform plan -out=tfplan
      - if: github.event_name == 'pull_request'
        run: terraform show -no-color tfplan
      - if: github.ref == 'refs/heads/main' && github.event_name == 'push'
        run: terraform apply -auto-approve tfplan

Applying from a saved plan (tfplan) rather than re-running terraform apply blind is the difference between "what you reviewed is what got applied" and "what got applied is whatever the state drifted to by the time the apply job ran."

8. Code Coverage Enforcement, Not Just Reporting

Uploading a coverage report is easy. Making coverage regressions actually block a merge is where the value is.

name: Coverage
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run coverage
      - uses: codecov/codecov-action@v4
        with:
          token: ${{ secrets.CODECOV_TOKEN }}
          fail_ci_if_error: true

Pair this with Codecov's (or Coveralls') PR-comment integration and a minimum-coverage-delta rule in your repo settings — the report alone changes nothing unless someone's forced to look at it.

9. Scheduled Database Migration Checks

Rather than blindly running migrations on every deploy (risky), a safer pattern is validating that migrations apply cleanly against a fresh database snapshot as part of CI — catching migration bugs before they hit staging.

name: Migration Check
on: pull_request

jobs:
  migrate-check:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: postgres
        ports: ['5432:5432']
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run migrate
        env:
          DATABASE_URL: postgres://postgres:postgres@localhost:5432/postgres

Using a services: container instead of a separately provisioned test DB keeps this fast and fully isolated — every run gets a clean Postgres instance.

10. Scheduled Backups With Verified Upload

Cron-triggered workflows are underused for anything beyond stale-issue bots. Scheduled backups with a verified upload step are a good example of "boring automation" that actually matters when you need it.

name: Nightly Backup
on:
  schedule:
    - cron: '0 2 * * *'

jobs:
  backup:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./backup.sh
      - uses: google-github-actions/upload-cloud-storage@v2
        with:
          path: backups/
          destination: my-backup-bucket/${{ github.run_id }}

Tag uploads with github.run_id (as above) so every backup run is traceable back to exactly which workflow execution produced it — invaluable when you're debugging "which backup is this."

11. Slack Notifications Scoped to Signal, Not Noise

Notifying on every PR event trains people to ignore the channel within a week. Scope notifications to events that actually need a human's attention — failed deploys, merged-to-main, security audit failures.

name: Notify on Deploy Failure
on:
  workflow_run:
    workflows: ['CI/CD Pipeline']
    types: [completed]

jobs:
  notify:
    if: github.event.workflow_run.conclusion == 'failure'
    runs-on: ubuntu-latest
    steps:
      - uses: slackapi/slack-github-action@v1.27.0
        with:
          channel-id: 'deploys'
          slack-message: '🚨 Deploy failed on main — check the workflow run.'
        env:
          SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}

Using workflow_run with a conclusion == 'failure' filter, rather than hooking every pull_request event, is what keeps this useful instead of becoming background noise.

12. Project Board Sync

Auto-adding new issues to a project board removes the "someone forgot to triage this" failure mode entirely.

name: Add to Project Board
on:
  issues:
    types: [opened]

jobs:
  add-to-project:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/add-to-project@v1.0.2
        with:
          project-url: https://github.com/orgs/your-org/projects/1
          github-token: ${{ secrets.PROJECT_TOKEN }}

Note this needs a token with project scope — the default GITHUB_TOKEN won't have permission to write to org-level Projects, which trips people up the first time they try this.

The So-What

None of these individually are groundbreaking — that's the point. The value compounds when you stack several of them: gated CI/CD, auto-merged safe dependency bumps, enforced coverage, and scoped notifications together mean your team stops doing manual toil and starts only getting pulled in when something actually needs a human decision.

A few general principles that apply across all of the above:

Prefer built-in tooling over third-party actions when it exists (gh release create --generate-notes over a dedicated release-notes action, for example) — fewer external dependencies in your CI supply chain.
Pin action versions, and update them — several widely-copied examples floating around still reference actions/checkout@v2 and setup-node@v1, both several major versions behind and missing performance/security improvements.
Gate, don't just report. A check that runs but doesn't block anything is documentation, not automation.

Discussion: What's the automation in your GitHub Actions setup that's saved you the most real time — and on the flip side, what's the one you set up that turned out to be more noise than signal? Curious what patterns people have actually kept versus ripped out after a few months.

The Fallback Password: Dissecting the Tenda Router Backdoor (CVE-2026-11405)

Amayo Clinton — Sun, 19 Jul 2026 18:20:54 +0000

If you've ever reviewed authentication code and felt a little itch when you saw an if (authFailed) { tryAnotherWay() } branch — congratulations, your instincts are correct. That exact pattern is at the center of a newly disclosed backdoor affecting multiple Tenda router models, and it's a great case study in how not to design an auth flow.

Let's break down what's actually happening in the firmware, why it matters beyond "yet another router CVE," and how you'd go looking for something like this yourself.

The TL;DR

CERT/CC (Carnegie Mellon's Software Engineering Institute) published VU#213560 / CVE-2026-11405 on July 6, 2026, describing an undocumented authentication bypass in the /bin/httpd binary shipped on several Tenda router firmware builds:

US_FH1201V1.0BR_V1.2.0.14(408)_EN_TD
US_W15EV1.0br_V15.11.0.5(1068_1567_841)_EN_TDE
US_AC10V1.0re_V15.03.06.46_multi_TDE01
US_AC5V1.0RTL_V15.03.06.48_multi_TDE01
US_AC6V2.0RTL_V15.03.06.51_multi_T

No patch is available. CERT/CC says it notified Tenda privately on May 19, 2026, and got silence for seven weeks before disclosing publicly. Tenda has a documented history of not responding to vulnerability reports going back to 2013.

The Actual Vulnerable Logic

Reconstructing the flow described in the advisory, the login() function in /bin/httpd looks roughly like this:

// Pseudocode reconstruction based on CERT/CC's description
int login(char *username, char *password) {
    // Primary path: standard MD5-hashed credential check
    char *stored_hash = get_stored_password_hash(username);
    char *submitted_hash = md5(password); // via check_rand_key / PasswordToMd5

    if (submitted_hash == stored_hash) {
        return grant_session(username, ROLE_ADMIN);
    }

    // --- This is the backdoor ---
    // Fallback path: only reached when normal auth fails
    char *backdoor_password = GetValue("sys.rzadmin.password");

    if (strcmp(password, backdoor_password) == 0) {
        // Note: username is NEVER checked here
        return grant_session("rzadmin", ROLE_ADMIN); // role=2
    }

    return AUTH_FAILED;
}

A few things jump out immediately if you're reading this as a developer:

1. It's not a hardcoded credential — it's a fallback credential

Most classic router backdoors (Zyxel's zyfwp, Fortinet's SSH backdoor from 2019, various D-Link/ASUS incidents) work by embedding a static, hardcoded username/password pair that's compiled into the binary or listed in /etc/passwd. You can find those with a simple strings pass or a known-credential wordlist.

This one's architecturally sneakier: the backdoor password isn't hardcoded in plaintext in the binary — it's read at runtime from a config key (sys.rzadmin.password) via GetValue(). That means:

It could theoretically be different per device/batch if that config value is set during manufacturing/provisioning
It's harder to spot via static binary analysis alone — you need to trace the GetValue() call and understand where that NVRAM/config key gets populated
It smells like a leftover engineering/support mechanism (remote diagnostics, QA testing) rather than a "let's plant a backdoor" decision — though intent doesn't really matter once it's shipped in production firmware

2. Two authentication failures stacked on top of each other

It's worth noting MD5 for password verification is already considered broken for anything security-sensitive — it's fast to brute-force and has known collision weaknesses. So even before you get to the backdoor, the "legitimate" auth path is using deprecated crypto. The backdoor is really a second, more severe failure layered on top of a first one.

3. No username validation = every account is the admin account

This is the detail that pushes this from "bad" to "critical." Because strcmp() only checks the password against the backdoor value and never validates username, you don't need to know a valid admin username. admin, root, asdf, empty string — doesn't matter. If you have the backdoor password, you're in with role=2 (root-equivalent access to the web management daemon).

Where This Sits in the CVSS/Exploitability Landscape

If you triage CVEs for a living, this one checks every box for "fix now, ask questions later":

Attack vector: Network (no local/physical access needed if remote management is exposed)
Privileges required: None
User interaction: None
Authentication bypass: Complete — this is the authentication mechanism failing open
Impact: Full administrative control — config changes, DNS/routing manipulation, disabling security features, pivoting into the LAN

The only mitigating factor right now is that no public PoC or confirmed active exploitation has been reported as of this writing. That window won't stay open long — once someone extracts the exact backdoor password (or the algorithm that derives it) from firmware, this becomes a mass-scannable vulnerability.

How You'd Actually Find Something Like This

If you want to understand the discovery process (or audit your own embedded/IoT firmware for similar issues), the general workflow researchers use looks like:

# 1. Extract the firmware filesystem
binwalk -e firmware_image.bin

# 2. Locate the web server binary
find . -name "httpd"

# 3. Pull printable strings, looking for suspicious config keys
strings ./bin/httpd | grep -iE "password|admin|rzadmin|backdoor"

# 4. Disassemble around the login() function
# (Ghidra or IDA Free work well for MIPS/ARM router binaries)
# Look for comparison logic that runs *after* a failed primary auth check —
# especially calls to GetValue()/NVRAM-style config getters followed by
# strcmp()/memcmp() rather than a hashed comparison

The giveaway pattern to grep for in disassembly: a hash-based comparison (md5, sha) followed conditionally by a plaintext strcmp() against a runtime-fetched value. Legitimate fallback/recovery auth (e.g., factory reset flows) usually requires a physical trigger (button press, serial console) — not a remote HTTP request.

Detection If You're Running Fleets of These Devices

If you manage a bunch of Tenda hardware (MSPs, this means you), here's a rough network-level check while waiting on a patch:

# Confirm whether remote/WAN management is exposed at all —
# this is your actual blast-radius question
nmap -p 80,443,8080 <router-ip>

# If reachable, check for the login endpoint and response behavior
curl -s -o /dev/null -w "%{http_code}\n" http://<router-ip>/login.cgi

You can't test for the specific backdoor password without it being disclosed (responsible security practice, and also nobody's published a PoC), but you can and should verify whether the management interface is internet-facing at all. That single control point — WAN-facing admin panel, yes/no — determines whether this bug is "theoretical" or "actively scannable" for your deployment.

Mitigations (Until Tenda Ships a Fix, If Ever)

CERT/CC's guidance, plus some practical additions:

Disable remote/WAN web management — this is the single highest-leverage fix. It doesn't close the backdoor, but it removes it from the internet-facing attack surface.
Change the default LAN IP range — reduces opportunistic discovery by automated scanners hunting default 192.168.x.1-style ranges. Doesn't stop targeted attackers.
Segment IoT/consumer hardware onto its own VLAN — if this router is sitting in a business environment, don't let it share a broadcast domain with anything sensitive.
Treat "no vendor response since 2013" as a procurement signal — Tenda's disclosure history (2013, 2020, 2021, 2022, now 2026) is itself a data point worth weighing against price when selecting network hardware for anything beyond disposable home use.

So What? (The Actionable Bit)

If you're building or reviewing embedded auth code, the concrete lesson here isn't "don't use backdoors" — nobody's shipping this intentionally as a "feature" in the marketing sense. It's:

Any fallback authentication path is a second attack surface. If you have a "primary check fails, try secondary check" pattern anywhere in your auth flow — for support tooling, factory testing, recovery — that secondary path needs the same scrutiny (and ideally the same removal-before-shipping discipline) as the primary one.
Config-driven secrets aren't automatically safer than hardcoded ones. They're harder to spot via static strings analysis, sure — but that's a detection problem, not a security improvement. If anything, it makes audits harder without making the underlying risk smaller.
Username validation isn't optional, ever, even in a fallback/debug path. "Any username + secret password = admin" is a strictly worse design than "specific username + secret password," and it costs nothing to enforce.

If you've got Tenda hardware anywhere in your stack — home lab, MSP client site, that one office router nobody's touched since 2022 — this is worth 10 minutes today to check exposure, even without a patch to apply.

Have you found similar "fallback auth" patterns during firmware audits or code reviews — intentional debug backdoors that just never got stripped before shipping? Where do you draw the line between "reasonable engineering shortcut" and "should never have existed in production"? Curious how other embedded/security folks think about auditing this class of bug systematically rather than one CVE at a time.

Git Mastery

Amayo Clinton — Mon, 13 Jul 2026 20:37:47 +0000

If you think you know Git because you can add, commit, and push, try this: build a single hello.sh script through every core Git concept — commits, history rewriting, tagging, branching, conflicts, rebasing, bare repos — and document every command as you go.

That's exactly what this Git project puts you through. It's deceptively simple on paper ("just print Hello World") and brutally thorough underneath. Here's the walkthrough, built from my actual terminal output and commit history.

The Setup

git config --global user.name "devuser"
git config --global user.email "devuser@example.com"

mkdir -p work/hello && cd work/hello
git init

Nothing fancy — just a repo and a script:

echo "Hello, World" > hello.sh
git add hello.sh
git commit -m "feat: add initial hello world script"

That first commit (d03dea2) is the root of everything that follows.

Building History On Purpose

The project pushes you to think about commits as units of meaning, not just checkpoints. When I added a shebang and comments to hello.sh, I didn't just commit the whole diff — I split it:

git add -p hello.sh
git commit -m "docs: add default value comment"
# commit: 7fd0362

git add hello.sh
git commit -m "refactor: use variable with default fallback"
# commit: a53609a

git add -p is the star here — it lets you stage parts of a file's changes, so a single edit to hello.sh becomes two logically separate commits instead of one messy one.

Reading history the useful way

Plain git log is fine, but for real work you want condensed, filtered, custom views:

git log --oneline          # condensed
git log -2                 # last 2 entries
git log --since="5 minutes ago"   # time-scoped

And a genuinely useful personalized format:

git log --pretty=format:"* %h %ad | %s%d [%an]" --date=short

* d0dd395 2026-04-23 | docs: restore README and move documentation to README_REPORT.md (HEAD -> main, origin/main, origin/HEAD) [devuser]
* 7d6d6db 2026-04-22 | docs: add complete project documentation with hashes [devuser]
* 0a72da5 2026-04-22 | docs: update README for shared repo [devuser]
* 237cb11 2026-04-22 | docs: add comment to Makefile (origin/greet) [devuser]
* a53609a 2026-04-21 | refactor: use variable with default fallback (tag: v1) [devuser]
* 7fd0362 2026-04-21 | docs: add default value comment (tag: v1-beta) [devuser]
* d03dea2 2026-04-21 | feat: add initial hello world script [devuser]

One line, all the context you need: hash, date, message, refs, author.

Time Travel: Checkout, Tags, and Not Losing Your Mind

Restoring old snapshots is where git checkout <hash> earns its keep:

git checkout d03dea2
cat hello.sh
# echo "Hello, World"

git checkout 7fd0362
cat hello.sh
# #!/bin/bash
# # Default is "World"
# echo "Hello, $1"

git checkout master   # back to the tip, no hash memorized

Tags turn "that one commit" into a name you'll actually remember:

git tag v1                  # tags a53609a — current version
git tag v1-beta HEAD~1       # tags 7fd0362 — one commit back, no hash needed

git tag
# v1
# v1-beta

Jumping between v1 and v1-beta is just git checkout <tagname> — tags behave like read-only bookmarks into history.

Changing Your Mind (Repeatedly)

This section of the project is really about the difference between unstaged, staged, and committed — and the different tool for undoing each:

git restore hello.sh              # discard unstaged edits
git restore --staged hello.sh     # unstage (keep the edits)
git revert HEAD --no-edit         # undo a commit by creating a new one

Then it gets fun: tag a commit, reset past it, and prove the "deleted" commit still exists until Git actually garbage-collects it.

git tag oops              # tags 1cff52e
git reset --hard v1       # HEAD now back at a53609a

git log --all --oneline
# 1cff52e is STILL visible — reset doesn't delete objects, it just moves refs

To actually make it disappear:

git reflog expire --expire=now --all
git gc --prune=now

This is the moment the project really teaches you something most tutorials skip: git reset doesn't delete data, it just moves pointers. Nothing is gone until the reflog expires and garbage collection runs.

One more subtlety — fixing a mistake without creating a new commit:

# forgot the author email — fix the file, then fold it into the last commit
git add hello.sh
git commit --amend --no-edit

--amend rewrites the last commit in place instead of adding a new one. Great for local fixes, dangerous on anything already pushed and shared.

Reorganizing the Project

mkdir lib
git mv hello.sh lib/hello.sh
git commit -m "chore: move hello.sh into lib/ directory"

git mv does the mv and the git add in one step — Git tracks it as a rename, not a delete+add, as long as the content is similar enough.

Going Under the Hood: Blobs, Trees, Commits

This is the part that actually explains why Git is fast and safe: everything is content-addressed.

git cat-file -t 0a72da543f
# commit

git cat-file -p 0a72da543f
# tree   74c47aeda48e094725bd8ae1d62adbbc88997e1b
# parent 980a0b51b84a5305bffdfbacd1f266bd8e9fa3a3
# author devuser <devuser@example.com>
# docs: update README for shared repo

A commit object is just a pointer to a tree (a snapshot of the directory) plus a parent (the previous commit) plus metadata. Walk the tree:

git ls-tree HEAD
# 100644 blob 12d4ffb...  Makefile
# 100644 blob 0791b4b...  README.md
# 040000 tree b47b7e2...  lib

git ls-tree HEAD lib/
# 100644 blob 2d14ca5...  lib/greeter.sh
# 100644 blob c282d10...  lib/hello.sh

git cat-file -p c282d107dea0aa9909c27c291de8a83182847034
# (raw content of lib/hello.sh)

Every version of every file ever committed lives in .git/objects/ as a blob, addressed by the SHA-1 hash of its content. HEAD just points at a branch ref, which points at a commit, which points at a tree, which points at blobs. That's the whole model.

Branching Without Fear

git switch -c greet

I built out a Greeter function on its own branch, isolated from master:

git add lib/greeter.sh
git commit -m "feat: add Greeter function in lib/greeter.sh"
# 0f958cb

git add lib/hello.sh
git commit -m "refactor: use Greeter function in hello.sh"

git add Makefile
git commit -m "docs: add comment to Makefile"
# 237cb11

And diffed the two branches directly, file by file:

git diff master greet -- Makefile
git diff master greet -- lib/hello.sh
git diff master greet -- lib/greeter.sh

The resulting graph, right before merging things back together:

* 237cb11 (origin/greet) docs: add comment to Makefile
* 0f958cb feat: add Greeter function in lib/greeter.sh
* ef6052e feat: add interactive name prompt in hello.sh
* 7ee3abd docs: add README
* 45087c6 chore: add Makefile with run target
* 90ca44f chore: move hello.sh into lib/ directory
* 1a2643c docs: add author comment
| * 1cff52e (tag: oops) chore unwanted change to be removed
| * 7fd9565 Revert "chore: add unwanted committed change"
| * fb95a77 chore: add unwanted committed change
|/
* a53609a (tag: v1) refactor: use variable with default fallback
* 7fd0362 (tag: v1-beta) docs: add default value comment
* 9562a00 feat: add shebang and accept name argument
* d03dea2 feat: add initial hello world script

You can actually see the oops line branching off and rejoining — a nice visual proof that reset didn't destroy anything, it just left that commit orphaned until GC swept it.

The Main Event: Conflicts and Rebasing

This is where the project stops being polite. First, a clean merge:

git switch greet
git merge master

Then I changed hello.sh on master itself:

git switch master
git add lib/hello.sh
git commit -m "feat: add interactive name prompt in hello.sh"
# ef6052e

Now merge master into greet again — except this time both branches touched the same lines:

git switch greet
git merge master
# CONFLICT (content): Merge conflict in lib/hello.sh

Resolving it by hand:

nano lib/hello.sh   # remove conflict markers, keep master's version
git add lib/hello.sh
git commit -m "fix: resolve merge conflict accepting master version"

Then: undo the merge and rebase instead

The project wants you to compare merging vs. rebasing on the same divergent history, so I rewound using the reflog and rebased instead:

git reset --hard ee0c23f   # pre-merge state, found via git reflog
git switch greet
git rebase master
# conflict again — resolve, then:
git add lib/hello.sh
git rebase --continue

Finally, merging greet back into master was a clean fast-forward — no merge commit at all:

git switch master
git merge greet
# Fast-forward

Fast-forward vs. merge vs. rebase, the short version:

Fast-forward: master had no new commits since greet branched off, so Git just slides the master pointer forward to match greet. No new commit, history stays linear.
Merge: both branches have unique commits, so Git creates a new commit with two parents, preserving exactly what happened and when. Honest history, but the graph gets messy.
Rebase: replays your branch's commits one by one on top of the new base, producing a straight line as if you'd branched off now instead of earlier. Clean history, but it rewrites commit hashes — never do this on a branch someone else is also working from.

Local, Remote, and Bare Repositories

Cloning is just copying the whole object database plus setting up a remote automatically:

git clone hello cloned_hello
cd cloned_hello

git remote -v
# origin  /home/devuser/Desktop/work/hello (fetch)
# origin  /home/devuser/Desktop/work/hello (push)

git branch -a
# * master
#   remotes/origin/HEAD -> origin/master
#   remotes/origin/greet
#   remotes/origin/master

Fetch pulls down remote history without touching your working files; merge (or pull, which is both at once) actually integrates it:

git fetch
git merge origin/master
# equivalent to:
git pull

Tracking a remote-only branch locally:

git branch --track greet origin/greet

And pushing to an actual server:

git remote add origin https://git.example.com/devuser/hello.git
git push origin master
git push origin greet

Bare repositories

A bare repo has no working directory — just the raw .git internals sitting at the top level. You never edit files in it directly; it exists purely as a shared exchange point that other repos push to and pull from. This is literally what GitHub, GitLab, and Gitea run on the server side.

git clone --bare hello hello.git
ls hello.git
# branches config description HEAD hooks info objects packed-refs refs

git remote add shared ../hello.git
git add README.md
git commit -m "docs: update README for shared repo"
git push shared master

And pulling those shared changes into the other clone:

cd ~/Desktop/work/cloned_hello
git remote add shared ../hello.git
git pull shared master

git log --oneline
# 0a72da5 docs: update README for shared repo   <- now present here too

What Actually Stuck

The exercise that reframed the most for me was the oops tag / reset / reflog sequence. Before this project, git reset --hard felt like deleting things. Watching a "deleted" commit still show up in git log --all — and only really disappearing after reflog expire + gc --prune=now — made it click that Git almost never destroys data on its own. It just stops pointing at it.

Second was rebase vs. merge, done back to back on the identical conflict. Reading about the difference is one thing; hitting the same conflict twice, once resolved with a merge commit and once resolved by replaying commits, made the tradeoff concrete instead of theoretical.

If you're doing this project (or something like it): don't skip the .git/objects/ exploration section. It's the one part that explains why everything else in Git works the way it does.

Closing Thoughts
Git has a reputation for being something you memorize commands for rather than actually understand — git add ., git commit -m "fix", git push, repeat. This project forced the opposite approach: build small, break things on purpose, and dig into why each command does what it does before moving to the next one.
If there's one takeaway to carry forward, it's this — Git rarely deletes anything without you explicitly telling it to (and meaning it). Once that clicks, branching, resetting, and rebasing stop feeling dangerous and start feeling like tools you can actually reach for with confidence.
If you're working through something similar, don't rush the sections that feel "boring" (looking at you, blobs and trees) — that's usually where the real understanding is hiding.
Thanks for reading — feel free to drop questions or your own Git war stories in the comments. 🐙

Linux Permissions, Actually Explained (Not Just Memorized)

Amayo Clinton — Mon, 13 Jul 2026 20:13:33 +0000

If you've been using Linux for more than a week, you've typed chmod 755 or chmod 644 into a terminal without really knowing what those numbers meant. You copy-pasted it from Stack Overflow, it worked, and you moved on. Fair enough — most days, that's all you need.

But permissions show up everywhere: SSH key errors, deploy scripts that mysteriously fail, Docker volumes that refuse to be read, cron jobs that silently do nothing. At some point "I'll just chmod 777 it" stops being a joke and starts being a real security hole. So let's actually break this down — what the letters mean, what the numbers mean, and how they connect — so you're reasoning about permissions instead of guessing.

Who Permissions Apply To

Every file and directory on a Unix-like system has exactly three permission "classes" checked against it:

User — the account that owns the file
Group — a set of accounts assigned to the file
Other — literally everyone else on the system

That's it. There's no "admin" class, no per-user access control list in the base model — just owner, group, and the rest of the world. When the kernel decides whether you're allowed to read, write, or execute something, it checks which of these three buckets you fall into, in that order, and applies the matching permission set.

This is worth sitting with for a second, because it explains a lot of "why can't I access this file" confusion. If you're not the owner and you're not in the file's group, Linux doesn't care that you're a sudo-capable admin on the box — it applies the other permissions, full stop (unless you escalate privileges, which is a separate mechanism entirely).

Reading Symbolic Notation

Run ls -l in any directory and you'll see a string like -rwxr-xr-- sitting to the left of every filename. This is symbolic notation, and once you know the pattern, it reads like a sentence.

The very first character isn't a permission at all — it's the file type:

- regular file
d directory
l symbolic link
c character device
b block device

Everything after that comes in groups of three, one group per class, always in the order user, group, other. Each group has the same three-slot pattern: read, write, execute.

r — permission granted
w — permission granted
x — permission granted
- — permission not granted, in that slot

So -rwxr-xr-- breaks down as: a regular file, owned by a user who can read/write/execute it, a group that can read/execute it (but not write), and everyone else who can only read it.

One subtlety that trips people up: x on a directory doesn't mean "execute" in the programmatic sense — it means "you're allowed to cd into it or access files inside it by name." Read on a directory just lets you list its contents (ls). You genuinely need both r and x to browse a directory normally, which is why you'll often see rwxr-xr-x on folders instead of rw-r--r--.

Octal Notation and the Math Behind It

Symbolic notation is readable but verbose. Octal notation compresses the same information into up to four digits, and it's what you'll actually type most of the time with chmod.

The trick is that each permission has a fixed numeric weight:

r = 4
w = 2
x = 1

To get the digit for a class, you just add up whichever permissions are granted. rwx is 4+2+1 = 7. rw- is 4+2 = 6. r-x is 4+1 = 5. r-- is just 4. There's no ambiguity — every combination of read/write/execute maps to exactly one number from 0 to 7, because these are binary flags being summed, not arbitrary values.

Do this once for each of the three classes and you get a three-digit mode. rwxr-xr-- becomes 7 (user) 5 (group) 4 (other), or 754. That's genuinely the entire algorithm — there's no lookup table to memorize, just three additions.

A fourth, leading digit exists too (covered below), which is why you'll sometimes see four-digit modes like 0755 or 4755 — the leading 0 just means "no special bits set," and it's often omitted since chmod 755 and chmod 0755 do the same thing.

chmod in Practice

Once you can do the read/write/execute math in your head, chmod stops being a magic incantation. Here are the combinations you'll actually reach for on a day-to-day basis:

A few notes on judgment calls, not just syntax:

755 for anything executable — scripts, binaries you built, CLI tools. Owner gets full control, everyone else can run it and see it, nobody but you can modify it.
644 for regular files — source code, configs meant to be world-readable, static assets. Nobody but the owner should be writing to most files by default.
700 for anything private — your SSH ~/.ssh directory, personal scripts with credentials baked in. SSH will actually refuse to use a private key if its permissions are too open, which is one of the few places Linux enforces permission hygiene for you.
777 is a code smell, not a fix. If you're reaching for chmod 777 to make an error go away, you haven't found the actual permission problem — you've just removed the protection that would've told you what it was. It's fine on a disposable container for five minutes of debugging; it's not fine on anything that touches real data.

You can also skip octal entirely and use symbolic (relative) syntax, which is handy when you only want to change one thing without recalculating the whole mode:

chmod u+x deploy.sh      # add execute for the owner only
chmod g-w config.yml     # remove write from the group
chmod o=r notes.txt      # set other to read-only, exactly
chmod a+r README.md      # add read for everyone

u, g, o, a map to user, group, other, all — and +, -, = add, remove, or set exactly. This form doesn't require you to know the existing permissions, which makes it safer for quick, targeted changes on files you didn't set up yourself.

Add -R to any chmod command to apply it recursively to a directory and everything inside it — but be careful, because blanket-applying 755 recursively will also make every file executable, which is rarely what you want. For directory trees, it's usually safer to set directory and file permissions separately with find:

find . -type d -exec chmod 755 {} \;   # directories: 755
find . -type f -exec chmod 644 {} \;   # files: 644

The Fourth Digit: setuid, setgid, and the Sticky Bit

Beyond the standard nine permission bits, there's a fourth, less commonly used set that changes how execution or ownership behaves, rather than just who has access. These are the special permission bits, and they're where a leading digit like 4, 2, or 1 comes from in a four-digit octal mode.

setuid (4000) — when set on an executable, the program runs with the file owner's privileges, not the privileges of whoever launched it. The classic example is /usr/bin/passwd: it needs to write to /etc/shadow, which regular users can't touch directly, so it's owned by root and setuid'd — letting any user change their own password without being root themselves. In symbolic notation, this shows up as an s where the owner's execute bit would normally be: rwsr-xr-x.

setgid (2000) — similar idea, but for the group. On an executable, it runs with the file's group privileges instead of the group of whoever ran it. On a directory, it does something different and genuinely useful: any new file created inside inherits the directory's group automatically, instead of the creating user's default group. This is the standard trick for shared team directories where everyone needs files to end up in the same group without remembering to chgrp manually every time.

Sticky bit (1000) — almost exclusively used on directories. It restricts deletion: even if a user has write access to a directory (and could therefore normally delete or rename anything in it), the sticky bit means they can only delete or rename files they themselves own. /tmp is the textbook example — it's world-writable (777) so any process can drop temp files there, but the sticky bit stops one user from deleting another user's temp files. Symbolically it appears as t in the other-execute slot: rwxr-xr-t.

You combine these by adding their weights the same way you add r, w, x: a directory that's setgid and has permissions 755 becomes 2755. A world-writable sticky directory is 1777, which is exactly what /tmp uses in practice.

Ownership: chown and chgrp

Permissions decide what a class can do; ownership decides who's in the user and group classes in the first place. These usually travel together:

chown jarret file.txt          # change the owner
chgrp devs file.txt            # change the group
chown jarret:devs file.txt     # change both at once
chown -R jarret:devs project/  # recursively, for a whole directory tree

You generally need root (or sudo) to change ownership to another user, for obvious reasons — otherwise anyone could hand their files off to someone else to dodge disk quotas or audit trails.

Debugging Real Permission Errors

Knowing the theory is one thing — recognizing it in the wild is another. A few situations you'll run into constantly:

"Permission denied" when running a script you just wrote. Nine times out of ten, you forgot the execute bit. Creating a file with a text editor gives it 644 by default, which has no execute permission for anyone. chmod +x script.sh (shorthand for chmod a+x) fixes it without you needing to work out the full octal mode.

SSH refuses your private key with "UNPROTECTED PRIVATE KEY FILE". SSH deliberately checks that your private key isn't readable by group or other, because a key anyone on the system can read isn't really private. The fix is almost always chmod 600 ~/.ssh/id_rsa — owner read/write, nobody else anything.

A web server can't read files you just deployed. This is usually an ownership mismatch, not a permission mismatch — the files are owned by your deploy user, but the web server runs as www-data or nginx, which falls into the other class and may not have read access if the mode is something tight like 600. The fix is either loosening the mode to 644/755 for other, or better, putting both accounts in a shared group and using 640/750 with chgrp.

A cron job works when you run it manually but silently fails on schedule. Cron often runs as a different user (or with a stripped-down environment) than your interactive shell. If the script or the files it touches aren't readable/executable by whatever user cron runs as, it fails quietly with no terminal to show you the error — check /var/log/syslog or journalctl -u cron for the actual permission denial.

Docker volume mounted from the host has the wrong permissions inside the container. Containers frequently run processes as a different UID than your host user, even though the filesystem UID numbers are shared. A file that's 644 and owned by UID 1000 on your host might be unreadable to a container process running as UID 999. This one isn't solved by chmod alone — you typically need to align the UID the container runs as with the UID that owns the mounted files.

In every one of these cases, the fix falls out naturally once you ask the right question: which class (user/group/other) is the process actually running as, and does that class have the permission it needs? That's the entire debugging methodology — everything above is just that question applied to a specific tool.

Putting It Together

Permissions on Linux really come down to three ideas stacked on top of each other: three classes (user, group, other), three abilities per class (read, write, execute), and one compact way to write all nine bits as three digits by adding 4, 2, and 1. Everything else — setuid, setgid, sticky bits, symbolic shorthand — is a small extension on top of that same base logic, not a separate system to memorize.

Next time you type chmod 644 without thinking about it, you'll know exactly what those two digits are doing — and more importantly, you'll be able to work out the right number for a situation you haven't seen a Stack Overflow answer for yet.

That's the whole model — three classes, three abilities, one bit of addition, and a few special cases layered on top. If you've got a permissions war story of your own (a 777 you regret, a setgid trick that saved a shared directory, a Docker UID mismatch that took way too long to track down), drop it in the comments — I'd genuinely like to hear it.

And if this was useful, a follow or a ❤️ helps more people find it. Thanks for reading!

Beyond the Lone Cheetah: Architecture Patterns for Multi-Agent Prides in Real-World Ecosystems

Amayo Clinton — Tue, 07 Jul 2026 23:18:02 +0000

Most engineers treat large language models like erratic, omniscient interns. They throw loose, natural-language prose into an API endpoint, something vague like "screen these loan applications for risk," and then act surprised when the model hallucinates a Western corporate SaaS model, drifts past compliance rules, or reproduces demographic bias baked into its training data.

In emerging financial ecosystems across Africa, from Nairobi's tech corridor to Kampala's e-commerce networks, the cost of these engineering failures isn't theoretical. An automation layer that misreads a cash flow pattern doesn't just dent a vanity metric. It can lock legitimate users out of credit or misjudge liquidity in a community savings structure. So the practical response is to stop treating an LLM as a conversational oracle and start treating it as a component that speaks in token probabilities and needs the same boundaries you'd put around any other untrusted input source.

What follows are the patterns I've found useful for moving from isolated, fragile automations toward coordinated, auditable multi-agent systems.

Calibrating autonomy with a bounded-authority gate

When an agent executes real actions, like triggering a microfinance payment or sending a notification, unbounded execution power is an invitation to trouble. Take a simple failure case: a customer-service agent handling refunds with no hard limits. Without constraints, it can be talked into approving an invalid refund just because the input says something like "I'll escalate this on social media."

The fix is a layered gate that checks role scope first, then a hard authority ceiling, and routes anything outside those bounds to a human, with a kill switch that overrides everything else regardless of where in the flow it fires:

Incoming request
|
v
Role check (does this fall within the agent's defined scope?)
|
v
Authority check (is the value within the agent's approval ceiling?)
|
within bounds --> execute autonomously
outside bounds --> freeze and escalate to a human

In code, the kill switch is checked first, before role or authority, because it's a global override and should short-circuit everything else:

class LoanTriageAgent:
    def __init__(self, user_context):
        self.role = "Tier-1 Loan Triage Specialist"
        self.max_authority_limit = 15000  # KES approval ceiling
        self.user_context = user_context

    def evaluate(self, transaction_amount, risk_flags, user_input):
        if os.getenv("AGENT_SYSTEM_ACTIVE") == "FALSE":
            return {"action": "ESCALATE", "reason": "Kill switch triggered"}

        if transaction_amount > self.max_authority_limit:
            return {"action": "ESCALATE", "reason": "Exceeded authority ceiling"}

        if "debt collector" in user_input.lower() or self.user_context.get("children_under_5", 0) >= 2:
            return {"action": "ESCALATE", "reason": "Vulnerable-demographic flag"}

        if len(risk_flags) >= 3:
            return {"action": "DENY", "reason": "Multiple concurrent risk flags"}

        return {"action": "APPROVE_AUTONOMOUSLY"}

The point isn't the specific thresholds, it's that the ceiling and the escalation path are explicit, testable, and sit outside the model's own judgment.

Auditing for bias before deployment

Models inherit the historical patterns in their training data, and in micro-lending or savings-cooperative contexts that can show up as a systematic gap between how the model treats informal-sector applicants (market vendors, seasonal traders) versus formally employed ones with comparable repayment capacity, simply because the training corpus underrepresents informal income patterns like agricultural liquidity cycles.

Before shipping a model into that kind of decision path, it's worth running it through a structured bias check rather than eyeballing a handful of outputs:

Check the balance of formal-versus-informal-sector examples in the training or fine-tuning data.
Confirm the model has explicit vocabulary for informal work (a market trader or a cooperative member shouldn't be an out-of-distribution case).
Track approval-rate disparities across applicant segments on a rolling basis in production.
Run counterfactual swaps: hold cash flow constant, change only the sector label, and see if the output changes.
Set a hard threshold, for example, a fallback to manual review if the disparity between segments crosses a defined limit.

Wiring this kind of check into CI, rather than treating fairness as a one-time review, is what turns it from an aspiration into something you can actually catch in a pull request.

Coordinating state across a chain of agents

Multi-agent systems fail quietly when each agent works in isolation and drops context between steps. A three-agent pipeline, a Scout that handles the initial conversation, a Guardian that scores risk, and a Reviewer that packages the case for a human, only works if all three share a single state contract rather than passing loosely-typed messages between themselves.

Scout agent (intake) --> Guardian agent (risk scoring) --> Reviewer agent (human handoff)
\ /
shared context: balances, harvest windows, applicant metadata

Concretely: the Scout agent picks up an unstructured message like "no money for school fees right now" and converts it into a structured handoff:

{
  "handoff_event": "FINANCIAL_STRESS_SIGNAL",
  "payload": {
    "child_age_metrics": [6, 9, 14],
    "target_district": "Kakamega",
    "next_harvest_window": "October/November"
  }
}

The Guardian agent takes that payload and scores it against seasonal repayment capacity rather than a static monthly-income model, since income variance tied to a harvest window is a very different risk shape than a salaried applicant's would be. If the resulting score lands in a mid-confidence band, it attaches context flags and passes the case along rather than deciding alone.

The Reviewer agent doesn't have write access to the ledger. Its only job is to turn the shared state into a short brief a human can act on quickly, something like: applicant is a maize farmer in Kakamega with income peaking in October and November, has three school-age children, is requesting funds for fees, has no active risk flags, and the system's suggestion is to match repayment to the November harvest and note her as a candidate for drought-index insurance.

That last step matters as much as the scoring: a human should be able to approve or reject the case from that brief alone, without digging back through the raw conversation.

Closing the loop with production telemetry

Static agent configurations degrade as real-world conditions shift, so it's worth building a lightweight feedback loop that watches production metrics and proposes, rather than silently applies, adjustments:

async def review_weekly_telemetry(logs):
    csat = logs.extract_metric("CSAT")
    escalations = logs.extract_metric("escalation_count")

    if csat < 0.80:
        proposal = {
            "component": "scout_agent",
            "change": "Adjust term-start calendar handling",
            "reasoning": "CSAT dropped among a specific cohort; investigate calendar misalignment.",
        }
        await send_for_human_approval("#prod-ops-approvals", proposal)
        return "Optimization proposal generated and sent for review."

Note the phrasing here is intentionally cautious: without a labeled comparison group, "CSAT dropped among rural users because of long rains" is a hypothesis to investigate, not a conclusion to log as fact. The loop's job is to surface the anomaly and route it to a person, not to auto-diagnose the cause.

The underlying principle

None of this is about clever prose engineering. It's regular software engineering applied to a component that happens to be probabilistic: bound its authority explicitly, test it for bias the same way you'd test for a regression, give agents in a pipeline a single shared contract instead of ad hoc handoffs, and treat any proposed change to production behavior as something a human signs off on, not something the system does to itself quietly.

How are you handling authority limits and state handoffs in your own agent pipelines? I'd like to hear what's worked and what hasn't.

The AUR Supply Chain Attack: When Trust Becomes the Vulnerability

Amayo Clinton — Thu, 18 Jun 2026 07:02:46 +0000

This Month, the Arch Linux community discovered that more than four hundred packages in the Arch User Repository had been quietly hijacked. The attackers did not exploit a bug in any software. They exploited something harder to patch: the trust that builds up around a package's name and history.

What happened

The Arch User Repository, commonly known as the AUR, is a community driven collection of build scripts maintained separately from Arch's official repositories. Anyone can adopt an abandoned package whose original maintainer has stopped updating it. That openness is exactly what this campaign relied on.

Researchers at Sonatype, who named the operation Atomic Arch, found that attackers were systematically adopting orphaned AUR packages, the ones whose maintainers had simply walked away. Once in control, they edited the PKGBUILD or install scripts to quietly run a command during the build process: npm install atomic-lockfile. That single line pulled in a malicious npm package alongside a couple of legitimate ones included for cover. The npm package carried a preinstall hook that dropped a bundled Linux binary named deps, and simply building the AUR package was enough to trigger it.

To make the changes look legitimate, the attackers also spoofed git commit metadata so it appeared the edits came from a long standing maintainer. An Arch Linux Trusted User later confirmed that maintainer's account had never actually been compromised. The packages kept their familiar names and commit histories. Only the build instructions underneath had changed.

What the malware actually does

Independent researcher Whanos reverse engineered the deps payload and identified it as a Rust based credential stealer built for developer machines and build systems. Once running, it can pull cookies, session tokens, and local storage from Chromium based browsers including Chrome, Edge, and Brave. It also lifts session data from Electron apps such as Slack, Discord, and Microsoft Teams. On top of that it harvests GitHub, npm, and HashiCorp Vault tokens, OpenAI and ChatGPT bearer credentials, SSH keys and known hosts files, shell history, Docker and Podman credentials, and VPN profiles.

The stolen data is exfiltrated over HTTP to the file sharing service temp.sh, while command and control traffic runs through a Tor onion service via a local loopback proxy. For persistence, the malware installs a systemd service set to restart automatically. If it landed with root access, it copies itself into /var/lib/ and installs a system level unit. Without root, it falls back to the user's home directory and a per user systemd unit.

There is also an optional eBPF rootkit component, though early reporting overstated its role. It does not grant any privilege escalation and only activates if the binary already has root and the right capability. When it does load, it uses pinned BPF maps to hide the malware's processes, names, and socket inodes from standard monitoring tools, and it actively blocks debugger attachment. A second, unanalyzed binary tied to a fake monero wallet GUI package was also found staged alongside the stealer, suspected to be a cryptominer.

This combination matters for remediation. A package manager can remove the files it installed, but it cannot prove a machine is clean once a rootkit capable payload has had the chance to run.

Scope and a second wave

Sonatype's initial report counted just over twenty compromised packages. Within a day, community trackers and the Arch mailing list had cataloged more than four hundred, with one list built by scanning the AUR git mirror directly landing around four hundred and eight, and later consolidated counts climbing even higher. Notably, the malicious atomic-lockfile npm package itself had only around one hundred and thirty four weekly downloads before it was pulled from the registry, meaning the AUR build process, not direct npm installation, was the real distribution channel.

A second, separate wave surfaced using the command bun install js-digest, traced to a different set of npm accounts that community researchers link to the same publisher behind atomic-lockfile. Its payload is a distinct binary by hash, also confirmed malicious. The full extent of this second wave is still being measured, since grep based searches of the AUR mirror return different totals depending on how much commit churn is included, but it is not a minor footnote to the first wave. Anyone checking their system should look for both atomic-lockfile and js-digest.

What to do if you use the AUR

Arch maintainers are resetting the malicious commits and banning the implicated accounts, and they are asking the community to keep reporting suspicious packages through the mailing list thread. For anyone who has built or updated an AUR package since June 11, the published list of affected packages should be treated as incomplete rather than authoritative.

Practical steps worth taking include checking recently built or updated AUR packages against community maintained detection lists and scripts, and searching build history and caches for references to npm install atomic-lockfile, bun install js-digest, or the payload path src/hooks/deps. If any flagged package was built on your system, the safest assumption is that the host is credential compromised. That means rotating browser sessions, SSH keys, GitHub and npm tokens, Slack, Teams, and Discord sessions, Vault tokens, Docker and Podman credentials, and any cloud access keys.

It is also worth hunting for persistence mechanisms directly, including unrecognized systemd services both at the system level and under a user's own systemd config directory, unexpected files under /var/lib/, and the presence of pinned BPF maps named hidden_pids, hidden_names, and hidden_inodes under /sys/fs/bpf/. Reviewing outbound network connections for Tor traffic or uploads to temp.sh is another useful signal. If a compromised package was built as root, the recommendation is to treat the rootkit as present and reinstall the system from trusted media, since there is no reliable way to confirm a clean state otherwise.

For detection purposes, the primary payload's SHA two fifty six hash is 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b, and a fuller set of indicators, including the onion command and control address, has been published in the ioctl.fail writeup.

The bigger lesson

This is not the first time an abandoned package has been weaponized this way. A similar tactic was used against an abandoned PDF viewer package back in 2018. What makes the 2026 version notable is the scale and the layered payload, combining credential theft with an optional kernel level hiding mechanism rather than relying on typosquatting or tricking users into installing the wrong thing entirely.

Sonatype is tracking the campaign as Sonatype 2026 003775 with a CVSS score of 8.7, though no CVE has been assigned since this is fundamentally a trust and process failure rather than a software vulnerability. The real takeaway for anyone using community package repositories is that a name and a commit history are not proof of safety. A package that has recently changed hands, or one that has suddenly become active again after long dormancy, deserves the same scrutiny you would give to software from a complete stranger. Reading the PKGBUILD and any install hooks before building is no longer optional diligence. It is the only line of defense the trust model has left.

When AI Gets It Wrong: The Hidden Security Risk of Hallucinations in Cybersecurity

Amayo Clinton — Sun, 17 May 2026 13:18:42 +0000

AI systems are getting better at detecting threats — but what happens when they confidently give you the wrong answer?

Cover image suggestion: A glitching neural network visualization or a cracked padlock with circuit board texture.

AI is rapidly being embedded into security operations — threat detection, incident response, log analysis, vulnerability triage. The efficiency gains are real. But there's a category of risk that doesn't get nearly enough attention: AI hallucination, and specifically what happens when it occurs inside a security context.

This isn't a hypothetical. It's a pattern already emerging in production environments, and the consequences can range from alert fatigue to catastrophic data loss

What Is AI Hallucination in a Security Context?

AI hallucination refers to when a model generates outputs that are confident, fluent, and factually wrong. Unlike a crash or an obvious error, hallucinations look correct. The model doesn't flag uncertainty — it just answers.

In low-stakes contexts (drafting an email, summarizing a document), a hallucination is annoying. In a security context, it can be catastrophic.

Here's why that matters: security teams are trained to trust their tooling. When a SIEM or AI-assisted SOC platform flags an alert, analysts act on it. When an AI recommends a remediation step, engineers often execute it. The trust relationship that makes AI useful in security operations is the same relationship that makes hallucinations so dangerous there.

Three Ways AI Hallucinations Become Security Incidents

False Positives That Erode Trust

When an AI system repeatedly generates false positive alerts — flagging benign behavior as malicious — teams naturally adapt. They begin treating alerts with suspicion. They start skipping review steps. Over time, the entire alerting pipeline loses credibility.

This is the alert fatigue problem at scale. And the insidious part is that it doesn't require the AI to fail dramatically. It just needs to be wrong often enough that humans stop believing it — at which point a real threat will look exactly like every other false alarm.

False Negatives That Create Blind Spots

The flip side is equally dangerous. AI systems trained on historical threat data can fail to recognize novel attack patterns — zero-days, new malware families, unusual lateral movement techniques. A model that has never seen a particular attack vector may simply not flag it.

The problem is amplified when teams have calibrated their response processes around AI-assisted triage. If the AI doesn't raise an alert, the threat may never receive human attention at all.

Incorrect Remediation Guidance

This is arguably the most dangerous failure mode, because it happens after trust has already been established.

Imagine: an AI correctly identifies a threat. The analyst trusts it. They then ask the AI what to do about it — and the AI confidently recommends deleting sensitive files, modifying critical system configurations, or disabling firewall rules.

If those actions are executed — especially via privileged accounts — the result can be:

Identity-based attack exposure from weakened access controls
Lateral movement enabled by disabled network segmentation
Irreversible data loss from confident-sounding but incorrect deletion commands

The attack surface doesn't just remain open. It widens. And the team may not realize the AI was wrong until the damage is already done.

Why This Keeps Happening

AI hallucinations in security contexts aren't a single-cause problem. They emerge from a combination of factors:

Training data quality. Models learn from historical data. If that data contains outdated threat signatures, biased datasets, or inaccurate records, those flaws surface in the model's outputs. As AI-generated content becomes more prevalent online, there's a growing risk of future models being trained on content produced by earlier hallucinating models — a compounding phenomenon sometimes called model collapse.

Prompt quality. Vague inputs give models more room to fill gaps with assumptions. A security analyst asking "what should I do about this?" gets a very different (and often less reliable) output than one asking "given this specific log output and these network conditions, what are three targeted remediation steps with rollback options?"

Over-trust in model confidence. AI models produce confident-sounding outputs regardless of accuracy. There's no built-in signal for "I'm not sure about this." Teams that don't build human review into their workflows have no circuit breaker.

What Teams Can Actually Do About It

These risks aren't reasons to avoid AI in security operations. They're reasons to deploy it thoughtfully. Here's what effective governance looks like in practice.

Require Human Review Before Privileged Action

AI-generated recommendations should not automatically trigger sensitive operations — infrastructure changes, access modifications, incident response actions — without human verification first. This applies even when the AI seems right. Models produce equally confident outputs whether they're correct or not, so the review step cannot be conditional on "something seems off."

Build this into your runbooks and your tooling, not just your policies.

Treat Training Data as a Security Asset

Your AI is only as reliable as what it learned from. Regularly audit the data used to train or ground your AI systems. Remove outdated threat signatures, biased datasets, and known inaccurate records. As AI-generated content proliferates across the internet, continuous data governance isn't optional — it's a prerequisite for reliable model outputs.

Apply Least-Privilege to AI Systems, Not Just Humans

If an AI system recommends deleting a file, it should not have permission to delete that file. Apply the same least-privilege principles to AI-driven systems that you apply to human accounts: read where reading is enough, no write access where writes aren't required, no delete access anywhere it isn't explicitly necessary.

This way, even if a hallucinated recommendation makes it through review, the blast radius is bounded by access controls.

Invest in Prompt Engineering for Security Teams

Output quality is heavily shaped by input quality. Security teams that interact directly with AI systems need to understand how to write prompts that are specific, verifiable, and actionable — not because prompt engineering is magic, but because vague inputs systematically increase hallucination risk.

Train your analysts not just to use AI tools, but to evaluate AI outputs critically. The mental model to instill: the AI is a fast, confident junior analyst. Always review their work.

Put Identity Security at the Center of AI Governance

Most AI hallucinations become security incidents at the moment of action — when an AI system or a human trusts an incorrect output enough to execute something. This is fundamentally an access problem.

The question to ask in your architecture review: if the AI says the worst possible thing and someone believes it, what's the most damage that can happen? Work backward from that to design your access controls, audit logging, and review requirements.

Security architectures that enforce least-privilege for both human and non-human identities (NHIs), monitor privileged activity, and require verification before sensitive actions are taken give organizations meaningful protection even when AI outputs are wrong.

The Bottom Line

AI in security operations is a force multiplier — for better and for worse. When it works, it catches threats faster than human analysts can. When it hallucinates, it can create the conditions for a breach while appearing to be managing one.

The answer isn't to distrust AI. It's to be precise about where trust is warranted and what safeguards exist when that trust is misplaced.

Human review requirements, least-privilege enforcement, data governance, and prompt engineering discipline aren't obstacles to AI adoption. They're what makes AI adoption survivable.

Have you seen AI hallucinations cause real problems in a security context? Share your experience in the comments — this is a space where practitioner knowledge matters a lot.

[Boost]

Amayo Clinton — Sun, 26 Apr 2026 12:46:42 +0000

Dishon Oketch

Apr 26

Your Guide Into the Development World: A Roadmap for Absolute Beginners

#codenewbie #webdev #programming #beginners

5 min read

DEV Community: Amayo Clinton

[Boost]

101 Tips For Being A Great Programmer (& Human)

Nostr, Explained for Developers — A Deep Dive

Table of contents

1. What Nostr actually is and isn't

2. The problem it was designed to solve

3. The protocol, piece by piece

3.1 Identity is a keypair, not an account

3.2 Content is a signed event — and that's the entire data model

3.3 Kinds: the field that does all the work

3.4 Relays are dumb pipes, not authorities

3.5 Clients are interchangeable, by construction

4. How the wire protocol actually works

5. NIPs: the extension system

6. Zaps: the feature that makes Nostr different from everything before it

7. Nostr vs. ActivityPub vs. Bluesky's AT Protocol

8. What real production apps look like on this stack

9. The honest tradeoffs and open problems

10. Getting started: a minimal working example

11. Where this is heading

12 GitHub Actions Workflows That Will Quietly Save Your DevOps Team Hours Every Week

1. CI/CD That Actually Gates Deployments

2. Linting and Static Analysis as a Required Check

3. Stale Issue/PR Triage

4. Dependency Updates Without the Manual Review Bottleneck

5. Secret Scanning and Dependency Vulnerability Checks

6. Release Automation with Auto-Generated Changelogs

7. Infrastructure as Code: Plan on PR, Apply on Merge

8. Code Coverage Enforcement, Not Just Reporting

9. Scheduled Database Migration Checks

10. Scheduled Backups With Verified Upload

11. Slack Notifications Scoped to Signal, Not Noise

12. Project Board Sync

The So-What

The Fallback Password: Dissecting the Tenda Router Backdoor (CVE-2026-11405)

The TL;DR

The Actual Vulnerable Logic

1. It's not a hardcoded credential — it's a fallback credential

2. Two authentication failures stacked on top of each other

3. No username validation = every account is the admin account

Where This Sits in the CVSS/Exploitability Landscape

How You'd Actually Find Something Like This

Detection If You're Running Fleets of These Devices

Mitigations (Until Tenda Ships a Fix, If Ever)

So What? (The Actionable Bit)

Git Mastery

The Setup

Building History On Purpose

Reading history the useful way

Time Travel: Checkout, Tags, and Not Losing Your Mind

Changing Your Mind (Repeatedly)

Reorganizing the Project

Going Under the Hood: Blobs, Trees, Commits

Branching Without Fear

The Main Event: Conflicts and Rebasing

Then: undo the merge and rebase instead

Local, Remote, and Bare Repositories

Bare repositories

What Actually Stuck

Linux Permissions, Actually Explained (Not Just Memorized)

Who Permissions Apply To

Reading Symbolic Notation

Octal Notation and the Math Behind It

chmod in Practice

The Fourth Digit: setuid, setgid, and the Sticky Bit

Ownership: chown and chgrp

Debugging Real Permission Errors

Putting It Together

Beyond the Lone Cheetah: Architecture Patterns for Multi-Agent Prides in Real-World Ecosystems

The AUR Supply Chain Attack: When Trust Becomes the Vulnerability

When AI Gets It Wrong: The Hidden Security Risk of Hallucinations in Cybersecurity

[Boost]

Your Guide Into the Development World: A Roadmap for Absolute Beginners