DEV Community: sameh

I wrote my own MTP engine in Swift because moving files off an Android phone shouldn't need Electron

sameh — Wed, 14 Oct 2026 05:30:32 +0000

Google's Android File Transfer for Mac is dead. The community replacement most people reach for, OpenMTP, is an Electron app — which always felt wrong to me for a utility whose whole job is shoving bytes over a cable as fast as possible.

So I wrote Android Rapid Transfer: a native file-transfer app for macOS, with a Linux build too, and its own MTP engine written from scratch in Swift. It's open source under the MIT license.

Why MTP is the hard part

MTP (Media Transfer Protocol) is the thing that makes phone-to-computer copies weird. Only one program can hold the phone at a time. Phones hide their files until you unlock them and tap "Allow". Some cables only charge. The protocol itself is chatty, so naive implementations crawl on folders with thousands of files.

The engine — MTPKit, with shared core logic in ARTCore — handles all of that: device detection and session management, bulk folder listings, and large transfers streamed in big USB reads and writes so throughput stays up. The UI only draws what's on screen, so a folder with 2,000 items lays out in about 50 milliseconds.

The Mac app

SwiftUI, dual-pane: your Mac's folders on one side, the phone's storage on the other, with Finder-style breadcrumbs and keyboard navigation. Copy either way with one click, drag between panes or straight from Finder, or queue files from several folders and paste them where they belong.

A few details I'm proud of:

Stop means stop. It takes effect immediately, even mid-file, and never leaves half-written files on either side. Interrupted copies can be resumed.
Live progress you can trust — files done, bytes, speed, time left, in the window, the Dock, and a notification when it finishes in the background.
Copy by date range — pick a range, get just those photos and videos, with a live preview while the phone is scanned.
It names the culprit. When another app has grabbed the phone (Google Drive, Dropbox, Samsung Smart Switch...), the connection screen tells you which one, because MTP only allows one at a time.

No analytics, no accounts, no telemetry. The only network call it makes on its own is the Sparkle update check, which you can turn off.

The Linux app

Same core and engine, native GTK4/libadwaita interface. It talks to the phone through the kernel's USB interface — no libusb, no libmtp, no FUSE mount — and notices plug/unplug through udev. When GNOME Files has the phone open, there's a "Release the Phone" button instead of a cryptic error. Ships as .deb, .rpm, AppImage, and tarball.

The numbers

Measured on one phone (Xiaomi REDMI Note 15 5G) over USB — single-device numbers, not a benchmark suite, your mileage will vary with phone, cable, and port (many phones only do USB 2.0 speeds regardless):

200 MB file to the phone: ~38 MB/s · to the Mac: ~42 MB/s
Folder of 50 files to the phone: 1.9 s
Full phone scan (208 folders, 2,052 files): 2.2 s

There's a 42-second demo video in the README: first launch to finished copies.

What's next

Notarized builds, a Homebrew cask, and — the part I can't do alone — device-compatibility reports. If you still tether an Android phone to a Mac (or a Linux box), I'd genuinely like to know your transfer speeds and whether your device is detected.

Repo: https://github.com/sameh0/android-rapid-transfer

I tried to build a CRA evidence packet for a WordPress plugin release. Here's what was missing.

sameh — Sat, 26 Sep 2026 09:42:57 +0000

I've spent the last few weeks researching the EU Cyber Resilience Act for a side project. The notification duties (Article 14) have applied since 11 September 2026 — weeks ago — so I wanted to see what "ready" actually looks like for a typical small commercial WordPress plugin vendor.

I took a composite release — call it FormsPro 4.3.1, a $99/year form-builder plugin with ~20,000 installs, sold from the vendor's own site. It's a composite of several real plugins, so nobody gets singled out. Then I tried to assemble the evidence packet: the set of artifacts that answers "what did you ship, what was in it, and what did you know, when?"

What I could find — the good news first

A version number and a real changelog. 4.3.1 even documents a security fix ("Fixed: validation bypass on file uploads"). Good.
The release zip, downloadable from the vendor site.
A public GitHub repo with a matching tag.

That's further than most get. Now the gaps — and these are the ones the CRA cares about.

1. Which commit built that zip?

The tag exists. But is the downloadable zip byte-identical to a CI build from that tag, or was it zipped on someone's laptop on a Friday afternoon? There is no build record: no commit hash, no build ID, no builder identity, no timestamp. If a regulator — or an enterprise customer — asks "prove this zip came from that source," the answer is trust me.

2. No SBOM tied to the release

There's a composer.json in the repo, which tells you what the developer intended to depend on. It doesn't tell you what shipped in the zip six months from now: the bundled libraries, the exact versions, the minified JS pulled from npm. The CRA (Annex I) asks for an inventory per product, and the only inventory that matters in an incident is the one tied to the artifact customers actually installed.

3. The security fix has no awareness timestamp

4.3.1 fixed a validation bypass. Was it actively exploited? If yes, the 24-hour early-notification duty — enforceable right now — started ticking at the moment of awareness, not at the moment of full understanding. Is there a timestamped record of when the report came in, who triaged it, and what was decided? I found a changelog line. A changelog line is not an intake record.

4. No scan output, no dispositions

Did anyone scan 4.3.1 before shipping? When a scanner flags a dependency next month, the question won't be "is there a CVE." It'll be: was it a false positive, unreachable code, mitigated, or missed — and who decided that, when? No owner, no rationale, no deadline. A scanner finding without a decision trail is just anxiety with a dashboard.

5. No stated support window

How long is 4.3.1 supported with security fixes? The CRA expects the support period to be stated outright. "We support the latest version" is the industry default — and it's exactly what the regulation is pushing vendors away from.

What the packet should look like

This is the whole thing:

formspro-4.3.1/
  release.json        # version, commit sha, build id, builder, timestamp
  sbom.cdx.json       # CycloneDX SBOM generated against the final zip
  changelog.md
  vuln-intake.log     # every report, timestamped, with triage decision
  scan-results/       # scanner output + per-finding disposition
  support-window.txt  # "4.3.x receives security fixes until 2027-06"

No compliance department, no law firm. About two hours of release hygiene, most of it automatable inside the release workflow. And it's the difference between answering "what was in the March release?" in ten minutes versus two weeks of git archaeology in the middle of an incident.

The Friday 17:20 test still applies: exploit report lands, maintainer's asleep, two versions in the wild. The teams that survive aren't the ones with the best incident response playbook — they're the ones who did this boring work beforehand.

Not legal advice — I'm a software engineer, not a lawyer. This is release hygiene that happens to overlap with what the CRA asks for.

I'm building Waybill to generate exactly this packet from a release workflow: SBOM per release, a versioned evidence archive, and vulnerability intake with real deadlines. Founding beta is $29/mo.

The full write-ups behind this post:

Question for the WordPress vendors here: if an enterprise customer emailed you today asking "what was in the version you shipped in March" — how long would it take you to answer with evidence, not memory?

The 24-hour CRA reporting clock: build the evidence packet before you need it

sameh — Thu, 24 Sep 2026 17:29:53 +0000

A vulnerability report lands at 17:20 on Friday. That is the wrong moment to design your incident process.

Educational material only — this is not legal advice.

A vulnerability report lands at 17:20 on Friday. The reporter says a flaw in a bundled component is being exploited. The maintainer is in another time zone. The last two releases used different versions, customer deployment data is incomplete, and nobody on the team has registered for the reporting platform.

The CRA's reporting duties for manufacturers are now live — they've applied since 11 September 2026. Manufacturers must report actively exploited vulnerabilities and severe incidents affecting product security through ENISA's Single Reporting Platform (SRP): an early warning within 24 hours of awareness, a fuller notification within 72 hours, then a final report — within 14 days of a fix for vulnerabilities, or within a month of the 72-hour notification for severe incidents.

The practical challenge isn't memorizing the clock. It's whether the team can identify the product, affected versions, current facts, decision owner, and next update while information is still incomplete.

Know what starts the workflow

Not every CVE match is an actively exploited vulnerability in your product. Create two intake triggers: credible information that a vulnerability in your product or a component is being actively exploited, and an event that may severely impact product security. At intake, don't wait for certainty — open a timed assessment, preserve the original report, assign an incident lead, and record when the organization became aware. "Awareness" starts the legal clock, so agree with counsel how you interpret and record it before you need it.

Separate facts from assessments

Keep observed facts apart from working assessments. Facts: report time and source, affected versions and platforms, indicators of exploitation, customer impact so far, preserved logs and samples. Assessments: is the issue present in shipped versions, is exploitation credible, does it meet severity criteria, confidence level and the next fact needed. A 24-hour warning can acknowledge uncertainty without blending assumptions into facts.

Pre-build the evidence packet

Create the packet structure before triage opens. Product identity: manufacturer, product and version range, platforms, EU distribution channels, support status, update mechanism. Technical evidence: affected artifacts and hashes, release-linked SBOMs, exploit indicators, reachability assessment, fix status. Decision trail: awareness timestamp, incident lead, reportability assessment, submission receipts, customer communication decisions. Don't alter original evidence — add versions and preserve the decision chain.

Give a five-person process to a two-person team

Assign named primary and backup owners for intake monitoring, technical triage, the reportability decision, SRP submission, customer communication, fix approval, and post-incident review. One escalation rule: if the primary is unreachable, the backup takes control after a defined period. The 24-hour window doesn't pause for holidays.

Rehearse the case most likely to hurt

Run a 60-minute tabletop with your actual product: a critical flaw in a bundled update component, two supported releases affected, a fix that breaks one platform's installer, some customers with auto-updates disabled. Ask the team to record awareness, find the affected releases and their SBOMs, draft the 24-hour warning from known facts only, and plan containment and customer guidance. Score it on retrieval time and decision clarity — the goal is removing avoidable delay, not theater.

Five readiness checks for this month

A security contact that reaches a person, not an abandoned inbox. SRP access for the right people, registered before you need it. Release traceability: component to affected versions, fast. One named decision owner, with a backup. One timed rehearsal producing a draft warning within the first hour. Fix access and ownership gaps before buying another scanner.

Has your team tested a CRA reporting workflow — or discovered it has no workable one? Drop a line or two in the comments about what would break first; I'm collecting practical lessons from small vendors, no call needed.

Sources

Your SBOM should be a release artifact, not a compliance screenshot

sameh — Thu, 24 Sep 2026 17:29:02 +0000

An SBOM you can't tie to a release is a screenshot, not evidence. Here's how to make it a release artifact.

Educational material only — this is not legal advice.

A software bill of materials can be generated in seconds and become unreliable just as quickly.

Run a scanner against a development checkout, save the result as sbom.json, and the team technically has a file. But which release does it describe? Was it generated before or after the lockfile changed? Does it include the bundled runtime, native modules, container base, installer, and vendored code? Can the same binary be tied back to the same component list six months later?

The Cyber Resilience Act makes the operational answer important. Annex I requires manufacturers to identify and document vulnerabilities and components — including by drawing up an SBOM in a commonly used, machine-readable format covering at least the product's top-level dependencies.

That wording sets a minimum. A useful SBOM process goes further by creating a trustworthy relationship between the inventory, the product artifact, and the release decision.

Define the unit of inventory before choosing a tool

"Generate an SBOM" is underspecified. First define what counts as one product release.

For a WordPress plugin, the unit may include PHP dependencies, bundled JavaScript, vendored libraries, and the exact ZIP delivered to customers. For an Electron app, add the Electron and Chromium versions, native Node modules, auto-update components, and per-platform installers.

Write a release inventory contract: product and version identifier, platforms, each build artifact and checksum, package ecosystems and lockfiles, bundled runtimes and vendored components, build commit and workflow run, SBOM format and tool version, and known blind spots. A generator that misses a bundled runtime isn't "mostly complete" if that runtime carries the vulnerability that matters.

Generate from the closest trustworthy point to shipment

Source-only scanning is useful in development, but release evidence should describe what customers receive. Generate or reconcile the SBOM as late in the trusted build pipeline as practical:

The release workflow resolves locked dependencies in a controlled environment.
The application and installers are built.
The SBOM is generated for the final artifact.
Automated checks validate format, identifiers, duplicates, and gaps.
Artifact, checksum, SBOM, test results, and approval are archived under one release identity.
The release ships only after the evidence bundle is complete.

SPDX and CycloneDX are the common formats — pick the one your tools and customers can consume. Preserving identifiers, versions, and provenance accurately matters more than the format choice.

Validate the SBOM like any other build output

An SBOM can be syntactically valid and materially wrong. Check four things: is it complete against your inventory contract? Is it internally consistent — versions, identifiers, duplicates, hashes? Is it tied to the shipped bytes, with hashes and release IDs stored alongside and corrections kept as traceable revisions? And is it reproducible enough to investigate — can you explain material component differences on rebuild?

The inventory feeds triage

A component inventory becomes valuable when it feeds vulnerability triage: inventory → match → assess reachability and exposure → decide → remediate or accept → verify → communicate. A scanner match is not the final risk decision — record the affected releases, whether the vulnerable code is reachable, exploitability in your configuration, the decision owner and rationale, and verification.

Note the CRA doesn't require publishing your SBOM to the public — the recitals explicitly recognize confidentiality concerns. But you must be able to produce, retain, and retrieve it. Store immutable release copies, log disclosures, and test retrieval during an incident exercise.

Review deltas, not full inventories

A 2,000-line inventory is hard to review; a release delta is actionable: components added or removed, dependencies upgraded, new licenses, components leaving support, findings changed since the last release. Keep the full SBOM as the system record; make the delta the human review surface.

The practical test

Pick one production release from six months ago and give a teammate 30 minutes: which components shipped? Which issues were open at release time? What changed from the previous version? If the answers need personal memory or archaeology across systems, the problem isn't the SBOM format — it's missing release evidence.

Where does your SBOM workflow break today — incomplete inventories, noisy matches, or evidence scattered across tools? Drop a line or two in the comments; I'm collecting patterns across small vendors, no call needed.

Sources

The CRA clock has started

sameh — Tue, 22 Sep 2026 15:06:52 +0000

The reporting duties that matter most are already live. If you sell software in the EU, here's what that actually means — and how to be ready without wasting effort.

Educational material only — this is not legal advice.

Two instincts are leading small software vendors astray on the EU's Cyber Resilience Act (CRA).

The first instinct: "The deadline is late 2027 — I have time." The second: "This is only for Microsoft and Siemens."

Both are wrong, and the calendar is the reason. The CRA was adopted on 10 October 2024 and entered into force on 10 December 2024. But it doesn't switch on all at once. The notification duties under Article 14 apply from 11 September 2026 — already in the past. The remaining product requirements — conformity assessments, CE marking, the full documentation package — follow on 11 December 2027.

That split timeline is the whole story. The part of the CRA that can hurt you first isn't the paperwork in 2027. It's the reporting duty that's live right now.

What "already live" actually means

Article 14 requires manufacturers of products with digital elements to notify authorities when they become aware of an actively exploited vulnerability in their product — or a severe incident affecting its security. The timeline is brutal by normal support-desk standards:

An early notification within 24 hours of becoming aware. A fuller notification within 72 hours. A final report within one month.

And this applies to any product with digital elements sold commercially in the EU — your SaaS, your WordPress plugin, your desktop app, your dev tool. Not just the giants.

The penalties underline the point: up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

Three things worth doing now

Almost everything the CRA asks of you early is operational, not legal. You don't need a law firm; you need a release process that produces evidence.

1. Build the SBOM into your release pipeline. For every release, generate a machine-readable inventory of what you shipped — every dependency, every version. CycloneDX is the pragmatic format. Do it in CI so it happens whether or not anyone remembers.

2. Keep evidence of what you ship and how long you support it. Archive each release's SBOM, record your stated support period, and keep incident records. When a regulator — or an enterprise customer — asks what was in version 4.8.0 and whether it was still supported, the answer should be a file, not a memory.

3. Set up a vulnerability intake and response process. Publish a security contact point, define who triages reports, and set internal deadlines that beat the regulatory ones. The 24-hour clock starts when you become aware — so "becoming aware" needs to be a defined process, not an accident.

The bottom line

The CRA rewards vendors who can show their work. Start with the release pipeline: if every release produces an SBOM and an archive entry, you're most of the way to the evidence trail the regulation assumes you have.

If you sell software in the EU, what does your current evidence trail look like? Drop a line or two in the comments about how you track releases today — no call, I'm just collecting patterns across small vendors.