Merge pull request #799 from pragma-org/edr-021
feat: add EDR-021: code annotations (NOTE, TODO and FIXME)
feat: add EDR-021: code annotations (NOTE, TODO and FIXME)
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]>
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]>
This is consistent with the naiive N^2 diffusion of votes early sketch that is implemented.
This is now possible because of de-duplication of the vote notification mechanism
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]>
Remove Buffer setup code for testing environment. Signed-off-by: Abhayraj Jaiswal <[email protected]>
This results in votes being forwarded already. However, this is obviously not safe to do this way in adversarial settings.
This is obviously a dirty hack, but works to drive the development right now and side-steps key registration, while already exploring how to pass the voting key into the right consensus components.
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`.
Replaces console.log with silent error handling to prevent leaking error details to stdout in production. Matches the error handling pattern used in JWT.verify(). Signed-off-by: A-Chronicle <[email protected]>
* 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.