ITE-5: Route to acceptance

[adityasaky]

ITE-5 was merged as draft back in May. We believe it's now time to discuss what needs to happen before it can be accepted. Since it was merged as draft, the signing specification it recommends has been renamed as DSSE (https://github.com/secure-systems-lab/dsse), and has also seen a v1.0 release! Therefore, it seems like the right time to move ITE-5 along.

ITE-5: https://github.com/in-toto/ITE/blob/master/ITE/5/README.adoc

[trishankatdatadog]

Happy to accept it, but it needs a serious backwards-compatibility plan. Is there any?

[adityasaky]

ITE-5 currently calls for implementations to support both envelopes. I wonder if we can define a timeframe of support for both envelopes past which the reference implementation supports only DSSE? We would have to align this period with a possible 2.0 release for the implementation.

[trishankatdatadog]

I think we should have a few options for the reference implementation:

1. Produce only old signatures.
2. Produce both old and new signatures.
3. Produce only new signatures.

It can choose a deprecation plan that gives concrete timelines for going from 1-3.

[adityasaky]

Thanks, Trishank, that sounds sensible to me. Do you have any thoughts on how long the implementation should support both signatures?

[trishankatdatadog]

How does everyone feel about 1 year for each phase? Too long? I think it's just short and long enough to keep people from saying we didn't warn them.

“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”

[adityasaky]

Well, we're already in phase 1, and phase 3 is indefinite. That leaves us at one year for phase 2, right?

[trishankatdatadog]

Well, we're already in phase 1, and phase 3 is indefinite. That leaves us at one year for phase 2, right?

@ofek py-in-toto is planning to phase out the old-style signatures we are using in a year. After that, to use new versions of py-in-toto, we need to upgrade our signatures to the new style, which will break old downloaders. Thoughts?

[ofek]

I guess we'll have to cope with that and notify users someone. We've had to introduce breaking changes before so this shouldn't be too big of an issue.

[trishankatdatadog]

@adityasaky is there a plan to maintain different major versions of py-in-toto? For example, 0.x for old-style, 1.x for both-styles, and 2.x for new-style? This way, we can backport bugfixes w/o breaking backwards-compatibility.

[adityasaky]

I'm not sure we have the maintainer bandwidth to pull that off. I guess it's really a question to ask of securesystemslib rather than in-toto?

Edit: I remember Lukas was also wary about maintaining support for two wrappers in sslib.

[trishankatdatadog]

I'm not sure we have the maintainer bandwidth to pull that off. I guess it's really a question to ask of securesystemslib rather than in-toto?

Ok, can you help us figure this out? I believe we've laid out our basic requirements at DD.

To clarify: we don't need three different major versions, but we do need concrete timeline and versioning.

[adityasaky]

I'll reach out to Joshua as well. Implementation support may also depend on the timeline TUF has for their transition.

[trishankatdatadog]

I'll reach out to Joshua as well. Implementation support may also depend on the timeline TUF has for their transition.

In fact: let's keep this simple. Just write code for both options (2) and (3), and set to do only (3) by default. End-users like DD can choose whether to use (2). Thanks.