Addressing custom extension fields

[Parth Patel]

https://slsa.dev/spec/v1.0/provenance#extension-fields allows for custom extension fields to be generated but the current implementation of the protobuf does not accommodate for these fields.

Is there guidance on how these fields should be used and parsed? For example, if company X made its own extension fields, would they have to maintain their own version of the protobuf?

Are there other recommendations on how this should be done (if not using protobuf)?

[Mark Lodato]

To my limited knowledge:

With proto3, I don't think there's a good answer. Proto3 basically ignores unknown fields and does not support extension fields, so you need to maintain your own version of the .proto file.

With proto2, I wonder if you could use extensions for this purpose? Something like:

// provenance.proto, converted to proto2 syntax
syntax = "proto2";
package slsa.v1;
message Provenance {
  optional BuildDefinition build_definition = 1;
  optional RunDetails run_details = 2;
  extensions 1000 to max;
}

// extension.proto
syntax = "proto2";
package mycompany;
extend slsa.v1.Provenance {
  optional Thing mycompany_thing = 123456;
}
message Thing {
  // ...
}

I don't know if this produces the proper JSON; needs testing. Also the API for accessing extensions is more awkward than regular fields.

[Parth Patel]

@kanchan-dhamane Did you or your team have any other thoughts here?

[Kanchan Dhamane]

@pxp928 , we don't want to maintain a custom implementation. Can we add extension field in RunDetails similar to the external_parameters?

[Parth Patel]

@pxp928 , we don't want to maintain a custom implementation. Can we add extension field in RunDetails similar to the external_parameters?

This is more of a question for the slsa maintainers. @MarkLodato Do you have thoughts around this?

[Mark Lodato]

I guess what @pxp928 is suggesting is to, instead of putting extensions directly on any message, all messages have an extensions field that is a map from extension name to JSON object. That would make it easier to express in protobuf and probably more future-proof. I'm open to that. Maybe we should do that in SLSA v1.1, and make that recommendation for other predicate types in the in-toto attestation repo?