DEV Community: Mike

Cloudflare Self-Managed OAuth — What It Means for Your Homelab Security

Mike — Fri, 26 Jun 2026 12:29:20 +0000

Cloudflare Self-Managed OAuth — What It Means for Your Homelab Security

On June 3, 2026, Cloudflare quietly launched something that flew under most homelab radars: self-managed OAuth clients. The announcement landed on the Cloudflare Fundamentals changelog, not the main blog. But for anyone running services behind Cloudflare — DNS, Tunnels, Zero Trust, Workers — this changes how you manage API access.
I run my entire homelab behind Cloudflare. DNS records for every service, Zero Trust Access in front of internal dashboards, API tokens scattered across Terraform configs and cron jobs. Every one of those tokens is a static string with broad permissions that lives in a .env file or a CI variable. If one leaks, the damage radius is whatever permissions I gave it — usually more than it needed.
Self-managed OAuth replaces that model. Here's what it is, how it works, and why homelab users should care.

What Self-Managed OAuth Actually Is

OAuth is the protocol behind every "Sign in with Google" button you've ever clicked. A third-party app asks for permission to access your account, you see a consent screen listing exactly what it wants, and you approve or deny it. The app never sees your password. It gets a short-lived token scoped to only the permissions you approved.

Cloudflare has supported OAuth for years — but only for apps that Cloudflare itself built, like Wrangler (the Workers CLI). If you wanted your own tool to talk to the Cloudflare API, you generated an API token from the dashboard, copied the string, and pasted it wherever it needed to go. That token sat there until you manually revoked it.
Self-managed OAuth means you can now create your own OAuth applications — the same kind Cloudflare uses internally. Your app gets a client ID and secret, users go through a consent flow, and the resulting access token has only the scopes you defined when you created the application. No static strings. No over-provisioned permissions. No token sitting in a plaintext config file for six months after you stopped using it.

How It Compares to API Tokens

If you've used Cloudflare API tokens before, the scope system will look familiar. You pick which parts of the account the application can touch — DNS read, DNS edit, Zone settings, Account-level analytics, Workers deployment, and so on. The difference is in how those permissions get enforced.
| | API Tokens | Self-Managed OAuth |
|---|---|---|
| Storage | Static string in config/env | Client ID + secret (one-time setup), then short-lived access tokens |
| Permission model | Set at token creation, rarely reviewed | Scopes shown to user on consent screen every time |
| Revocation | Manual — find the token, delete it | Revoke the application or the user's grant independently |
| Auditability | Token was used — that's about it | Per-user grants, consent timestamps, scope history |
| User identity | The token is the identity | Tied to a specific Cloudflare user account |
For a homelab, the killer feature is the consent screen. Every person who uses your OAuth application sees exactly what permissions they're granting before they click approve. With API tokens, you copy a string and hope whoever has it doesn't abuse it. With OAuth, the scope is transparent and the grant is deliberate.

What This Means for Homelab Users

Most homelab users aren't building third-party SaaS products. So why does this matter?
Three likely future use cases — with one current limitation.
There is one important limitation: Cloudflare currently supports Authorization Code flow for third-party OAuth clients. That works well for web apps, CLIs, desktop apps, and tools that can complete a browser-based login. It is less straightforward for unattended CI/CD pipelines and cron jobs because Cloudflare does not currently support Client Credentials or Device Authorization flows for third-party clients.
Terraform and infrastructure-as-code. If you manage Cloudflare DNS with Terraform — and plenty of homelabbers do, because it beats clicking around the dashboard — you currently store an API token with DNS edit permissions — it sits in your Terraform state or variables file. That token has full write access to every DNS zone in your account. With self-managed OAuth, you create an application with DNS read and DNS edit scopes, and when Terraform providers and related tooling support Cloudflare OAuth authentication, the access token is scoped and short-lived. If your Terraform state leaks, the damage is contained.
CI/CD pipelines. GitHub Actions deploying to Cloudflare Pages, Workers, or updating DNS records as part of a deploy pipeline — every one of those needs an API token today. Self-managed OAuth points toward a better model for CI/CD, but today unattended pipelines may still need API tokens unless the workflow can complete an Authorization Code flow securely. When tooling catches up, the payoff is real: revoke one contributor's grant instead of rotating tokens across every pipeline.
Automation scripts and cron jobs. I run scripts that update DNS records, check zone analytics, and rotate origin certificates. Each one has its own API token with more permissions than it strictly needs because creating a narrowly-scoped token for every small script is tedious. Self-managed OAuth makes narrow scoping practical for interactive tools and backend services, but unattended cron jobs may still need API tokens until Cloudflare supports a non-interactive OAuth flow or the tooling handles refresh securely. When those pieces land, the model is clear: one OAuth application per automation domain, a grant per user or service account, and the consent flow handles the rest.
The common thread: you stop managing tokens and start managing access.

Setting It Up — Where to Start

Self-managed OAuth is available on all Cloudflare plans, including the free tier. Here's the setup path.
First, navigate to Manage Account → OAuth Clients in the Cloudflare dashboard. This is where you create and manage OAuth applications.

When you create an application, you'll define:

Name and description. What is this application, and who is it for? Be specific — "Homelab Terraform DNS Manager" is better than "my app."
Redirect URLs. Where Cloudflare sends the user after they approve or deny the consent request. For a CLI tool, this is typically a localhost URL. For a web app, it's your callback endpoint.
Scopes. The permissions your application requests. Pick only what you need. If your Terraform config only manages DNS, don't request Workers or Analytics scopes.
Visibility. Applications start as private — only members of your Cloudflare account can use them. This is the right setting for homelab use. Public visibility requires domain verification and is meant for apps distributed to other Cloudflare users. Once the application is created, you get a client ID and client secret. The client ID is public — it identifies your application in the OAuth flow. The client secret is private — treat it like a password. Store it in a secrets manager or encrypted config, never in plaintext in a repo. ## Security Implications — The Good and The Trade-offs Self-managed OAuth improves your security posture in ways that matter for a homelab. Least privilege becomes practical. API tokens reward laziness — it's easier to create one "edit all the things" token than ten narrowly-scoped ones. OAuth applications make narrow scoping the default. You define scopes once at application creation, and every access token inherits them. Revocation is granular. With API tokens, you revoke the entire token and break everything that used it. With OAuth, you can revoke a single user's grant without touching other users of the same application. If a service account gets compromised, you cut off that grant and everything else keeps working. No long-lived static secrets. API tokens sit in config files indefinitely. OAuth access tokens expire. Refresh tokens can be rotated. The window for a leaked credential to be useful is measured in hours, not months. The trade-offs are worth noting. More moving parts. OAuth adds a consent flow to your authentication pipeline. For a CLI tool that previously just read an environment variable, you now need to handle the browser-based Authorization Code flow. Client secret is still a secret. You're trading one static secret (the API token) for another (the client secret). The difference is that the client secret is used only during the OAuth handshake, not for every API call. The access token that actually hits the API is short-lived and scoped. Setup is more involved. Creating an API token takes 30 seconds. Setting up an OAuth application, configuring redirect URLs, and integrating the OAuth flow into your tool takes longer. The payoff is in ongoing security, not initial convenience. ## Practical Takeaways for the Homelab Here's what I'd suggest for a homelab user who wants to adopt this. Start with your highest-risk tokens. Audit the API tokens you currently have in your Cloudflare account. Find the ones with the broadest permissions — the "edit all zones" tokens, the ones shared across multiple services, the ones you created a year ago and forgot about. Migrate those first. Create one OAuth application per role, not per script. You don't need a separate OAuth application for every cron job. Group by function: DNS management, Workers deployment, analytics reporting. Each application gets the minimum scopes for that role, and multiple scripts or tools can use the same application. Keep private visibility. Unless you're building a tool for other Cloudflare users, leave your applications set to private. Private applications are only usable by members of your Cloudflare account — which is exactly what you want for homelab automation. Rotate client secrets. Treat client secrets the same way you'd treat API tokens — rotate them periodically. Cloudflare doesn't enforce rotation, so build it into your maintenance routine. Monitor your grants. The OAuth Clients page in the dashboard shows which users have granted consent to each application. Check it occasionally. Revoke grants for users or service accounts you no longer need. Self-managed OAuth isn't going to replace API tokens overnight — plenty of tools and Terraform providers still expect a static token. But the direction is clear. Cloudflare is building the infrastructure for a world where API access is scoped, consented, and auditable rather than a string you copy once and forget. For a homelab, that's one less thing to lose sleep over.

High School to Homelab — A Student's Linux Journey

Mike — Tue, 23 Jun 2026 11:30:50 +0000

High School to Homelab — A Student's Linux Journey

Last week, a high school student posted on r/homelab. i5-6500T. 40TB NAS. ThinkPad X13 running Proxmox. Looking for advice on his setup.

At the time I read it, the post had 163 points and 70+ comments. Not a single "you're too young for this." The entire thread was encouragement, technical tips, and people genuinely excited that a teenager was building real infrastructure.

I scrolled through it twice. Not because the hardware was impressive — it was solid, sensible gear. I kept reading because I recognised something.

I teach Cambridge Computer Science. I've watched students memorise the OSI model for an exam and forget it the next week. I've seen students write perfect pseudocode for a bubble sort and freeze when their Python script throws a traceback. The gap between knowing about computers and knowing computers is real, and it's wide.

That Reddit post made me think about something I've believed for a while now: the students who build homelabs often learn far more deeply than the students who only read textbooks. Here's why.

How I Learned Linux — By Breaking Things

I didn't learn Linux in a classroom. I learned it on a BMAX Pro 8 that I bought for $320, installed Proxmox on, and promptly broke three times in the first week.

The first time I misconfigured a network bridge, every VM lost connectivity. The second time I filled a ZFS pool and couldn't figure out why zfs list showed space I couldn't use. The third time a kernel update borked the NVIDIA drivers I'd spent two days compiling.

Each time, I fixed it. Not because I'm brilliant — because the server ran services I actually needed. My blog. My automation workflows. My AI models. When your own infrastructure is on the line, you learn fast.

That's the difference between classroom Linux and homelab Linux. In a classroom, if you break something, you raise your hand and the teacher fixes it. In a homelab, if you break something, your services go dark and nobody's coming to save you. The pressure is low-stakes (it's just your own stuff) but the motivation is real.

What a Homelab Actually Teaches

Here's what I didn't understand when I started: a homelab isn't a hardware project. It's a compressed operating systems course where you do the labs on your own production servers.

Real networking, not textbook networking

The Cambridge A-Level syllabus covers IP addressing, subnetting, DNS, and the TCP/IP stack. Students can define a subnet mask on an exam. But plug a cable into a Proxmox node and try to get a VM talking to the internet, and suddenly 192.168.1.0/24 isn't a notation — it's a decision with consequences.

When you set up a Linux bridge in Proxmox, you learn what a bridge actually is. When you configure a VLAN for your IoT devices, you understand why network segmentation matters. When you set up Nginx as a reverse proxy, you finally get what a port is and why it matters that only one service can bind to port 80.

I've written about the minimal homelab setup I run, and here's what surprised me: the networking concepts I thought I understood from reading became viscerally clear the first time I configured them for real.

Linux administration — not just `cd` and `ls`

Desktop Linux teaches you the GUI. Homelab Linux teaches you the guts.

Running services on Debian means you learn systemd — not because you want to, but because your Docker containers won't auto-start without it. You learn journalctl because your n8n workflow crashed at 3 AM and you need to know why. You learn apt, dpkg, and package pinning because a dist-upgrade broke your GPU passthrough and you need to rollback.

These aren't exotic skills. They're what separate someone who "uses Linux" from someone who can admin a Linux server. And they're exactly what CS students need if they want to work in infrastructure, DevOps, or any role that touches production systems.

Troubleshooting as a skill

The Cambridge syllabus covers debugging — for code. But debugging a server is a different muscle. When your Proxmox node won't boot after a kernel update, you can't set a breakpoint. You check the boot log. You chroot in from a live USB. You learn that fsck exists and that you should have run it three hours ago.

I once spent an evening convinced my Proxmox installation was corrupted. Turns out I'd plugged the Ethernet cable into the wrong port. Two hours of kernel parameter debugging for a Layer 1 problem. That night taught me more about systematic troubleshooting than any textbook chapter.

How homelab skills connect to Cambridge CS topics

What I find fascinating — and what makes me push students toward homelabs — is how directly these skills map to the Cambridge Computer Science syllabus.

What you do in a homelab	Cambridge syllabus topic
Install Proxmox, partition disks	Memory, storage devices, and media
Set up network bridges, VLANs	Network hardware, IP addressing
Configure DNS, reverse proxy	DNS, client-server model
Write shell scripts for automation	Pseudocode and programming concepts
Run Docker containers	Operating systems, virtual machines
Debug boot failures, kernel panics	Interrupts, system software
Monitor with systemd/journalctl	Monitoring and control systems
Set up MariaDB for services	Database concepts, SQL

This isn't forced. When you build a homelab, you don't think "today I will study storage devices." You think "I need more space for my media server." But the act of buying an SSD, partitioning it, mounting it, and expanding your ZFS pool teaches you more about storage than any diagram in a textbook.

That's the magic. The learning is a side effect of building something you actually want.

If you're preparing for the Cambridge exams, I've written a detailed Paper 1 theory walkthrough covering the same topics — it's the exam answer angle to match the hands-on learning your homelab gives you.

The Minimum Viable Student Homelab

You don't need a 40TB NAS and a rack. The Reddit student's setup is impressive, but it's also more than anyone needs to start learning.

Here's what I'd tell a CS student who wants to build their first homelab:

A used office PC. A Dell Optiplex or Lenovo ThinkCentre with 16GB RAM costs $50–$100 on eBay. It sips power, it's quiet enough for a bedroom, and it'll run Proxmox and a dozen containers without breaking a sweat.

Proxmox VE. Free. Open source. Runs on basically anything. The web interface lowers the barrier to entry, but the underlying system is Debian — so you're learning real Linux from day one.

Start with three services. A web server (Nginx), a database (MariaDB), and something fun — a Plex server, a Minecraft server, a personal website. Three services is enough to learn networking, storage, and system administration without getting overwhelmed.

Break something on purpose. Pull a config file. Misconfigure a firewall rule. Fill a disk. Then fix it. The fixing is where the learning happens.

A word on safety. Don't expose services to the public internet until you understand updates, firewalls, passwords, SSH keys, backups, and basic hardening. A homelab is for learning — keep it on your local network while you're figuring things out. The mistakes are much safer behind a router.

I've compared the CHUWI MiniBook X and BMAX Pro 8 as homelab starters, and honestly, either works. But the $150 N100-based BMAX is the sweet spot for a student — it's in the same price range as a Raspberry Pi 5 kit but gives you 16GB of RAM and an x86 CPU that runs a full Linux hypervisor.

The Skills Employers Actually Want

Here's something I tell my students: nobody hires a graduate because they can explain virtual memory. They hire graduates who can SSH into a server, diagnose why a service is down, and fix it.

When you build a homelab, your CV gets a quiet upgrade. You can't list "ran a Proxmox node for two years" as a formal qualification, but you can describe what you actually did: "Managed Linux servers running Docker, Nginx, MariaDB, and automated workflows with systemd. Configured network bridges, VLANs, and firewall rules. Troubleshot kernel panics, disk failures, and service outages."

That's not a bullet point from a coursework submission. That's evidence you can operate real systems. And in a job market where CS graduates are competing with AI tools that can write code, the ability to run systems is increasingly what sets people apart.

The Thing Nobody Tells You

The Reddit student's post had 70 comments of technical advice. But not a single person said what I wish someone had told me when I started: the best way to learn computer science is to build something you depend on.

When your personal website goes down, you're motivated to understand DNS. When your Plex server can't transcode, you learn about CPU scheduling and hardware acceleration. When your backup script fails silently for a month and you lose a week of config changes, you learn about monitoring and alerting the hard way — and you never forget.

Classroom CS teaches you the theory. Homelab CS teaches you the practice. You need both.

That high school student with the 40TB NAS and ThinkPad X13? He's not just building a server. He's building the foundation for a career — and learning more on a Tuesday night than most students learn in a semester.

If you're a student reading this: grab a used PC, install Proxmox, and break something. Then fix it. That's the whole curriculum.

The Chat Graveyard — How to Export, Search, and Learn from Your AI Conversations

Mike — Sun, 21 Jun 2026 10:03:50 +0000

Liquid syntax error: Unknown tag 'endraw'

Learning Docker by Building a Container Engine from Scratch

Mike — Sun, 21 Jun 2026 10:03:45 +0000

Learning Docker by Building a Container Engine from Scratch

If you've used Docker for any length of time, you've probably internalized the vocabulary. Images. Containers. Dockerfiles. docker run -d --name my-app nginx. It works. You ship code. Everyone's happy.

But here's a question: what actually happens when you type docker run?

Most people answer with something about "lightweight VMs" or "process isolation." That's correct in spirit but useless in detail. The real answer involves several Linux kernel primitives that have existed for over a decade. Docker didn't invent containers. It packaged them.

In this post, I'm going to walk you through building a minimal container engine using raw Linux primitives. No Docker. No Podman. No LXC. Just the kernel, a C compiler and a few Go scripts. By the end, you'll understand isolation at the syscall level — and you'll never look at docker run the same way again.

I won't be building something production-ready. This is a learning tool. The goal is understanding, not shipping. If you want a real container runtime after this, go read the runC source. You'll actually understand it.

What a Container Actually Is

Before we touch a terminal, let's define what we're building. A container is a process with a lie told to it by the kernel.

That lie comes in three parts:

Visibility. The process can only see what the kernel lets it see — other processes, network interfaces, files, user IDs. This is namespaces.
Resources. The process can only consume what the kernel allocates — CPU shares, memory limits, I/O bandwidth. This is cgroups.
Filesystem. The process thinks it has a root filesystem, but it's actually looking at a directory (or a stack of directory layers) we prepared. This is chroot/pivot_root plus a union filesystem.

That's it. Three lies. Together they create the illusion of a dedicated machine. Docker's entire value proposition — the CLI, the registry, the Dockerfile format, the networking bridge — sits on top of these three primitives. Everything else is tooling.

Lie #1: Namespaces — Controlling What a Process Can See

Linux namespaces partition kernel resources so one set of processes sees a different reality from another. Modern Linux has eight namespace types: mount, PID, network, IPC, UTS, user, cgroup, and time. Containers typically rely most heavily on mount, PID, network, IPC, UTS, and user namespaces.

The Six Namespaces That Matter

Namespace	What It Isolates	Clone Flag	Why Containers Need It
PID	Process IDs	`CLONE_NEWPID`	So PID 1 inside the container isn't the host's init process
Mount	Filesystem mount points	`CLONE_NEWNS`	So the container has its own `/proc`, `/sys`, and root filesystem
Network	Network interfaces, routing tables, firewall rules	`CLONE_NEWNET`	So the container gets its own `eth0` and IP address
UTS	Hostname and domain name	`CLONE_NEWUTS`	So `hostname` inside the container returns something different
IPC	SysV message queues, shared memory, semaphores	`CLONE_NEWIPC`	So processes can't read shared memory segments from the host
User	UID/GID mappings	`CLONE_NEWUSER`	So root inside the container is unprivileged outside

The PID namespace is the one that surprises people most. When you create a new PID namespace, the first process inside gets PID 1. It looks like init. If that process dies, the kernel sends SIGKILL to every other process in the namespace — exactly like the host's init. This is why Docker containers stop when the main process exits.

Here's the simplest possible namespace demonstration. Save this as ns_demo.go:

package main

import (
    "fmt"
    "os"
    "os/exec"
    "syscall"
)

func main() {
    if len(os.Args) &lt; 2 {
        fmt.Println("Usage: ns_demo  [args...]")
        os.Exit(1)
    }

    cmd := exec.Command(os.Args[1], os.Args[2:]...)
    cmd.Stdin = os.Stdin
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    // Run the command in new namespaces
    cmd.SysProcAttr = &amp;syscall.SysProcAttr{
        Cloneflags: syscall.CLONE_NEWUTS |  // new hostname
            syscall.CLONE_NEWPID |          // new PID space
            syscall.CLONE_NEWNS,            // new mount space
    }

    if err := cmd.Run(); err != nil {
        fmt.Fprintf(os.Stderr, "Error: %v\n", err)
        os.Exit(1)
    }
}

Build it, then run it with a shell:

go build -o ns_demo ns_demo.go
sudo ./ns_demo /bin/bash

Inside this shell, run hostname my-container and then hostname. You'll see my-container. Now open another terminal and run hostname — still your actual hostname. The UTS namespace isolated it. Run echo $$ — you'll see 1. The PID namespace gave you your own process tree.

You're already running a container. A terrible one with no filesystem isolation and no resource limits, but a container nonetheless. This is what Docker does under the hood — it just wraps it with a lot of tooling.

Lie #2: cgroups — Controlling What a Process Can Use

Namespaces control visibility. cgroups (control groups) control consumption. Without cgroups, a container process can eat 100% of the host CPU, fill all available RAM, and saturate the disk. Namespaces won't stop it.

cgroups are organized as a filesystem, typically mounted at /sys/fs/cgroup. Each subsystem — CPU, memory, blkio, pids — has its own directory tree. Creating a new cgroup means making a directory. Setting limits means writing to files inside that directory.

The cgroup v2 interface, available since the Linux 4.x era and now common on modern distributions, is simpler than cgroup v1 because controllers live under a unified hierarchy. Everything lives under a single tree.

Note: these commands assume a simple cgroup v2 setup where root can create and write to a child cgroup under /sys/fs/cgroup. On many systemd-managed distributions, direct writes may fail unless the process is running inside a delegated cgroup or scope. Here's how you'd limit a container to 100MB of RAM and half a CPU core:

# Create a new cgroup for the container
CGROUP=/sys/fs/cgroup/my-container
sudo mkdir -p "$CGROUP"

# Limit memory to 100 MB
echo "104857600" | sudo tee "$CGROUP/memory.max"

# Limit CPU to 50% of one core (50000 microseconds per 100ms period)
echo "50000 100000" | sudo tee "$CGROUP/cpu.max"

# Limit to 10 PIDs (prevents fork bombs inside the container)
echo "10" | sudo tee "$CGROUP/pids.max"

# Move the container process into the cgroup
echo $CONTAINER_PID | sudo tee "$CGROUP/cgroup.procs"

That's it. Four echo commands and your container can't exceed 100MB of RAM, can't use more than 50% of a CPU core, and can't spawn more than 10 processes. Docker's --memory, --cpus, and --pids-limit flags map directly to these files.

The cgroup is a teaching tool in itself. If you were building a real container engine, you'd create a new cgroup, write the limits, then fork the container process with its PID added to cgroup.procs. The kernel handles enforcement. If the container exceeds its memory limit, the OOM killer terminates the largest process inside. No polling. No daemon watching. Just the kernel saying "no."

Lie #3: The Filesystem — chroot, pivot_root, and Union Mounts

Namespaces control what the process sees. cgroups control what it uses. But the process can still see your host's entire filesystem — your SSH keys, your /etc/passwd, your home directory. That's a security disaster.

Phase 1: chroot (The Simple Way)

The chroot syscall changes the root directory of a process. Everything under / becomes the contents of whatever directory you point at.

func chrootInto(newRoot string) error {
    // chroot to the new root
    if err := syscall.Chroot(newRoot); err != nil {
        return err
    }
    return syscall.Chdir("/")
}

Give this an Ubuntu rootfs (download it with debootstrap) and the process thinks it's running on a dedicated Ubuntu machine. But chroot was never designed as a security boundary. A root process inside a chroot can escape in several well-documented ways. It's fine for learning but not for production.

Phase 2: pivot_root (The Proper Way)

pivot_root is the syscall designed for containers. It moves the current root filesystem to a subdirectory and places a new filesystem at /. Unlike chroot, it properly detaches the old root so the process can't escape.

func pivotRoot(newRoot string) error {
    // Bind mount newRoot to itself (required by pivot_root)
    if err := syscall.Mount(newRoot, newRoot, "", syscall.MS_BIND|syscall.MS_REC, ""); err != nil {
        return fmt.Errorf("bind mount rootfs: %w", err)
    }

    // Create a directory for the old root
    putOld := filepath.Join(newRoot, ".pivot_root")
    if err := os.MkdirAll(putOld, 0700); err != nil {
        return fmt.Errorf("mkdir putOld: %w", err)
    }

    // pivot_root: swap the root filesystem
    if err := syscall.PivotRoot(newRoot, putOld); err != nil {
        return fmt.Errorf("pivot_root: %w", err)
    }

    // Change working directory to the new root
    if err := syscall.Chdir("/"); err != nil {
        return fmt.Errorf("chdir /: %w", err)
    }

    // Unmount the old root so the process can't escape
    putOld = "/.pivot_root"
    if err := syscall.Unmount(putOld, syscall.MNT_DETACH); err != nil {
        return fmt.Errorf("unmount old root: %w", err)
    }
    return os.Remove(putOld)
}

This is what Docker does. It's also what LXC and runC do. The pattern is identical across runtimes because there's only one kernel API for this job.

Phase 3: OverlayFS (Where Images Come From)

Your container has a root filesystem — but where did that filesystem come from? Docker "pulls images." What's actually happening?

A Docker image is a stack of read-only layers, each representing a filesystem diff. When you RUN apt install nginx in a Dockerfile, it creates a new layer containing only the files that command added or changed. When you run the container, Docker combines those layers into a single view using a union filesystem — typically OverlayFS on modern kernels.

Here's how OverlayFS works:

# Create the directory structure
mkdir lower upper work merged

# lower = read-only base (e.g., Ubuntu rootfs)
# upper = writable layer (container changes go here)
# work  = internal OverlayFS scratch space
# merged = the unified view the container sees

# Mount the overlay
sudo mount -t overlay overlay \
    -o lowerdir=lower,upperdir=upper,workdir=work \
    merged

# Now 'merged' shows lower + upper combined
# Reads prefer upper; writes go to upper (copy-on-write)

When you docker pull ubuntu:22.04, you're downloading compressed filesystem layer blobs, usually tar-based, along with metadata and digests. When you docker run, Docker mounts them with OverlayFS and passes the merged directory as the root filesystem to pivot_root. That's the whole image system. No magic. Just a clever filesystem trick that's been in the Linux kernel since 2014.

Putting It All Together: The Minimal Container Engine

Let's assemble what we've learned. Here's the flow our engine follows:

Prepare the rootfs. Either unpack a tarball or set up an OverlayFS mount
Create cgroup limits. Write to /sys/fs/cgroup/my-container/
Fork a child process with namespace flags (CLONE_NEWPID | CLONE_NEWNET | CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC)
Inside the child: call pivot_root to the prepared rootfs
Mount /proc so ps and friends work inside the container
Add the child PID to the cgroup for resource enforcement
Exec the container command (e.g., /bin/bash)

This is a simplified teaching demo. It shows the core mechanics, but it is not a portable or production-quality runtime. In particular, cgroup setup may differ on systemd-managed hosts, and the child process may start before all resource limits are fully applied.

Here's a complete Go program that does this. It's under 200 lines and runs a real container:

package main

import (
    "fmt"
    "os"
    "os/exec"
    "path/filepath"
    "syscall"
)

func main() {
    if len(os.Args) &lt; 2 {
        fmt.Println("Usage: mini-container  [args...]")
        os.Exit(1)
    }

    rootfs := "/tmp/mini-container-rootfs"
    cgroupPath := "/sys/fs/cgroup/mini-container"

    // 1. Prepare rootfs (requires pre-existing directory or tarball)
    if _, err := os.Stat(rootfs); os.IsNotExist(err) {
        fmt.Fprintf(os.Stderr, "Rootfs not found at %s\n", rootfs)
        fmt.Fprintf(os.Stderr, "Create one with: sudo debootstrap stable %s\n", rootfs)
        os.Exit(1)
    }

    // 2. Set up cgroup
    if err := setupCgroup(cgroupPath); err != nil {
        fmt.Fprintf(os.Stderr, "cgroup setup failed: %v\n", err)
        os.Exit(1)
    }

    // 3. Fork the container process
    cmd := exec.Command("/proc/self/exe", append([]string{"init"}, os.Args[1:]...)...)
    cmd.Stdin = os.Stdin
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    cmd.SysProcAttr = &amp;syscall.SysProcAttr{
        Cloneflags: syscall.CLONE_NEWPID |
            syscall.CLONE_NEWNET |
            syscall.CLONE_NEWNS |
            syscall.CLONE_NEWUTS |
            syscall.CLONE_NEWIPC,
    }

    if err := cmd.Start(); err != nil {
        fmt.Fprintf(os.Stderr, "Failed to start container: %v\n", err)
        os.Exit(1)
    }

    // 4. Add child to cgroup
    if err := addToCgroup(cgroupPath, cmd.Process.Pid); err != nil {
        fmt.Fprintf(os.Stderr, "Failed to add process to cgroup: %v\n", err)
    }

    if err := cmd.Wait(); err != nil {
        if exitErr, ok := err.(*exec.ExitError); ok {
            os.Exit(exitErr.ExitCode())
        }
        os.Exit(1)
    }
}

// init runs inside the container after namespace creation
func init() {
    if len(os.Args) &lt; 2 || os.Args[1] != "init" {
        return
    }

    rootfs := "/tmp/mini-container-rootfs"

    // pivot_root into the container rootfs
    if err := pivotRoot(rootfs); err != nil {
        fmt.Fprintf(os.Stderr, "pivot_root failed: %v\n", err)
        os.Exit(1)
    }

    // Mount /proc
    if err := syscall.Mount("proc", "/proc", "proc", 0, ""); err != nil {
        fmt.Fprintf(os.Stderr, "mount /proc failed: %v\n", err)
    }

    // Execute the requested command
    cmd := exec.Command(os.Args[2], os.Args[3:]...)
    cmd.Stdin = os.Stdin
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    if err := cmd.Run(); err != nil {
        if exitErr, ok := err.(*exec.ExitError); ok {
            os.Exit(exitErr.ExitCode())
        }
        os.Exit(1)
    }
    os.Exit(0)
}

func pivotRoot(newRoot string) error {
    if err := syscall.Mount(newRoot, newRoot, "", syscall.MS_BIND|syscall.MS_REC, ""); err != nil {
        return err
    }
    putOld := filepath.Join(newRoot, ".pivot_root")
    os.MkdirAll(putOld, 0700)
    if err := syscall.PivotRoot(newRoot, putOld); err != nil {
        return err
    }
    syscall.Chdir("/")
    putOld = "/.pivot_root"
    syscall.Unmount(putOld, syscall.MNT_DETACH)
    return os.Remove(putOld)
}

func setupCgroup(path string) error {
    os.MkdirAll(path, 0755)
    // Memory limit: 100 MB
    os.WriteFile(filepath.Join(path, "memory.max"), []byte("104857600"), 0644)
    // CPU limit: 50% of a core
    os.WriteFile(filepath.Join(path, "cpu.max"), []byte("50000 100000"), 0644)
    // PID limit: 10
    os.WriteFile(filepath.Join(path, "pids.max"), []byte("10"), 0644)
    return nil
}

func addToCgroup(path string, pid int) error {
    return os.WriteFile(
        filepath.Join(path, "cgroup.procs"),
        []byte(fmt.Sprintf("%d", pid)),
        0644,
    )
}

To use it:

# Step 1: Create a root filesystem
sudo debootstrap stable /tmp/mini-container-rootfs

# Step 2: Build and run the container
go build -o mini-container main.go
sudo ./mini-container /bin/bash

# You're now root in a container with:
# - Its own PID namespace (ps aux shows only your processes)
# - Its own mount namespace (/ is the debootstrap rootfs)
# - Memory capped at 100 MB
# - CPU capped at 50%
# - Max 10 processes

That's a container. Not a complete one — there's no networking, no seccomp profile, no image pulling, no volume mounts. But every one of those features is just another syscall layered on top.

What Docker Adds (And Why You Should Still Use It)

After building this, you might wonder why anyone uses Docker at all. The short answer: you don't want to manage overlay mounts by hand. You don't want to write Go code every time you need a container. Docker gives you:

The registry. docker pull nginx downloads a tarball, verifies checksums, and unpacks layers. Building that from scratch is hundreds of lines of HTTP + tar + hash verification code.
The networking bridge. docker network create sets up bridge interfaces, iptables rules, and DNS resolution. Raw network namespaces give you only a loopback interface. Getting packets in and out requires veth pairs and manual routing.
The image cache. Docker tracks which layers you've already downloaded and reuses them. An nginx:latest base image pulled once is shared across every container that uses it. OverlayFS makes this efficient at the filesystem level, but Docker's daemon tracks metadata so you don't have to.
seccomp and capabilities. Docker runs containers with a reduced default capability set and applies a default seccomp profile based on an allowlist, blocking many higher-risk syscalls by default. Your mini-container above runs with full root capabilities. That's fine for learning; it's a disaster in production.

The point of building the minimal version isn't to replace Docker. It's to understand what Docker actually does. When a production container won't start, you'll know to check /proc//ns/ to see which namespaces are active. When memory limits aren't working, you'll know to look at cgroup.procs. When a file written inside a container disappears after restart, you'll understand that it went to the upper OverlayFS layer and the container runtime cleaned it up.

How I Use This Knowledge in My Own Setup

I run Docker Compose on my homelab mini PC for Plex, n8n, and about a dozen other services. Before I understood the internals, Docker was a black box that either worked or didn't — and when it didn't, I was stuck reading Stack Overflow threads from 2019.

Understanding namespaces and cgroups changed how I debug. When a container leaked memory, I checked /sys/fs/cgroup/system.slice/docker-.scope/memory.current instead of guessing. When networking broke, I inspected the veth pairs instead of restarting the Docker daemon. When a container couldn't write files, I checked the OverlayFS upper directory permissions instead of rebuilding the image.

You don't need to build a container engine to use these insights. Just knowing the kernel primitives gives you a troubleshooting map that docker logs doesn't provide.

If you're running a homelab on Proxmox, I covered the full setup in my Proxmox Homelab: Setup on a Mini PC, Ubuntu VMs & Beyond. And if you're experimenting with running workloads on older hardware, my Run AI Models on Old Hardware — 10 Year Old Xeon Guide shows what's possible when you understand the hardware-software boundary — which is the same mindset this container deep-dive builds.

The Kernel Is the Platform

Containers aren't lightweight VMs. They're processes with kernel-enforced blindfolds. The magic isn't in Docker Engine or containerd or runC. It's in Linux kernel primitives that have been developed and refined over many years.

Build the minimal version once — even if you never run it again. Once you've called pivot_root by hand and watched a process wake up inside a different filesystem, Docker stops being a mysterious platform and becomes what it actually is: a well-designed convenience layer on top of Linux primitives you can use yourself.

Am I Overcomplicating This? — The Minimal Homelab That Actually Works

Mike — Wed, 17 Jun 2026 02:30:46 +0000

Am I Overcomplicating This? — The Minimal Homelab That Actually Works

Scroll through r/homelab for ten minutes and you'll see server racks that look like data center colocations. 42U cabinets. Enterprise switches with SFP+ cages blinking amber. Dual Xeon boxes drawing 400 watts. Kubernetes clusters running on five nodes for a Plex server and Pi-hole.

I get it. The hardware is cool. The blinking lights are satisfying. And there's a real dopamine hit from provisioning a VM through Proxmox the first time.

But here's the thing: most of that gear sits idle 23 hours a day. The average homelab runs Plex, a few Docker containers, maybe Home Assistant, and a file share. That workload fits on a $150 mini PC with room to spare.

After a year of running my own setup, here's what I've learned about building a homelab that actually earns its keep — without the overcomplication.

The Problem With Homelab Culture

The homelab community has a scaling problem, and it's not technical. It's social. When every top post on Reddit shows a half-rack of enterprise gear, the message is clear: this is what a real homelab looks like.

New people internalize that. They think they need a managed switch to run Docker. They spend weekends reading about VLANs before they've deployed a single container. They price out Dell PowerEdge servers when a used Optiplex would crush the same workload at 10% of the power draw.

I almost fell into this trap myself. Before I bought my BMAX Pro 8, I spent two weeks researching rack-mount cases and PoE switches. For what? A Plex server and a few dev tools?

The turning point was realizing I could list every service I actually wanted to run on a Post-it note. If your requirements fit on a sticky note, they'll fit on a mini PC.

What You Actually Need (vs. What You Don't)

Let's cut through the noise. Here's the honest breakdown.

You Need	You Don't Need
A small, quiet PC with 16+ GB RAM	A rack-mounted server with dual PSUs
Docker Compose	Kubernetes (unless you're learning it for work)
One or two SSDs	A NAS with 8 drive bays and ZFS
A basic router with port forwarding	A managed switch with VLAN segmentation
SSH + terminal	iDRAC / iLO / IPMI
A GitHub repo of your compose files	Ansible playbooks for 3 machines
Uptime Kuma for monitoring	Grafana + Prometheus + Loki stack

None of the "don't need" items are wrong. If you're a network engineer learning VLANs for a certification, buy the managed switch. If you run a business from your homelab, sure, invest in redundancy. But for the rest of us — developers, tinkerers, people who want Plex and a few containers — the simple version works.

My Stack: One Box, Docker Compose, Done

Here's what I actually run. One BMAX Pro 8 mini PC with an Intel i7-1260P and 24 GB of DDR4 RAM. It's silent, draws about 25 watts, and cost me roughly $150 used. It sits on a shelf behind my monitor. No rack. No UPS. No blinking switch.

On this one box, I run:

Plex Media Server — streaming to two TVs and my phone. Transcoding works fine for 1080p content on the Intel Iris Xe iGPU.
Radarr, Sonarr, qBittorrent — the standard media automation stack. I wrote a full guide on setting these up on Ubuntu if you want the step-by-step.
Hermes Agent — an always-on AI assistant I set up on this mini PC. Handles cron jobs, answers questions, manages my kanban board.
n8n — workflow automation. I use it to cross-post blog content, send notifications, and run scheduled tasks.
Uptime Kuma — a dead-simple status page. I know within 30 seconds if a service goes down.
Ollama — local LLM inference. Small models like Gemma 4 2B and Llama 3.2 3B run at 10-15 tokens per second. Good enough for quick coding help and drafting. I covered the hardware requirements in detail in my old-hardware AI guide.
A few Postgres instances — one per project. Lightweight, no noticeable CPU impact.

All of this runs through Docker Compose. One docker-compose.yml file. One command to bring everything up:

docker compose up -d

That's it. No Kubernetes manifests. No Helm charts. No Terraform. Just a compose file checked into a private GitHub repo so I can rebuild from scratch in ten minutes if the SSD dies.

Why Not Proxmox?

I have a full Proxmox guide on this site, so I'm not anti-Proxmox. It's great for learning virtualization, isolating services into separate VMs, and experimenting with different operating systems.

But if you're running a handful of Docker containers, Proxmox adds a layer you don't need. Docker already isolates services. Adding a hypervisor underneath means more RAM overhead, more disk space for VM images, and another thing to update. On a 24 GB machine, every gigabyte counts.

Start without Proxmox. If you later need a Windows VM or want to run multiple Linux distros side by side, the Proxmox guide is there. But don't install it because Reddit told you to.

The Services That Actually Get Used

Here's something I've noticed after a year: about 80% of the services I've ever deployed got abandoned within a month. The ones that stick are the ones that solve a real, recurring problem.

The test is simple. If you'd notice within 24 hours that a service went down, it's worth running. If you'd go a week without realizing it crashed, delete it. It's burning RAM and adding maintenance overhead for nothing.

My keepers:

Media server stack. If you watch content, Plex/Jellyfin + Radarr/Sonarr is the core that justifies the whole machine.
A status monitor. Uptime Kuma takes 30 seconds to deploy and saves you from the "is the server down or is my internet out?" panic. It sends a Telegram notification when something fails.
One automation tool. n8n, Node-RED, or just a cron job. Pick one. Don't run three.
A local AI. Having an LLM that works during internet outages and doesn't log your prompts? Worth the RAM. Start with Ollama and gemma4:2b.

Everything else — databases, caches, message queues — you spin up when a project needs them, not before.

Cost Breakdown: Minimal vs. Overcomplicated

Here's what a year of homelab looks like at two different scales.

	Minimal ($150 mini PC)	Overcomplicated (rack server)
Hardware	$150 (used mini PC)	$800+ (used server + rack + switch)
Power (annual)	~$25 (25W × 24h × 365d × ~$0.12/kWh)	~$420 (400W × 24h × 365d × ~$0.12/kWh)
Noise	Silent	50-60 dB (fridge-level hum)
Space	Fits behind a monitor	Needs a closet or basement
Maintenance	`docker compose pull && docker compose up -d`	Firmware updates, drive replacements, switch configs
Year 1 total	~$175	~$1,220

That $1,000+ difference buys you… what? Faster Plex transcoding you won't notice? Redundant power supplies for a setup where "downtime" means you can't watch a movie for an hour?

If you're running a business from your homelab, the overcomplicated setup might make sense. For the rest of us, the mini PC wins on every metric that matters: cost, noise, power, and time spent on maintenance.

How to Start Your Minimal Homelab Today

If you're reading this and feeling overwhelmed by homelab Reddit, here's your escape plan:

1. Buy a used mini PC or thin client. Look for an Intel N100 or better with 16 GB RAM. The BMAX Pro 8, a used Dell Optiplex Micro, or a Lenovo ThinkCentre Tiny — all under $200 on eBay. Avoid anything with a fan loud enough to hear across the room.

2. Install Ubuntu Server LTS. Not Debian. Not Arch. Not Proxmox. Ubuntu Server has the largest package ecosystem, the most Docker Compose tutorials written for it, and it just works. You can switch later.

3. Install Docker and Docker Compose. Follow the official Docker install guide. Three commands, done.

4. Pick ONE service to start. Plex. Pi-hole. Home Assistant. Whatever you'd actually use tomorrow. Deploy it with a compose file. Get it working. Use it for a week. Then add the next thing.

5. Check your compose file into a private GitHub repo. If your SSD dies, you should be able to rebuild your entire setup by cloning a repo and running docker compose up -d. That's the goal. If you need a 20-step recovery procedure involving Proxmox backups and VM snapshots, you've already overcomplicated it.

6. Resist the urge to add infrastructure. You don't need Traefik when your services listen on different ports. You don't need a reverse proxy when you can just type 192.168.1.50:32400 in your browser. You don't need VLANs when everything runs on one machine. Add complexity only when a specific problem demands it.

Build What You'll Actually Use

The best homelab isn't the one with the most blinking lights or the highest spec sheet. It's the one that runs the services you use every day, stays out of your way, and doesn't make you dread update weekends.

If a $150 mini PC handles everything on your list, you've won. You've got a homelab that works, costs nearly nothing to run, and leaves you with time to actually use the services you're hosting — instead of spending every Saturday debugging why the Kubernetes ingress controller won't pick up your new cert.

Start small. Add only what you need. And if someone on Reddit tells you that you need a 10Gbps switch for your Plex server, close the tab.

OpenCV 5 is coming — Get Started with Computer Vision in Python for CS Students

Mike — Thu, 11 Jun 2026 12:48:30 +0000

You've written Python programs that print to the terminal, read files, and maybe even scraped a website. But have you written code that can see? Code that can detect edges in a photograph or find faces in a group picture?

That's computer vision — and it's not as hard to get started as you might think.

OpenCV (Open Source Computer Vision Library) is the tool that makes it possible. Version 5 was announced this June with the biggest set of improvements in years: cleaner Python bindings, named parameters so you're not guessing argument order, and a leaner, faster core. If you're a CS student who knows Python basics, you can be running real computer vision code in under an hour.

What Is OpenCV — and Why Version 5 Matters

OpenCV has been the standard library for computer vision since it was first released by Intel in 2000. It's written in C++ for speed but has Python bindings that make it accessible to anyone. If you've ever used a face unlock on your phone, seen a self-driving car detect pedestrians, or watched a Snapchat filter track your face — there's a good chance OpenCV is somewhere in the pipeline.

Version 5 is a major cleanup release. The OpenCV team stripped out decades of legacy code: the old C API is gone (cvCreateMat() and friends, retired), Python 2 support is dropped (Python 3.6+ only), and the classic machine learning module has been moved to opencv_contrib (the team recommends scikit-learn instead). The Features module got a significant upgrade — renamed from Features2D, it now handles feature vectors from modern deep networks and includes new detectors like ALIKED and DISK, plus the LightGlue feature matcher.

For Python developers, the biggest quality-of-life change is named parameters. In OpenCV 4 you had to remember argument order for every function — cv2.rectangle(img, (x1,y1), (x2,y2), (255,0,0), 2). In OpenCV 5 you can write cv2.rectangle(img, pt1=(x1,y1), pt2=(x2,y2), color=(255,0,0), thickness=2). That alone makes the library far more approachable for beginners.

Under the hood, OpenCV 5 requires C++17, runs a cleaner hardware acceleration layer, and has proper support for FP16/BF16 tensor types. Both the 4.x and 5.x branches are actively maintained, with improvements backported between them — so you're not on a dead-end branch.

Installation — One Line and You're Running

OpenCV 5 was announced on June 4, 2026 with a pip release pending. The command below works with both OpenCV 4.x and 5.x. As of this writing, pip install opencv-python gives you the latest 4.x release (4.13.0.92). Once the 5.0 pip package ships, the same package on PyPI will give you 5.x.

pip install opencv-python

That's it. To verify everything worked, fire up a Python shell:

import cv2
print(cv2.__version__)   # 4.13.x from pip today; 5.x.x once the pip package ships

The code in this guide works with both OpenCV 4.x (from pip) and 5.x (from source). No compilers, no system packages, no fighting with CMake. (If you need the extra modules from opencv_contrib — things like ArUco markers or the xfeatures2d module — install opencv-contrib-python instead.)

For a faster alternative to pip, check out my guide on switching to uv — Python's newer package manager.

I recommend setting up a dedicated virtual environment for your computer vision experiments. If you're not sure how, I've written a full guide on setting up a Python development environment that walks you through it.

Core Operations — Read, Write, Transform

Every computer vision project starts with the same three steps: load an image, do something to it, save or display the result.

import cv2

# Read an image from disk
img = cv2.imread("photo.jpg")

# Display it (press any key to close)
cv2.imshow("Original", img)
cv2.waitKey(0)

# Save the result
cv2.imwrite("output.jpg", img)

Watch out: OpenCV loads images in BGR format, not RGB. If you pass an OpenCV image to matplotlib or PIL, the colours will look wrong. The fix is a one-liner:

img_rgb = cv2.cvtColor(img, cv2.COLOR_BGR2RGB)

Resize, Crop, and Rotate

These are the three most common transformations — and they're all one or two lines each.

# Resize to a specific width and height
resized = cv2.resize(img, (640, 480))

# Crop — NumPy array slicing. Format: img[y1:y2, x1:x2]
cropped = img[100:400, 200:500]

# Rotate — get the rotation matrix, then apply it
h, w = img.shape[:2]
center = (w // 2, h // 2)
M = cv2.getRotationMatrix2D(center, angle=45, scale=1.0)
rotated = cv2.warpAffine(img, M, (w, h))

Since OpenCV images are NumPy arrays behind the scenes, you can use all your usual NumPy tricks — slicing, stacking, arithmetic — directly on the image data.

Colour Spaces — RGB, Grayscale, and HSV

Colour space conversion is fundamental to computer vision. OpenCV makes it trivial:

# Grayscale
gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)

# HSV (Hue, Saturation, Value)
hsv = cv2.cvtColor(img, cv2.COLOR_BGR2HSV)

Why does this matter? Grayscale simplifies everything — edge detection, thresholding, and most analysis algorithms work on single-channel images. HSV is useful for colour-based segmentation: isolating objects by colour is far easier in HSV than RGB because the hue channel separates colour from brightness.

If you're studying A-Level Computer Science, this connects directly to the syllabus: image representation (pixels, colour depth, resolution) appears in Paper 1 Theory. For a deeper dive into how computers represent data, check out my Number Systems Visual Guide.

Basic Image Processing — Blur, Detect Edges, Threshold

These three operations form the backbone of most computer vision pipelines. Each is a single function call in OpenCV.

Blurring (Smoothing)

Blurring reduces noise and detail — useful as a pre-processing step before edge detection.

# Gaussian blur — the workhorse
blurred = cv2.GaussianBlur(img, (5, 5), 0)

# Simple averaging blur
blurred_avg = cv2.blur(img, (5, 5))

The (5, 5) is the kernel size — a bigger number means more blur.

Canny Edge Detection

This is the classic algorithm. It finds sharp changes in pixel intensity and draws them as white lines on a black background. Here's the entire pipeline in three lines:

gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)    # Step 1: grayscale
blurred = cv2.GaussianBlur(gray, (5, 5), 0)     # Step 2: smooth
edges = cv2.Canny(blurred, threshold1=50, threshold2=150)  # Step 3: detect

The two thresholds control sensitivity. Any gradient above 150 is definitely an edge. Below 50 is definitely not. Between 50 and 150, it's an edge only if it connects to a strong edge. This dual-threshold approach is what makes Canny so reliable — it catches real edges while ignoring noise.

If you're curious about the underlying maths: Canny computes the image gradient (rate of change) in the x and y directions, finds the magnitude and direction of each gradient, then applies non-maximum suppression to thin the edges. It's a beautifully simple algorithm that's been the standard since 1986.

Thresholding

Thresholding converts a grayscale image to pure black and white based on a cutoff value.

gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)
_, binary = cv2.threshold(gray, thresh=127, maxval=255, type=cv2.THRESH_BINARY)

Every pixel below 127 becomes black (0), every pixel above becomes white (255). This is the simplest form of image segmentation and the foundation for more advanced techniques like adaptive thresholding and Otsu's method.

Drawing Shapes and Text

OpenCV can draw directly onto images — useful for annotating detection results or visualising data.

# Rectangle — perfect for bounding boxes
cv2.rectangle(img, pt1=(50, 50), pt2=(200, 200), color=(0, 255, 0), thickness=2)

# Circle
cv2.circle(img, center=(320, 240), radius=50, color=(0, 0, 255), thickness=-1)  # -1 fills it

# Line
cv2.line(img, pt1=(0, 0), pt2=(640, 480), color=(255, 0, 0), thickness=3)

# Text
cv2.putText(img, text="Hello OpenCV", org=(50, 450),
            fontFace=cv2.FONT_HERSHEY_SIMPLEX, fontScale=1.0,
            color=(255, 255, 255), thickness=2)

Notice the named parameters — pt1=, color=, thickness= — this is the OpenCV 5 Python improvement at work. No more remembering whether thickness comes before or after the colour tuple.

Mini-Project — Face Detection in 15 Lines

Let's pull everything together with a working face detector. OpenCV ships with pre-trained Haar cascade classifiers — XML files that describe what a frontal face looks like in terms of simple features (edges, lines, rectangles at different scales).

Here's the full script:

import cv2

# Load the pre-trained face cascade
face_cascade = cv2.CascadeClassifier(
    cv2.data.haarcascades + "haarcascade_frontalface_default.xml"
)

# Read the image
img = cv2.imread("group-photo.jpg")
gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)

# Detect faces
faces = face_cascade.detectMultiScale(
    gray, scaleFactor=1.1, minNeighbors=5, minSize=(30, 30)
)

# Draw rectangles around each face
for (x, y, w, h) in faces:
    cv2.rectangle(img, pt1=(x, y), pt2=(x + w, y + h),
                  color=(0, 255, 0), thickness=2)

# Save and display
cv2.imwrite("faces-detected.jpg", img)
print(f"Found {len(faces)} face(s). Output saved.")

The parameters worth understanding:

scaleFactor=1.1 — the image is scaled down by 10% at each pass. Smaller values (like 1.05) are more accurate but slower.
minNeighbors=5 — how many overlapping detections are needed to confirm a face. Higher values reduce false positives.
minSize=(30, 30) — ignore anything smaller than 30×30 pixels.

Run this on a group photo and you'll get bounding boxes around every face the cascade finds. It's not perfect — Haar cascades are 2001-era technology and can miss faces at odd angles or in poor lighting — but for a 15-line script, the result is impressive.

If you want to try live face detection from a webcam, swap the image loading for a video capture loop:

cap = cv2.VideoCapture(0)  # 0 = default webcam

while True:
    ret, frame = cap.read()
    gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY)
    faces = face_cascade.detectMultiScale(gray, 1.1, 5, minSize=(30, 30))

    for (x, y, w, h) in faces:
        cv2.rectangle(frame, (x, y), (x + w, y + h), (0, 255, 0), 2)

    cv2.imshow("Live Face Detection", frame)
    if cv2.waitKey(1) & 0xFF == ord("q"):
        break

cap.release()
cv2.destroyAllWindows()

Press q to quit. That's real-time computer vision running on your machine.

Where to Go Next

You've covered the fundamentals: loading images, transforming them, detecting edges, and finding faces. From here, OpenCV opens up into a much larger world:

Object tracking — follow a moving object across video frames with cv2.Tracker APIs.
Optical character recognition (OCR) — extract text from images using OpenCV's EAST text detector or pairing OpenCV with Tesseract.
Feature matching — find the same object in two different images using ORB or SIFT, then use the new LightGlue matcher for better accuracy.
Deep learning integration — OpenCV's dnn module can load models from TensorFlow, PyTorch, and ONNX. You can run YOLO object detection or image classification directly within OpenCV.
Training your own detector — once you're comfortable with Haar cascades, try training a custom cascade for a specific object (your face, a logo, a particular object).

The official OpenCV Python tutorials at docs.opencv.org are excellent, and the opencv/samples/python directory in the GitHub repo contains dozens of working examples — from camera calibration to augmented reality.

If Python debugging is still something you're working on, I've got a guide on reading tracebacks and finding bugs that covers the skills you'll need when your computer vision code doesn't do what you expect.

Computer vision is one of those topics where the theory clicks when you see the output. Reading about edge detection is fine — seeing your own photo turned into crisp white outlines is better. The code examples in this guide are all self-contained; copy them, swap in your own images, and experiment. Change the thresholds and kernel sizes. Try different cascade files. The fastest way to learn OpenCV is to break things and figure out why they broke.

Cambridge 9618 Paper 1 Theory Fundamentals — AS Computer Science Topic Guide

Mike — Mon, 08 Jun 2026 13:23:51 +0000

The June 2026 Cambridge AS/A-Level Computer Science Paper 1 (9618) has just been sat. If you took it, you're probably wondering how you did. If you're preparing for a future sitting, you want to know what topics come up and how to score full marks.

I've been teaching Cambridge A-Level CS for over a decade, and I've seen the same patterns repeat across every Paper 1 — the same topics, the same question styles, and the same mistakes that cost students easy marks.

This guide covers the AS theory topics assessed in Cambridge 9618 Paper 1: sections 1–8 of the syllabus. For each section, I'll show you what examiners look for, the question styles that commonly appear, model answers, and the pitfalls that catch students out.

If you sat the 2025 paper, you can also check out my full June 2025 Paper 1 walkthrough series for comparison.

Paper 1 at a Glance

Paper 1 tests theory — no programming. It's worth 75 marks over 1 hour 30 minutes. The questions cover the AS syllabus: sections 1–8.

These are the topic areas that commonly appear, along with the relative weight examiners tend to give them:

Section	Topic	Common Revision Areas
1	Information representation	Binary, hex, two's complement, BCD, sound and image representation
2	Communication	Protocols, packet switching, network topologies, internet technologies
3	Hardware	Logic gates, Boolean algebra, input/output/storage devices
4	Processor fundamentals	Von Neumann architecture, registers, fetch-execute cycle, interrupts, assembly language
5	System software	Operating systems, utility software, language translators, IDEs
6	Security, privacy and data integrity	Threats, security measures, encryption, validation vs verification
7	Ethics and ownership	Professional ethics, copyright, software licensing, AI impact
8	Databases	Primary/foreign keys, SQL, normalisation

Examiners award marks for individual components — not just whether your answer is right. You can pick up 6 out of 8 marks on a question even if your final answer is incomplete, as long as each correct part earns its allocation.

1. Information Representation

This section appears on every paper and tests conversion fluency. You need to convert between denary, binary, hexadecimal, two's complement, and BCD without hesitation. For a deeper dive into binary and hex with visual examples, see my Number Systems Visual Guide.

Binary → Denary → Hex

Denary	Binary (8-bit)	Hex
45	0010 1101	2D
170	1010 1010	AA
255	1111 1111	FF

Two's Complement

Two's complement represents negative numbers so the CPU can perform subtraction using addition. To find the two's complement: invert all bits, then add 1.

Example — Represent –45 in 8-bit two's complement:

Write +45 in 8-bit binary: 0010 1101
Invert all bits (one's complement): 1101 0010
Add 1: 1101 0011

So –45 is 1101 0011 in 8-bit two's complement.

Range: 8-bit = −128 to +127, 16-bit = −32,768 to +32,767.

Common mistake: Mixing up the range formula. For n bits: −2^(n−1) to +2^(n−1) − 1.

BCD (Binary-Coded Decimal)

Represent each decimal digit as its own 4-bit binary number. Used where exact decimal representation matters (calculators, digital displays).

Example — Represent 257 in BCD:

2 → 0010
5 → 0101
7 → 0111 Result: 0010 0101 0111

Common mistake: Converting the whole number to binary (257 = 1 0000 0001) instead of encoding each digit separately.

Sound and Image Representation

Paper 1 often includes questions on how computers represent multimedia:

Bitmap images: a grid of pixels, each assigned a colour value. Resolution = width × height in pixels. Colour depth = bits per pixel.
Sound sampling: converting analogue sound to digital by taking samples at regular intervals. Sample rate (Hz) and bit depth determine quality. File size = sample rate × bit depth × duration × channels.

Common mistake: Confusing sample rate (how often we measure) with bit depth (how many bits per measurement).

2. Communication

Protocols

The examiner wants to know what each protocol does, not just its name.

Protocol	Layer/Purpose	What It Does
TCP	Transport	Reliable, connection-oriented delivery with error checking, acknowledgements, and sequencing
IP	Network	Routes packets across networks using IP addresses — connectionless, no delivery guarantee
HTTP/HTTPS	Application	Transfers web pages; HTTPS adds SSL/TLS encryption
FTP	Application	Transfers files between client and server
SMTP	Application	Sends email from client to server
POP3/IMAP	Application	Retrieves email from server to client

Model answer — "Explain the difference between TCP and IP":

IP handles addressing and routing — it gets packets from source to destination across networks but does not guarantee delivery. TCP runs on top of IP and adds reliability: it numbers packets, acknowledges receipt, retransmits lost packets, and reassembles them in the correct order at the destination.

Packet Switching

Model answer — "Describe how packet switching works":

Data is split into packets. Each packet contains a header (source/destination IP, sequence number, checksum) and a payload (the data). Packets travel independently across the network through routers. Each router reads the destination address and forwards the packet to the next hop using its routing table. At the destination, packets are reassembled into the correct order using sequence numbers.

Common mistake: Forgetting to mention sequence numbers or reassembly. The fact that packets can arrive out of order is the whole point.

3. Hardware

Logic Gates & Boolean Algebra

You need to be able to:

Draw logic circuits from Boolean expressions
Complete truth tables for AND, OR, NOT, NAND, NOR, XOR
Simplify expressions using Boolean algebra

Gate	Symbol	Truth Table (A,B → Output)
AND	A·B	(0,0)→0, (0,1)→0, (1,0)→0, (1,1)→1
OR	A+B	(0,0)→0, (0,1)→1, (1,0)→1, (1,1)→1
NOT	Ā	0→1, 1→0
NAND	¬(A·B)	(0,0)→1, (0,1)→1, (1,0)→1, (1,1)→0
NOR	¬(A+B)	(0,0)→1, (0,1)→0, (1,0)→0, (1,1)→0
XOR	A⊕B	(0,0)→0, (0,1)→1, (1,0)→1, (1,1)→0

Common mistake: Confusing NAND and NOR outputs. NAND = "NOT AND" — it's 1 unless both inputs are 1. NOR = "NOT OR" — it's 0 unless both inputs are 0.

Input and Output Devices

Paper 1 commonly asks you to describe how devices work:

Sensors: measure physical quantities (temperature, light, pressure) and convert them to digital signals via an ADC
Touchscreens: capacitive (detects electrical charge from finger) vs resistive (pressure on two layers)
Printers: laser (toner fused by heat), inkjet (liquid ink sprayed through nozzles), 3D (additive manufacturing)

Common mistake: Describing what a device does instead of how it works. Examiners want the mechanism.

4. Processor Fundamentals

This is almost always Question 1, and it's worth a lot of marks.

Von Neumann Architecture

The Von Neumann model uses a single memory store for both data and instructions. Examiners want you to name registers and explain what they do — not just list them.

Key registers:

PC (Program Counter): stores the address of the next instruction — not the instruction itself
MAR (Memory Address Register): holds the address being read from or written to
MDR (Memory Data Register): holds the data that has been read from or is about to be written to the address in MAR
CIR (Current Instruction Register): holds the instruction currently being decoded or executed
ACC (Accumulator): stores intermediate results from the ALU
IX (Index Register): used for indexed addressing — modifies operand addresses
Status Register: holds flags (carry, overflow, negative, zero) set by the ALU

Common mistake: Students say "the PC stores the instruction." It stores the address of the next instruction. The instruction itself goes into the CIR after being fetched.

Model answer — "Describe the role of the PC and MAR during the fetch stage":

The PC holds the address of the next instruction to be fetched. This address is copied to the MAR. The MAR sends this address along the address bus to memory. The instruction at that address is then retrieved and placed into the MDR via the data bus, and transferred to the CIR for decoding.

The Fetch-Execute Cycle

You'll be asked to describe the cycle or annotate Register Transfer Notation (RTN). Here's the sequence:

MAR ← [PC]           // Copy PC to MAR
PC ← [PC] + 1        // Increment PC
MDR ← [[MAR]]        // Fetch instruction from memory
CIR ← [MDR]          // Copy instruction to CIR
// Decode: Control Unit decodes the instruction in CIR
// Execute: Instruction is carried out (may involve ALU, ACC, memory reads/writes)

Common mistake: Forgetting to increment the PC during fetch, or incrementing it at the wrong point. The PC increments after its value is copied to the MAR.

Interrupts

An interrupt is a signal from a device or software that pauses the current process so the CPU can handle something urgent.

Model answer — "Explain how the CPU handles an interrupt from a keyboard":

At the start or end of each fetch-execute cycle, the CPU checks the interrupt register. If an interrupt is present, its priority is compared against the current task. If the interrupt has higher priority, the current contents of registers (PC, ACC, CIR, etc.) are saved to the stack. The CPU then loads and executes the Interrupt Service Routine (ISR) for the keyboard. When the ISR completes, the saved register values are restored from the stack, and the original program resumes.

Common mistake: Students forget to mention the stack, priority checking, or that the interrupt is checked at the start/end of each F-E cycle.

Assembly Language & Addressing Modes

Assembly language uses mnemonics (LDM, ADD, STA, CMP, JMP) instead of machine code. Each instruction translates to an opcode + operand.

Mode	Operand Is	Example
Immediate	The actual value	`LDM #45` loads value 45
Direct	A memory address	`ADD 10` adds contents of address 10
Indirect	A pointer to the address	`LDM (20)` uses contents of address 20 as pointer to data
Indexed	Base address + offset	`LDM 100,X` loads from address (100 + contents of IX)
Relative	Offset from current instruction	`JMP -6` jumps backward 6 instructions

Common mistake: Thinking immediate addressing uses a memory address. The # symbol tells you it's immediate — the operand is the value.

5. System Software

This section tests your understanding of what keeps a computer running beyond the hardware.

Operating System Functions

An operating system manages:

Memory management: allocating RAM to programs, freeing it when programs close, preventing programs from accessing each other's memory
Process management: scheduling which program runs on the CPU at any moment (round-robin, priority-based)
File management: organising files into a directory structure, controlling read/write access
Security management: user accounts, passwords, access rights
Hardware management: communicating with devices through device drivers

Common mistake: Listing OS functions without explaining what each one actually does. "The OS manages memory" doesn't get full marks. Say how — allocates, tracks, frees.

Utility Software

Utilities perform specific maintenance tasks:

Disk defragmentation: reorganises fragmented files into contiguous blocks for faster access (only needed on HDDs, not SSDs)
Virus checkers: scan files for known malware signatures
Backup software: creates copies of data for recovery
File compression: reduces file size for storage or transmission

Language Translators

Translator	What It Does	Pros	Cons
Assembler	Converts assembly code to machine code	Fast execution, direct hardware access	Platform-specific, harder to write
Compiler	Translates whole source code to machine code at once	Fast execution, optimised output	Slow during development — must recompile after every change
Interpreter	Translates and executes line by line	Faster debugging, no compile step	Slower execution, must be present to run

Common mistake: Saying a compiler "runs" the code. It translates it. The compiled executable runs.

6. Security, Privacy and Data Integrity

Security Threats

Malware: viruses (self-replicating, attaches to files), worms (spreads across networks without user action), spyware (monitors user activity)
Hacking: unauthorised access to a computer system
Phishing: fraudulent emails or websites that trick users into revealing personal data
Pharming: redirecting a legitimate website's traffic to a fake site

Security Measures

Measure	What It Does
Firewall	Monitors and filters incoming/outgoing network traffic based on rules
Encryption	Scrambles data so only authorised parties with the key can read it
Access rights	Restricts what users can read, write, or execute
Antivirus	Scans for and removes known malware using signature databases
Digital signatures	Verifies the authenticity and integrity of a message or document

Model answer — "Explain two security measures a school network should implement":

A firewall should be installed to filter incoming and outgoing traffic, blocking unauthorised access attempts. User accounts with passwords and access rights should be set up so students can only access their own files and appropriate network resources.

Validation vs Verification

This is a classic exam question. Students regularly confuse the two.

Validation: checking whether data is reasonable or meets specified criteria before it's accepted (range check, length check, format check, presence check)
Verification: checking whether data has been entered or transferred correctly (double entry, visual check, checksum)

Common mistake: Describing validation as "checking if data is correct." Validation checks if data is possible, not if it's correct. A date of birth of 31/02/2010 passes a format check but is still wrong — only verification catches that.

7. Ethics and Ownership

Professional Ethics

The syllabus expects you to discuss the ethical responsibilities of computer professionals:

Respecting intellectual property and copyright
Protecting user privacy and data
Being honest about system capabilities and limitations
Considering the societal impact of technology

Software Licensing

Type	Description
Free software	Users can run, study, modify, and redistribute (e.g., Linux)
Open source	Source code is publicly available; may have restrictions on redistribution
Shareware	Free to try for a limited time; payment required for full version
Commercial	Requires purchase; source code typically not available

Common mistake: Using "free software" and "open source" interchangeably. Free software is about user freedom — open source is about code availability. They overlap but aren't the same thing.

AI and Ethics (Brief)

The AS syllabus includes AI ethics in section 7 — not the technical details of how AI works, but its impact on society. Students should be able to discuss:

Employment: AI automating jobs in manufacturing, customer service, and data entry
Bias: AI systems trained on biased data producing discriminatory outcomes
Privacy: AI-powered surveillance and data collection

Keep AI-related answers focused on ethical impact, not technical function. That's what section 7 tests.

8. Databases

SQL questions give you a table structure and ask you to write queries. You need SELECT, INSERT, UPDATE, and DELETE.

Example schema:

Student(StudentID, Name, DateOfBirth, TutorGroup)
Course(CourseID, Title, Department)
Enrolment(StudentID, CourseID, Grade)

Model answer — "List all students in TutorGroup '12A' who have Grade 'A' in any course":

SELECT DISTINCT Student.Name
FROM Student
JOIN Enrolment ON Student.StudentID = Enrolment.StudentID
WHERE Student.TutorGroup = '12A'
AND Enrolment.Grade = 'A';

Common mistake: Forgetting DISTINCT when a student could have multiple A grades, or missing the JOIN condition (causing a Cartesian product).

Primary and Foreign Keys

Primary key: uniquely identifies each record in a table (e.g., StudentID in Student)
Foreign key: an attribute in one table that references the primary key of another table (e.g., StudentID in Enrolment references Student.StudentID)

Common mistake: Saying a foreign key is unique in its own table. It's not — the same StudentID appears in many Enrolment rows.

Normalisation

Paper 1 often includes a question about database normalisation:

First Normal Form (1NF): no repeating groups; each cell holds a single value
Second Normal Form (2NF): 1NF + no partial dependencies (every non-key attribute depends on the whole primary key)
Third Normal Form (3NF): 2NF + no transitive dependencies (non-key attributes don't depend on other non-key attributes)

Common mistake: Describing 2NF without first establishing that the table is in 1NF. You must state each form as building on the previous one.

Exam Technique for Paper 1

Over a decade of marking, here's what separates A* candidates from the rest:

Read the mark allocation. A [1] mark needs one point. A [4] mark needs four distinct points. Don't write a paragraph for a 1-mark question — move on.
Use the examiner's terminology. If the syllabus calls it "Program Counter," write "Program Counter," not "the thing that holds the next address." You won't lose marks for informal language, but precise terminology shows understanding.
Show your working for calculations. Even if your final answer is wrong, you can pick up method marks for correct conversions, correct formulas, or correct intermediate steps.
Don't repeat the question in your answer. "The Program Counter stores the address of the next instruction" gets the mark. "The PC is a register that is used for storing the address" says the same thing with more words.
For "explain" and "describe" questions, give a reason. "The stack uses LIFO" is a statement. "The stack uses LIFO because the most recently pushed item is always the first one accessed" is an explanation.
Time management: Paper 1 is 75 marks in 90 minutes — roughly 72 seconds per mark. Don't spend 10 minutes on a 4-mark question. Mark it, move on, come back if you have time.

What This Means for Paper 2

Paper 1 covers the theory. Paper 2 tests practical programming — pseudocode, algorithm design, and problem-solving. If you've just finished Paper 1, here's what to focus on next:

Writing pseudocode procedures with loops and conditionals
File handling commands: OPEN, READ, WRITE, CLOSE
Arrays: declaration, traversal, searching
Algorithm tracing — given pseudocode and inputs, predict the output

If you need a programming refresher, my Python for Cambridge CS Paper 2 walkthrough covers the same fundamentals for both IGCSE 0478 and AS 9618.

I'll be posting a full Paper 2 topic guide soon — subscribe to the Techie Mike YouTube channel to catch it.

Self-Assessment Checklist

Here's a checklist to mark yourself against after Paper 1. If you can confidently answer "yes" to each, you're in good shape.

[ ] I can convert between denary, binary, hex, two's complement, and BCD
[ ] I can explain how sound is sampled and how bitmap images are represented
[ ] I can describe the role of TCP, IP, HTTP, FTP, SMTP, and POP3/IMAP
[ ] I can explain how packet switching works — including reassembly
[ ] I can draw logic circuits from Boolean expressions and complete truth tables for all gates
[ ] I can describe how sensors, touchscreens, and printers work
[ ] I can name all 7 key registers and explain the role of each
[ ] I can describe the fetch-execute cycle step by step
[ ] I can explain how interrupts are detected and handled — including the stack
[ ] I can identify addressing modes in assembly language instructions
[ ] I can describe the five OS management functions with examples
[ ] I can distinguish between an assembler, compiler, and interpreter
[ ] I can explain at least three security threats and their corresponding countermeasures
[ ] I can clearly distinguish validation from verification with examples
[ ] I can discuss the ethical impact of AI on employment, bias, and privacy
[ ] I can explain free software vs open source vs shareware vs commercial licensing
[ ] I can write SQL queries with SELECT, JOIN, WHERE, and INSERT
[ ] I can explain the difference between primary key and foreign key
[ ] I can describe 1NF, 2NF, and 3NF

That's the full Paper 1 theory coverage for sections 1–8. If you sat the June 2026 paper, I hope this helps you check your answers. If you're preparing for a future sitting, bookmark this — the syllabus topics don't change, and neither do the marking patterns.

Got questions about a specific topic? Drop them in the comments or find me on the Techie Mike YouTube channel where I cover CS exam topics in video form.

Good luck with Paper 2.

VSCode Webview Bug Exposed GitHub Tokens via github.dev

Mike — Fri, 05 Jun 2026 22:00:29 +0000

Just by clicking a link, it's possible for an attacker to steal a GitHub token that can read and write to your repos — including private ones.

This isn't a hypothetical vulnerability or a "theoretical risk" scenario. Security researcher Ammar Askar published a working proof-of-concept on June 2, 2026 that demonstrates the attack against the browser-based version of VSCode. The story hit the front page of Hacker News with over 600 points, and for good reason — it affects anyone who uses GitHub and VSCode.

I use VSCode every day for writing code, editing this blog's Ghost theme, and managing my homelab scripts. So when I saw this, I stopped what I was doing and checked my own setup. Here's what I found, how this bug works in plain terms, and what you need to do to protect yourself.

What's the Attack?

VSCode has a feature called webviews — embedded iframes that render things like Markdown previews and Jupyter notebook outputs. These webviews use a different browser origin (vscode-webview://) from the main editor window (vscode-file://) so that any JavaScript running inside them can't access the core VSCode process. That's the sandbox.

The problem is that webviews need keyboard shortcuts to work. When you press Ctrl+F to search inside a preview, that keypress needs to reach the iframe. VSCode solves this by bubbling up keydown events from the webview to the main window. JavaScript running inside the webview can listen for keypresses and forward them to the host.

Here's the catch — nothing stops a script running inside that webview from pretending to be the user pressing keys. Attackers can dispatch synthetic keyboard events that VSCode treats as real user input.

The Exploit Chain

The attack works against github.dev — the browser-based version of VSCode that GitHub launches when you change github.com to github.dev in a repo URL. GitHub POSTs a full OAuth token to github.dev that has read/write access to all repos you can access, not just the one you're viewing. That token is the prize.

Here's how an attacker chains the exploit together:

Step 1: The Bait

An attacker creates a GitHub repo containing a Jupyter notebook with a malicious payload. Jupyter notebooks rendered in VSCode webviews can execute arbitrary JavaScript using a common trick — an `tag with anonerror` handler:

`html

This executes inside the webview sandbox, which means it can't directly access Node.js APIs or VSCode internals. But it can dispatch keyboard events.

Step 2: Keydown Event Simulation

The attacker's JavaScript waits for VSCode to finish loading, then dispatches a synthetic keyboard event:

`javascript window.dispatchEvent( new KeyboardEvent("keydown", { key: "a", code: "KeyA", keyCode: 65, ctrlKey: true, shiftKey: true }) ); `

The keyboard shortcut Ctrl+Shift+A maps to Notifications: Accept Notification Primary Action — a default VSCode keybinding that clicks the primary button on whatever notification is currently displayed.

Step 3: Extension Installation

The malicious repo includes a .vscode/extensions.json file that recommends a workspace extension:

`json { "recommendations": [ "HackerMan.evil-extension" ] } `

When VSCode opens the repo, it pops up a notification: "This workspace recommends extensions. Install?" The attacker's JavaScript accepts that notification via the Ctrl+Shift+A shortcut.

But there's a catch — newer versions of VSCode show a publisher trust dialog before installing extensions from unknown publishers. The exploit bypasses this by using a local workspace extension placed in .vscode/extensions/ inside the repo. Local extensions skip the publisher trust check if the workspace is trusted, which github.dev workspaces are by default.

Step 4: Custom Keybinding Escalation

The local workspace extension can't execute arbitrary code directly (Content Security Policy blocks it on the web version). But it can contribute custom keybindings to VSCode. The package.json adds a keybinding that calls workbench.extensions.installExtension with skipPublisherTrust: true:

`json "contributes": { "keybindings": [ { "key": "ctrl+f1", "command": "runCommands", "args": { "commands": [{ "command": "workbench.extensions.installExtension", "args": [ "HackerMan.real-malicious-extension", { "donotSync": true, "context": { "skipPublisherTrust": true } } ] }] } } ] } `

Step 5: Token Exfiltration

With the real malicious extension installed, the attacker now has full extension-level access inside github.dev. That extension reads the stored GitHub OAuth token and exfiltrates it — along with a list of all your private repos.

The whole chain happens automatically in about 10-15 seconds after you click the link.

Does Desktop VSCode Have the Same Bug?

The one-click attack mainly targeted github.dev, because the victim only had to open a crafted browser link.

Askar noted that related webview behaviour also exists in desktop VSCode, but Microsoft later stated that this specific issue does not affect VS Code Desktop. The practical risk is different: on desktop, an attacker would need a separate route, such as convincing someone to clone a repo and open a malicious notebook or workspace locally.

So the browser-based github.dev version is the bigger concern here. A malicious link is enough to start the chain; desktop exploitation would require more user interaction.

What Has Microsoft Done?

Microsoft responded quickly once Askar disclosed the bug publicly on June 2. According to reports from the VSCode issue tracker, by June 3 Microsoft had merged at least two fixes:

Stopgap fix: Added a confirmation dialog when opening notebooks in the web version of VSCode. This gives users a chance to leave the page before any JavaScript executes.
Complete fix: Blocked the skipPublisherTrust bypass for commands called via keybindings. Also prevented keydown event bubbling from notebook webviews.

The VSCode team's defense-in-depth approach — using CSP headers, script-src 'none' policies, and DOMPurify for Markdown rendering — limited the damage to webviews that can already execute JavaScript (like Jupyter notebook outputs). If a similar bug existed in the Markdown preview, the impact would have been far worse: one-click RCE on desktop from simply viewing an extension page.

How to Protect Yourself

Even with the fixes applied, it's worth locking down your setup. Here's what I did:

1. Clear github.dev Site Data

If you've ever used github.dev, clear your browser data for the domain. This removes any stored session tokens and forces a fresh authentication flow:

In Chrome:

Click the padlock icon in the URL bar
Go to Cookies and site data > Manage on-device site data
Find github.dev and delete it

In Firefox:

Right-click the page → View Page Info → Permissions → Clear Cookies and Site Data

2. Use Fine-Grained PATs Instead of Full Tokens

GitHub now recommends fine-grained PATs where possible, but classic tokens still exist and may still be needed for some workflows. If you have old classic tokens sitting around, revoke anything you don't actively use and replace broad access with fine-grained tokens scoped to specific repositories and permissions. This is the same kind of security hygiene I've covered in other posts about securing your online accounts — limit what's exposed and rotate what can't be limited.

`bash

Check what tokens the GitHub CLI has cached

gh auth status

Revoke a token via CLI

gh auth logout
`

3. Use `gh` CLI Instead of Token-Based Auth

The GitHub CLI stores OAuth tokens more securely than VSCode extensions do. Switch to using gh for authenticated API calls and git operations:

`bash

Authenticate via browser (safer)

gh auth login

Configure git to use gh as credential helper

gh auth setup-git
`

4. Audit Your VSCode Extensions

I wrote about why you might want to consider alternatives to VSCode in a previous post, but regardless of which editor you use, audit your extensions:

`bash

List all installed VSCode extensions

code --list-extensions

Check for any you don't recognize or haven't used recently

5. Enable Two-Factor Authentication on GitHub

This will not prevent token theft. A stolen OAuth token can still be used for whatever permissions it already has.

But 2FA still helps protect your account against password-based compromise and some account-level changes. Treat it as a safety layer, not a fix for stolen tokens.

The Bigger Picture

This bug is a reminder that VSCode's security model relies heavily on its webview sandbox — and that sandbox has cracks. The attack is creative in how it chains together seemingly unrelated features: keyboard shortcuts, workspace extensions, and publisher trust.

For developers, the takeaway is to treat repository links — especially those pointing to .dev or web-based editors — with the same wariness as executable files. A link to a repo is a link to code, and in this case, that code can act on your behalf.

Askar chose full disclosure rather than responsible disclosure because of a poor experience with Microsoft's Security Response Center (MSRC) on a previous VSCode bug. He argues that public disclosure is the only tool researchers have to push for better security practices. Whether you agree with that approach or not, the result is a bug that got fixed within 24 hours of going public — which is a lot faster than many responsibly-disclosed vulnerabilities I've seen.

References

Original disclosure by Ammar Askar
Proof-of-concept repo
VSCode Issue Tracker
Why Developers Should Consider Using Cursor AI Over VSCode — my previous post looking at VSCode alternatives

Debugging Python for A-Level CS — Reading Tracebacks and Finding Bugs

Mike — Fri, 05 Jun 2026 11:05:03 +0000

Debugging Python for A-Level CS — Reading Tracebacks and Finding Bugs
Read the full guide: https://www.techiemike.com/debugging-python-tracebacks-a-level-cs

DEV Community: Mike

Cloudflare Self-Managed OAuth — What It Means for Your Homelab Security

Cloudflare Self-Managed OAuth — What It Means for Your Homelab Security

What Self-Managed OAuth Actually Is

How It Compares to API Tokens

What This Means for Homelab Users

Setting It Up — Where to Start

High School to Homelab — A Student's Linux Journey

High School to Homelab — A Student's Linux Journey

How I Learned Linux — By Breaking Things

What a Homelab Actually Teaches

Real networking, not textbook networking

Linux administration — not just cd and ls

Troubleshooting as a skill

How homelab skills connect to Cambridge CS topics

The Minimum Viable Student Homelab

The Skills Employers Actually Want

The Thing Nobody Tells You

The Chat Graveyard — How to Export, Search, and Learn from Your AI Conversations

Learning Docker by Building a Container Engine from Scratch

Learning Docker by Building a Container Engine from Scratch

What a Container Actually Is

Lie #1: Namespaces — Controlling What a Process Can See

The Six Namespaces That Matter

Lie #2: cgroups — Controlling What a Process Can Use

Lie #3: The Filesystem — chroot, pivot_root, and Union Mounts

Phase 1: chroot (The Simple Way)

Phase 2: pivot_root (The Proper Way)

Phase 3: OverlayFS (Where Images Come From)

Putting It All Together: The Minimal Container Engine

What Docker Adds (And Why You Should Still Use It)

How I Use This Knowledge in My Own Setup

The Kernel Is the Platform

Am I Overcomplicating This? — The Minimal Homelab That Actually Works

Am I Overcomplicating This? — The Minimal Homelab That Actually Works

The Problem With Homelab Culture

What You Actually Need (vs. What You Don't)

My Stack: One Box, Docker Compose, Done

Why Not Proxmox?

The Services That Actually Get Used

Cost Breakdown: Minimal vs. Overcomplicated

How to Start Your Minimal Homelab Today

Build What You'll Actually Use

OpenCV 5 is coming — Get Started with Computer Vision in Python for CS Students

What Is OpenCV — and Why Version 5 Matters

Installation — One Line and You're Running

Core Operations — Read, Write, Transform

Resize, Crop, and Rotate

Colour Spaces — RGB, Grayscale, and HSV

Basic Image Processing — Blur, Detect Edges, Threshold

Blurring (Smoothing)

Canny Edge Detection

Thresholding

Drawing Shapes and Text

Mini-Project — Face Detection in 15 Lines

Where to Go Next

Cambridge 9618 Paper 1 Theory Fundamentals — AS Computer Science Topic Guide

Paper 1 at a Glance

1. Information Representation

Binary → Denary → Hex

Two's Complement

BCD (Binary-Coded Decimal)

Sound and Image Representation

2. Communication

Protocols

Packet Switching

3. Hardware

Logic Gates & Boolean Algebra

Input and Output Devices

4. Processor Fundamentals

Von Neumann Architecture

The Fetch-Execute Cycle

Interrupts

Assembly Language & Addressing Modes

5. System Software

Operating System Functions

Utility Software

Language Translators

6. Security, Privacy and Data Integrity

Security Threats

Linux administration — not just `cd` and `ls`

3. Use `gh` CLI Instead of Token-Based Auth