in-toto/attestation Maintainers Meeting

# in-toto/attestation Maintainers Meeting ## Next ### Agenda ## 2024-09-27 ### Attendees * John Kjell (TestifySec) * Aditya Sirish (NYU) * Marcela Melara (Intel) * Parth Patel (Kusari) * James Carnegie (Docker) * Andrew Leonard (Red Hat) ### Agenda * Trust in subjects vs predicate content * CycloneDX attestation vs in-toto attestations * Thresholds with multiple signatures vs multiple attestations ## 2024-08-30 ### Attendees * Aditya Sirish (NYU) * Parth Patel (Kusari) * Daniel Moch (Lockheed Martin) * Marco Deicas (Google) * John Kjell (TestifySec) ### Agenda * Welcome new members * Updates * ITE-10/11: merged as draft * in-toto policies WG: working on iterating over ITEs * Policies vs attestations * Attestations meeting started discussing -verifier when it was moved to @in-toto * But main discussions happen in the policies WG as part of the spec work * General feedback: we should be clear about dilineation of attestations and policies, where each spec is, etc. * Reference predicate * Use of SCAI? * If using SCAI, would define attributes for this * Using SCAI -> would have to unpack to inspect all attributes, can't rely only on predicate type * Is there a proposal to create a library of SCAI attributes? * Not a formal proposal yet, but it's been suggested * Briefly discussed before: treat generic SCAI as a template, have predicates built on top with curated attributes * John: Opening the door to generic reference types could open the door to it being misused when other specific options may exist * There may not be a right or wrong answer and it depends on how people also perceive * On the policy side: is there a requirement to fully understand all of the predicates to be able to set policies? * Parth: SCAI can do everything but we run the risk of defeating the purpose of having predicate types in the first place * Creating new predicate types is probably the best way to go * Marco: We need guidance on how to handle potentially overlapping predicates, if the reference predicate is accepted * Marco: predicates should be smaller, unambiguous in how they're used * Aditya: there was an earlier discussion related to this, making predicates unambiguous * And also pushing to reduce the number of optional fields in a predicate to avoid ambiguity in how they're parsed ## 2024-06-28 ### Attendees * Tom Hennen * John Kjell * Parth Patel * Matthias Glastra * Victor Lu * Daniel Moch * Marcela Melara ### Agenda * Welcome new members * Issue triage * PR approval? https://github.com/in-toto/attestation/pull/370 * Current thoughts on https://github.com/in-toto/attestation/issues/179 * Opens * Question Slack about SLSA: https://cloud-native.slack.com/archives/C06HBJUEJBT/p1719428415478259 ## 2024-05-31 CANCELED. ## 2024-04-26 :movie_camera: [Recording](https://zoom.us/rec/share/pAv5v8KYCtwcXMKuAJ5HUE93BqQkUtGyj0ebLq_C9JERYd2kZ6Umn6a1pyEdoN0o.hQixfa61RMiw19Yf) ### Attendees - John Kjell (TestifySec) - Parth Patel (Kusari) - Aditya Sirish (NYU) - Mikhail Swift (TestifySec) - Toddy Mladenov - Marcela Melara (Intel) ### Agenda * [Tom] Re-defining a more [general VSA predicate](https://docs.google.com/presentation/d/1_1ikfSaja87-Qx2ev26DYdiNgS6AEvVFO92oSwNGvJ8/edit) * Deferring for discussion over future PR * Add Typescript protobuf generation to support a few downstream use cases (e.g. [1]( https://github.com/github-early-access/generate-build-provenance/blob/main/src/provenance.ts)) * NPM attestations (Build and Publish) done in TypeScript * Any additional use cases? * What direction would maintainers prefer? * Goal or anti-goal to generate more and more language bindings? * How can we make it easier for folks to generate their own language bindings? * TypeScript seems popular enough (and the use in NPM is significant) to justify hosting. * Generating bindings will help implementations move towards standard protobuf definitions of predicates. * https://github.com/in-toto/attestation/issues/339 * **Action item**: follow up on issue 339 * **Action item**: Open issue for docs update on "How-to generate language binding" * Vuln predicate updates? * PR started here for protobuf - https://github.com/in-toto/attestation/pull/345 * Toddy will present some more feedback and use cases next call * Why not Sarif? * Too generic for many specific use cases * Many vendors use same fields in varying ways * Opportunity to move towards a more useful standard for OSS tooling (trivy, grype, etc) * GUAC open issue to switch to new predicate - https://github.com/guacsec/guac/issues/1242 * **Action item**: ask GitHub about supporting predicate-type similarly to "Upload Sarif" action * PR Review * Currently 5 open * Deployment attestation * New predicate proposal - express information about admission control to specific environments * Overlaps with a "Policy" or layout and the VSA * Looking for additional viewpoints * What is a new predicate vs reusing another * Providing evidence should be a predicate * Describing expectations should be a policy * Ideal scenario is to define a predicate to ensure it's easy to also define expectations consitently * Expand "Resource Descriptor" definition * https://github.com/in-toto/attestation/pull/338 * Important intent is to allow unique identification * Human Reviews * https://github.com/in-toto/attestation/pull/151 * Allows for code reviews and/or dependency package review * Perhaps allow for "sub-types" * Could possibly apply to SLSA Source Track * **Action Item**: Reach out to Kris K and Nicolas * VEX is another type of "Human Review" * Is there a general set of recommendations for these types * Signature of human reviewer is potentially a property of the attesation * SBOM Attestations * Don't want protobufs for large specifications (like CycloneDX and SPDX) * SBOMs are also growing very large - how can we enable references to external evidence * Question comes to, what is a "Best Practice" around policy evaluation of these attestations * **Action Item**: File an issue for discussing how to capture "Best Practices" ## 2024-03-29 (PUBLIC) :movie_camera: [Recording](https://zoom.us/rec/share/4aBc0EuUE4ILwOgkh6AtW9xr-YTyXPpTYwEbEZNhk4fkFd_RlZudmAeTlOlh4UFa.AjcL7wW0g7_RrNiM) ### Attendees * Aditya Sirish (NYU) * Marcela Melara (Intel) * Alan Chung Ma ### Agenda * [Aditya, John] Attestation collection predicate * What is needed for resolution on [PR #338](https://github.com/in-toto/attestation/pull/338)? * Should we allow identifiers that aren't cryptographic hashes in the `digest` field? * Maybe it's ok to loosen the requirement of who generated * [Alan] Design for [scalable layouts](https://docs.google.com/document/d/1-pP-ycaIMN1H6llK1BWdovmNsY8AZ-grVRZZZwuWw2o/edit#heading=h.pwepozqf8x8p) * Concern around needing to hardcode individual steps in the policy, and switching to a 1-to-1 mapping between steps and predicates * Q: For steps that generate two attestations (e.g., builds generating SBOM and SLSA), how would the policy for this be written? * Might be able to resolve this with more use of sub-layouts * Need clarification around the model of a step * We have hardcoding in the attestation-verifier: May just be an issue with transformational predicates (Links, Provenance), it's not always easy to determine if a predicate is transformational. * Want to be able to define policies: * Live attestations (i.e., ones where you have time-sensitive policies); the harder part is associating a DSSE signature with a timestamp * Rules around tools that were used to generate artifacts or attestations * Need examples of these policies * Could we use generic VSAs to condense layouts? * Discussion around resolution of attestations referenced within other attestations * Raises the question and need for policy orchestration * May address some of the scalability issues of layouts * Need to begin to document requirements, ideas, questions * Triage Issues: * [digest in digest_set and ResourceDescriptor is not valid JSON #269](https://github.com/in-toto/attestation/issues/269) * Seems resolved on the OP's end * Pinged the OP to make sure we can close * [Inefficient payload encoding #289](https://github.com/in-toto/attestation/issues/289) * [Define a field for attestor identification #329](https://github.com/in-toto/attestation/issues/329) * Resolve these two offline * Opens: * Who is going to OSS NA '24? ## 2024-02-23 (PUBLIC) ### Attendees * Aditya Sirish (NYU) * Tom Hennen (Google) * Parth Patel (Kusari) * Trishank Karthik Kuppusamy (Datadog) * Matthias Glastra * Kairo De Araujo (Testifysec) * Alan Chung Ma (Purdue) ### Agenda * [Storing in-toto attestations in an OCI registry](https://docs.google.com/document/d/19mXclYjXjql1h3Yjijvev9tvALlT7cJQvbmJmk7IFCU/edit#heading=h.yrkjslw0kw3a) -- another use case for a null predicate? * Quick summary of this doc * The idea is to have a reference to a predicate instead of storing the predicate as a whole * Null predicate -> subject points to the actual predicate blob * Tom: Wasn't there a reference predicate proposal? * https://github.com/in-toto/attestation/issues/179 * This lets you point at some other evidence. * In some cases it makes a lot of sense but we move a lot of work to the users to fetch / resolve the predicate * Parth: Would the target also be DSSE? Signed? * Aditya: I think not, I think the signature is only over the reference and that includes the hash of the target predicate * Trishank: do you really need yet another attestation with a null predicate that's signed? Couldn't it be part of the OCI metadata or something? * Also, the more attestations / references you have, the more overhead you add to the registry? * Tom: https://github.com/in-toto/attestation/issues/271 and https://github.com/in-toto/attestation/pull/283 * These may also help address this Docker-specific concern? * This would also avoid a world where downstream has multiple options to parse the same thing * Matthias: OCI reference type predicate might be helpful too * Aditya: Is this similar to the OCI content descriptor as payload option from the doc? * Tom: We're also looking at how to upload to OCI * Tom and Parth will look at the doc and drop comments too * ITE-11 * https://github.com/in-toto/ite/pull/50 * Adds 'expected attributes' to enforce additional arbitrary checks to based on the values of a predicate * Some outstanding FRs that we'd prefer to defer while submiting this as draft * Especially interesting is an FR about adding better user error messages * Allow some way to cross the predicate/step boundary * Demo of attestation-verifier * Discussion of ergonomics of expectedMaterials / Products at the step level vs attributes at the predicate level * Open Issues / PRs * CycloneDX PR * https://github.com/in-toto/attestation/pull/296 * in-toto/attestation has models for predicates but does not handle the generation in different contexts * in-toto-go consolidation is focused on clarifying all of this * ITE-9 formatting in in-toto/attestation * https://github.com/in-toto/attestation/issues/326 * Folks proposing new predicates should not have to use a document that says draft at the top * Subjects conjunctive or disjunctive * https://github.com/in-toto/attestation/issues/292 * Maybe a slight clarification to the spec is in order in the validation model * AoB * KubeCon EU! * We have COntribFest, feel free to propose ideas to hack on then ## 2024-02-09 ### Attendees * Mikhail Swift * Parth Patel * Marcela Melara ### Agenda * Meeting cadence & time, possible office hours? * Change cadence monthly to an hour? Open meeting to public * Every third Friday of the month to deconflict with in-toto community meeting * Reconvene next week (2/16) to establish cadence * Go to ITSC to put events on public calendar * 1.1 Release * PR #295 may be re-worked * Resolve CycloneDX PR (#296) * Document that repo is only concerned with cataloging data structures, not collecting/generating the predicates ## 2024-01-26 * PRs * Release attestations - probably fine for 0.1 * Some minor details to be resolved. * Some aesthetic concerns, but that's not for us to really decide. We shouldn't block them on that. * Lets wait for open comments to be resolved before final approvals. * Add Protobuf and Go generated code for CycloneDX 1.5 * Why do we need to have the langauge bindings ourselves vs just letting users import them themselvs * Why not just put in DSSE * Doesn't provide 'standard' bindings (via statement subject) to the artifacts the SBOM covers * If you're using in-toto tooling it would be easier to manage in a statement. * Conversely if you're not using in-toto tooling it would be more painful (you have to unwrap it from the statement before handling) * Marcela suggests we should document this dicsussion more. * What are the risks? * 1. That things get out of sync with the official thing. Who's problem is that? (The proposers?) * 2. That our library adds dependencies that others don't need, that wind up being bad (e.g. having a vuln, etc...) and wind up hindering adoption of our library because "I don't need `thing`, and it has `vulns` I don't want to take". * What's next: * Seems like we respectfully disagree. Need to decide if we take it or not. * Resolution: Whatever tooling uses this should import the deps, bug we're the wrong layer. * ITSC Is asking us to make these meetings public (any major subproject is supposed to have public meetings) * Doesn't matter to Parth or Tom or Marcela. We can make it all public if we want. * 1.1 * What are our completion criteria * We have new predicates (seem stable) * Have we made any changes to the spec itself? * If we go with what we said in 1.0 (as criteria for 1.1) then we're probably good to go. * go bindings seem stable * Appetite for changes to the `statement` layer? * "Encouraged", "fine", "discouraged", "really let's not"? * Major changes -> for 2.0, long timeline? * Would attestor ID be a required field, what would go in it? * Backward compatibility might be hard. * Issue Triage ## 2023-10-13 * Compressed predicates? * https://github.com/in-toto/attestation/issues/289 * Proto spec for a bundle? * https://github.com/in-toto/attestation/issues/280 * VSA -> in-toto? * https://github.com/in-toto/attestation/issues/277 * Probably something for tomhennen to address with Kris * Do we want a separate label for creating _code_ vs any changes to the spec itself? * Or maybe feature requests that go beyond the spec and validating the spec should go in the corresponding in-toto langauge repo? ## 2023-07-28 * https://github.com/in-toto/attestation/pull/227 * Review plz * https://github.com/in-toto/attestation/issues/269 * We _do_ [define a set of known digest types](https://github.com/in-toto/attestation/blob/main/spec/v1/digest_set.md) * Asked for more information on the issue. * If nothing else we could provide guidance on patterns that can be used to resolve their issues. * https://github.com/in-toto/attestation/pull/268 * [OSV Severity](https://ossf.github.io/osv-schema/#severity-field) * Should we ask folks to only submit predicate types if they have working implementations * They might like to send the PRs to get feedback _before_ they write the code * It would probably be good to document the existing predicate types that GUAC, Witness, Archivista produce (as a good starting point) * Action: no change in what we ask for now, Parth and Mikhail will look into documenting what they already support. * Securing Software Repositories * E.g. PyPI, Homebrew, RubyGems * Some discussions very SLSA specific, but in-toto is involved in verification. * Talk of resconstructing attestations and then verifying things match. * Either requires the attestation to have very little information or a very smart client. * Should the attestation framework have guidance around how and how not to verify attestations. * Probably yes. * Moving SLSA VSA to in-toto (so it's not SLSA specific) * Can maybe incorporate some ideas from the in-toto summary type. * Yes, that makes sense. * Action: * https://github.com/in-toto/attestation/issues/270 * What, if anything, do we need to change to merge summary and VSAs * Aditya will work with Tom on this. ## 2023-07-14 * https://github.com/in-toto/attestation/pull/227 * Review plz * https://github.com/in-toto/attestation/pull/151 * Subject references the whl and not the source repo which seems odd? * Probably should have examples of both * 1. If the reviewer reviewed the source repo then great, the subject should reference the source repo, not the wheel. * 2. If the reviewer reviewed the artifact itself (e.g. the unzipped the archive and reviewed that) then the subject should reference the artifact. * Reference that SLSA considers a zip file of source [to be a package](https://slsa.dev/spec/v1.0/terminology#package-model) * Should reviwer be a resource descriptior? * Are humans resources? * According to HR departments they are * Are all reviewers humans? * Could imagine an LLM doing some reviews * How are 'scans' different from reviews? * Seems like scans are more deterministic and clear about what the results mean. * 'Reviews' are more squishy and provide good feelings, but may not be as tight as what scans promise. * Prep summary for in-toto community meetings ahead of time? * Meh * Issue triage process? * GitHub has a feature to drive triage * Every SLSA spec meeting they pick the top 5 new issues to handle * Should we do something like that? * Even if we just closed things it would be valuable. (or tag as backlogs) * Should we spend some time at meetings to go through issues? * Yes. * When do we want to release the next python version? * Should be good to go? We should release another patch before 1.0. Things have still been changing. ## 2023-06-09 * https://github.com/in-toto/attestation/issues/242 * Seems fine to make this change. * Ideally SLSA wouldn't need duplicates. Hope they can resolve. * https://github.com/slsa-framework/slsa-github-generator/pull/2220 * Questions around naming different attestations, especially when attestations need to be propagated between different data stores * There's a divergence between what the ITA spec says, and how people are using attestations/DSSE * (How much) should we engage? * https://www.testifysec.com/blog/attestations-vs-scanning/ (example of multiple attestations) * Problems: * How to write additional attestations (in a bundle) atomically * How can consumers just get the attestations they want * How can uninformed transporters just get all the attestations ## 2023-05-12 * Who should host wrapper APIs (per PR #220)? * Respective language repos should host the wrapper APIs * Don't want to worry about maintaining more than the language bindings * /attestation should probably still provide validation * Who should host specific application use cases? * Also under the respective implementation repo? ## 2023-04-28 * Language bindings * Cutting a 1.0.1 release to signal Python, Go and Java libraries * Versions for packages don't need to be in sync with spec (this is indicated by the package name) * Should ask the individual in-toto implementations what they want * Need to discuss with SLSA folks about who will manage the canonical protobuf * Should we use the new Kusari [Spector tool](https://github.com/kusaridev/spector) for validation * Schema validator written in Rust * Might encourage us to release /attestation crate * Currently only supports SLSA provenance validation * Could add support for other predicates * Open PRs * Waiting for Santiago to review #203 * Cole and Aditya should discuss similarties/diffs between TestifySec's and the proposal in #151 ## 2023-04-14 * Python bindings * Best practices around how to generate go/python code from the protos? * Using the Python generated code isn't working well. * Different generator for each target language. Seems like a maintenance nightmare. * For go, typically push generated code into repo. For other languages, typically generate packages and push to repo. * This _does_ seem like a maintenance problem? But, what's the alternative? * 1. we host protobuf, downstream generate code (git submodule?) * 2. we deal with the pain and be maintainers of generated code * 3. pick _a_ language and use that to confirm the protobuf definitions work as expected * Aditya to prototype on a fork (thanks Aditya) ## 2023-03-24 * We released v1 yay! * Binding multiple attestations in a single Statement * Two options: Look at SCAI predicate * Possibly introduce a ResourceDescriptor predicate * RFC: Aditya's blog post for SLSA * There seems to be a lot of misunderstanding in the SLSA community around what in-toto is and does * Folks don't realize there is policy, and other predicate types * Also wonder why in-toto is needed if we have SLSA provenance * Some suggestions: * Answer these questions * Give an example of an attestation bundle that contains SBOM, SLSA, VSA, something else * Tie this back to the protos * Open PRs: * CycloneDX predicate: Needs one approval * Human code review predicate * Results of test runs predicate ## 2023-03-17 * Remaining blockers for Statement v1 * PR #153 [joshua] * Ready for review by Marcela * Parth was suggesting we might want to define the monotonic principle before publishing. Marcela thinks this might be fine. This looks fine as written. * Looks fine to merge. * Filed issue #157 to track updating motivation use cases. * If the above is resolved then we just need to get rid of 'draft' and we're ~done * Still want to have comms/annoucement, but that's not a blocker. * How to get blog post published? (Aditya will ping people on slack) * Supporting SBOM predicates: Can we recommend EO compliance? I.e. If the producer wants to generate an EO-compliant SBOM, they should ensure they include the [NTIA-defined minimum fields](https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf) * Just point to the NTIA and SBOM-specific documentation in a disclaimer in the specific SBOM predicate spec. * Should we create a generic/intermeditate SBOM predicate that can be used for conversions between specific and generic predicates. This can simplify verification because there needs to be only one verifier that has type-specific converters. * When do you need to start versioning the intermediate type? * ITE-10 verifier/policy engines should be able to reason about equivalences/relationships between similar types (e.g. SBOM) * Witness transfer to in-toto: * For now focusing on v1 compliance, will provide feedback on spec later ## 2023-03-10 * Remaining blockers for Statement v1 * PR #143 [marcela] * Mark's comments on semantics should be the last outstanding * Decide to make semantics of field combinations specific to predicate * PR #150 [tom] * Fixes some broken links * Issue #127 * Fairly open-ended * We can try to get any changes we can get in by March 17 * Target March 17 2023 * Joint blog post with CNCF and SLSA [aditya] * Context: Aditya prepared a in-toto + SLSA post * OpenSSF SCI positioning recommended to do companion blog posts * CNCF: in-toto attestation * OpenSSF: on how SLSA can use in-toto * [Should SLSA repo define the various build types](https://github.com/slsa-framework/slsa/issues/662) * Some older PRs: * Runtime trace predicate * Feedback needs to be addressed * Aditya and Shripad might have time to get to v0.1 * CycloneDX * Thoughts on only pointing to external documentation in predicate definition * For SPDX, we can use the predicate type to identify the content type and integrity --> this is all we can ensure * SBOM usage is much too inconsistent to make any definitive statements about fields or examples * Only thing we should require is that `predicateType` field specifies the version of the SBOM spec * Can cosign be used to sign SBOM? They can create DSSE, but do not use an attestation bundle * Should we agree on using predicateTypes with `https://in-toto.io` prefixes for predicates hosted exclusively by in-toto/attestation? * Consensus is yes ## 2023-02-17 * Release timeline for Statement v1 * Timeline: before SLSA v1 (currently targeting mid-to-late March) * Decide blockers * Resolve #133, leave possibiilty for non-hashable things. * #135 follows immediately, no conflict * Proto update for reference attestation * Clarify DigestSet terminology * Consider https://github.com/in-toto/attestation/issues/136 ? * Complicates client filtering of individual predicate types. * Can make things more brittle. * E.g. if you need to regenerate individual predicates. * Enough reason to defer from v1. * Probably better to use reference types and have a predicate that's a list of references to existing signed attestations it would be more flexible. (still not for v1!, could just be a new predicate type) * Cut 1.0 * Open Issues and PRs * Adding CycloneDX predicate ([#129](https://github.com/in-toto/attestation/pull/129)) --> does this have a real use case right now? * Some folks are doing stuff like this with SPDX things in OCI registries right now * They might be too big for some use cases? * Seem to be compelling reasons to allow this. * Probably best for us to take the framing of "If you want to communicate this data with in-toto please do it this way." This isn't necessarily an endorsement of any particular use case. * AI: Does the above decision need to be documented better/in more places? * May fit in README, vetted predicates list, or ITE-9 * Reviewed/documented/defined (definitely not endorsed) * Assigned to Joshua Lock. * AI: Double-check the PR to see it makes sense for CycloneDX? - Parth Patel * Runtime predicate ([#111](https://github.com/in-toto/attestation/pull/111)) * AI: Parth to address comments. * Marcela's PR on reference types ([#133](https://github.com/in-toto/attestation/pull/133)) * Need to decide on single reference type that covers artifacts and non-hashable resources? * See: Discussion around [SLSA ArtifactReference definition](https://github.com/slsa-framework/slsa/issues/614) * [marcela] RFC: Some v1.0-draft ([#135](https://github.com/in-toto/attestation/pull/135)) * Support Intel-run OSS hackathon (late April)? * Answer needed today! * e.g. Here are some projects that might be intersting * If in-toto attestations are submitted as a project to consider we need to propose issues/features to add as options. * Joshua Lock: would not object, would be nice. * Could easily identify things for folks to work on * Predicates that would be nice to have * cue policies to validate predicates * proto defs for all predicates * tests that validate things * language libs for all the proto definitions? * GUAC would probably be interested too (but not a project with Intel maintainers!) ## 02/03/2023 ### Agenda * Open Issues and PRs * How do we prioritize? * Tom: Focus on the ones people are talking about / asking updates for * Templates / minimum threshold for issues? (Did I get this right?) * Timestamps at the Statement layer * Tom: "Timestamp" is ambiguous, needs to be explicit about what it is * Tom: Mark mentioned not having a baked in expiration, can be part of user policies * Parth: Any particular use case? * Tom: Propose closing this, specific use cases can be handled in predicate * Statement v1 * Joshua: +1 on marking that Statement v1 * Any potential changes to the Statement layer? * Marcela: Subject entries may gain additional type information for URIs / non digests etc * Marcela: It should be an optional extra field, backwards compatible * Tom: Do we know SLSA timeline to meet its v1 goal? * Joshua: They've fallen behind but plan is to have something out there ASAP (ideally RFC ready by end-of-Feb) * Tom: What about attestor ID field? * Should it be in the predicate for it to be unambiguous? * Tom: Mark's proposal for digest set * Do we just allow anything? * Tom: Standard hash algorithms make sense * Tom: Custom ones are more complex (go mod for ex), we have to be careful if a system is doing something wrong * Tom: in-toto can support it without endorsing it * Aditya: Should in-toto specify explicit algorithms or just make general recommendations? Handle special systems using ITE-4? * Parth: Not support anything today with lack of collission resistance * Tom: We also have to consider transition periods from one hash algorithm to the next where former is known to be weak but is still supported * Aditya: Statement v1 should go hand in hand with the attestation spec as a whole to be less confusing * Aditya: Add in-toto versioning discussion to in-toto community meeting * Tom: We have to address three things: * 1. Subject type -> reference type (@marcela) * 2. Digest set -> custom types (@tom) * 3. Language clean ups (@aditya) * Other suggested enhancements to discuss * Evidence in statement layer * https://github.com/in-toto/attestation/issues/114 * Marcela's work on reference types ties in * Joshua: In the Provenance v1 format, there's an explicit run byproducts bit that is a list of references -> reference types * https://slsa.dev/provenance/v1/#byproducts * Signatures for attestation bundles * Tom: Bundles may not always be the same, you may not always want to include all attestations in the bundle * Proto definitions * SLSA uses CUE for human readable versions, not used for verification ## 01/25/2023 ### Agenda * Changing time to later? * Would be tricky for Joshua. * Doodle poll for meeting time? (tomhennen to send) * Fast track reviews of predicates that predate ITE-9 * SBOM attestations * SPDX predicate doesn't follow ITE-9, but no one is actually using it. * Perhaps for folks who want to communicate large data we can just recommend reference attestations. * gitsign's commit attestation * SLSA source control? * Any others? * Would like to see the documentation standardized. * Could provide feedback AND ask folks to follow the ITE-9 template. * Update ITE-9 for explicit usecase that requires the new predicate * Would be nice to have a getting started doc (marcela to do via README overhaul) * Help people understand that it's on them to drive the effort * We can help with use cases, thinking through options, etc... * What's you use case? * Why don't existing predicates cover this use case? * What is your concrete proposal (we can't write the spec for you)? * What policy questions do you want to be able to answer with the predicate? * Roadmap 2023 * RFC on roadmap doc https://github.com/in-toto/docs/pull/70 * Check-in protobuf vs. JSON-Schema * tomhennen to look at making a generic in-toto statement proto/cue thiny * Predicate library repo * Probably getting ahead of ourselves here. Let's visit later. * Open Issues and PRs * Add goModuleH1 to the list of predefined digests (PR #108) * Standard reference attestation type? [tomhennen + marcela] * Tracked in issues #27 and #117 * Should we add attestor.id to the statement layer? Optional. * Open PR for reference type * Support attestation subject URI as alternative for digest * Tracked in issue #28 and PR #95 * tomhennen to ping Mark on this * Runtime trace predicate (PR #111) * Parth to move from draft into review * Clarify policy engines in README.md (PR #124) * marcela to discuss as part of README cleanup ### Attendees * Parth Patel * Marcela Melara * Tom Hennen ## 01/11/2023 Meeting ### Agenda * SCAI v0.1 merge * Check-in protobuf vs. JSON-Schema * Opening the "predicate library" repo * Evidence in statement layer? https://github.com/in-toto/attestation/issues/114 * Standard reference attestation type? [tomhennen] * Support attestation subject URI as alternative for digest: https://github.com/in-toto/attestation/pull/95 * Signatures for attestation bundles * Individual attestations are signed, but bundles as a whole not. Can this be subverted? Can attestations in a bundle be maliciously deleted from the bundle? * Roadmap/goals for 2023 [marcela] ### Attendees * Parth Patel * Marcela Melara * Aditya Sirish * Mikhail Swift ### Notes #### SCAI v0.1 - Merged! - Approved by Parth and Mikhail #### Roadmap/goals - Attestation specific items - Clean up attestation spec - List of predicates - Backlog of issues and PRs - Layouts for attestations - Predicate dictionary - Bring in Michael Lieberman and others working on this ## 11/16/2022 Meeting ### Agenda * Logistics: * Roles of core maintainers (should they join the meeting? for what?) * Decision-making so far: predicate type list * "ok, given that this is what we want to do, here are some suggestions to do it within the in-toto framework" * Looking at the agenda: "should we ask people to use pbuf for formats" * Process: * How do we admit new changes to attestions (i.e., PR-merging) * A lot of decisions will happen through async mechanisms * Should we share meeting results after each meeting? * Can we just publish our meeting notes? * process: how to? * post them on slack for now (#in-toto) * Brief roll-up to the community meeting * SCAI * Ready to go as far as Parth and Tom are concerned * Marcela would probably like to make some additional changes before submitting. * Do we need some way to link attestations? It would be helpful instead of embedding the evidence directly? This would keep the attestaitons smaller which provides more flexibility (such as providing them in RPCs that have size limits). * Putting the evidence in a DSSE would be helpful since it allows the signature to differ from that of the SCAI producer, which is nice. * Could the SCAI predicate be reconceived as a more generic in-toto attestation type that doesn't just make claims but also provides evidence (links to evidence) for why it makes those claims. * Related to the ongoing discussion around verifiable sboms https://docs.google.com/document/d/1sojT2WnbJLDeDPid5FFRAK6Ue4Pu8WEm4kDtxVSTIGM/ * Predicate definitions * in-toto/predicate-library * there's a Python implementation of the objects in SCAI – where can they live? * Protobuf? Something else? * Standard implementation allows greater interop (generated code) and testing that things are emitting the format correctly. * SLSA provenance is looking at Protobuf for schema and CUE for human-readable summary and format validation https://github.com/slsa-framework/slsa/pull/525 * Format validation will be very useful for people that don't want to use protobuf generated code * Alternative: JSON-Schema, but not many high quality libraries that implement the latest (years old) version of the JSON-Schema spec * Marcela has WIP JSON-Schema and Protobuf SCAI implementations * For intoto statements: https://docs.google.com/document/d/1y7gjPJqogdEBeaqI2iDPsWinbWG6UUSkQLNIUYInedk/edit?resourcekey=0-jt8rZKWB12NiGCL5ZR3Y4gem ### Attendees * Santiago Torres * Joshua Lock * Tom Hennen * Parth Patel * Marcela Melara ### Notes ## 11/02/2022 Meeting ### Agenda * SCAI * https://arxiv.org/pdf/2210.05813.pdf * https://github.com/in-toto/attestation/pull/112 * Human Review * https://github.com/in-toto/attestation/compare/main...adityasaky:in-toto-attestation:human-review-attestations * Alpha Omega https://github.com/ossf/alpha-omega/issues/28 * Predicate & attestation validation * Tom Hennen ### Attendees * Aditya Sirish (NYU) * Parth Patel (Kusari) * Marcela Melara (Intel) * Tom Hennen (Google) ### Notes #### SCAI * Marcela: Overview of the SCAI and the accompanying predicate * Parth: SCAI can be a vehicle for attesting to things like hermetic builds with evidence being the full runtime attestation * Aditya: How does this tie into the evidence in statement conversation? * There are likely situations where you want to attest to something in the same statement, the builder for SLSA for example * Other scenarios where SCAI makes more sense * Bundling them together makes it easier * Tom: Is SCAI too general with its description of attributes? * Marcela: Indeed difficult to validate assertions with different attribute formats. Needs to be thought out / studied * Tom: What abou the attribute -> target mapping? What does the stack protection flag for example apply to? * Marcela: Intent of attestor is tough to glean * Tom: It'll become clearer after a producer is implemented * Perhaps it can be resolved by adding the identity of the producer to the predicate, mapping of producer to what its attributes indicate * Marcela: There's an outer layer called "Report" that has a description of some of this information, perhaps it can be included in the predicate after all * Perhaps the predicate definition can be updated to **require** an existing attestation framework which can act as a source of producer information * Can add producer fields and show a few examples * Tom: Suspicion is that the producer of this attestation is likely different from producer of SLSA attestation * We see this with SBOMs right now * Marcela: Likes the idea of tying attributes to producers * However, if each attribute is tied to a producer, who signs the overall attestation? * Tom: Perhaps the build service could sign while checking what it's signing and the identities * Aditya: multiple SCAI predicates with different signers should work * Threshold for evidence? * Marcela: Authenticated is mentioned, should it be required? * Aditya: Broader question of policy / validation as well, Tom's agenda item #### Policy and Validation * Marcela: For SCAI, it's undecided, depends on attributes and evidence * If evidence is ommitted, depends on the trust in signer * in-toto has artifact rules * Tom: Two users for policies * Engineer who writes very specific policies: this component has this flag, this other thing these attributes etc. * A large organization that wants to set a broad policy: everything in our org must be built by secure builders, stack protecttion enabled etc * Engineers don't necessarily want to bother with this * What's the simplest thing needed to make this happen? * Parth: Thinking about it from GUAC perspective as well * Ease of use is important * Marcela: appreciates perspective of organizational level of policy vs technical nitty gritties * For SCAI, have been working on generating assertions automatically so inidividuals don't have to do it manually * Hopes to be able to open source it / demo it * Parth: For runtime traces, have Chains sign SCAI based on runtime trace attestation it observed * Tom: Q in odds with SCAI but in-toto attestations are a generic way of conveying properties, an alternate is to describe predicates for everything we want. * Eg: one for stack protection * Parth: would more examples help? #### Logistics * Meeting again in two weeks * Aditya: Hope to update human review to ITE-9 format * Alpha Omega is considering in-toto attestations for their reviews and we should encompass those efforts * Spring cleaning coming up that should clarify governance / maintainers / oversight etc raised last meeting ## 10/19/2022 Meeting ### Agenda * Introductions (if necessary) * Cataloguing vs. curating predicates in in-toto/attestation repository * Maintainer obligations: respond to issues (often Q&A) * Concern with a strict curation model is potentially preventing similar attestations with different goals, e.g. source code review enabled on repo vs. source code review performed by specific entity * We catalogue predicates, but entries into the catalogue must meet a bar, which may include * whether a similar predicate can be used/extended instead) * if the predicate has well-defined goals, such that it's easy for adopters to understand and implement * Logistics * Governance * Meeting Cadence * Process discussion for predicate assessments * Do we host predicate definitions, as well as catalogue them? * Runtime Trace * SCAI * Human Review * Alpha Omega * Predicate & attestation validation ### Attendees * Aditya Sirish (NYU) * Tom Hennen (Google) * Parth Patel (Kusari) * Joshua Lock (VMware) * Mikhail Swift (TestifySec) * Marcela Melara (Intel) ### Notes Quick Round of introductions #### Cataloguing vs Curating Predicates in /attestation * Joshua: /attestation provides the spec * Folks want more guidance / curation of attestation types * From currently open PRs, it's clear there's need for some "peer" review * Marcela: Curation makes sense * Tom: Strict guidelines about which attestations to use may not fit all contexts * This can lead to some attestation types getting overloaded * Joshua: Sounds more like cataloguing attestations that meet a certain bar is the goal * Also ties back to attestation subtypes - balance when something needs to be a new type vs extension of existing predicate * Subtypes should map cleanly to new use cases * Marcela: multiple use cases at the same time, different predicates should be allowed * Parth: Do we want to specify how predicate specs should be written up / information to include? * ITE-9, Predicate Conventions * These should be merged #### Logistics ##### Governance * Marcela: we should make governance clear for this group * Action Item: disambiguate the different groups of folks with oversight over in-toto projects ##### Meeting Cadence * Meet every other week until we cover a backlog of predicates * Switch to monthly cadence after #### Runtime Trace https://github.com/in-toto/attestation/pull/111 * Parth: overview of the runtime trace efforts so far * Should trace policy be a separate, signed attestation? * Joshua: SLSA had some discussions about adding "evidence" field to the statement, probably ties into this * Tom: Is this for build traces only? * Mikhail: We still want the trace policy used at trace time rather than just the developer-signed copy * Tom: Attestation should include the policy - network captured or not flag for example. * Parth: Different types of attestations for process vs network discussed * Attestation Bundles: traces are huge, plan to split them up and distribute via bundles * Should ordering be handled internal to a trace attestation or do bundles maintain order? * Mikhail: Hash of bundle and store it in Rekor, distribute bundle separately but discoverability issues * Marcela: related issue regarding URIs as part of subjects * Tom / Parth: overarching runtime trace attestation splitting out into process + network seems to be the way forward

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.