demo for policy state

[haotran-california]

@patzielinski

I've been thinking that building out the demos would be productive way for me to contribute. I could leverage my tinkering with the CLI to showcase more commands. So when I saw this example policy state in the updated design docs, which you pointed me towards, I figured it could be an opportunity to link back to previously established work.

rootOfTrust:
keys: {R1, R2, R3, P1, P2, P3}
signers:
    rootOfTrust: (2, {R1, R2, R3})
    primary: (2, {P1, P2, P3})

ruleFile: primary
keys: {Alice, Bob, Carol, Helen, Ilda}
rules:
    protect-main-prod: {git:refs/heads/main,
                        git:refs/heads/prod}
        -> (2, {Alice, Bob, Carol})
    protect-ios-app: {file:ios/*}
        -> (1, {Alice})
    protect-android-app: {file:android/*}
        -> (1, {Bob})
    protect-core-libraries: {file:src/*}
        -> (2, {Carol, Helen, Ilda})

ruleFile: protect-ios-app
keys: {Dana, George}
rules:
    authorize-ios-team: {file:ios/*}
        -> (1, {Dana, George})

ruleFile: protect-android-app
keys: {Eric, Frank}
rules:
    authorize-android-team: {file:android/*}
        -> (1, {Eric, Frank})

I figured out the commands on my machine to replicate this policy state with a bash script. But I don't really have a high level feel for what needs to be done to turn this idea into a demo. Could you point me in the right direction?

[patzielinski]

Hi @haotran-california!

I think expanding our demo and showcasing other features of gittuf is a great idea. There are some scripts which demonstrate various scenarios available here: https://github.com/adityasaky/gittuf-ndss-eval.

They're written similar to how the demo is at the moment (both format/style + in Python), so I think that we can somehow combine them with what we have currently in this demo repository.

For the script you added, we can possibly have that as one of multiple "example deployments". I suggest converting it to Python however to allow for cross-platform compatibility.

[patzielinski]

This is a great start! A few items/suggestions.

[haotran-california]

@patzielinski

Thank you for reading through and leaving comments!

I was going down a rabbit hole with Docker and refactoring the Python code instead of addressing the issues. So you saved me a bunch of time. But let me get your thoughts on that last idea.

The idea was to use nested functions to improve readability of the commands. This sub-divides the commands from one big function into several smaller ones. But this breaks away from the style of run_demo too much to be worth the trouble right?

[haotran-california]

@patzielinski

Perhaps I can add images/diagrams to help in turning Aditya's experiments into demos? Experiment 2 has a diagram in the ndss repo but I'm not sure if the other ones are in the whitepaper. I can read through and check.

[patzielinski]

The idea was to use nested functions to improve readability of the commands. This sub-divides the commands from one big function into several smaller ones. But this breaks away from the style of run_demo too much to be worth the trouble right?

I see the value of this but I think it's better to just have each command listed individually in the code to make it easier to read the file in order.

Perhaps I can add images/diagrams to help in turning Aditya's experiments into demos? Experiment 2 has a diagram in the ndss repo but I'm not sure if the other ones are in the whitepaper. I can read through and check.

There are some others in the paper (available here). I can draw up the other figures or you can give it a shot, if you'd like.

Note that you'll need to add the click dependency in the CI run (e.g. add a step that uses pip to install click) in order for CI to be able to test the demo successfully.

[haotran-california]

@patzielinski

Right thanks for clarifying on the nested functions front. If you could draw up the diagrams that would be great! Might be best for me to sit back and follow your lead for a bit.