-
Notifications
You must be signed in to change notification settings - Fork 3
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
chore: invites should use special invite ID, not project public key #571
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks ok to me. A surprising amount that needed changed! I got bored and didn't completely read the changes to the tests, but the rest looks ok with a couple of minor comments.
* @param {Readonly<Buffer>} projectKey | ||
* @returns {Buffer} | ||
*/ | ||
export function projectKeyToProjectInviteId(projectKey) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this belongs in @mapeo/crypto, so that we can version it separately. We can move it in a follow-up PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in digidem/mapeo-crypto#26.
Similar to `keyToPublicId`, this adds a `keyToInviteId` for deriving an invite ID. This was originally added in `@mapeo/core` but should live here instead. See <digidem/comapeo-core#571>.
Similar to `keyToPublicId`, this adds a `keyToInviteId` for deriving an invite ID. This was originally added in `@mapeo/core` but should live here instead. See <digidem/comapeo-core#571>.
A sophisticated bad actor who knows a project's public ID could spam invites to determine whether someone was in a project.
Now, they need the harder-to-get "project invite ID", which is a separate generated value.
Closes #559.