Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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

Closed
Tracked by #126 ...
lidel opened this issue Aug 27, 2024 · 1 comment · Fixed by #41
Closed
Tracked by #126 ...

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

lidel opened this issue Aug 27, 2024 · 1 comment · Fixed by #41
Labels
effort/hours Estimated to take one or several hours exp/intermediate Prior experience is likely helpful P1 High: Likely tackled by core team if no one steps up

Comments

@lidel
Copy link
Member

lidel commented Aug 27, 2024

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'
@lidel lidel added effort/hours Estimated to take one or several hours exp/intermediate Prior experience is likely helpful P1 High: Likely tackled by core team if no one steps up labels Aug 27, 2024
@gammazero gammazero mentioned this issue Oct 17, 2024
28 tasks
@lidel lidel mentioned this issue Nov 14, 2024
60 tasks
hsanjuan added a commit that referenced this issue Dec 11, 2024
Fixes #40. This ensures that double-hashed IPNS entries both in modern and legacy
forms are correctly supported, including both:
  * /ipns/<domain>
  * /ipns/key

Before, only the modern form with /ipns/<domain> was correctly supported for
double-hashed entries.

Testcases have been added for all forms.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
effort/hours Estimated to take one or several hours exp/intermediate Prior experience is likely helpful P1 High: Likely tackled by core team if no one steps up
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants
@lidel and others