Ptech/sync upstream main

.firebaserc

@@ -0,0 +1,17 @@
+{
+  "projects": {
+    "default": "bdaya-oidc"
+  },
+  "targets": {
+    "bdaya-oidc": {
+      "hosting": {
+        "oidc-flutter-example": [
+          "oidc-flutter-example"
+        ],
+        "oidc-flutter-docs": [
+          "oidc-flutter-docs"
+        ]
+      }
+    }
+  }
+}

.gitguardian.yaml

@@ -0,0 +1,9 @@
+version: 2
+
+secret:
+  # PR #459 / #386 review: these are test-only mTLS fixtures generated by
+  # packages/oidc_core/test/fixtures/mtls/generate.sh for the RFC 8705
+  # client-certificate-authentication test suite. They are not real secrets
+  # and are never used outside `dart test`.
+  ignored_paths:
+    - 'packages/oidc_core/test/fixtures/mtls/*.key'

.github/actions/flutter_base/action.yaml

@@ -7,25 +7,188 @@ inputs:
     default: "stable"
   flutter-version:
     description: "Flutter version to use"
-    default: "3.22.0"
+    # >=3.41 required: the SwiftPM (FlutterFramework) plugin layout in
+    # oidc_darwin needs Flutter 3.41+ / Dart 3.11+.
+    default: "3.47.6"
 
 runs:
   using: "composite"
   steps:
+    # Resolve the exact (channel, version, arch, hash) this run will use,
+    # and the cache coordinates subosito/flutter-action would itself use for
+    # them, WITHOUT installing anything yet. `dry-run: true` short-circuits
+    # only flutter-action's own "Run setup script" step; its "Set action
+    # inputs" step always runs in print-only mode regardless and is what
+    # sets the CACHE-PATH/CACHE-KEY outputs read below. `cache`/`pub-cache`
+    # are both false here: we only want these outputs, never flutter-
+    # action's own cache steps -- see the next step's comment for why.
+    - name: Resolve Flutter SDK version + cache coordinates
+      id: flutter_sdk_info
+      uses: subosito/flutter-action@v2
+      with:
+        channel: ${{ inputs.channel }}
+        flutter-version: ${{ inputs.flutter-version }}
+        cache: false
+        pub-cache: "false"
+        dry-run: true
+
+    # subosito/flutter-action's OWN `cache: true` (an internal actions/cache
+    # step keyed on the same CACHE-KEY/CACHE-PATH resolved above) is broken
+    # on macOS and Windows runners: a long-standing, still-open upstream bug
+    # (subosito/flutter-action#350 -- multiple independent reporters,
+    # including one whose experience exactly matches ours: "Caches
+    # perfectly for android builds ('linux') but fails for macOS"). By the
+    # time its cache step's POST (save) phase runs at the end of the job, it
+    # cannot re-resolve the `${{ steps.flutter-action.outputs.CACHE-PATH }}`
+    # expression its own `with: path:` depends on, logs "Input required and
+    # not supplied: path", and silently no-ops -- so the SDK is NEVER
+    # persisted and every run on those OSes re-downloads+extracts it from
+    # scratch (65s+ on macOS, worse under load). Confirmed live on this
+    # repo's own main-branch runs (e.g. run 37523659563, 2026-10-06): the
+    # windows/macos/ios "Cache Flutter" POST step prints exactly that
+    # warning every time, while the Linux jobs (unit_core, linux, android,
+    # web) -- which go through this exact same flutter_base action -- cache
+    # and restore it just fine, because they hit an already-warm cache and
+    # never even reach the broken save path.
+    #
+    # The bug is NOT specific to flutter-action's own internal step, or to
+    # being nested inside a third-party composite action: a first attempt
+    # at this fix routed the same key/path through our own, non-nested
+    # actions/cache step below, referencing them via
+    # `${{ steps.flutter_sdk_info.outputs.CACHE-PATH }}` (an output of the
+    # step above) directly in its `with:` -- and hit the EXACT SAME "Input
+    # required and not supplied: path" warning on macOS/Windows (confirmed
+    # live, run 37532075225). The actual trigger is narrower: a `with:`
+    # expression in ANY step (ours or a third party's) that reads
+    # `steps.<id>.outputs.*` cannot be re-resolved when that step's POST
+    # hook runs at the end of the job, on macOS/Windows runners specifically
+    # -- regardless of nesting. Our own pub-cache step below has never hit
+    # this because its `key`/`path` only reference flat, non-output values
+    # (`inputs.channel`, `runner.os`, `hashFiles(...)`), which DO replay
+    # correctly in POST on every OS (its POST logs a real "Failed to save:
+    # ... another job may be creating this cache" race, never an
+    # empty-input warning).
+    #
+    # Fix: copy the two outputs we need into plain environment variables via
+    # $GITHUB_ENV right away, then have the restore/save steps below
+    # reference `env.*` instead of `steps.flutter_sdk_info.outputs.*`. Env-var-backed
+    # context (`env.*`, `inputs.*`) is a flat key/value store the runner
+    # persists for the rest of the job and replays correctly in POST on
+    # every OS; the `steps.*.outputs` context is the piece that doesn't
+    # survive the replay.
+    - name: Export Flutter SDK cache coordinates
+      shell: bash
+      run: |
+        set -eu
+        echo "FLUTTER_SDK_CACHE_PATH=${{ steps.flutter_sdk_info.outputs.CACHE-PATH }}" >> "$GITHUB_ENV"
+        echo "FLUTTER_SDK_CACHE_KEY=${{ steps.flutter_sdk_info.outputs.CACHE-KEY }}" >> "$GITHUB_ENV"
+
+    - name: Restore Flutter SDK cache
+      id: flutter_sdk_cache
+      uses: actions/cache/restore@v6
+      with:
+        path: ${{ env.FLUTTER_SDK_CACHE_PATH }}
+        key: ${{ env.FLUTTER_SDK_CACHE_KEY }}
+
     - name: Set up Flutter
       uses: subosito/flutter-action@v2
       with:
-        cache: true
+        # Both false: the SDK cache is handled entirely by our own step
+        # above (flutter-action's internal version is the broken one on
+        # macOS/Windows -- see that step's comment). `cache: true` with no
+        # explicit `pub-cache` input would ALSO silently enable flutter-
+        # action's OWN internal pub-cache step (its action.yaml: `if:
+        # (inputs.pub-cache == '' && inputs.cache == 'true') || ...`), whose
+        # key unconditionally appends `${{ hashFiles('**/pubspec.lock') }}`
+        # -- an UNSCOPED glob from the repo root, not the narrower
+        # `packages/**/pubspec.yaml` below. Confirmed live: a run on this
+        # exact composite action hit "hashFiles('**/pubspec.lock') couldn't
+        # finish within 120 seconds" on a macOS leg, and the GH Actions
+        # cache listing (`gh api repos/Bdaya-Dev/oidc/actions/caches`)
+        # showed a `flutter-linux-...-<hash>-` key with an EMPTY trailing
+        # segment -- the same hashFiles call degrading to "" on Linux too,
+        # just not fatally there. pub-cache: "false" keeps that disabled
+        # regardless (we run our own narrowly-scoped pub cache below
+        # instead) for every job that goes through this action, including
+        # ios/macos/android/web/linux/windows via integration_test_base --
+        # without changing anything those jobs own.
+        cache: false
+        pub-cache: "false"
         channel: ${{ inputs.channel }}
         flutter-version: ${{ inputs.flutter-version }}
 
+    # Save, split from restore above (actions/cache/save, not the combined
+    # actions/cache action), and gated to pushes on main only: every other
+    # ref (PR runs, workflow_dispatch runs like the ones used to verify this
+    # fix) restores whatever main has already populated but never saves its
+    # own copy. The SDK archive is multi-GB per OS (~1.7-2.2GB each); since
+    # this repo's total GH Actions cache is capped at 10GB and already
+    # shares that budget with the pub cache above and the Gradle caches the
+    # android job writes, letting every PR/dispatch run freely create its
+    # own branch-scoped SDK entry would grow the total without bound (GH
+    # cache entries are scoped per-ref, so PR branches don't share main's
+    # entries for writes, only for reads). A `restore-keys` fallback isn't
+    # meaningful here either way -- a different (channel, version, arch,
+    # hash) tuple is simply a different, non-interchangeable SDK build, not
+    # a partial match worth falling back to.
+    # Split into separate restore/save actions (rather than the combined
+    # actions/cache@v6 used for the pub cache below) specifically so this
+    # step runs and completes synchronously, right here, instead of
+    # deferring the actual save to a POST hook at the end of the job: no
+    # POST-phase replay is involved at all, which sidesteps the whole class
+    # of bug described on the restore step above (both actions/cache/
+    # restore and actions/cache/save are plain `main`-only actions with no
+    # `post:` step).
+    - name: Save Flutter SDK cache
+      if: ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' && steps.flutter_sdk_cache.outputs.cache-hit != 'true' }}
+      uses: actions/cache/save@v6
+      with:
+        path: ${{ env.FLUTTER_SDK_CACHE_PATH }}
+        key: ${{ env.FLUTTER_SDK_CACHE_KEY }}
+
+    # Replaces the internal pub-cache step disabled above. subosito/
+    # flutter-action's own `cache: true` only caches the downloaded
+    # Flutter/Dart SDK (keyed by version), not the hosted-package pub cache
+    # that `melos bootstrap` below populates via `pub get` across every
+    # workspace package, nor the pub-global packages activated later by
+    # the coverage-formatting steps (coverage/combine_coverage/
+    # remove_from_coverage). Missing previously (every job paid a cold
+    # `pub get` + cold global-package resolve/compile on every run). Now
+    # that unit_tests is split into many parallel jobs (see tests.yaml),
+    # this matters more, not less: every one of those jobs runs its own
+    # `melos bootstrap` independently, so a warm cache is shared across all
+    # of them (and across sdk channels via the key).
+    # Keyed on the channel (stable/beta resolve different dependency sets)
+    # and a hash of every pubspec, scoped under packages/ (cheap: at this
+    # point in the job nothing has generated android/Pods/build dirs yet,
+    # so the glob only walks source files) instead of an unscoped `**` from
+    # the repo root -- a dependency change invalidates it; restore-keys
+    # fall back to the most recent cache for the same channel so a partial
+    # hit still saves most of the network/compile cost. Concurrent jobs
+    # racing to save the same key is harmless: actions/cache only lets the
+    # first writer persist it, and the pub cache's own content is derived
+    # purely from pubspec.yaml/pubspec.lock, so two independent
+    # populations of the same key are equivalent.
+    - name: Cache pub dependencies
+      uses: actions/cache@v6
+      with:
+        # Two paths, not one: this action also runs on windows-latest (the
+        # `windows` job, via integration_test_base) where the global pub
+        # cache lives under %LOCALAPPDATA%\Pub\Cache
+        # (~/AppData/Local/Pub/Cache under this workflow's bash shell), not
+        # ~/.pub-cache -- see the windows job's own PATH export in
+        # tests.yaml, which adds both for the same reason. A path that
+        # doesn't exist on a given OS is simply skipped by actions/cache,
+        # so listing both is harmless on Linux/macOS.
+        path: |
+          ~/.pub-cache
+          ~/AppData/Local/Pub/Cache
+        key: pub-${{ runner.os }}-${{ inputs.channel }}-${{ hashFiles('pubspec.yaml', 'pubspec.lock', 'packages/**/pubspec.yaml') }}
+        restore-keys: |
+          pub-${{ runner.os }}-${{ inputs.channel }}-
+
     # see https://github.com/invertase/melos/issues/796
     - uses: bluefireteam/melos-action@main
       continue-on-error: true
       with:
         run-bootstrap: true
-        bootstrap-no-example: false
-    - uses: bluefireteam/melos-action@main
-      with:
-        run-bootstrap: true
-        bootstrap-no-example: true

.github/actions/integration_test_base/action.yaml

@@ -7,7 +7,9 @@ inputs:
     default: "stable"
   flutter-version:
     description: "Flutter version to use"
-    default: "3.22.0"
+    # >=3.41 required: the SwiftPM (FlutterFramework) plugin layout in
+    # oidc_darwin needs Flutter 3.41+ / Dart 3.11+.
+    default: "3.47.6"
 
 runs:
   using: "composite"

.github/dependabot.yaml

@@ -30,17 +30,13 @@ updates:
     schedule:
       interval: "monthly"
   - package-ecosystem: "pub"
-    directory: "/packages/oidc_ios"
+    directory: "/packages/oidc_darwin"
     schedule:
       interval: "monthly"
   - package-ecosystem: "pub"
     directory: "/packages/oidc_linux"
     schedule:
       interval: "monthly"
-  - package-ecosystem: "pub"
-    directory: "/packages/oidc_macos"
-    schedule:
-      interval: "monthly"
   - package-ecosystem: "pub"
     directory: "/packages/oidc_web"
     schedule:

.github/scripts/firebase_channel_deploy.sh

@@ -0,0 +1,55 @@
+#!/usr/bin/env bash
+# Deploy one Firebase Hosting preview channel with honest error classification.
+#
+# Why not FirebaseExtended/action-hosting-deploy: firebase-tools' apiv2 client
+# retries POSTs after transient "premature close" network errors even though
+# the channel-release POST is not idempotent. The first POST usually succeeds
+# server-side, so the retry gets HTTP 400 FAILED_PRECONDITION ("supplied
+# version ... is the current active version"). The action treats that as a
+# hard failure and, when given a repoToken, writes a failing "Deploy Preview"
+# check-run onto the PR even when the job is green. Here that error means
+# "the content is already live" and is classified as success; anything else
+# fails the step for real (no blanket continue-on-error).
+#
+# Inputs (env): FIREBASE_SERVICE_ACCOUNT, PROJECT_ID, TARGET, CHANNEL
+# Outputs (GITHUB_OUTPUT): url=<stable channel URL>
+set -uo pipefail
+
+: "${FIREBASE_SERVICE_ACCOUNT:?}" "${PROJECT_ID:?}" "${TARGET:?}" "${CHANNEL:?}"
+
+export GOOGLE_APPLICATION_CREDENTIALS="${RUNNER_TEMP}/firebase-sa-${TARGET}.json"
+printf '%s' "$FIREBASE_SERVICE_ACCOUNT" > "$GOOGLE_APPLICATION_CREDENTIALS"
+trap 'rm -f "$GOOGLE_APPLICATION_CREDENTIALS"' EXIT
+
+FIREBASE="npx --yes firebase-tools@15"
+
+set +e
+out="$($FIREBASE hosting:channel:deploy "$CHANNEL" \
+  --only "$TARGET" --expires 7d --project "$PROJECT_ID" --json 2>&1)"
+code=$?
+set -e
+echo "$out"
+
+if [ "$code" -ne 0 ]; then
+  if grep -q "is the current active version" <<<"$out"; then
+    echo "::notice title=Redundant release::${TARGET}/${CHANNEL}: content already live; treating as success."
+  else
+    echo "::error title=Firebase preview deploy failed::target=${TARGET} channel=${CHANNEL}"
+    exit 1
+  fi
+fi
+
+# Channel URLs are stable per channel (https://<site>--<channel>-<hash>.web.app).
+# Take it from the deploy output; on the redundant-release path fall back to
+# the channel list.
+url="$(grep -oE "https://[A-Za-z0-9-]+\.web\.app" <<<"$out" | grep -- "--${CHANNEL}-" | head -1 || true)"
+if [ -z "$url" ]; then
+  list_out="$($FIREBASE hosting:channel:list --site "$TARGET" --project "$PROJECT_ID" 2>&1 || true)"
+  url="$(grep -oE "https://[A-Za-z0-9-]+\.web\.app" <<<"$list_out" | grep -- "--${CHANNEL}-" | head -1 || true)"
+fi
+
+echo "url=${url}" >> "$GITHUB_OUTPUT"
+{
+  echo "### Firebase preview: \`${TARGET}\`"
+  if [ -n "$url" ]; then echo "${url} (expires 7d after last deploy)"; else echo "_deployed, but URL could not be determined_"; fi
+} >> "$GITHUB_STEP_SUMMARY"