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.

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

Remove Author and Signature fields from Record #15

Merged
merged 4 commits into from
Feb 7, 2018

Conversation

dirkmc
Copy link
Contributor

@dirkmc dirkmc commented Jan 31, 2018

No description provided.

pb/record.proto Outdated
// Time the record was received, set by receiver
optional string timeReceived = 5;
optional string timeReceived = 3;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please don't change the field id, it is backwards incompatible.

Copy link
Member

@Stebalien Stebalien Feb 1, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(although I'm pretty sure that's technically a harmless change.)

But I agree, don't change this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch.. please take a look at the diff of record.pb.go. The protoc compiler I'm using has added in a field called Descriptor. I'm not sure what that is so just want to make sure it's ok

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never mind I fixed

pb/record.proto Outdated
optional string author = 3;

// A PKI signature for the key+value+author
optional bytes signature = 4;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably leave a comment reserving these fields.

@vyzo
Copy link

vyzo commented Feb 1, 2018

i think @whyrusleeping should chime in here too, that's a pretty drastic change in behaviour and i'd like to know if we'll break anything by suddenly removing signatures and their validation.

@vyzo vyzo requested a review from whyrusleeping February 1, 2018 10:46
@Stebalien
Copy link
Member

@vyzo I've talked with @whyrusleeping offline but yes, I'd like him to give a final signoff. This shouldn't break anything as we only validate signatures iff they're present but still...

After talking about this with Juan again (and again), we're pretty sure this signature came about as an early attempt at IPRS. Unfortunately, when we added support for multiple IPNS keys, we kept on signing the DHT records with the wrong key so trying to use this for IPRS at this point wouldn't work all that well...

Personally, I'd almost like to just introduce IPRS as separate path. For the "backwards compat period", ipfs nodes would publish/retrieve both the IPRS and old records. After that compatibility period, they'd stop retrieving the old records. With request pipelining, this shouldn't be that expensive and allows us to start over.

Anyways, the way we do signatures on these records and IPNS records is kind of broken and is only secure by happy coincidence (ipfs/notes#249).

@whyrusleeping
Copy link
Contributor

Yeah, I'm comfortable moving forward with this. The signatures on the dht records themselves are pretty useless all things considered, and as @Stebalien it might have been an early (failed) attempt at IPRS

Copy link
Contributor

@whyrusleeping whyrusleeping left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept LGTM, Note that I havent thoroughly reviewed the code. I can do so if thats wanted.

@Stebalien Stebalien merged commit 59e56e8 into libp2p:master Feb 7, 2018
@Stebalien
Copy link
Member

LGTM. Thanks @dirkmc!

@dirkmc dirkmc deleted the fix/remove-sigs branch February 7, 2018 23:03
@dirkmc
Copy link
Contributor Author

dirkmc commented Feb 7, 2018

Glad to be of help
Do you think we still need #10?

@Stebalien
Copy link
Member

@dirkmc I'd still like to use something like the ValidationRecord elsewhere in our code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants