Try   HackMD

in-toto Community Meetings

CNCF Public Calendar: https://tockify.com/cncf.public.events/monthly?search=in-toto
Pre 2023 Meeting Notes: https://hackmd.io/@adityasaky/ry4Wuico3

06/06/2025

Agenda

Attendees

  • Santiago Torres-Arias (Purdue)
  • Aditya Sirish A Yelgundhalli (NYU)
  • Tom Hennen (Google)
  • Patrick Zielinski (NYU)
  • Victor Lu
  • Alan Chung Ma

05/02/2025

Agenda

Attendees

  • Santiago Torres-Arias (Purdue)
  • Aditya Saky (NYU)
  • Justin Cappos (NYU)
  • Daniel Moch (Lockheed Martin)
  • Jack Kelly (ControlPlane)
  • John Kjell (ControlPlane)
  • Mikhail Swift (Testify Sec
  • Marcela Melara (Intel Labs)
  • Trishank K Kuppusamy (Datadog)
  • Alan Chung Ma (Keytos)

04/11/2025

Agenda

  • New community member introductions
  • Post KubeCon discussion
  • post-graduation/post-kubecon updates:
    • Review/update the roadmap
    • Gearing up for elections!
    • Celebrate future success!

Attendees

  • Santiago Torres-Arias (Purdue)
  • Aditya Saky (NYU)
  • Justin Cappos (NYU)
  • Alan Chung-Ma ()
  • Marco Deicas (Google)
  • Daniel Moch (Lockheed Martin)
  • Jack Kelly (ControlPlane)

Notes

03/07/2025

Agenda

Attendees

  • John Kjell (TestifySec)
  • Daniel Moch (Lockheed Martin)
  • Tom Hennen (Google)
  • Alan Chung Ma
  • Kairo de Araujo
  • Marcela Melara (Intel)
  • Cole Kennedy (TestifySec)

02/07/2025

Agenda

  • New community member introductions
  • Joint in-toto & TUF project kiosk at Kubecon EU
  • in-toto graduation vote has begun!

Attendees

  • Aditya Sirish (NYU)
  • Jack K (ControlPlane)
  • Marcela Melara (Intel)
  • Justin Cappos (NYU)
  • Yi Zha (Microsoft)
  • Trishank K Kuppusamy (Datadog)
  • Tom Meadows (TestifySec)
  • Kairo de Araujo
  • Santiago Torres-Arias (Purdue)
  • John Kjell (TestifySec)
  • Tom Hennen (Google)

Notes

  • Intros
    • None
  • KubeCon EU Booth
    • Will be a spreadhseet
  • Graduation vote
    • Have around half of the ToC votes
    • Expecting to be done by KubeCon EU
    • KubeCon related - Project videos
      • Graduated projects can pick one KubeCon to show videos
      • Unsure if we will have the graduation benefits in time to request for EU
      • Likely to have a Graduation anouncement KubeCon EU
      • Could save the video for KubeCon NA
  • ITSC Elections
    • Every 2 years
    • Need to put a new date
    • Around a month to schedule to match last time
    • OpenSSF TAC elections
    • Action: Schedule ITSC meeting
  • RATS
    • Remote ATtestation ProcedureS (rats)
    • Many commonalities with In-Toto, interest in finding common ground
    • Meeting Noon eastern Monday 10th
    • Looking for bridge builders to attend
  • Minder potential collaboration
    • OpenSSF effort called Baseline
    • Subsume scorecard and badges. Check all these boxes and we know you're doing the right things for your SCS
    • OpenSSF Sandbox project called Minder
    • Minder could output signed attestations rather than purely trusting live info from Minder
  • Progress on attestation-verifier -> go-witness
    • Working on attestations v2 in go-witness
    • Should it be separate or directly integrated
    • The changes to make attestation-verifier work with go-witness are disruptive
    • Currently support CEL, interested in supporting other policy engines
  • Related: in-toto policies (spec v2)
    • Alan and Trishank are working on initial draft
    • Marcela & Trishank planning an OSS NA talk
  • Attestation Framework compliance with ITE-5

01/10/2025

Agenda

  • New community member introductions (if any)
  • [Justin] in-toto graduation
  • [marcela] Updates from in-toto policies WG
  • [tomhennen] Attestations - should we (have we) documented what tooling supports attestations and what the limitations are.
  • AoB

Attendees

  • Justin Cappos
  • Yi Zha (Microsoft)
  • Aditya Sirish A Yelgundhalli
  • Alan Chung Ma
  • Tom Hennen
  • Santiago Torres Arias
  • Marcela Melara
  • Lakshya Gupta

Notes

  • New community member introductions (if any)
    • Yi Zha (Microsoft) – maintainer on Notary and ratify projects; seeking to adopt attestations in these projects
  • [Justin] in-toto graduation
  • [marcela] Updates from in-toto policies WG
    • Started working on in-toto v2.0 spec doc to describe our evolved thinking about layouts, predicate-level rules, inspections etc.
    • Have been in discussions with Behnaz (Oracle) on Macaron, which have informed our thinking as well
  • [tomhennen] Attestations - should we (have we) documented what tooling supports attestations and what the limitations are.
    • It's not possible to sign arbitrary attestations with cosign
    • It is possible with Witness, but still a bit cumbersome to do in a GHA
    • Where should we document tooling that supports in-toto attestations?
      • in-toto/community, in-toto/attestation ?
      • 4 levels of support: L0 (pre-ITE9 links), L1 (subset of ITE9 attestations), L2 (integrates attestation library), L3 (provides its own wrappers around in-toto)
  • Should we have closer discussions with sigstore client maintainers?
    • Already seeing some friction around the APIs they use vs what in-toto/attestation provides
    • The main issue seems the layering of different attestation components
    • Across projects, we should focus on the high-level workflows we're trying to support, because we're all often more focused on our own projects
      • Should we go to the SDLC WG to provide the needed bird's eye view?

12/06/2024

Agenda

  • in-toto presence at KubeCon EU 2025 project opportunities
    • Can we staff a booth with the TUF folks?
  • in-toto Graduation 3rd adopter interview [source]
  • Status on in-toto GitHub projects and website (Roadmap ??)
    • in-toto-golang status
      • While witness is set to be the recommended implementation, it is still missing some key features from the in-toto spec (e.g. v1 layouts)
    • Demo modernization, showcase attestations
    • Using in-toto in our projects - showcases both a trust in our own tools and can also offer more examples on how to use in-toto
  • (Kairo) in-toto helm-charts
  • [Trishank] Policies
    • Marcela, Aditya, and I thinking about just drafting and releasing a v2 in-toto spec
    • Will refer to attestations instead of links
    • Will refer to policies instead of layouts
    • Policies will just reuse ITEs 10 and 11 now
    • Concepts rather than formats
      • Supply chain as DAG
      • Multiple types of predicate per step (ITE-10)
      • Attribute constraints (ITE-11)
    • So can accommodate different engines like Witness and Macaron
      • Can worry about policy engine interoperability in the future when need arises

Attendees

  • John Kjell (TestifySec)
  • Santiago
  • Aditya
  • Justin
  • Jack Kelly (ControlPlane)
  • Daniel Moch (Lockheed Martin)
  • Kairo Araujo
  • Lakshya Gupta
  • Tom Meadows (TestifySec)
  • Marcela Melara (Intel Labs)
  • Alan Chung Ma
  • Trishank Karthik Kuppusamy (Datadog)
  • Marco Deicas (Google)

Notes

Introductions

  • Welcome to Daniel, Marco, and Lakshya

KubeCon EU 2025

Dates: April 1-4
Location: London, England, UK

  • any plans for maintainer track talks?
    • Any specific talk ideas?
    • We have some case studies in the pipeline
    • Can we turn the talk into an adoption / case study focused panel?
    • Will NA based adopters be able to make it to EU? Maybe best to do the panel in KubeCon NA
  • Can we staff a booth with the TUF folks?
    • Looks like we have the numbers, Aditya to sync with TUF folks
  • Look to announce in-toto graduation
  • Maintainers summit

Graduation

  • We're close!
  • We've reached out to multiple folks this week for the final TOC interview

Deprecating in-toto golang in favor of go-witness

  • reduce maintenance burden
  • what is the process to gracefully deprecate?
    • https://go.dev/wiki/Deprecated
      • "Some tools will warn on use of deprecated identifiers and their docs are hidden on pkg.go.dev."
    • Let's add deprecation warnings for the slsa models pointing to /attestation
    • Let's add deprecation warnings for InTotoRun() etc., see if anyone's using those APIs
  • Does anyone have some cycles to make this happen?

Demo modernization

  • Should the demo use attestation and other newer features?
  • Should we collate all the demos we have already?
    • ite-4
    • scai-demo
    • kubecon demos
  • Alan: will spend some cycles on this

Using in-toto on our projects

  • We can use the witness-run action
  • witness uses witness-run already but documentation needs to improve
    • Including some docs on how to verify
  • Maybe we could also explore the github attest stuff

in-toto Helm Charts

Policies

  • Trishank: plan to draft a v2 in-toto spec
  • Uses /attestation instead of links
  • Uses "policies" instead of "layouts"
    • Codify ITE-10 and ITE-11
    • Discuss in terms of "properties / features"
    • Show attestation-verifier and ITE-10/11 as an example
    • Maybe also show macaron and others with how they can express the supply chain DAG
    • The stance we want to take is to verify the DAG of the supply chain
    • Rules / policy engines can be selected rather than hardcoded into layouts / spec
  • Santiago: Have you talked to macaron?
    • Yes, Behnaz has been a part of the policies WG
    • Exploring how to represent the supply chain DAG in macaron
  • KubeCon EU can use this? Possibly

11/01/2024

Agenda

  • New community members introductions (if any)
  • in-toto Helm Charts (poke) (link?)
  • KubeCon preparations
  • Roadmap PR
  • AoB

Attendees

  • Santiago Torres-Arias
  • Jack Kelly
  • Marcela Melara
  • Tom Hennen
  • John Kjell
  • Kairo Araujo
  • Thomas Meadows
  • Aditya
  • Sunil Ravipati
  • Alan Chung-Ma

Notes

Introductions

  • No new faces

Helm Charts

Kubecon Preparations

  • Sign up sheet for booth duty
    • John: will send one out
  • Is this a combined TUF/in-toto booth?
    • schrodinger's booth
    • Yes but TUF isn't prepared for it?
    • Will coordinate
  • Do we expect an in-toto maintainer meet?
    • Tuesday is SigstoreCon
    • Maybe one evening

Roadmap

  • There's been good feedback on the PR for the roadmap
  • One open feedback point is to describe that this is both a description of ongoing / future work as well as a description of recent work
    • In a sense, it combines review and roadmap roles
  • Merged!

AoB

  • Marcela: update on policies work
    • Meeting twice a month (EMEA / APAC friendly times)
    • Opportunity to collaborate with other projects such as Macaron (Behnaz from Oracle)
    • As of yesterday, going to send Behnaz some more complicated in-toto layouts to see how they'd be implemented using Macaron
    • Santiago: are there thoughts on the roadmap for this effort?
    • John: some conversations about policies 2.0 vs 3.0
    • Also, macaron isn't part of the CNCF, there are organizational questions about adopting as well

10/05/2024

Agenda

  • New community members introductions (if any)
  • Graduation review help!
  • CNCF governance review
  • in-toto Helm Charts
  • AoB

Attendees

  • Santiago Torres-Arias
  • Aditya Sirish
  • Justin Cappos
  • Mikhail Swift
  • Tom Meadows
  • Kairo de Araujo
  • Jack Kelly
  • John Kjell
  • Cole Kennedy

Notes

Introductions

None this time

Graduation review help

  • Santiago met with TOC sponsor, one or two outstanding issues
    • No process for subprocess onboarding / offboarding
    • Need a third name for an interview
      • Santiago <-> Cole to evaluate if an adopter can help out
  • Santiago will be making some changes to the governance docs, ITSC to review
    • This includes onboarding / offboarding subprojects and their maintainers
    • Cole: Will ITSC have final say on who the maintainers are? Filtering mechanism?
    • Santiago: Yes. The change in question would just be surfacing that policy more clearly

CNCF Governance Review

  • Trishank has taken on the CNCF governance review
  • John: Probably similar to the presentation to TAG-security, except a focus on the governance to ensure it encourages contributions

in-toto Helm Charts

  • Kairo: Propose a separate in-toto repository with helm-charts
  • Initially will include Archivista
  • Will open an issue on in-toto/community to propose this

09/06/2024

Agenda

  • New community members introductions (if any)
  • Should we establish guidance for how opinionated we are on new predicate types? This could speed up reviews of types.
  • Policy WG Updates
  • Case study/Blog (Cole)

Attendees

  • Aditya Sirish (NYU)
  • Tom Hennen (Google)
  • Alan Chung Ma
  • Marcela Melara (Intel)
  • Jack Kelly (ControlPlane)
  • Matthias Glastra
  • Noel Cortes (Lockheed Martin)
  • John Kjell (TestifySec)
  • Cole Kennedy (TestifySec)
  • Tom Meadows (TestifySec)
  • Sunil Ravipati

Notes

  • Intros
    • None
  • Predicate types
    • Marcela: There are open PRs for new predicate types, how oppinionated should these predecate types be?
    • Marcela: Deployment and reference predicates proposed among others
    • Marcela: Potentially people feel uncomfortable modifying exisisting predicates.
    • Tom: Agree. People also not comfortable proposing spec changes for cases that are currently unsupported
    • Tom: Extension for the same or closely similar usecases. New for distinctly different rather than forcing.
    • John: Do we have an oppinionated implementation or a library. More than one way to do things with existing predicates. Let people know that is fine, more than 1 way to do things in programming.
    • John: Could need a practical user's guide, decision making process for which attestations to use, when are optional fields important for policy
    • Marcela: For existing predicates that could meet the same goal test it out first to show a need for a new one. Discussion ongoing for very generic predicates having many optionals leading to less guidance.
    • Tom: Someone could be raising a proposal in the design phase, others may have a working example
    • Marcela: Most things come in as PRs first rather than issues. Some conflicting docs.
    • Matthias: CNCF project like phases could be useful for predicates. Start sandbox and progress with community use.
    • Tom: DIY vs Endorsed
    • Marcela & Tom: Maybe define which group/community/individual owns the predicate?
    • John: Policy working group to maintain consistency with the attestations
    • Cole: lots of orgs with lots of data without consistency.
  • Policy WG updates
    • John: Trishank working on ITE10 & 11(?) considering json schema + JSONET
    • John: Difference between variable substitution and templating
  • Graduation progress
    • John: Happy to help
    • Jack & Cole: Not heard anything extra regarding graduation
    • Cole: If we need user interviews we might have some users happy to help
  • Case study
    • Cole: Still under NDA, user of Witness and Archivista.
    • Cole: Value in centeralized evidence store. Don't need to migrate CI/CD platform. Community tools solving real business problems.
    • Marcela: Awesome to have case study. Tangencially, any plans to integrate with BOMctl to analyze SBOM?
    • Cole: Happy to discuss further
    • Cole: Blog in the next few weeks. Looking to present full Case Study at an in-toto maintainers track. A section on users and statistics would be good.

08/01/2024

Agenda

  • Policy working group updates:
    • John: they have been going through usecases
    • Some focus on developing information about these usecases without requiring deep in-toto knowledge
    • Next: they will go through the usecases from bottom up (i.e., what are the constituent steps on a policy)
    • Participation: tom: intuition is that we should wait until we get a more concrete proposal before getting more participation
  • New special interest group:
    • Security baseline (Dana): open PR with some diagrams and other things with many references to in-toto and references to witness and archivisita
    • It would be a good thing to support from the in-toto community
  • CNCF Tag-security:
    • there are efforts to bring down barriers between both CNCF and OpenSSF.
    • There may also be some different baseline efforts between the two, so we may want to be involved in both.
    • The baselines are a bit focused on more of the low-level practices (e.g., how to configure github securely/etc). There may be work with the way that the security toolbelt fits in this
    • Anybody can join this sig, (it's probably under the best practices working group)
  • SLSA source track:
    • Trying to understand how SCPs can provide security guarantees without getting bogged down on the specifics of how each platform implements one of them
  • in-toto highlights:
    • Crowdstrike gave some visibilty for in-toto
    • Some features in the news
    • cncf blog
    • Possibly a good idea to reach out to CS to see if they are interested in discussing in-toto
  • Graduation interviews: PSA
  • in-toto-golang:
    • attestation people are complainig about compliance with the spec
    • a couple of times the attestation group has gone to the respective repos to make the approrpriate updates so that they consume the protos
    • How to engage with the right people with -go

Attendees

  • Justin Cappos (NYU)
  • John Kjell (TestifySec)
  • Tom Hennen (Google)
  • Tom Meadows (TestifySec)
  • Marcela Melara (Intel)
  • Santiago Torres-Arias (Purdue)

Notes

06/07/2024

Agenda

  • Meeting logistics
    • Slack notification before every meeting
    • A meeting link that ITSC have admin access to
    • Cole will take care of this
  • New community member introductions (if any)
    • Ayush Gupta (welcome!)
  • Docs [Jack Kelly]
    • Happy to see progress here, especially from Witness and
    • Would like to see a separate Slack channel to coordinate
    • Slightly overwhelming work
    • 30+ applications for project yesterday
      • Lukas and Justin processing applications
    • A lot of work that needs sharing
    • Let's find a group of people to help
    • Thomas keen on collaborating
    • What is the deadline for the LF work?
      • Can be seen from the LF website (needs login)
    • Coordination: two options
      • Specific communications in specific channels we have already
      • Meta comms should probably go into a separate doc-specific channel or in #in-toto itself
        • Let's start with #in-toto first and then decide if we need a specific channel later
        • Make liberal use of Slack threads!
  • in-toto-golang [Marcela]
    • Earlier this year, go-consolidation effort
    • Are we archiving the in-toto-golang repo?
    • Folks have not received the message that the repo is technically deprecated
    • How we should proceed with informing the community?
    • We should tell them about newer, modern efforts such as Witness, Archivista, and so on
    • Notice: "no longer maintained, see here and here instead"
    • Is support for link attestators live yet in Witness? Was a big blocker
    • Background: why Testify moved from in-toto-golang to Witness
    • Pretty close to feature-complete, but need a diff chart for what's missing
    • Examples: need Cosign support for signing attestations
    • Call for help: need community feedback on what is wanted vs not
    • File issues in in-toto-golang and Witness?
    • Can use LFX mentorship round for support
    • Aditya needs help to merge a draft (please link)
      • Example: attestation-verifier
    • How should folks contribute to new efforts? [Trishank]
      • Could someone volunteer to lead archiving in-toto-golang and pointing to Witness and friends here?
      • To write deprecation docs
      • Attestation framework also needs help with things like bindings
      • When to use what
      • Who are the -golang maintainers?
      • Could we use help from the LFX folks here?
      • Jack would like to volunteer, but would also like some help from the -golang maintainer group
  • Adding support for non "link" type attestation to witness policy [Cole]
    • https://github.com/in-toto/go-witness/issues/267
    • Want to converge with ITE-11
    • Looking for feedback
    • Need step names for linking them together
      • Step names tell you what you need to know
    • Should we tie to just Rego? Do we want other options like Cue?
    • Cognitive dissonance from multiple languages? [Trishank]
      • Machines should be creating the "compiled" low-level policies
        • The high-level policy shouldn't be machine-generated
        • Idea: users can add something on top of layouts? Then machines will write implementation details
    • Attestation-verifier seems like a good choice
      • Especially for tickets
      • Let's fold support back into Witness
    • Policies
      • Layers of policies (maybe sublayouts?)
    • Let's start a Slack thread in #in-toto to discuss
  • Graduation status? [Trishank]
    • Many +1s
    • A new person (please add name) is starting review
    • Minor cleanups from us
    • Mostly on them to move from old to new format
  • Any other business?
    • Ayush to start a Slack thread on CNCF

Attendees

  • Aditya Sirish (NYU)
  • Zach Steindler (GitHub, OpenSSF TAC)
  • Jack Kelly (ControlPlane, ITSC)
  • Justin Cappos (NYU, ITSC)
  • John Kjell (TestifySec)
  • Kairo de Araujo (TestifySec)
  • Tom Meadows (TestifySec)
  • Cole Kennedy (TestifySec, ITSC)
  • Tom Hennen (Google)
  • Noel Cortes (Lockheed Martin)
  • Ayush Gupta (Open Source Contributor)
  • Marcela Melara (Intel, OpenSSF TAC)
  • Trishank Karthik Kuppusamy (Datadog)
  • Mike LeBeau (TestifySec)
  • Adam Nauth (Best Buy)

Notes

05/03/2024

:movie_camera: https://zoom.us/rec/share/x_wiHIReWXw-2669uyV1MfPIEvvJo4NvDreyxhCEvAYhgGsS7eiPfay8EYFTttK1.Fn30n1KybWjI-mVW

Agenda

Attendees

  • Aditya Sirish (NYU)
  • Zach Steindler (GitHub, OpenSSF TAC)
  • Jack Kelly (ControlPlane, ITSC)
  • Justin Cappos (NYU, ITSC)
  • Santiago Torres-Arias (Purdue, ITSC)
  • John Kjell (TestifySec)
  • Kairo de Araujo (TestifySec)
  • Tom Meadows (TestifySec)
  • Cole Kennedy (TestifySec, ITSC)
  • Tanner Jones (TestifySec)
  • Tom Hennen (Google)
  • Noel Cortes

Notes

  • Intros

    • None today

  • OSS NA

    • Discussion on serialization stuff. Dedicating some cycles to generalize source track for SLSA?
    • Deployment attestation that was discussed for a bit:
      • The discussion centered around what goes into the deployment
      • Further, some review of the usecase (i.e., know what's running right now)
      • Effectively a Deployment attestation is an attestation about a VSA (i.e., does this policy apply in this environment)
      • i.e., should this be its own predicate, or should it be a VSA with some attributes
    • OSS NA talks:
      • John and Thom gave a talk on in-toto + witness + etc
        • A lot of the discussion is around how to make things easier, not just possible
    • .
    • .

  • in-toto Layouts, client tools, etc:

    • General discussion around how do we start supporting attestations as defined by the attestation group
    • More discussion around how do we start writing policy in better ways
    • Thom and Tom: Layout transpilations, using best practices, examples, demos, etc.
    • Cole: how do we handle alert fatigue etc
    • Tom: Chat w/ Aditya: request access to doc (private for now) that describes a sketch for templating to turn a higher level user-facing policy into an in-toto layout
    • John: we get to have a lot of conversations in an abstract sense. Plus, we don't need to have an in-toto layout to apply to everything.

  • GH Attestations:

    • GitHub is providing an attestation store. You can also have GHA generate slsa prov + sboms + attest to action in the background for you
    • Cole: what is the general pattern for build. What about the policy enforcement/etc?
    • Adam: besides the types that are supported, what are the other types of attestations you're looking into, are there patterns to support other types? (A: there are a lot of things that are being considered right now)
    • Adam: can you submit your own attestations as a third party/etc? (A: yeah, when you call attest action will they submit the result in sigstore bundle to GHAAS. There are no commitments around how long is the data going to be stored. However, the AS may not be the place for long term storage or the "last place" where the attestations should be)

:tulip: 04/05/2024 :tulip:

:movie_camera: https://zoom.us/rec/share/5xrBYUGZ-qarwMmipTz34jTvw-An0YEh9Wwc95faoZryT5VZATiT5gVW3AC09GZo.gfH-3kU_Y4ENWjPc

Agenda

  • New community member introductions (if any)
    • Laurent Simon
      • Google, working on SLSA, Scorecard within OSSF
    • Isaac Hepworth
      • Google, Chair of SCI WG at OSSF
    • Andrew McNamara
      • Here from discussion of VSAs from SLSA
  • Kubecon Meetup Updates (TBD)
  • Project updates
    • in-toto-golang consolidation
      • Witness joined the in-toto community, some shared functionality with in-toto-golang
      • Consoliate and retire the in-toto-golang tool in favor of Witness
      • Identified functionality in in-toto-golang, now being added to Witness
      • Outstanding:
        • Use Witness to generate in-toto Links
        • Add policy and attestation verifier functionality into Witness
      • Would also like to nudge ITE-11
    • witness
      • terminology updates (santiago)
        • Terminology Discussion
        • Looking for feedback from the community
        • Within Witness, there's conflicting terms wrt the spec
        • In particular under discussion: "attestors" vs "collectors"
        • A list of conflicting terms will be collected
        • Want to avoid renaming in the future
        • Question around use of "externalParameters" in SLSA
    • archivista
    • attestation (msm)
      • Policy verification attestation –> which predicate? VSA, SCAI, other?
        • Tom H: https://docs.google.com/presentation/d/1_1ikfSaja87-Qx2ev26DYdiNgS6AEvVFO92oSwNGvJ8/edit?usp=sharing
        • Produces know a lot about how they expect something to be built
        • Consumers less so
        • Need to record the fact that someone has evaluated an artifact and has decided it meets certain needs
        • Record some of the properties the artifact has based on the policy evaluation
        • Zach: fuzzy on who the trusted parties are in the context of the VSA
        • Sometimes it's the producer, sometimes it's the consumer?
        • Tom: discussion about how VSAs could be used for the NPM case
        • Zach: highlights desire to provide the plumbing for these semantics without making the policy verification assurance, which would be for the consumer to do
        • John: interesting thing is the attributes communicated in the VSA
        • Thinking through what the important traits are and who is doing the verification
        • And how do you convey the trust to downstream consumers
        • Andrew: in SLSA, there was a conformance program we were trying to launch
        • That has some auditor / external entity that can state conformance
        • VSA is a shortcut to trust based on other policy
        • Tom Meadows: can you do policy verification every time you deploy?
        • VSA helps make it simple enough + latency worries
        • Marcela: clearly a need to capture a policy decision
        • The original VSA on the SLSA end was doing that for decisions around Provenance
        • But clearly also a need to express policy decisions in other places
        • And hence the generalization effort
        • The discussion on formats: the format is almost secondary to making sure we have the right semantics
        • Justin/Cole: VSAs kick in for sublayouts
        • When you have something like a sublayout, you provide someone else the means to create policy/layout
        • What are the actual properties we're getting out here? Trust?
        • Aditya: Delegation would still be to a sub-policy
        • VSA is a result of verifying the sublayout but the delegation is still to the entity defining the policy
      • Deploy attestation predicate
        • Laurent: a lot of the work that's been done is on production of software
        • Not so much on consumption
        • An admission controller wants to know "can I deploy this in this environment?"
        • Shift left: say as an attestation: "this is where you can deploy this container"
        • It also simplifies policy evaluation
        • Andrew: so does this overlap with the VSA?
        • Laurent: VSA is a determination about the artifact's properties
        • Deployment attestation is about consumers making a determination whether to deploy an artifact
        • Justin: why not do this as part of a layout?
        • Tom M: would this be time sensitive?
    • gsoc (santiago)
  • OSS NA '24 meetup (msm)
  • AOB

Attendees

  • Justin Cappos (NYU)
  • Aditya Sirish (NYU)
  • Cole (TestifySec)
  • Zach Steindler (GitHub; OpenSSF TAC)
  • Andrew M (Red Hat)
  • Kairo de Araujo (TestifySec)
  • Jack K (ControlPlane)
  • Marcela Melara (Intel)
  • Alan Chung Ma
  • Isaac Hepworth
  • John Kjell
  • Laurent Simon
  • Tom Hennen
  • Ishaan Jain
  • James Carnegie
  • Noel
  • Tom Meadows

:tulip: 03/01/2024 :tulip:

Agenda

  • New community member introductions (if any)
  • Project updates
    • in-toto-golang consolidation
    • witness
      • attestation collection
    • archivista
    • gsoc (santiago)
  • KubeCon
    • Meetup
    • Booth Schedule
    • KubeCon talks
  • AOB

Attendees

  • Santiago Torres-Arias (Purdue)
  • Aditya Sirish (NYU)
  • Alan Chung Ma (Keytos)
  • Trishank Karthik Kuppusamy (Datadog)
  • Kairo De Araujo (TestifySec)
  • Justin Cappos (NYU)
  • James Carnegie (Docker)
  • Toddy Mladenov (Microsoft)
  • John Kjell (TestifySec)
  • Jack Kelly (ContrlPlane)
  • Marina Moore (NYU)
  • David Dooling (Docker)
  • Cole Kennedy (TestifySec)
  • Marcela Melara (Intel)
  • Tanner Jones (TestifySec)
  • Sunil Ravipati
  • Mikhail Swift (TestifySec)

Notes

New community member introductions

  • None today

Projects Updates

  • in-toto-golang consolidation / witness
    • Meeting regularly
    • Link attestor in witness
    • Can pull in other predicates defined in in-toto/attestation as well
    • Discussed witness policy <-> ITE-10/11
    • Prototyped support for attestation collection in attestation-verifier
    • We need to discuss how collection can be upstreamed into the attestation spec
    • Aditya: can we think of a collection as a successor to the link predicate?
    • Aditya: With some chages, we can see it seems like it could work
    • It has materials + products and supports "mixins" for different information sources / collectors
    • All of this would go in environment / byproducts in the original link
    • With this model, it's easier to write policies about expected data sources + what they say
  • Archivista
    • Kairo: Making it so Archivista can be used to identify the policy for some artifact
    • In addition to the attestations of course
    • Doing so with support for key rotation as well
    • Plan to demo in the next meeting
  • GSoC
    • Santiago: plan to submit a couple of projects
    • A sigstore integration or plugging somethings better into GUAC
    • There's interest in the Jenkins plugin but it needs more work such as adding sigstore support and updating SLSA support
    • Rebuilderd implementation could be updated to support SLSA provenance
    • Maybe a demo for SLSA that is similar to in-toto/demo but uses in-toto tooling to generate SLSA predicates
    • Marcela: some implementations need to be updated to support attestations / predicates via the protos
    • Some discussion about time commitments – it's maybe a couple hours a week after the summer starts
    • John and Trishank interested in mentoring

KubeCon EU

  • Meetup
    • John: we don't have project meetings this time
    • Quite a few of us have the all access pass
    • There'll be lunch / coffee etc as a result
    • So we'd just have to find a table
    • If folks don't have the all access pass, we can find some other place to meet
    • We could discuss in-toto-golang consolidation, DSSE extensions, etc.
    • Cole: Can we ask the CNCF for a room?
    • If we can't get a room through them, Cole might be able to reserve a room someplace
  • Booth
  • KubeCon Talks
    • Maintainer track
    • Navigating the Software Supply Chain Defense Landscape
    • Panel with John / Marina
    • Tom Meadows has talks at colocated events that might touch on in-toto
    • SBOMs That You Can Trust (Chainloop)
    • Yahoo folks are talking about Sigstore that also touches on attestations
    • ContribFest

AOB

  • Marcela: There are several in-toto and supply chain related talks at OSS NA
  • Santiago: for the Docker folks, any movement on the OCI <-> attestations work?
    • James: in the short term, we'll be moving forward with the spec as is
    • Interested in working on this some more
    • The Docker folks missed the in-toto/attestation meeting
    • Santiago: Sigstore is moving towards not storing attestations in the log
  • Trishank / John: Discussion around custom extension types in DSSE
    • https://github.com/secure-systems-lab/dsse/pull/61
    • https://github.com/secure-systems-lab/dsse/issues/59
    • That PR / issue could use more eyes / opinions
    • Santiago: Maybe we could just call it the ITE-7 extension more generally speaking
    • Aditya: The original motivation for extensions was to ensure there was no confusion in the fields that must be verified
    • Eg: a client must not assume it needn't verify the tlog because that field is dropped from the envelope
    • Trishank: Also important to consider cases with a mix of required and optional fields

02/02/2024

Agenda

  • New community member introductions (if any)
  • in-toto Go consolidation
  • Tom Meadows: standardising documentation websites across in-toto
  • Jonny Stoten: in-toto attestation storage in OCI registries
  • Santiago: in-toto release/publish attestation

Attendees

  • Santiago Torres-Arias (Purdue)
  • Aditya Sirish (NYU)
  • Marcela Melara (Intel)
  • Jack Kelly (ControlPlane)
  • Cole Kennedy (Testifysec)
  • Joel Kamp (Docker)
  • Tom Meadows (Testifysec)
  • David Dooling (Docker)
  • James Carnegie (Docker)
  • Mikhail Swift (TestifySec)
  • Justin Cappos (NYU)
  • Ian Dunbar-Hall (Lockheed Martin)
  • Trishank Karthik Kuppusamy (Datadog)
  • Mike LeBeau (TestifySec)
  • John Kjell (Testifysec)
  • Noel Cortes (Lockheed Martin)
  • Jonny Stoten (Docker)
  • Azeem
  • Toddy Mladenov (MSFT)
  • Zach Steindler (GitHub)

Notes

  • First successful CNCF Zoom Meet :tada:

Introductions

  • Tom Meadows
  • James Carnegie
  • Joel Kamp
  • David Dooling
  • Toddy Mladenov

Go consolidation

  • Move foundational capabilities like KMS to go-securesystemslib
  • Can be reused downstream by go-witness, go-tuf, etc
  • Also helps standardize DSSE extensions etc so all ecosystems are consistent
  • First action is about governance of go-sslib
  • Working in parallel on in-toto-golang / go-witness / witness streamlining
  • Trishank mentioned in the last meeting about an abstract storage interface for attestations
  • Santiago: did you reach out to Sigstore clients SIG?
  • John: Hayden joined the last call and we chatted about how this would work <-> sigstore/sigstore
  • There are some differences in opinion and some outstanding conversations
  • Tom: I'm going to sigstore community meetings
  • With time things can be ironed out and we can likely maintain a shared library over time
  • Joel Kamp: It'd be great to have a single library for all this
  • Tom: We're actually working on KMS support in go-witness based off sigstore/sigstore implementation which is high quality

Standardizing Documentation

  • Tom: Documentation / information of in-toto are on a few different places with separate web frameworks
  • Spent some time on how to improve docs for Witness
  • Working to figure out how to get a better website / docs for Witness
  • Also same goals for Archivista
  • Built a proof of concept for how to standardize all of these docs
  • Santiago: We should also probably revisit the main in-toto website
  • We should at least start with a mention of Witness / Archivista on the main website
  • Jack: Review link - https://github.com/cncf/techdocs/tree/main/assessments/0009-in-toto
  • Santiago: Was waiting for graduation to start moving forward
  • But since there's some lag, maybe we can ask the CNCF about a potential website refresh
  • Justin: I've been working with the CNCF on the style guide changes / review etc
  • We should change the style guide so it makes sense for the people who actually want to make changes
  • Let's rework the contribution guide to make it work for contributors rather than something strict enforced top down
  • Santiago: I like the model of in-toto/attestation where the subproject is handling these details
  • https://github.com/in-toto/docs/pull/84
  • Tom: tooling was discussed previously. One I put forwards was Docusaurus. I have a small implementation of consolodating docs across projects.
  • starts screenshare
  • docusaurus recommends 3 separate servers
  • one main file for configuration, no complicated html or JS
  • Biggest strength and weakness is we dont want contriubters to have to use HTML/CSS/JS docusaurus has that as optional. Mostly markdown with opt in reactjs.
  • Aditya: Would this pull in API docstrings etc? Preferable to not have to update those separately / twice
  • Tom: May be possible to pull that in, we should avoid repetition for sure
  • Santiago: We should reach out to the CNCF for resources on infrastructure / cloud credits as well

in-toto/attestation storage in OCI

  • Jonny: We're thinking about how to store in-toto attestations in OCI
  • An attestation manifest sits next to an image
  • That then points to in-toto statements as they aren't signed at the moment
  • We're also looking at how to incorporate a future with signed attestations without breaking those relying on older unsigned statements
  • We have a few options
  • First we just put an unsigned DSSE envelope and put that next to the image, basically what the spec says minus the sig
  • Has some disadvantages as the data in the envelope is duplicated in the registry (b64 encoding)
  • Another approach is to insert a DSSE envelope and the payload is an OCI descriptor that's a reference to the original statement / digest
  • The signature is over the OCI descriptor and the descriptor is resolved to get the actual statement
  • Yet another approach is to use an in-toto resource descriptor instead of an OCI descriptor, refers to the statement again
  • Worth documenting how Sigstore does it today
  • Perhaps an ITE is in order
  • What is a media type for a statement? Distinct from DSSE etc?
  • Aditya: We have a related thought about resolving attestations in our verification workflow etc
  • We should think about the impact on the verification, especially if the sig is over a reference to an unsigned attestation, etc.
  • Zach: this might be scope creep, but what we're noticing in helping customers store in-toto attestations in registries is that different providers have different implementations. Azure container registry supports the OCI 1.1 referrer spec, which is different than Docker and AWS ECR today. Having a consistent way to relate in-toto documents to container images would be a huge win for the ecosystem!
  • Marcela: The media type bit was discussed by in-toto/attestation
  • We tried to provide guidance, would be nice to have more feedback on that
  • Also added to the chat the PR for RD resolution in the attestation-verifier
  • https://github.com/in-toto/attestation-verifier/pull/22
  • Toddy: I can shed some light on OCI
  • OCI 1.1 is supposed to be released possibly today
  • There's a referrer spec that's used by some registries, others may support soon
  • In Notary, the signing is based on the descriptor of the artifact
  • David: Any notes about referrers / attestation discovery would be great context
  • Santiago: homework for me as well, also describe what Sigstore did etc
  • https://github.com/in-toto/attestation/blob/main/spec/v1/bundle.md#storage-convention

Release / publish attestation

  • https://github.com/in-toto/attestation/pull/319
  • Predicate proposal from Zach for release / publish
  • Coming from the NPM usecase
  • Trishank: Very useful for OSS registries
  • Zach: Primary motivation was we did build provenance for NPM and then we added the publish attestation hastily
  • Now going through the ITE-9 process
  • There have been discussions in the Python community related to this
  • Happy to help answer questions, clarify, shepherd the predicate through
  • Marcela: Perspective from the attestation maintainers
  • We're in agreement that the release predicate is ready for 0.1
  • Some outstanding comments that need to be resolved / maybe worth bumping the thread
  • Santiago: Think about pipeline from a predicate being accepted to being available in witness etc
  • John: Discussing in go consolidation

AOB

  • Aditya: KubeCon is coming up! Maintainer track, booth, etc
  • Justin: Might want to consider another time for a meeting every third month or so for those who can't make this one

01/05/2024

INTERIM MEETING LINK: https://meet.google.com/wvm-fnrx-qpa

Agenda

Attendees

  • Justin Cappos (NYU)
  • John Kjell (TestifySec)
  • Kairo De Araujo (TestifySec)
  • Jack Kelly (ControlPlane)
  • Tom Meadows (TestifySec)
  • Toddy Mladenov (Microsoft)
  • Aditya Sirish (NYU)
  • Marcela Melara (Intel)
  • Judy Bogart
  • Alan Chung Ma

Notes

New community member introductions

  • Tom Meadows
    • Joined TestifySec in December
    • Working on Witness
    • At Jetstack before, worked on cert-manager
  • Toddy Mladenov
    • Maintainer of Notary, works at Microsoft
    • Supply chain security for about 2 years

Consolidate in-toto Go tooling

  • We have a bunch of Go implementations that we need to consolidate
  • Tom: My experience predominantly has been with go-witness
  • Also used go-sslib for DSSE
  • go-witness does not use go-sslib / in-toto-golang
  • John: Support for extensions is the blocker for using go-sslib
  • Tom: We have definitions for predicates etc as well
  • go-witness also has signer interfaces that abstracts signing, would be good to consolidate that too
  • John: Agree with all of that
  • python-sslib supports more signers, that's an area we can work on for witness as well <-> go-sslib
  • Sigstore also has its own implementations
  • From a security perspective, consolidating all of this into one place is highly desirable
  • The attestation repo -> we should start consuming proto defs in go-witness
  • Also define witness specific protos in /attestation (ITE-9)
  • in-toto-golang may be on the verge of duplicating work that should go in go-witness instead
  • attestation-verifier <-> unification with witness policies is also a goal
  • A dedicated working group to finish all of this would be nice
  • Write some code!
  • Marcela: As an /attestation maintainer, we provide proto defs for all implementations, not just Go
  • There's a question of what must be implemented in a Go library vs on the spec side
  • It makes sense to keep base packages for diff predicates / statement close to the spec
  • Would welcome the witness ones as well
  • How do we envision each repo or package being used?
  • Aditya: Can we put together a task force that can consolidate all of this?
  • We can better answer the question of how these diff packages are used then as well
  • Related: ITE-10/11 need to move forward to allow for policy unification
  • Justin: Now's a good time to express any concerns people have with them
  • Else, we can start moving forward
  • John: One more thing to consider is governance of go-sslib
  • We trust NYU SSL but making governance more explicit would be helpful
  • Action Item: to put the task force together on Slack
  • Action Item: to move with ITE-10/11
  • Action Item: governance for sslib

Proposed Documentation Contribution Policy

  • Justin: Maybe 6 months ago we asked the CNCF to do docs review
  • Some folks including Judy spent some time working with us to make suggestions
  • One thing that was noted was that we don't have a guide for what docs look like
  • Justin proposed a draft of this policy
  • Modeled on the Kubernetes docs contribution guide
  • If it's a small contribution, just propose it
  • If it's more involved, talk to us
  • The goal is to get to a stage where we can approve this relatively quickly
  • Then we can start working on the documentation issues the techdocs assessment found
  • We also have a bit of a strange repo setup with docs, community
  • Maybe we should rename repositories to make things clearer
  • Judy: In addition to documentation being in spec, the CNCF requires graduated projects to make docs available in the project website
  • We need to create an architecture on the website to render the current docs
  • Justin: Also, we actually have decent docs in terms of contents, but it's scattered across different places and not very visible
  • Aditya: Rename docs to specification, maybe also rename in-toto/in-toto to in-toto-python
  • Can render spec similar to TUF
  • Judy: "Default repo" should be something docs related still rather than /community
  • John: in-toto.io should be the starting point for docs related to all in-toto projects
  • And still have /docs repo of some kind that is also rendered
  • Tom: As a newbie to in-toto, when I go to github.com/in-toto, I except the readme but also really except the specification
  • I except in-toto/in-toto to be the specification
  • Judy: One recommendation is to better index / label parts of the spec as well
  • Kairo: audio issues :(
  • Jack: Is there a link to the report?
  • https://github.com/cncf/techdocs/tree/main/assessments/0009-in-toto
  • Justin: I personally think everything in the report is valuable
  • Some of it you're like "wow we really need to fix this"
  • Some you're like "well, maybe…"
  • So let's get the contrib guide settled and then we can focus on the actual issues / recommendations
  • Judy: One important thing we should decide is also the tech stack to render docs, readthedocs for python but it's not for everything else, etc
  • Aditya: who needs to approve the guide?
  • Justin: community, majority of the ITSC as well
  • One thing to note is that Judy pointed we should modify parts that point back to Kubernetes
  • Lots of mentions were already changed but some were kept to acknowledge where it came from / examples

How do we expose subproject docs?

  • Tom: Witness + Archivista need a docs overhaul
  • Opportunity for Tom and Kairo to help with this broader effort
  • Something we've been discussing in Witness / Archivista is how we must be presenting docs on the website
  • Right now, docs are just in the repo
  • Should the website rendering be part of in-toto.io? Consistency? Sections for different projects?
  • Important that people coming to in-toto can clearly see Witness / Archivista are part of in-toto
  • Aditya: maybe a docs task force is in order?
  • Justin: Judy raised a great point, we need to decide on the tool and we should do it ASAP, maybe as part of the guide definition
  • Tom: Looking at a few options like mkdocs, docusource (and others)
  • John: We're solving this problem for Witness / Archivista, should be generalizable to all repos in @in-toto
  • Hopefully we can use the same tool to deploy / build all of this
  • readthedocs has ads which is also something to think about, unless we opt to pay
  • Justin: does CNCF have a preference?
  • Judy: Maybe docusource, need to confirm with Nate W
  • Action Item: organize task force on slack

AOB

  • Justin: there's a seat on the TOC for maintainers, an in-toto maintainer could run
  • We get one vote as a project
  • Aditya: in-toto at KubeCon EU
  • Jack: cross impl testing needs to move over

12/01/2023

INTERIM MEETING LINK: https://meet.google.com/aig-rasy-uxq

Agenda

  • New community member introductions (if any)
    • Toddy
    • David
    • Thomas
  • KubeCon Review
    • Booth
    • Shoutout from supply chain keynote (Fredrick)
    • Good turnout for maintainers' talk
      • SOTU
      • Demo
      • ITE 9-10 work
      • Positive reception: 10/10
      • People are still learning about supply chain security
      • How do we make our tooling more accessible?
      • When will the video go up?
      • People want to understand the Attestation model
  • CLOMonitor updates
  • [Proposal] - Policy Working Group
    • [Discussion] Datadog experiments
      • Should subjects be materials or products in informational/transformational predicates?
      • Should we support arbitrary policy languages/engines (e.g., Rego) in ITE-11?
      • Happy to co-develop here
  • Witness & Archivista donation follow-up?
    • CNCF needs Santiago to file a legal review ticket
  • [Discussion] Plugin Support?
    • The Caddy model
    • Use cases
      • Mixing closed-source with open-source tooling
    • Ideas
      • Could we include some tooling/interfaces in the Attestation framework?
        • e.g., gRPC interfaces for protobuf messages
        • Pros: can implement different instances of the same interfaces
        • Cons: maintenance overhead
      • Witness as a "glue" tool
      • Dynamic languages such as Python as "glue" tooling
  • Any other business
    • N/A

Attendees

  • John Kjell (TestifySec)
  • Cole Kennedy (TestifySec)
  • Mikhail Swift (TestifySec)
  • Trishank Karthik Kuppusamy (Datadog)
  • Toddy Mladenov (Microsoft)
  • David Dooling (Docker)
  • Thomas Meadows (TestifySec)
  • Adam Nauth (Best Buy)
  • Kairo De Araujo (TestifySec)
  • Marcela Melara (Intel)
  • Alan Chung Ma (Purdue)

Notes

  • (See agenda above)

11/03/2023

INTERIM MEETING LINK: https://nyu.zoom.us/j/91097299041

Agenda

  • New community member introductions (if any)
  • KubeCon Demo (Marcela)
  • KubeCon Planning
    • Meeting agenda
    • Booth personnel / schedule
  • AOB

Attendees

  • Aditya Sirish (NYU)
  • Justin Cappos (NYU)
  • Jonny Stoten (Docker)
  • Jack K (ControlPlane)
  • Santiago Torres-Arias (Purdue)
  • Marina Moore (NYU)
  • Ian Dunbar-Hall (Lockheed Martin)
  • John Kjell (TestifySec)
  • Alan Chung Ma (Purdue)
  • Tom Hennen (Google)
  • Marcela Melara (Intel)
  • Mikhail Swift (TestifySec)
  • David Dooling (Docker)
  • Lukas Puehringer (NYU)
  • Adam Nauth (Best Buy)

Notes

New community member introductions (if any)

  • David Dooling from Docker

KubeCon Demo

  • Dry run for KubeCon demo on Tuesday
  • Some of it uses in-toto, some doesn't
  • Lukas: Does the layout support a new DSL?
  • Aditya / Marcela: ITE-11 adds CEL support
  • Santiago: Part of the demo that fetches in other attestations has synergy with GUAC?
  • Marcela: That's by design!
  • https://github.com/in-toto/scai-demos/blob/main/docs/kccncna2023.md

KubeCon Planning

  • Meeting
    • Monday at 10:30 AM local time
    • Santiago: Possibly ITSC ought to meet too to discuss Witness/Archivista, graduation etc
    • Justin: Not sure we can do a lot more about graduation at the moment, I reached out
    • Santiago: How does Witness/Archivista donation affect graduation?
    • John: There's precedent to something like this with other projects
    • We've gotten more contributions to the projects as well, probably in part due to job listings
    • Moving repos over will make things easier for people to contribute too
    • We're ready to move things ASAP
    • We also have some new folks joining who'll be working on open source things
    • Santiago: We should add Witness/Archivista things to the meeting agenda
    • Another thing to discuss is the Docker OpenPubKey
    • John: There was also a discussion re OPK on #in-toto for Witness
    • Some agenda items could also be in the TUF meeting in the afternoon to ensure the right people are in the rooms
    • Santiago: in-toto + TFX is another thing we should discuss
    • With a small delta, we could be using in-toto in tensorflow workloads
  • Booth planning

AOB

  • Jonny: Inspect cert contents in attestation-verifier
    • Need to assert cert contents match predicate contents
    • Tom: slsa-verifier does this types of checks on the cert for sigstore
    • Aditya: TAP-18 helps with identity and issuer but other contents?
    • Mikhail: ITE-7 can help here?
    • Aditya: Yes but one of the requirements is a comparison of cert values and attestation values rather than separate checks on each
    • It's a question of layers: in-toto separates signature verification from attestation verification
    • But lines are blurred with sigstore signatures that embeds other information
    • Maybe good to whiteboard?
    • Santiago: How do we proceed?
    • Jonny: I can share some sample policies I've been working on

10/06/2023

INTERIM MEETING LINK: https://nyu.zoom.us/j/91097299041

Agenda

  • New community member introductions (if any)
  • Intel SCAI Donation
  • in-toto/attestation-verifier repo transfer (Aditya)
  • Witness / Archivista donation (John Kjell)
  • in-toto <-> slsa-verifier? (Trishank?)
  • SBOMit update (Ian or Marina or Justin)
  • KubeCon Planning
  • AOB
    • Docker <-> OpenPubKey

Attendees

  • Justin Cappos (NYU)
  • Aditya Sirish (NYU)
  • Marcela Melara (Intel)
  • Santiago Torres-Arias (Purdue)
  • Tanner Jones (TestifySec)
  • Tom Hennen (Google)
  • Mike (TestifySec)
  • Jack K (Control Plane)
  • Kairo Araujo (VMware)
  • Jonny Stoten (Docker)
  • Ian Dunbar-Hall (Lockheed Martin)
  • Adam Nauth (BestBuy)
  • Mikhail Swift (TestifySec)
  • John Kjell (TestifySec)
  • Alan Chung Ma (Purdue)
  • Trishank Karthik Kuppusamy (Datadog)

Notes

New community member introductions

  • Jonny Stoten
    • From Docker, interested in adding signed attestations to Docker
  • Mike
    • From TestifySec, formerly GitLab
  • Adam Nauth
    • From Best Buy, exploring using in-toto for about a year, hoping to contribute, working through approvals
  • Tanner Jones
    • From TestifySec, Technical Account Manager working with US Navy

Intel SCAI Donation

  • SCAI -> Supply Chain Attribute Integrity
  • A predicate that captures attributes about artifacts
  • Donation is of some APIs that use in-toto/attestation bits as well as some demos
  • Also included is some policy checking code
  • Repository is now under the in-toto org: https://github.com/in-toto/scai-demos

in-toto/attestation-verifier repo transfer

  • Prototype verifier for ITE-10 and 11 layouts
  • What about backwards compatibility?
    • Handled with ITE-10 / ITE-11 and how they interplay with future in-toto spec versions
  • Demo of the verifier
  • General acceptance to move forward with this
  • Link: https://github.com/in-toto/community/issues/14

Witness / Archivista donation

  • John: TestifySec wants to donate these projects to in-toto
  • Link: https://github.com/in-toto/community/issues/15
  • Witness designed to be a modular with attestors for different integrations / systems
  • Witness policies are similar to ITE-10/11 work
  • Archivista is a mechanism to store attestations
  • Verification becomes simpler by having attestations stored in a single place
  • Archivista creates a graph based on attestation subjects, can be walked back during verification to pull in related attestations
  • Looking for community thoughts and feedback, new attestors and predicates that can be added
  • Marcela: I was looking at Sigstore's attestation storage capabilities
  • Can you talk a bit about being able to provide similar auditability / transparency guarantees?
  • Mikhail: with Archivista we're not focused on TL-like bits that Rekor does well
  • We originally tried using Rekor as a store but didn't pan out
  • Focused on being able to build a graph and search
  • Mikhail: We consider Archivista "untrusted" to that end
  • You put in attestations and pull them out, with Archivista providing hints
  • "Trust but verify": Pull out attestations but actually verify against functionaries and so on with policies
  • John: Archivista can store policies as well, and plan to use TUF in Archivista to bootstrap the policies
  • ITE-2 + plan to wrap verification to generate attestation like the in-toto spec
  • Aditya: supportive
  • Marcela: related is the generalizing of the VSA predicate
  • John: we ought to mark the projects appropriately to indicate maturity levels, especially with in-toto going up for CNCF graduation

in-toto <-> slsa-verifier

  • Conversations ongoing to see if ITE-10/11 efforts can align with slsa-verifier

SBOMit

  • Ian: TAC voted to accept project to sandbox
  • SBOMit is a bridge between in-toto and SBOM generation to allow for verifying SBOM contents
  • The project is primarily a specification
  • Short term: provide attestations that can separately verify SBOM claims
  • Long term: build in verification of SBOMs that use in-toto attestations

KubeCon Planning

  • Booth
    • Some folks have already signed up to help staff
    • Justin also interested in helping out but not on the roster yet
    • Alan: what is the goal of the booth?
    • Aditya: Educate potential adopters / integrators about the project
  • Project meeting
    • Two hour meeting the day before KubeCon starts
    • We should put together an agenda for that
  • Get together at Chicago?
    • Lunch or dinner would be nice
    • Look at calendar and propose options for us to get together

Docker <-> OpenPubKey

  • Tom: Can the Docker folks talk about OpenPubKey etc?
  • Jonny: OpenPubKey removes CA compared to Sigstore
  • Does need transparency logging and some other infra pieces to be a true solution in that space
  • But not requring the CA was a consideration
  • Tom: Would love to discuss more of the Sigstore context in that community
  • We currently use Notary v1 for signing docker official images, but project is unmaintained
  • We think Notation did not offer a particularly compelling story
  • John: There was also some mention re TUF, more details?
  • Jonny: Slightly less well defined in our heads
  • Using TUF to distribute policy, so we know which key should be signing policy, attestations etc
  • With OpenPubKey, we also need to distribute old OIDC public keys
  • Could be just put them in a TUF repo
  • We've also talked about using OpenPubKey to sign contents of a TUF repo but early days
  • Trishank: maybe not the best meeting to discuss TUF but would love to welcome you to that community
  • ITE-2 describes how TUF can be used with in-toto attestations
  • Seems like OpenPubKey is less a Sigstore replacement and more a Fulcio replacement?
  • Jonny: The way we want to use it at Docker is to remove that reliance on a CA
  • More generally, that's not the purpose of OpenPubKey
  • OpenPubKey could perhaps be used with Fulcio, so perhaps not really a direct alternative
  • Trishank: We ought to understand how all these different systems work together, TUF, in-toto, Sigstore, OpenPubKey
  • Justin: Marina Moore did a pretty detailed analysis of Sigstore etc, comparing with TUF and so on
  • We'd be interested in working with you all to extend that to OpenPubKey
  • Planned to reach out to Sharon
Last changed by 
 
lukpueh
4
1
5303

Read more

SSLAB Students

Cindy (@cindykimxp) - https://github.com/in-toto/in-toto/pull/357 Kristel (@kristelfung) - https://salsa.debian.org/reproducible-builds/debian-rebuilder-setup Yuanrui (@SolidifiedRay) - https://github.com/in-toto/in-toto/pull/364 - layout tool frontend (D3.js) Benjamin (@itsbenwu) - layout tool backend Isha (@IshaDave)

Jun 26, 2020
Read more from lukpueh
Published on HackMD