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

verify and publish do not use generic YAMF hashes #17

Open
adzialocha opened this issue Jan 2, 2021 · 5 comments
Open

verify and publish do not use generic YAMF hashes #17

adzialocha opened this issue Jan 2, 2021 · 5 comments

Comments

@adzialocha
Copy link

adzialocha commented Jan 2, 2021

While decode and encode accepts any YAMF hash format, the methods verify and publish seem to be hard-coded to only support the BLAKE2b case:

  1. https://github.com/pietgeursen/bamboo-rs/blob/master/bamboo-core/src/entry/publish.rs#L26
  2. https://github.com/pietgeursen/bamboo-rs/blob/master/bamboo-core/src/entry/verify.rs#L137-L139

I'm not sure if publish and verify are meant to be opinionated implementations against the more low-level methods of the library, but wanted to bring up that they could also be made more generic to support all YAMF formats?

@pietgeursen
Copy link
Owner

Yeah, good point.

I'm not sure if publish and verify are meant to be opinionated implementations against the more low-level methods of the library

Nah, not really. I think it's just me being lazy because there's only one yamf-hash type at the moment.
Let's see if we can fix this when we pull out the YamfHash stuff in #18

@pietgeursen
Copy link
Owner

More thoughts:

What are the use cases?

    1. You want to start a new feed and want to specify what the hash type should be
    • Seems legit
    1. You want to publish to an existing feed but want to change your hash type?
    • Seems possible but rare. If it's even allowed to happen according to the spec?
    1. verify should handle all the yamf hash variants, even if they've changed types in a single feed.
    • Is important but doesn't require making verify generic, you just pass it the previous entries and it takes care to decode the hashes correctly.

@pietgeursen
Copy link
Owner

Also, you can't make something generic over a variant of an enum.

So publish can't be made to be generic over variants of YamfHash.

But I'm sure we can satisfy the use-cases we want, just not with generics.

@pietgeursen
Copy link
Owner

To revisit this:

Current state:

  • p2panda would like to use blake3 hashes because they're shorter
  • a yamfhash design goal is to only add new hashes when existing ones break
    • there are two old open PRs requesting new hash types which Aljoscha doesn't want to merge.
  • I want bamboo to work with multiple hash types (and pub key types too eventually).

Some possible ways forward:

  • fork the yamf-hash spec into https://github.com/bamboo-rs and add blake3
    • might annoy @AljoschaMeyer 👎
    • yamf-hash is starting to be yet another multiformat which seems redundant 👎 . But it's in the name so 👍
    • easy to do 👍 👍 👍
    • would be compatible with existing bamboo entries 👍
    • Implementing it in yamf-hash is pretty much done 👍
  • change bamboo to use multihash
    • I haven't worked how hard it's going to be to work that crate into bamboo ❓
    • would require forking the bamboo spec too
    • we get lots of hash types out of the box 👍
    • someone else maintains that code 👍
    • breaking change to existing bamboo entries 👎
  • make bamboo be generic over the hasher by defining a trait that could be implemented for yamf-hash or other hash types
    • lets the consumer of the library decide which hashing scheme they want to use: 👍
    • quite a lot of work 👎
    • will make the api of bamboo harder to work with (gut feeling) 👎
    • breaking change to existing bamboo entries 👎

@cafca
Copy link

cafca commented Oct 13, 2021

I don't care about existing bamboo entries and I don't know of anybody who does (yet) :D

Anyway, my guess is that

fork the yamf-hash spec into https://github.com/bamboo-rs and add blake3

is the least controversial and most pragmatic option because it wouldn't require changing the original YAMF spec.

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

No branches or pull requests

3 participants