Skip to content
New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom

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

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

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 •
edited
Loading

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
This was referenced Aug 27, 2024
Open
Closed
@lidel lidel mentioned this issue Sep 3, 2024
Merged
@gammazero gammazero mentioned this issue Oct 17, 2024
Closed
28 tasks
@lidel lidel mentioned this issue Nov 14, 2024
Open
47 tasks
hsanjuan added a commit that referenced this issue Dec 11, 2024
@hsanjuan
Improve support for IPNS double-hashed entries
98b2a84 
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.
@hsanjuan hsanjuan mentioned this issue Dec 11, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
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
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Improve support for IPNS double-hashed entries ipfs-shipyard/nopfs
3 participants
@lidel and others