RFE: support succinct delegations

[jku]

This is about exposing the TAP15 support that has just been added to python-tuf. Copying from discussions with @mvrachev:

Maybe a two step process:

• tufrepo edit X add-delegation --succinct <options> this edits targets role X, making the delegation into a succinct one
• tufrepo init-succinct-roles X reads the delegation and initializes all the delegated metadata files

The second step is a bit weird as it may create thousands and thousands of files, and changing the delegation details afterwards will of course break everything... but that seems to be what we need right now.

add-delegation change needs a bit of thought WRT how it relates to the non-succinct delegations -- but I think switching from one to the other is allowed to just wipe everything... This is why we use git as storage: resetting is easy if mistakes are made. It's also slightly incompatible with current CLI "API" (as the delegation name is required by add-delegation at the moment)

[MVrachev]

We should try and think what edge cases can appear from splitting the addition of succinct roles delegations and bin initialization into two steps. I have thought about the following scenarios:

• First case:
  1. User calls tufrepo edit X add-delegation --succinct with bit_length = 5
  2. User calls tufrepo init-succinct-roles X and initializes all bins
  3. User calls tufrepo edit X add-delegation --succinct with bit_length = 8, but doesn't initilize a new set of bins.

The question here is do we delete the old set of bins on a new call of tufrepo edit X add-delegation --succinct? Maybe it does make sense as the old bins loose their importance when a new delegation is created.

• Second case:
  1. User calls tufrepo edit X add-delegation --succinct with bit_length = 5
  2. User calls tufrepo init-succinct-roles X and initializes all bins
  3. User decides again to call tufrepo init-succinct-roles X.

Do we instantiate a new set of bins? It sounds like a reasonable thing to do as this looks like the user wants deliberately a new set of bins targets metadata.

The second step is a bit weird as it may create thousands and thousands of files, and changing the delegation details afterwards will of course break everything... but that seems to be what we need right now.

That's what I was thinking above. Should we delete all of the bins files on delegation change or leave this as a separate new command like tufrepo clean-succinct-roles-info X or tufrepo remove-succinct-roles X?

[jku]

Good thoughts. I'm totally fine with tufrepo being a bit of a footgun (so handling every edge case safely isn't necessary): it is a swiss army knife for editing metadata, not a real repo maintenance system. So dangerous commands are ok, especially since resetting to a known state is easy with git. I would like the tool to be able to produce any valid and reasonable metadata though: that sort of edge cases are good to handle.

first case:

The question here is do we delete the old set of bins on a new call of tufrepo edit X add-delegation --succinct?

I would say no:

• edit X is meant to mean "modify role X only"
• the fact that this is git based makes both recovery from mistakes and removing metadata files pretty easy

---

Second case:

Do we instantiate a new set of bins?

I think so. We could make sure none of the files exist already before creating any files: the name is "init" after all so I think it's reasonable to assume the roles don't exist when you run it.

I don't think we need a clean/remove command as a "git rm" should work just fine there.

[jku]

Creation of the delegation is now supported, but adding targets is still clunky. Still, closing this as #39 exists for the add-target issue