owned this note   changed 5 years ago  
Linked with GitHub

TAP Meeting

Meeting info

Date: August 4
Time: 10 am est
Link: meet.google.com/ctz-zqbt-uaw
Attendees:

Agenda

TAP 1: Ready to merge?
Version Management: merge as draft?

Implementations

For Notary v2: python or go?

TAP 12

Notes

  • TAP 1 changes: Trishank will review today.
    • Should probably add a Type header to TAPs before status
      • Joshua to update PR with TAP 1 & TAP 2 edits for Type header
      • Can we rename statuses to be clearer about what milestones they are indicating
      • Follow on PR to update the existing TAPs
      • Would be nice to have a flow diagram that indicates which statuses TAPs can move between
  • Version management TAP: Trishank will try to review this week
  • Notary v2 implementations
    • Go prototype would carry more weight with Notary v2 community
      • Go implementation doesn't have delegations. In fact it's not compliant with specification version 1.0
    • There's value in a Go implementation, but should aim for something we can accomplish in weeks i.e. most of the functionality implemented this month in order to demonstrate
    • Python implementation is more complete and a known entity
    • Proposal: Marina to start implementing succinct hashed bin delegations in Go, just to get a feel for the codebase
  • TAP 13: need to figure out metadata format, may make sense in parallel with an implementation?
  • Separate keydb for delegated roles: postpone for now, good for completeness but not time well spent before the refactor is complete
  • How to count unique signatures and roles in agreement; what do we mean when we say a threshold of 2? Two unique sets of signatures? Or two "people" tell me it's OK?
    • we would benefit from pseudocode in the specification to help define how we do delegations and operate on the graph
      • Trishank & Marina to draft pseudocode together

Meeting info

Date: July 28
Time: 10 am est
Link: meet.google.com/bjz-fqma-pff
Attendees: Justin Cappos, Trishank Karthik Kuppusamy, Joshua Lock, Marina Moore, Lukas Puhringer

Agenda

Future TAPs (copied from last week's agenda)

  • Snapshot merkle tree
  • [JL] Targets and metadata on different hosts? (re: PEP 458 integration and tuf#1079
    • seems safer to have this as signed metadata on the host?
    • can achieve this with a mirrors role, but feels like overkill

Followup from last week

TAP 11 moved to accepted 🎉
Version management

  • New field added to targets, root
  • Needs implementation

TAP 12 Implementation

Changes to TAP 1

Next steps

TAP implementations

  • version management
  • succinct hashed bin delegations
  • TAP 13

Notes

  • TAP 11: will try to move to Final once the TAP 1 workflow is updated (as below)
  • Add types to TAP 1 so that there are informational and standards, with the latter requiring a change to the specification before the TAP becomes Final
    • Joshua to update PR #124 to include types
  • Version management: needs an implementation before it moves to Accepted, but could land as Draft
    • TAP 1 should make it clear that merging a Draft TAP without an associated implementation is fine
    • Draft: written TAP is OK
    • Accepted: there's a PoC implementation
    • Final: the specification is updated and implementation merged
  • TAP 12: Marina is moving towards implementation
  • Succinct hash bin delegations
    • Ready to start on an implementation?
  • Future TAPs
    • Snapshot Merkle Tree – split snapshot file for very, very large repos. Needed for Notary v2 scalability.
      • Marina has some text written in Notary v2 proposal, need to reorganise into something that looks like a TAP.
    • User Selection of the Top-Level Target Files Through Mapping Metadata. Needed for Notary v2.
      • Should we do the reference implementation in Python or Go?
      • Marina will take on implementing this in Go
    • Separate metadata and targets hosts?
      • Longer term we might should think about the mirrors support in the specification, but we don't know enough to make this more than an action item for now
  • go-tuf: now in our org. Should commit to spending more time maintaining that version. Ensure anything that ends up in the specification ends up there also.
    • Make minor changes around some of the TAPs and see whether we can draw the original authors back in

Meeting info

Date: July 17, 2020
Time: 10 am est
Link: meet.google.com/pwp-orgq-cmo
Attendees: Justin Cappos, Trishank Karthik Kuppusamy, Joshua Lock, Marina Moore, Lukas Puhringer

Agenda

Draft TAPs

TAP 5: Setting URLs for roles in the root metadata file

  • Is this superceded by TAP 13?

TAP 8: Key rotation
TAP 11: POUFs

  • The Reference Implementation POUF is in the TAP repository. Can this TAP be moved to accepted?
  • There is also an open pr to update this TAP

TAP 12: Improving keyid flexibility

PRed TAPs

Version Management

  • Open question in pr: supported versions/deprecated field to indicate to clients when a version will be deprecated
  • If accepted, should other TAPs require this TAP?
  • [JL] this TAP should probably encourage us to be more rigorous about backwards compatability. Rather than just stating something is backwards incompatible we might want to think about how existing implementations can continue to operate with the newer metadata as Evan began discussing in taps#13.

TAP 13 User Selection of the Top-Level Target Files Through Mapping Metadata

  • Open question in pr: mapping metadata format

Succinct Hashed bin delegations

  • No open questions, ready to merge as draft?

Future TAPs

  • Snapshot merkle tree
  • [JL] Targets and metadata on different hosts? (re: PEP 458 integration and tuf#1079
    • seems safer to have this as signed metadata on the host?
    • can achieve this with a mirrors role, but feels like overkill

Changes to TAP 1

  • The acceptance procedure isn't fully documented. Do we want to specify that?
  • When should TAP numbers be assigned? When should taps move from Accepted to Final?

Accepted TAPs moving to Final

TAP 4
TAP 3

Minutes

  • Joshua: Should we accept draft TAPs that are not backed with any augmented reference implementation?
    • Justin: No, we should not, although we have this a bit before.
  • TAP 5
    • Trishank: We should be conservative/judicious about which TAPs are accepted.
    • Justin: So far, we have been.
    • Marina: It is also helpful to document reasons why a TAP was rejected.
    • We have voted to reject TAP 5, and should document why.
  • TAPs 3-4
    • Where do they fit in the reference implementation?
    • Lukas: 3 is a MAJOR change, so certainly not 1.0.0 of the spec.
    • Lukas: 4 is a MINOR change.
    • Evan Cordell has filed an issue on TAPs 3-5 which we should finally get back to.
    • Lukas: TAP 3 is already on the draft branch of the specification, so it will be released on the next MAJOR release.
    • Marina: when will it get released?
    • Joshua: we should wait until we get the version management question figured out.
  • TAP 11
    • Once this PR is accepted, and Joshua accepts the TAP, then it is accepted.
  • TAP 12
    • Marina: "Diamond of death" problem is out of scope of this TAP. We will track it in a separate issue.
    • Trishank: Have we dealt with all the issues brought up in the TAP discussion, such as dealing with two duplicate public keys distributed under ostensibly different key IDs?
    • Justin: This is something the reference implementation should reject as an invalid targets file.
    • Trishank: Yes, but we do we? We should double-check.
    • Lukas: Happy to accept TAP as it is.
  • Succinct Hashed bin delegations
    • Lukas: Looks good.
    • Justin: 32-bit length makes sense to point to bins because it fits most computer architectures.
    • Trishank: We should add some notes to the TAP to advise implementors to be careful about not falling for DoS attacks by walking too deep or broad a malicious hashed-bin delegation graph.
    • Marina: we should more clearly/completely document hashed bins delegations in the specification.
  • TAP 1
    • Trishank: Time for an update? (Pun intended.)
    • Marina: What is the acceptance procedure? Does it mean we (formal TAP Editors) all agree?
    • Marina: How do we assign TAP numbers? PRs not yet accepted as marked do not get numbers, which do not make for easy reference.
    • Does every (draft?) TAP need to be backed by an augmented reference implementation?
    • Joshua: TAP 1 does not specify whether to include a TAP in a particular version of the specification, which makes it hard to reason about what TAPs are under which versions of the spec.
    • Joshua: volunteer to draft a PR.
  • TAP 8
    • Marina: Blocked by an augmented reference implementation.
    • Justin: Driven by one use case from one person in one community.
    • Justin: It's a nice mechanism, but needs more readers to reason about everything.
    • Trishank: Nice use case and mechanism, but no one else has asked for it, but worried about complexity it will add to the current reference implementation at least.
    • Lukas: Agreed.
    • Joshua: Volunteered to think about this TAP and implement it.
  • We will reconvene next week to discuss the rest of the TAPs.
Select a repo