DEV Community: crimsondhaks

macOS brightness and volume move in big jumps — Glissé is a free app that makes them smooth

crimsondhaks — Thu, 10 Sep 2026 12:26:58 +0000

The problem

Tap the volume key on a Mac and the level jumps a sixteenth at a time. Brightness behaves the same way. Hold Option and Shift while you tap and you get quarter steps, which helps, but you are still tapping a key over and over to move a small amount — and with brightness you are doing that while staring at a screen that is too bright.

There is no way to simply slide to the value you want.

What Glissé does

Put one finger on the left edge of the trackpad and slide up or down: brightness. Do the same on the right edge: volume.

That is the whole interaction. No clicking, no modifier key to hold down, no window, no overlay. The real macOS HUD appears — the same one the keyboard produces — and the trackpad ticks under your finger as the value moves.

It sits in the menu bar as one small glyph. There is nothing to set up before it works.

What makes it worth installing

It does one thing, and it works the moment you install it. No configuration, no gesture builder, no preference pane to learn. The edges of your trackpad are simply sliders now.

It is free and open source under the MIT licence. No trial, no licence key, no account, no telemetry, no analytics, and no network code of any kind — the app makes no outbound connection, ever. The whole source is on GitHub, so you can read exactly what it does before you run it, or build it yourself if you would rather.

Two things here are easy to fake, and this does not fake them:

The brightness change is the real backlight, not a dark overlay or a gamma trick.
The on-screen display is the actual macOS HUD, not a lookalike drawn by the app.

How it knows you meant it

A gesture only starts if your finger begins inside the edge strip, and only if it is the only finger on the trackpad. A touch that starts in the middle and later wanders to the edge can never activate the slider, for its whole life. It also stops listening for half a second after every keystroke, so typing does not set it off.

Those rules are unglamorous, and they are most of the reason it feels like part of the system rather than something bolted on.

Features

Left edge for brightness, right edge for volume — swappable
Smooth control with the real system HUD
Haptic ticks as the value moves: off, light, medium or strong
Pauses for half a second after every keystroke, so typing never sets it off
Fine-control mode for much smaller changes
Bottom-quarter-only mode, if you ever trigger it by accident
Optional modifier requirement — hold or toggle Control, Option, Command, Shift or Fn
Optional pointer freeze while you slide
Optional three-finger tap as middle click
External monitor brightness over DDC
Launch at login
Menu bar only: no dock icon, no window

What you need

macOS 13 Ventura or later, and a Force Touch trackpad or a Magic Trackpad. On hardware with no actuator the haptics are skipped quietly and everything else works.

The main feature needs no permission at all. Sliding, volume and brightness all work the first time you launch it, before you have granted anything. Accessibility is requested only for the system HUD and three optional extras. The two event taps it installs are listen-only, so they physically cannot swallow or alter a keystroke.

Install

brew install --cask --no-quarantine helgafinn/tap/glisse

Or download the DMG from the releases page on GitHub.

The honest part

The build is ad-hoc signed rather than notarised, because notarising needs a paid Apple Developer account this project does not have. That is what --no-quarantine is for, and it has a real cost: macOS forgets the Accessibility permission on every upgrade, so you have to grant it again.
There is no App Store version and there cannot be one. Reading raw trackpad contacts, producing the system HUD and talking to a monitor over I2C have no entitlements available. This is a program you choose to trust, and it should say that plainly instead of implying that a review process vouched for it.
External monitor brightness is written but not verified — no second display was available to test it on.
Intel Macs and the standalone Magic Trackpad are also unverified. The code is there and compiles, but nobody has run it on that hardware yet.

Every private system call the app makes is listed in the README, each with the reason no public alternative exists.

Changelog

v1.0.0 — first release. Edge sliding for brightness and volume, real system HUD, haptics, typing suppression, fine control, bottom-quarter mode, optional modifier requirement, pointer freeze, three-finger middle click, DDC for external displays, launch at login.

AI disclosure

This post, and a large part of the app, were written with AI assistance. The list of unverified paths above is honest rather than promotional, and is the part worth checking for yourself.

Source, README and issues: https://github.com/helgafinn/glisse

Pinning GitHub Actions to a SHA is not protection

crimsondhaks — Wed, 02 Sep 2026 11:57:10 +0000

In March 2025 an attacker compromised tj-actions/changed-files and rewrote its
release tags to point at malicious code. The injected code dumped runner memory
into workflow logs, which on a public repository means printing your secrets
where anyone can read them. Around 23,000 repositories depended on that action,
most of them through a mutable tag like @v45.

Repositories that had pinned the action to a commit SHA were unaffected. That is
worth sitting with for a moment, because it is rare for a security practice to
draw such a clean line through a real incident. The advice worked exactly as
advertised.

So we all pinned. And then we quietly undid it.

What pinning actually buys you

uses: actions/checkout@v5 means "run whatever v5 points at when this
workflow starts". The tag is a pointer the upstream author can move at any time,
and nothing about your repository changes when they do. You are trusting the tag
to keep meaning what it meant when you wrote the line.

uses: actions/checkout@fbc6f3992d24b796d5a048ff273f7fcc4a7b6c09 means "run
this exact commit". Nobody can repoint it. If the upstream repository is
compromised tomorrow, your workflow keeps running the code you reviewed.

That is the entire mechanism. It is not clever, and that is its strength.

The part nobody mentions

A pin is a snapshot, and snapshots go stale. The action you froze in March has
since fixed bugs, gained features, and patched its own vulnerabilities, and you
are running none of it. So you enable Dependabot, which is exactly the right
call — an un-updated pin is its own risk.

Now look at what arrives in your pull request queue:

- uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8
+ uses: actions/checkout@fbc6f3992d24b796d5a048ff273f7fcc4a7b6c09

What changed? You cannot tell. Not because you are careless — because the diff
contains no information. Two hex strings differ. That is the whole change.

GitHub's own engineering blog describes a repository where
roughly one in six commits were Dependabot version bumps,
61 of them in twelve months, sometimes several in a single day. Nobody
meaningfully reviews an opaque hash 61 times a year. You approve it, because the
alternative is manually diffing a third-party repository before every merge, and
nobody has budgeted for that.

One maintainer put it plainly on her own blog, admitting she
blindly accepts Dependabot pull requests and noting this negates the benefit of pinning.
That is not a confession of bad practice. It is an accurate description of what
the workflow makes people do.

So the pin is still in the file. The review it depends on is gone. You are
running unreviewed third-party code with your credentials, with a line in your
YAML that looks like diligence.

It gets slightly worse

Two details make this sharper than it first appears.

Dependabot Alerts do not cover SHA-pinned actions. Users have been
asking GitHub to fix this asymmetry
for a while. You are told to pin, then told to enable version updates to combat
staleness, and the alerting that would tell you a pinned action has a known
vulnerability does not apply to the form you were told to use.

The version comment is not verified by anything. Tooling writes bumps like
this:

uses: actions/checkout@fbc6f3992d24b796d5a048ff273f7fcc4a7b6c09 # v5.1.0

That line makes two claims. First, run this commit — GitHub enforces it. Second,
this commit is v5.1.0 — nothing enforces it at all. It is a comment. Your eyes
read v5.1.0 and move on, and the only thing GitHub cares about is the hash.

Those two claims agreeing is precisely what a retagged release breaks. In the
tj-actions incident the tags were moved; the SHAs were not. If a pin's comment
says v5.1.0 and the v5.1.0 tag now resolves to a different commit, something
worth knowing has happened — either your pin is stale, or the tag moved under
you. That check takes one API call, and almost nobody performs it.

This is not a niche concern

GitHub reported
11.5 billion Actions minutes used in 2025, up 35% year over year.
Datadog's security research found that
two out of three organizations have at least one vulnerability in an Actions workflow.

And the incidents kept coming after tj-actions. In May 2026 a threat group
compromised 5,561 public repositories in about six hours
by pushing workflows carrying dormant workflow_dispatch backdoors. TanStack's
router was breached through
cache poisoning that led to OIDC token theft and 84 malicious npm packages.

Attackers moved to CI because CI holds credentials, runs on every push, and is
reviewed less carefully than application code. Workflow files are code with
production access that we treat as configuration.

Sources above were paraphrased; content was rephrased for compliance with
licensing restrictions.

What would actually help

Not "review your Dependabot PRs more carefully." That advice has been available
the whole time and it loses to arithmetic: 61 bumps a year against a finite
attention budget.

What helps is making the diff contain information again. When a pin moves, the
questions worth answering are mechanical, and mechanical questions can be
answered mechanically:

Does the new commit exist in any tag or branch upstream, or is it floating outside published history?
If the pin claims a version, does that tag still resolve to this commit?
Did the action's declared interface change — inputs, outputs, required flags?
Did its execution model change, for instance a JavaScript action becoming a Docker action that can pull an arbitrary image?
Did it gain network calls, secret references, or dynamic code execution that it did not have before?

None of that requires judgment. It requires fetching two revisions and
comparing them, which is a thing a computer should do for you before you click
approve.

Two honest caveats

No static check can be certain. An action that builds a resource name at
runtime could reach anything, and a tool claiming certainty there is lying. The
right behaviour is to say what could not be determined rather than stay quiet.

A clean report is not a safety guarantee. It means the reviewable surface
did not change in a way worth flagging. A sufficiently careful attacker can stay
below that line. This raises the cost of an attack; it does not eliminate it.

The point

Pinning to a SHA is still correct. Keep doing it.

But recognise what it is: a mechanism that converts a trust problem into a
review problem. It only pays out if the review happens, and we built a workflow
that guarantees it does not. The pin in your YAML is not protection. It is a
place where protection could go, if something were reading it.

I wrote action-diff to do the
comparison above — it reads both revisions of a bumped action and reports what
changed, including whether the pin's claimed version still resolves to the
commit it names. It is MIT licensed and runs as a GitHub Action or a CLI.

Use it, use something else, or write your own. The tooling matters much less
than noticing that a practice we all adopted has quietly stopped working.