decentraland / builder / 32493389482

53%

master: 53%

Pull #3469

github

fix(auth): upgrade decentraland-crypto-fetch to 3

Signs the payload format `@dcl/crypto-middleware` 6.x verifies. This repo
builds its own payload by concatenation rather than through the library, so
the bump alone is not enough: `createAuthHeaders` lowercased the whole
string, metadata included, after appending it. It now lowercases only the
method and path and appends the timestamp and metadata verbatim, so the
metadata header it sends is covered byte-for-byte by the signature.

No deploy ordering is needed here. Every call site sends either no metadata,
`{}`, or `{ type: worldPermissionType }`, and all four `WorldPermissionType`
values are lowercase under a lowercase key, so both formats produce identical
bytes for every request this repo makes. The change is inert on the wire and
can ship independently of the services.

Two overrides make the tree resolvable and consistent:

`decentraland-crypto-fetch` flat, because the published `decentraland-dapps`
still depends on `^2.0.1` and npm was installing a second, nested copy of the
signer at 2.0.1. Any signed request made from dapps code would have kept
emitting the old format from inside this app. The tree now holds exactly one
instance, at 3.0.0, deduped.

`@dcl/hooks` nested, because it declares `decentraland-crypto-fetch@^2.0.1`
as a peer and arrives transitively through `decentraland-ui2`, so npm could
satisfy neither range and every workflow failed at install with ERESOLVE --
`audit` and `test` both died there without running anything. No published
`@dcl/hooks` accepts 3.x. The pin is over-restrictive rather than meaningful:
hooks' only use is `signedFetchFactory()`, unchanged in 3.0.0, and it signs no
metadata, so it is unaffected by the format change.

Lockfile moves only where the bump forces it: `core-js-pure` drops out as a
2.0.1-only dependency, and `@dcl/crypto` goes 3.4.5 -> 3.7.0 with its subtree
because 3.0.0 pins that version exactly.

2444 of 5783 branches covered (42.26%)

Branch coverage included in aggregate %.

0 of 3 new or added lines in 1 file covered. (0.0%)

7516 of 13018 relevant lines covered (57.74%)

35.52 hits per line