Skip to content

Support legacy double-hash entries for IPNS CIDs and DNSLink #40

Closed
@lidel

Description

@lidel

Why

Filling this issue so we don't have regression in IPNS Blocking (https://github.com/ipshipyard/waterworks-infra/issues/209) when switching from legacy badbits service to modern NOPFS-based support in rainbow and kubo.

We need to ensure modern nopfs in rainbow/kubo applies check to /ipns/{id} content paths starting with either ipns record as cidv1 and a string with dnslink name.

What

Work here is to check NOpfs behavior, namely, if legacy double-hashed rules are applied to /ipns/ namespace, and if not, implement it.

Badbits denylist already has a lot of IPNS CIDs + our legacy infra supports double-hashed DNSLink since https://github.com/protocol/badbits.dwebops.pub/pull/40002.

We also clarified in specs ipfs/specs#482

Test vectors

  • phishing campaign: /ipns/k51qzi5uqu5dixwsch9wpd9rolqby1m0uqj5hhxwtxal0dwltastfmh01dlniq//6ef262a67f2c7caa9722b0fe46aced2f1559c749eab2bcf2f2701f43f802e900
  • dnslink: double-hashed DNSLink in legacy format:
    > const crypto = await import('crypto')
    > crypto.createHash('sha256').update('very-bad-example.eth' + '/').digest('hex')
    'fb5a70b1aade810d21e8195a0da05f40ebd099e4b4d6bf088dc604e4fcf34263'

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High: Likely tackled by core team if no one steps upeffort/hoursEstimated to take one or several hoursexp/intermediatePrior experience is likely helpful

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions