Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

Remove support for deprecated IPNS records v1 #4197

Closed
lidel opened this issue Aug 31, 2022 · 0 comments · Fixed by #4207
Closed

Remove support for deprecated IPNS records v1 #4197

lidel opened this issue Aug 31, 2022 · 0 comments · Fixed by #4207
Labels
kind/maintenance Work required to avoid breaking changes or harm to project's status quo need/triage Needs initial labeling and prioritization P1 High: Likely tackled by core team if no one steps up

Comments

@lidel
Copy link
Member

lidel commented Aug 31, 2022

Part of ipfs/specs#314, corresponding Kubo issue: ipfs/kubo#9240

Support for extensible records (and v2 signature) was added in 2021 (ipfs/js-ipns#121). JS-IPFS is producing and preferring updated v2 IPNS records by default, but if no v2 is found, it will still accept deprecated v1 for backward-compatibility during the transition period.

A year later, we should remove fallback support for validating v1 signatures and ignore them instead.

@lidel lidel added P1 High: Likely tackled by core team if no one steps up kind/maintenance Work required to avoid breaking changes or harm to project's status quo need/triage Needs initial labeling and prioritization labels Aug 31, 2022
lidel added a commit to ipfs/js-ipns that referenced this issue Sep 12, 2022
This is part of deprecation described in ipfs/js-ipfs#4197
- record creation continues to create both V1 and V2  signatures
- record validation no longer accepts V1 signatures

Meaning:
- modern nodes are 100% V2, they ignore V1 signatures
- legacy nodes (go-ipfs < v0.9.0, js-ipfs before Jun 2021) are still
  able to resolve names created by js-ipns, because V1 is still present
lidel added a commit to ipfs/js-ipns that referenced this issue Sep 12, 2022
This is part of deprecation described in ipfs/js-ipfs#4197
- record creation continues to create both V1 and V2  signatures
- record validation no longer accepts V1 signatures

Meaning:
- modern nodes are 100% V2, they ignore V1 signatures
- legacy nodes (go-ipfs < v0.9.0, js-ipfs before Jun 2021) are still
  able to resolve names created by js-ipns, because V1 is still present
lidel added a commit to ipfs/js-ipns that referenced this issue Sep 20, 2022
* fix: require V2 signatures

This is part of deprecation described in ipfs/js-ipfs#4197
- record creation continues to create both V1 and V2  signatures
- record validation no longer accepts V1 signatures

Meaning:
- modern nodes are 100% V2, they ignore V1 signatures
- legacy nodes (go-ipfs < v0.9.0, js-ipfs before Jun 2021) are still
  able to resolve names created by js-ipns, because V1 is still present

BREAKING CHANGE: IPNS V1 signatures are ignored, records without V2 signature are no longer marked as Valid.
achingbrain pushed a commit that referenced this issue Sep 22, 2022
Co-authored-by: achingbrain <alex@achingbrain.net>

js-ipfs will now ignore V1 signatures when validating IPNS records, and always require V2.

See ipfs/js-ipns#180 for low level details (needs that to be released before merging this)

Closes #4197

BREAKING  CHANGE: IPNS Records that do not have V2 but have V1 signature will no longer pass validation, even if V1 is correct. V2 is mandatory to pass validation. See "Record validation" in ipfs/specs#319 for details.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/maintenance Work required to avoid breaking changes or harm to project's status quo need/triage Needs initial labeling and prioritization P1 High: Likely tackled by core team if no one steps up
Projects
No open projects
Archived in project
Development

Successfully merging a pull request may close this issue.

1 participant