Aditya Sirish

Let's introduce a new exception and replace PrefixError with it when we're ready for in-toto 3.0.0, a generic error for any artifact collisions.

This is another one that I think we might want to solve via go-securesystemslib (it's also something that comes up in gittuf for example: https://github.com/gittuf/gittuf/issues/276). IIRC python-securesystemslib supports encrypted keys,...

Very excited to see this happen!

I think this isn't fully resolved until we pull in pb layers?

Hi @cosmin79, thanks for flagging this. I'm wondering what the right course of action here is, as the spec doesn't mandate one way or another. Ideally, it would be better...

I'd wager we should handle this and add tests via https://github.com/in-toto/in-toto/issues/563 to catch regressions in future.

I should also note that the spec is being updated (https://github.com/in-toto/docs/pull/75) to be more explicit about the patterns. That'd make in-toto-golang non compliant.

IIRC it's only the hash but I can take another look. FWIW, we're evaluating the future of in-toto-golang and how it may be merged with github.com/in-toto/witness / go-witness, so perhaps...

No, the consolidation effort will likely take longer than that.

I suspect this is a go version mismatch because of the use of `max` in a dependency. cc @shibumi