Conversation
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
b93d957 to
caa95eb
Compare
0cac700 to
5e60f5d
Compare
|
|
||
| [](http://ipfs.io) | ||
| [](http://webchat.freenode.net/?channels=%23ipfs) | ||
| [](https://ipfs.tech) |
There was a problem hiding this comment.
Instead of making this change here, can you please PR these lines then running npx aegir check-project in the root of this repo will update the badges, etc.
achingbrain
left a comment
There was a problem hiding this comment.
LGTM, just needs a BREAKING CHANGE: ... line in the commit message.
| { | ||
| value: Uint8Array, | ||
| signature: Uint8Array, | ||
| signature: Uint8Array, // V1 (legacy, ignored) |
There was a problem hiding this comment.
imo unnecessary noise for readme – is someone wants to dig, they will be able to read specs: ipfs/specs#319
| } else { | ||
| signature = entry.signature ?? new Uint8Array(0) | ||
| dataForSignature = ipnsEntryDataForV1Sig(value, validityType, validity) | ||
| throw errCode(new Error('missing data or signatureV2'), ERRORS.ERR_SIGNATURE_VERIFICATION) |
There was a problem hiding this comment.
Maybe split if ((entry.signatureV2 != null) && (entry.data != null)) { with an escape hatch thrown error for missing data, and one for signature, instead of combining them?
There was a problem hiding this comment.
the more we combine errors, and the less detail we provide, the more problems we will run into like ipfs/interop#462 where it's much harder to track down issues than it needs to be.
There was a problem hiding this comment.
I prefer to keep it simple and have single error: these fields are all-or-nothing.
## [3.0.0](v2.0.3...v3.0.0) (2022-09-20) ### ⚠ BREAKING CHANGES * IPNS V1 signatures are ignored, records without V2 signature are no longer marked as Valid. ### Bug Fixes * require V2 signatures ([#180](#180)) ([d522bcc](d522bcc))
|
🎉 This PR is included in version 3.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
ipfs/js-ipns#180 BREAKING CHANGE: IPNS V1 signatures are ignored, records without V2 signature are no longer marked as Valid.
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.
## [37.5.4](v37.5.3...v37.5.4) (2022-09-22) ### Bug Fixes * update readme badges ([#1073](#1073)) ([d0e865b](d0e865b)), closes [/github.com/ipfs/js-ipns/pull/180#discussion_r972826024](https://github.com/ipfs//github.com/ipfs/js-ipns/pull/180/issues/discussion_r972826024)
This is part of deprecation described in ipfs/js-ipfs#4197
ipns.createcontinues to create records with both V1 and V2 signaturesipns.validateno longer accepts V1 signaturesMeaning: