Comments (4)
Hi Trishank. You bring up a very good point. After further thought, I don't think we need the "backwards compatibility mode" at all. It doesn't fill any known need, and we can always add such a feature in the future if/when it's needed. I'll send out a PR to remove it.
Originally, the intention of this mode was for two use cases:
- New producer + old consumer. The thinking was that the producer can produce a "backwards compatible signature" and then some process afterward can convert to the old format. But why? Just have the producer generate the old format directly.
- Old producer (or existing signature) + new consumer. The thinking was that these existing signatures can be transformed automatically into "backwards compatible signatures" and then consumed by the new consumer. But why? Just have the consumer support both formats. It's going to need to do this anyway for real backwards compatibility (as Trishank explained).
Thus, the feature doesn't seem to serve any real purpose. Removing it will reduce complexity.
from dsse.
Not to mention that we should more seriously think about backwards-compatibility in the first place. As it is, the spec is not at all backwards-compatible with older clients who may not have the luxury to update, and older repositories who may not have the luxury to maintain two different, incompatible versions of metadata.
from dsse.
Hi Trishank. You bring up a very good point. After further thought, I don't think we need the "backwards compatibility mode" at all. It doesn't fill any known need, and we can always add such a feature in the future if/when it's needed. I'll send out a PR to remove it.
Originally, the intention of this mode was for two use cases:
- New producer + old consumer. The thinking was that the producer can produce a "backwards compatible signature" and then some process afterward can convert to the old format. But why? Just have the producer generate the old format directly.
- Old producer (or existing signature) + new consumer. The thinking was that these existing signatures can be transformed automatically into "backwards compatible signatures" and then consumed by the new consumer. But why? Just have the consumer support both formats. It's going to need to do this anyway for real backwards compatibility (as Trishank explained).
Thus, the feature doesn't seem to serve any real purpose. Removing it will reduce complexity.
I think I agree, but let me think about this a bit more with a demo.
from dsse.
@trishankatdatadog Bump, do you have any thoughts? If this makes sense, we can likely merge #19...
from dsse.
Related Issues (20)
- Add envelope version HOT 8
- Communicating signing algorithm and parameters HOT 10
- Envelope headers HOT 6
- Extending DSSE to accept optional signature specific metadata HOT 26
- How to verify an envelope properly? HOT 5
- Add field for certificate chains, or explain alternative solution HOT 26
- Clarify design philosphy
- Document the sigstore/sigstore client libraries? HOT 3
- Specify DSSE Signature encoding in the Protocol or as a Parameter HOT 6
- "DSSE Multi-signature Verification" protocol lacks detail about threshold verification HOT 3
- Have you considered signing a hash digest of the payload instead of the payload itself? HOT 3
- Feature: generate DSSE language clients from the protobuf HOT 4
- reconsider threshold (aka multi-sig) verification HOT 7
- DSSE Maintainers HOT 4
- Process to enhance DSSE HOT 2
- Extending DSSE Signatures HOT 22
- DSSE Extension for Timestamping and PKI Support
- Document rationale for DSSE vs COSE etc. HOT 4
- Reducing overhead for payload encoding HOT 15
- What should be listed as parameters for signature in the protocol?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dsse.