Repository mapping metadata

[sam-m-weber]

In the "Repository mapping metadata" section it states that the repository mapping metadata MUST contain a list of repositories that MUST sign the targets metadata for the image paths. However, I cannot find where this is used. Should this be in the full verification process? And does the partial verification process use this as well?

[awwad]

There are definitely clarifications required here, at least. I'll discuss this with some folks and write a PR.

[JustinCappos]

@awwad Can you have this conversation soon? Perhaps someone else can write the copy, but it feels like this is blocked on you now. Let's get someone else to help with it so we can unblock it.

[awwad]

The short(-ish) version of the story:

The text in the various verification procedures (and possibly some of the constraints on the repositories in other sections -- someone should check that part after this) assumes that there are two repositories -- one Director and one Image Repository.

We discussed having much more flexibility in the number of distinct repositories with distinct metadata, to accommodate more elaborate needs. (For example, it's one way to handle fleet management, though there are other ways.) The reference implementation allows for this flexibility already, because the mechanism it uses to enforce the repository consensus (Director agreeing with Image Repo) is through TUF's TAP 4, using mapping metadata (a.k.a. the map file). It looks like the "Repository mapping metadata" section intends to allow for this same flexibility, but the verification procedures are not written with it in mind. Since this standard is intended as a more thorough document, I do not think it makes sense to say, somewhere (as we occasionally did in the Implementation Specification) something remotely as hand-waving as "[the algorithms are written for the typical configuration, and if you change the mappings, which you are allowed to do, things look different]". I can't imagine that.

So our options basically are:

1. Adjust the algorithms:
   1. to adjust the shape of the verification procedure sections in the standard so that we treat repositories more neutrally, with little if/else bits for if-this-is-a-Director-repository, and wrap-up sections that have the effect of "if a consensus is reached for the repositories the mapping file requires to agree..." (but more readable).
2. Lock down the repositories to one Director and one Repository
   1. This relegates the mapping bit to the deployment considerations, where it probably still merits an explanation of how the procedures change if you want to make use of a more flexible repository configuration.

[awwad]

If that's adequate for someone to make a pass at the document, great. If more discussion is required, great. 😄

[tkfu]

On the 03/13 standards call, we noted that @awwad added the above comments just a few minutes before the meeting. Since nobody has had a chance to digest them yet, we're leaving this open for discussion.

[JustinCappos]

The short(-ish) version of the story:

The text in the various verification procedures (and possibly some of the constraints on the repositories in other sections -- someone should check that part after this) assumes that there are two repositories -- one Director and one Image Repository.

We discussed having much more flexibility in the number of distinct repositories with distinct metadata, to accommodate more elaborate needs. (For example, it's one way to handle fleet management, though there are other ways.) The reference implementation allows for this flexibility already, because the mechanism it uses to enforce the repository consensus (Director agreeing with Image Repo) is through TUF's TAP 4, using mapping metadata (a.k.a. the map file). It looks like the "Repository mapping metadata" section intends to allow for this same flexibility, but the verification procedures are not written with it in mind. Since this standard is intended as a more thorough document, I do not think it makes sense to say, somewhere (as we occasionally did in the Implementation Specification) something remotely as hand-waving as "[the algorithms are written for the typical configuration, and if you change the mappings, which you are allowed to do, things look different]". I can't imagine that.

So our options basically are:

1. Adjust the algorithms:

   1. to adjust the shape of the verification procedure sections in the standard so that we treat repositories more neutrally, with little if/else bits for if-this-is-a-Director-repository, and wrap-up sections that have the effect of "if a consensus is reached for the repositories the mapping file requires to agree..." (but more readable).

2. Lock down the repositories to one Director and one Repository

   1. This relegates the mapping bit to the deployment considerations, where it probably still merits an explanation of how the procedures change if you want to make use of a more flexible repository configuration.

I think that solution 1 above is the clear winner. Would someone have time to make a pass?

Also, to answer the other part of Sam's question, no this doesn't apply to PV secondaries.

[trishankatdatadog]

Related to #88

[jhdalek55]

In our 3/27 conference call @trishankatdatadog agreed to provide the needed copy.

[jhdalek55]

On our 4/10 Standards call, it was noted that pull request #99 will addressed this issue. It is pending review of some wording and then this issue will be closed.

[jhdalek55]

On our 4/24 Standards call, it was agreed that this issue should be kept open for some additional discussion. Please review pull request #99 to see the most recent changes in content. @awwad and @trishankatdatadog have made a number of changes, and additional comments are welcomed.

[jhdalek55]

Can we get some review and feedback on this issue, preferably before our next meeting? Thanks.

Lois

[trishankatdatadog]

On Thu, May 2, 2019 at 5:50 PM Lois Anne DeLong ***@***.***> wrote: Can we get some review and feedback on this issue, preferably before our next meeting? Thanks.

I am just too swamped at work, sorry. I'll try to see what I can do before next meeting...

[jhdalek55]

On the 5/8 Standards call, @patrickvacek offered to review PR#99, which will close this issue.

[trishankatdatadog]

On Wed, May 8, 2019 at 2:01 PM Lois Anne DeLong ***@***.***> wrote: On the 5/8 Standards call, @patrickvacek <https://github.com/patrickvacek> offered to review PR#99, which will close this issue.

Thanks, Patrick, much appreciated, sorry for dropping the ball on this. Happy to help address comments.

[tkfu]

On the 5/22 standards call, we agreed to close the existing PRs, and only include the 2-repo case directly in the standard. Guidance on how to implement more complicated setups will go in deployment considerations. @tkfu will put together a PR this week to do that.