DEV Community: Sagar Ghag

Patches Welcome #1: Apple Quietly Broke Flutter Builds, and Nobody Noticed for 10 Months

Sagar Ghag — Thu, 05 Nov 2026 17:37:04 +0000

flutter build ios started failing on my machine with a permissions error pointing at a build output directory. The actual problem was three layers deeper: Apple silently removed GNU rsync from macOS 15.4, its replacement ignores a flag Flutter depends on, and the existing fix had been a no-op for almost a year.

How I found it

I run the Flutter SDK through Nix. The SDK lives in /nix/store, which is read-only by design. That's a supported configuration. Flutter merged PR #148580 in May 2024 specifically to handle read-only SDK paths by passing --chmod=Du=rwx,Dgo=rx,Fu=rw,Fgo=r to rsync during framework copies.

Worked fine until one day it didn't. The error:

fatal error: lipo: can't create temporary output file:
  …/Flutter.framework/Flutter.lipo (Permission denied)

That's lipo complaining it can't write to a file in the build output directory. Not the SDK. The build output. I spent a while staring at that before realising: the output directory inherited the source's read-only permissions because the copy step silently failed to set them.

The mechanism

I traced it to packages/flutter_tools/lib/src/build_system/targets/darwin.dart. The copyFramework function runs rsync with --chmod to make the copied framework writable before thinFramework rewrites it in place with lipo. The flag is there. It's correct. It does nothing.

macOS 15.4 removed GNU rsync. /usr/bin/rsync is now Apple's openrsync fork, and openrsync accepts --chmod, validates it, and then never applies it. Exit code 0. No warning.

I dug into Apple's open source distributions to confirm. The dispatcher source at rsync-91.0.6 shows two backends: rsync_openrsync (default) and rsync_samba (GNU). The --chmod flag exists only in the samba longopts table. Between tags rsync-91.81.3 (2025-02-26) and rsync-146 (2025-04-25), Apple removed the GNU fallback entirely. That brackets macOS 15.4.

Apple documented none of this. The macOS 15.4 security content doesn't mention rsync. The openrsync man page still says --chmod supports literal modes like 755. It doesn't. chmod_parse() in openrsync/main.c has no octal production; 755 returns EINVAL. The relative forms parse but the mode never reaches disk.

I wrote a minimal repro that takes Flutter out of the equation entirely:

mkdir -p /tmp/rs/src/F.framework && echo hi > /tmp/rs/src/F.framework/bin
chmod -R a-w /tmp/rs/src/F.framework
mkdir -p /tmp/rs/dst
/usr/bin/rsync -av --chmod=Du=rwx,Dgo=rx,Fu=rw,Fgo=r \
  /tmp/rs/src/F.framework /tmp/rs/dst/
ls -ld /tmp/rs/dst/F.framework
# dr-xr-xr-x (--chmod did nothing, exit was 0)

Same flags, same source. GNU rsync 3.4.4 produces drwxr-xr-x. Apple's openrsync produces dr-xr-xr-x. That single variable explains the entire failure.

The fix

I filed issue #189645 with the full root cause analysis, the Apple source audit, the minimal repro, and a proposed fix. Then I opened PR #189658.

The fix is one idea: don't trust rsync --chmod. Run chmod -R u+w on the copied framework path after every rsync completes. 120 lines added across darwin.dart, build_swift_package.dart, and three test files. Zero lines deleted.

The review took two rounds with two Google engineers. Chris Bracken (@cbracken) caught that I was using printTrace on failure and suggested ToolExit instead. Victoria Ashworth (@vashworth) pushed back on that: since chmod is only needed for read-only SDK environments, a build-breaking ToolExit would punish normal installs. She pointed me to _utils.logger.printWarning for a non-fatal warning. Both reviewers approved. Auto-submit merged it.

I learned something from that exchange. My instinct was to fail loudly. Vashworth's instinct was to fail proportionally. The chmod path matters on Nix and Bazel and hardened CI. On a regular ~/flutter install, it's a no-op that should stay quiet. She was right.

What I didn't fix

The existing tests assert that --chmod is present in the rsync argument list. They don't check that the resulting files are actually writable. That's the test gap that let this regression hide for 10 months across three separate bug reports (#147142, #167823, #189645). I didn't close that gap. My PR tests that chmod runs after rsync, which is better, but a true end-to-end assertion on post-copy file modes would be stronger. I left that for a follow-up.

I also filed the openrsync --chmod bug with Apple via Feedback Assistant. No response as of writing. The --chmod flag is documented in Apple's man page, parses without error, and does nothing. That's been true since March 2025.

Contributing to a 170k-star repo

The issue mattered more than the PR. I spent a full day writing #189645: reading Apple's dispatcher source, testing every documented --chmod form, building the macOS version matrix, linking the three prior issues that got closed as environment-specific. The PR was 120 lines. The issue was the argument that those 120 lines needed to exist.

Flutter's review process is human. Two reviewers, each with a different concern. One focused on error visibility, the other on blast radius. The CLA bot, the test checker bot, and gemini-code-assist all showed up too (the bot suggested wrapping chmod in try-catch, which was actually reasonable). But the decisions were made by two engineers who understood the trade-offs I didn't see from the outside.

If you're thinking about contributing to a large framework: file the issue first, with a repro that removes your specific setup from the equation. The Nix angle got the previous two reports closed as niche. My repro used nothing but mkdir, chmod, and rsync. The problem stopped being about Nix and started being about macOS.

PR #189658 · Issue #189645 · flutter/flutter

I Built a Flutter Plugin That Generates Crypto Keys Inside Your Phone's Hardware Chip

Sagar Ghag — Thu, 05 Nov 2026 14:06:36 +0000

Flutter has no native way to generate a cryptographic key inside the device's hardware security chip and sign something with it. You can store keys in the Secure Enclave on iOS or StrongBox on Android, but you have to write Swift and Kotlin yourself, bridge it through method channels, handle the three different signature formats each platform returns, and then figure out how to make the result usable for Ethereum's account abstraction standards. I spent 8 weeks doing exactly that, and the result is chainkey.

The actual problem

I was building a Web3 authentication flow in Flutter. The requirement: seedless wallets. No mnemonic phrase, no "write down these 12 words." The private key lives in the Secure Enclave (iOS) or StrongBox (Android) and never leaves the chip. Every signature requires biometric presence: Face ID, Touch ID, or fingerprint.

No Flutter package did this. The closest options handled key storage in software (Dart-side, exportable) or wrapped a single platform. None handled all three targets (iOS, Android, Web) behind one API, and none produced signatures in a format Ethereum smart contracts could verify.

What chainkey does

Five coordinated packages. One umbrella (chainkey), one interface (chainkey_platform_interface), three platform implementations.

const chainkey = Chainkey();

// Generate a P-256 key inside the hardware enclave
await chainkey.generateHardwareKey(
  keyAlias: 'my_wallet',
  requireUserPresence: true, // biometric on every sign
);

// Sign a 32-byte hash (triggers Face ID / fingerprint)
final signature = await chainkey.signWithHardwareKey(
  keyAlias: 'my_wallet',
  data: transactionHash,
);

// signature.r and signature.s are already low-S normalized
// Ready for EIP-7212 precompile or ERC-4337 UserOperation

The key never leaves the chip. requireUserPresence: true means the OS prompts for biometric auth on every sign call. You can customize the biometric prompt text on both platforms (iOS LAContext.localizedReason, Android BiometricPrompt.PromptInfo with title, subtitle, negative button).

The hard part: signature format hell

This is the thing that ate most of the 8 weeks. Each platform returns signatures in a different format:

Apple's Security framework gives you raw SEC1 point coordinates. Android's KeyStore gives you ASN.1 DER-encoded bytes. Ethereum expects 64 bytes: r concatenated with s, low-S normalized per BIP-62/EIP-2.

I built four converters to bridge these:

ASN.1 DER unpacker (parses the TLV structure Android returns)
SEC1 point formatter (handles compressed and uncompressed public keys)
SPKI parser (extracts the raw key from the SubjectPublicKeyInfo wrapper)
Low-S normalizer (if s > n/2, replace with n - s)

All four are validated against Wycheproof test vectors and the EIP-7212 reference. The Wycheproof vectors specifically caught an edge case in the DER parser where a leading zero byte in r was being included in the output, producing a 33-byte value instead of 32. That would silently fail on-chain with no error message.

WebAuthn passkeys (v0.4.0)

v0.4.0 added a full WebAuthn passkey engine across all three platforms: iOS AuthenticationServices, Android CredentialManager, and Web navigator.credentials via dart:js_interop. Registration and assertion, with a binary AuthenticatorData parser and a zero-copy UTF-8 ClientDataJSON scanner that extracts the challenge field at the byte offsets Solady and Safe contracts expect.

I also wrote a CLI tool (dart run chainkey:verify_domain) that validates your apple-app-site-association and assetlinks.json files for WebAuthn RP binding. Getting those wrong is silent on iOS (the passkey creation just fails with a generic error) and debugging it from the Dart side is painful.

The signature serializers (v0.5.0)

The latest release added three contract-specific encoders:

encodeSafePasskeySignature() for Safe 4337 WebAuthn Signer
encodeErc7579WebAuthnSignature() for ZeroDev Kernel v3 and Biconomy Nexus
encodeEip7212Payload() for the secp256r1 precompile (160-byte payload)

These exist because every smart account implementation expects a slightly different ABI encoding for the same underlying (r, s, authenticatorData, clientDataJSON) tuple. Getting the encoding wrong produces a signature that looks valid locally but reverts on-chain.

Performance

Signing latency matters because it's user-facing (the biometric prompt appears and the user waits). The integration test suite measures pure crypto latency with biometric disabled:

P50: 42ms
KPI target: under 350ms

42ms for a hardware enclave round-trip is fast enough that the user never perceives the signing step. The biometric prompt itself takes longer.

What I haven't solved

The package is pre-1.0. The roadmap has 14 open issues across two epics. Key rotation (what happens when the user gets a new phone and the old Secure Enclave key is gone) is the biggest unsolved problem. The current answer is "your smart contract wallet has a recovery mechanism, and that's outside the scope of this package." I'm not happy with that answer but it's honest.

I also chose P-256 over secp256k1. This was deliberate: P-256 aligns with WebAuthn and the EIP-7212 precompile, which is gaining L2 adoption. But it means chainkey does not work with legacy EOA wallets. Hardware enclaves on iOS and Android don't support secp256k1 at all, so this wasn't really a choice.

160/160 on pub.dev. 77 commits. 12,747 lines across Dart, Kotlin, and Swift. Apache-2.0.

pub.dev/packages/chainkey. Source at github.com/GhagSagar23/chainkey.

I Built a Face Liveness Detection Package for Flutter. 4 Other Developers Forked It Into Their Own Products.

Sagar Ghag — Thu, 05 Nov 2026 13:20:42 +0000

I needed liveness detection in a Flutter app two years ago. The options were: pay for a commercial SDK (₹8-15L/year for the ones that actually worked on Indian Android hardware), roll a web-based flow through a WebView (latency kills it on 4G), or wire up Google ML Kit's face detection and write the challenge-response logic myself.

I wrote it myself. That package is livelyness_detection, and it now has 40 likes on pub.dev, a 160/160 quality score, and four separate developers have built derivative packages on top of it. One of those, m7_livelyness_detection, has officially discontinued itself and redirects to mine.

What it actually does

The package runs a camera feed through Google ML Kit's face detection, then walks the user through a sequence of active challenges: blink, turn left, turn right, smile. Each challenge has configurable thresholds (BlinkDetectionThreshold, SmileDetectionThreshold) so you can tune sensitivity per use case. The detection screen is a full-bleed camera preview with a frosted oval guide and an animated progress ring. One function call:

final CapturedImage? result = await LivelynessDetection.detect(
  config: DetectionConfig(
    steps: [
      LivelynessStepItem(step: LivelynessStep.blink),
      LivelynessStepItem(step: LivelynessStep.turnLeft),
      LivelynessStepItem(step: LivelynessStep.smile),
    ],
    startWithInfoScreen: true,
  ),
);

It pops a CapturedImage or null if the user cancels. The captured image includes which steps completed and, since v2.1.0, a PadResult with the passive anti-spoofing verdict.

Passive anti-spoofing, and why Phase 1 isn't enough

v2.1.0 added passive anti-spoofing (PAD). The idea: a real face has involuntary micro-movements. Head euler angles drift, eye-open probability jitters, the bounding box wobbles. A printed photo held still has near-zero variance across all of these. The analyzer watches a 45-frame sliding window (about 1.5 seconds at 30fps) and flags faces with flat variance as spoofs.

It catches flat printed photos reliably. It does not catch a hand-held printed photo, because your hand introduces enough jitter to pass. I put that in the security notes on day one because I've seen packages claim "anti-spoofing" without qualifying what that means. Phase 1 is a floor, not a ceiling.

v2.2.0 added Phase 2: an opt-in TFLite two-model ensemble (MiniFASNet at crop scales 2.7 and 4.0) that runs over a method channel. Both the heuristic check and the TFLite score have to pass. Either failing is a spoof. Fail-closed: if the TFLite model fails to load or score, the verdict is spoof, not inconclusive. I haven't tested this against screen replays or 3D masks yet.

The adoption I didn't plan for

I published the first version because I needed it for a client project. The adoption came from GitHub search results and pub.dev visibility. I didn't write blog posts or pitch it in Flutter communities. Some numbers as of November 2026:

19 independent repositories on GitHub import the package (GitHub code search for livelyness_detection in pubspec.yaml, excluding my own repos)
24 forks
13 external contributors have opened issues or PRs
10 closed issues filed by developers I've never met, reporting real bugs from production use

Four derivative packages exist on pub.dev. The one that matters most is m7_livelyness_detection, which was a maintained fork for a while. Its pub.dev page now reads "DISCONTINUED" with a redirect to livelyness_detection. I didn't ask for that. The maintainer decided the fork wasn't worth maintaining separately.

The 160/160 score

pub.dev's scoring is automated: 30/30 Dart file conventions, 20/20 documentation, 20/20 platform support, 50/50 static analysis, 40/40 up-to-date dependencies. The score doesn't mean the package is good. It means the public API is documented, the analyzer is clean, null safety is correct, and platform declarations match actual platform support. I've seen packages with perfect scores that solve no real problem, and packages with 80/160 that I'd trust in production.

What the score does tell you: I maintained it. The 40/40 on dependencies means I kept them current across 7 versions over two years, which is the part most open-source packages quietly stop doing.

What I'd do differently

The name has a typo. livelyness isn't a word; liveliness is. I didn't catch it before the first pub.dev publish, and pub.dev package names are immutable. Every import, every pubspec.yaml entry, every GitHub search carries the misspelling. I thought about publishing under a corrected name and deprecating the original, but 19 repos and 4 derivative packages reference the current name. The cost of a rename is higher than the cost of the typo.

The v1 API used a builder pattern that made simple cases verbose. v2.0.0 was a breaking rewrite to a single detect() call. Breaking changes in a package with active users are expensive to ship even when they're right. I should have started with the simpler API.

What's next

Phase 2 TFLite is opt-in and I want to make it good enough to be the default. That means testing against screen replays (a phone showing a video of a face) and cheaper 3D masks. The MiniFASNet ensemble handles printed photos well but I don't have benchmark numbers for video replays yet.

The package is at pub.dev/packages/livelyness_detection. Source is at github.com/Kryonex-Labs/livelyness_detection. Issues and PRs welcome.

I Built ai_guardrails: Local-First Safety for Dart and Flutter AI Apps

Sagar Ghag — Fri, 11 Sep 2026 12:12:50 +0000

AI features in Dart and Flutter apps usually start with a provider call. That is also where a few uncomfortable questions begin:

Does a user prompt contain an email address, card number, or API key?
Is retrieved RAG content trying to override the system prompt?
Is streamed output about to leak a secret or produce unsafe tool-call arguments?
Can we add these protections without sending user data to another service?

I built ai_guardrails to make those checks a small, local layer around any LLM integration.

It is a pure-Dart, provider-agnostic package for Dart and Flutter. It has no runtime dependencies and does not make network calls by itself. Use it with OpenAI, Gemini, Anthropic, a local model, or your own HTTP gateway.

The basic idea

Create a scanner chain for input and output, then wrap the call you already have:

import 'package:ai_guardrails/ai_guardrails.dart';

final guard = AiGuard(
  inputScanners: [
    PiiScanner(action: GuardAction.redact),
    SecretScanner(),
    PromptInjectionScanner(threshold: 0.5),
    InvisibleTextScanner(),
  ],
  outputScanners: [
    RepetitionScanner(),
    SchemaValidator({
      'type': 'object',
      'required': ['answer'],
      'properties': {
        'answer': {'type': 'string'},
      },
    }),
  ],
);

final outcome = await guard.run(
  input: userMessage,
  llmCall: (sanitizedInput) => myLlm.complete(sanitizedInput),
);

if (outcome.blocked) {
  print('Blocked at ${outcome.blockedStage}: ${outcome.blockReason}');
  return;
}

print(outcome.output);

Redacting scanners run in order, so the model receives the final sanitized input. If an input scanner blocks, the provider call never happens.

What it covers

ai_guardrails includes local heuristic scanners for common LLM-risk surfaces:

PII detection and redaction across US, EU, India, Brazil, Mexico, Japan, South Korea, Canada, and Australia
Secret detection for API keys, tokens, JWTs, and private-key blocks
Prompt-injection, Unicode-smuggling, suspicious URL, and padding-attack detection
Generated-code, SQL, HTML, JSON, URL, numeric-range, and choice validation
Tool-call validation and tool-output scanning for agentic workflows
RAG retrieval scanning, streaming response scanning, multi-turn escalation, and declarative conversation flows
Policy profiles, JSON configuration, audit logs, metrics, OpenTelemetry-compatible tracing, benchmarking, and red-team probing

The package also supports optional async scanners. Semantic checks such as fact checking, topic safety, hallucination checking, and embedding grounding use callbacks you provide, so the core package stays provider-neutral.

PII without sacrificing a natural response

For many chat experiences, redacting PII before it leaves the device is the safe choice—but users still expect a natural response. ai_guardrails supports a round trip for that case:

final guard = AiGuard(
  inputScanners: [PiiScanner(action: GuardAction.redact)],
);

final outcome = await guard.run(
  input: 'Email alice@example.com about the release.',
  llmCall: myLlm.complete,
);

// The model sees: "Email [EMAIL_1] about the release."
// outcome.output can restore the placeholder for the app.
// outcome.rawOutput preserves the model's pre-rehydration response.

That behavior is deliberate and should be used only where returning the original value to the user is appropriate. The redaction map and raw output remain available when an application needs tighter control.

Designed for the pipeline, not just a single prompt

LLM safety does not end at a chat textbox. The package has first-class stages for the inputs an application assembles around a model call:

// Drop poisoned or unsafe RAG chunks before prompt assembly.
final retrieval = await guard.runRetrievalStage(retrievedChunks);

// Scan untrusted tool results before returning them to the model.
final toolResults = await guard.runToolOutputStage([
  ToolOutput(toolName: 'search', content: untrustedSearchResult),
]);

For streaming applications, StreamingAiGuard scans complete response segments as they arrive and ends the stream when a scanner blocks. For whole-document rules such as JSON schema validation, run a final full-output pass after the stream completes.

What this package is—and is not

The built-in local scanners are deterministic heuristics. They are intentionally fast, offline, and inexpensive, but they do not understand every meaning, evasion, or cultural context. Treat them as defense in depth, not as a compliance certification or a substitute for application authorization.

For semantic checks, the package exposes callback boundaries rather than embedding a provider SDK. Your app decides whether to use an on-device model, a private endpoint, or a cloud model—and owns the associated privacy and cost choices.

Try it

dart pub add ai_guardrails

The package is open source under Apache-2.0. The README includes provider examples, configuration-driven policies, and a full scanner reference.

I would especially love feedback from teams building Flutter copilots, RAG search, local-model experiences, and agentic tools. What safety checks are you currently reimplementing in every Dart project?