Apr 28, 6-7 AM (8)
Apr 28, 7-8 AM (37)
Apr 28, 8-9 AM (54)
Apr 28, 9-10 AM (59)
Apr 28, 10-11 AM (53)
Apr 28, 11-12 PM (56)
Apr 28, 12-1 PM (49)
Apr 28, 1-2 PM (54)
Apr 28, 2-3 PM (69)
Apr 28, 3-4 PM (31)
Apr 28, 4-5 PM (14)
Apr 28, 5-6 PM (47)
Apr 28, 6-7 PM (9)
Apr 28, 7-8 PM (9)
Apr 28, 8-9 PM (14)
Apr 28, 9-10 PM (20)
Apr 28, 10-11 PM (34)
Apr 28, 11-12 AM (29)
Apr 29, 12-1 AM (13)
Apr 29, 1-2 AM (1)
Apr 29, 2-3 AM (1)
Apr 29, 3-4 AM (6)
Apr 29, 4-5 AM (1)
Apr 29, 5-6 AM (4)
Apr 29, 6-7 AM (12)
Apr 29, 7-8 AM (45)
Apr 29, 8-9 AM (75)
Apr 29, 9-10 AM (49)
Apr 29, 10-11 AM (28)
Apr 29, 11-12 PM (51)
Apr 29, 12-1 PM (39)
Apr 29, 1-2 PM (21)
Apr 29, 2-3 PM (67)
Apr 29, 3-4 PM (25)
Apr 29, 4-5 PM (36)
Apr 29, 5-6 PM (16)
Apr 29, 6-7 PM (10)
Apr 29, 7-8 PM (14)
Apr 29, 8-9 PM (13)
Apr 29, 9-10 PM (17)
Apr 29, 10-11 PM (25)
Apr 29, 11-12 AM (29)
Apr 30, 12-1 AM (6)
Apr 30, 1-2 AM (8)
Apr 30, 2-3 AM (1)
Apr 30, 3-4 AM (6)
Apr 30, 4-5 AM (2)
Apr 30, 5-6 AM (8)
Apr 30, 6-7 AM (15)
Apr 30, 7-8 AM (17)
Apr 30, 8-9 AM (100)
Apr 30, 9-10 AM (19)
Apr 30, 10-11 AM (50)
Apr 30, 11-12 PM (120)
Apr 30, 12-1 PM (69)
Apr 30, 1-2 PM (45)
Apr 30, 2-3 PM (117)
Apr 30, 3-4 PM (29)
Apr 30, 4-5 PM (34)
Apr 30, 5-6 PM (9)
Apr 30, 6-7 PM (20)
Apr 30, 7-8 PM (23)
Apr 30, 8-9 PM (28)
Apr 30, 9-10 PM (13)
Apr 30, 10-11 PM (25)
Apr 30, 11-12 AM (15)
May 01, 12-1 AM (18)
May 01, 1-2 AM (15)
May 01, 2-3 AM (6)
May 01, 3-4 AM (7)
May 01, 4-5 AM (3)
May 01, 5-6 AM (5)
May 01, 6-7 AM (8)
May 01, 7-8 AM (15)
May 01, 8-9 AM (24)
May 01, 9-10 AM (17)
May 01, 10-11 AM (16)
May 01, 11-12 PM (17)
May 01, 12-1 PM (39)
May 01, 1-2 PM (32)
May 01, 2-3 PM (19)
May 01, 3-4 PM (16)
May 01, 4-5 PM (25)
May 01, 5-6 PM (11)
May 01, 6-7 PM (20)
May 01, 7-8 PM (22)
May 01, 8-9 PM (65)
May 01, 9-10 PM (15)
May 01, 10-11 PM (40)
May 01, 11-12 AM (61)
May 02, 12-1 AM (6)
May 02, 1-2 AM (11)
May 02, 2-3 AM (5)
May 02, 3-4 AM (8)
May 02, 4-5 AM (6)
May 02, 5-6 AM (2)
May 02, 6-7 AM (2)
May 02, 7-8 AM (14)
May 02, 8-9 AM (7)
May 02, 9-10 AM (8)
May 02, 10-11 AM (11)
May 02, 11-12 PM (7)
May 02, 12-1 PM (7)
May 02, 1-2 PM (3)
May 02, 2-3 PM (14)
May 02, 3-4 PM (9)
May 02, 4-5 PM (27)
May 02, 5-6 PM (9)
May 02, 6-7 PM (29)
May 02, 7-8 PM (11)
May 02, 8-9 PM (15)
May 02, 9-10 PM (1)
May 02, 10-11 PM (20)
May 02, 11-12 AM (18)
May 03, 12-1 AM (8)
May 03, 1-2 AM (1)
May 03, 2-3 AM (4)
May 03, 3-4 AM (7)
May 03, 4-5 AM (1)
May 03, 5-6 AM (4)
May 03, 6-7 AM (32)
May 03, 7-8 AM (5)
May 03, 8-9 AM (1)
May 03, 9-10 AM (3)
May 03, 10-11 AM (10)
May 03, 11-12 PM (11)
May 03, 12-1 PM (16)
May 03, 1-2 PM (11)
May 03, 2-3 PM (2)
May 03, 3-4 PM (2)
May 03, 4-5 PM (5)
May 03, 5-6 PM (0)
May 03, 6-7 PM (5)
May 03, 7-8 PM (6)
May 03, 8-9 PM (8)
May 03, 9-10 PM (15)
May 03, 10-11 PM (23)
May 03, 11-12 AM (17)
May 04, 12-1 AM (4)
May 04, 1-2 AM (4)
May 04, 2-3 AM (10)
May 04, 3-4 AM (9)
May 04, 4-5 AM (5)
May 04, 5-6 AM (6)
May 04, 6-7 AM (6)
May 04, 7-8 AM (28)
May 04, 8-9 AM (24)
May 04, 9-10 AM (43)
May 04, 10-11 AM (36)
May 04, 11-12 PM (61)
May 04, 12-1 PM (34)
May 04, 1-2 PM (47)
May 04, 2-3 PM (64)
May 04, 3-4 PM (33)
May 04, 4-5 PM (64)
May 04, 5-6 PM (49)
May 04, 6-7 PM (13)
May 04, 7-8 PM (31)
May 04, 8-9 PM (45)
May 04, 9-10 PM (9)
May 04, 10-11 PM (54)
May 04, 11-12 AM (24)
May 05, 12-1 AM (4)
May 05, 1-2 AM (5)
May 05, 2-3 AM (5)
May 05, 3-4 AM (11)
May 05, 4-5 AM (11)
May 05, 5-6 AM (23)
May 05, 6-7 AM (2)
3,744 commits this week Apr 28, 2026 - May 05, 2026
fix(didcomm): handle keylist-update-response from mediator
The SDK sent MediationKeysUpdateList to the mediator but did not process
the response, so per-recipient failures reported by the mediator went
unnoticed.

Register a handler for the keylist-update-response protocol message.
Each entry in body.updated is inspected; results other than success or
no_change are logged as warnings with the recipient DID and action.
Confirmed against the Identus mediator (MediatorCoordinationExecuter.scala)
which returns this response with tuples of (recipient_did, action, result).

Closes #391

Signed-off-by: Seydi Charyyev <[email protected]>
fix(pollux): check nbf claim in JWT.verify
JWT.verify did not validate the nbf (not before) claim, so JWTs with nbf in the future were incorrectly considered valid. This is a security issue per RFC 7519 Section 4.1.5.

Added an explicit nbf check after JWT decode: if nbf is present and the current time is before it, verify() returns false. JWTs without an nbf claim keep the previous behavior (no nbf enforced).

This is a sister fix to #489/#550 (which addressed the exp claim).

Closes #551

Signed-off-by: Seydi Charyyev <[email protected]>
fix(pollux): check exp claim in JWT.verify
JWT.verify did not validate the exp (expiration) claim, so expired JWTs were incorrectly considered valid. This is a security issue per RFC 7519 Section 4.1.4.

Added an explicit exp check after JWT decode: if exp is present and the current time is at or past it, verify() returns false. JWTs without an exp claim keep the previous behavior (no expiration enforced).

Closes #489

Signed-off-by: Seydi Charyyev <[email protected]>
plan modules: expose `identifier.unit-id` and `package-ids-by-name`
Pure additions for consumers that need to look up packages by
plan-id rather than canonical name.

* `package.identifier.unit-id` (modules/package.nix): a new
  optional field carrying plan.json's per-entry `id` (defaults to
  null when not derived from a plan entry).
* `modules/install-plan/planned.nix`: when constructing the
  per-plan-id package entries, populate `package.identifier`
  with `name` / `version` / `unit-id`.  Without this,
  reading `package.identifier.{name,version}` on a plan-id-keyed
  entry threw — the canonical-name-keyed entry already gets a
  real identifier via `load-cabal-plan.nix`, but the per-plan-id
  ones (used when one canonical name has multiple plan instances)
  did not.
* `package-ids-by-name` (modules/plan.nix +
  install-plan/override-package-by-name.nix): a name → [id]
  index over `plan-json.install-plan`.  A canonical pkg-name can
  appear under several plan ids (per-instance UnitIDs that differ
  only in their dep UnitIDs, or a multi-component package split
  across per-component entries); consumers can now iterate the
  ids unambiguously instead of name-matching against
  `config.packages`.
dummy GHC: mirror real GHC's `--info` capabilities and ghc-pkg `id:` field (#2502)
* dummy GHC: mirror real GHC's `--info` capabilities and ghc-pkg `id:` field

Bring plan-to-nix's dummy GHC closer to the real cross GHC it
stands in for, so cabal-install computes the same UnitId hashes
either way.

`--info` capability fields cabal-install reads to decide
configure-args (`--enable-shared` / `--disable-shared`,
`--enable-library-for-ghci` / `--disable-library-for-ghci`,
etc.) — those land in `pkgHashConfigInputs` and feed the UnitId
hash.  The current dummy stops at platform fields, so cabal
silently picks the conservative `--disable-*` defaults.  Mirror
the real cross GHC's reported capabilities, conditioned on
target platform:

  * x86_64-w64-mingw32 (Windows mingw): no `Support shared
    libraries` field, `Support dynamic-too: NO`, `GHC Dynamic:
    NO`, RTS ways without any `_dyn` entries, Stage 1.
  * ghcjs / wasm: stage-1 with only `v debug` RTS ways and no
    dynamic linking.
  * native Linux / Darwin: dynamic everything, Stage 2.

ghc-pkg dump entries:

  * Add the missing `id:` line.  Real `ghc-pkg dump` always
    emits one, and consumers (including cabal-install's solver)
    rely on it.
  * Mirror the `-inplace` convention real GHC uses for in-tree
    libraries (base, ghc-prim, text, ...) by appending `-inplace`
    to both the package's own id and to dep ids referenced from
    other packages.  Skip the suffix for `rts` and
    `system-cxx-std-lib`, which are registered with bare
    `<name>-<version>` ids in the real package conf and would
    otherwise fork dep-id strings from what cabal computes.

* nix-tools: move cabal-install patch back inside nix-tools/ tree

#2501 placed the shared patch at `builder/cabal-install-patches/`
and referenced it from `nix-tools/cabal-install-patches.nix` as
`../builder/cabal-install-patches/...`.  That breaks the static
nix-tools build (e.g. job
`aarch64-darwin.nix-tools.static.zipped.nix-tools-static-no-ifd`,
build 1046198 on ci.zw3rk.com) with

  error: access to absolute path '/nix/store/builder' is forbidden
         in pure evaluation mode (use '--impure' to override)

`cabalProject'` copies `src = ./.` (the nix-tools dir) to the
nix store and re-evaluates module paths from there.  A path that
escapes the source tree resolves to `/nix/store/<...>/../builder`
→ `/nix/store/builder`, which doesn't exist and is rejected
under pure-eval.

Move the patch into `nix-tools/cabal-install-patches/` so the
relative path (`./cabal-install-patches/...`) stays inside the
copied source tree.  Both the regular and static nix-tools
builds still import the same shared module, so they continue to
patch cabal-install identically.

* dummy GHC: convert in-script bash comments to nix comments

The previous commit added two large explanatory `#` comment
blocks *inside* the dummy GHC's shell script (one before the
`${...}` capability-fields interpolation, one before the
`suffix()` bash function in the ghc-pkg-dump script).  Bash
comments inside the `''...''` strings are part of the resulting
script — every word change re-hashes the derivation and busts
caches downstream.

Move both blocks into nix-level `${ # ... "" }` interpolations
that evaluate to the empty string.  The comments stay adjacent
to the code they describe but no longer land in the script,
so re-wording them only churns the .nix file.