-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add initial / PoC gittuf remote handling protocol #411
base: main
Are you sure you want to change the base?
Conversation
I think this is ready for a first round of feedback! |
Note: as of 13e4a00, the transport doesn't work. I'm working on making it more resilient to different local conditions. |
Things work again (and are more robust than before). I also tested out some trivial force pushes / fetches and they work as well, though we will need #369 in some form to mark rsl entries for rebased comments as skipped. |
A feature that would work well with the transport, since it controls all pushes and pulls, is caching the latest verified RSL entry in a specific reference, allowing only the user's signing key to commit to it. This approach would significantly speed up verification. After the initial pull from the main repository, gittuf's impact on the user experience would be minimal, even with large repositories, as long as users pull from their remote regularly. |
Yeah, we definitely need that (#245). This and a couple other things make me wonder if we want to carve out |
ec5806b
to
7198832
Compare
the code is still a mess and i want to work on cleaning things up, but the functionality seems fairly stable. This hasn't switched on gittuf verify-ref yet, I'm waiting on some other changes to land. In the meantime, seeking feedback and opinions on the best way to structure the curl and ssh helpers! |
8f7af5a
to
2b1540f
Compare
Impressive work, Aditya! Your code walkthrough the other day was very helpful, but I must admit, I still find it hard to navigate by myself. Maybe you could try to better separate (1) main flow, (2) transport, and (3) gittuf logic. IIUC (1) is controlled by the messages received from and sent to the git parent process, where stdin/stdout are the read and write message queues. By (2) I mean the messages sent to and received from the http transport (curl) or ssh client (ssh) child processes spawned by us, with similar queues. And finally, (3) would be the interposed gittuf logic this feature is actually about, i.e. fetching, verifying, creating and pushing additional refs. It would be extremely helpful to see at one glance the expected messages in both directions and on both ends, and maybe even their typical sequence. If this is not possible in code, it could be done in documentation. What could be done in code, would be to reduce the amount of nesting. In that regard, I have one specific question: Is the internal |
598c78f
to
fd99ef3
Compare
Signed-off-by: Aditya Sirish <aditya@saky.in>
fd99ef3
to
01007b7
Compare
@lukpueh and I have discussed how to improve this package and make it more maintainable (see his comment above for the general improvements). I propose we do this iteratively, separately, and for now go ahead and merge this as an alpha implementation of the transport. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this doesn't affect people who don't explicitly opt-in to using the transport, I think we can indeed go ahead and merge this in. I can open an issue about this being in alpha and needing improvements.
Side note: we should also probably add something to the docs discussing/describing/detailing this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good. I haven't run it; I have just one suggestion. Thank you!
+1 on adding docs detailing that this is an alpha feature, and also explaining the current functionalities it adds on top of git, maybe somthing like a list of commands that have additional calls to gittuf, and what those calls are/do.
// var rslTip string | ||
// cmd := exec.Command("git", "--git-dir", gitDir, "rev-parse", rsl.Ref) //nolint:gosec | ||
// rslTipB, err := cmd.Output() | ||
// if err == nil { | ||
// rslTip = string(bytes.TrimSpace(rslTipB)) | ||
// } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this supposed to still be here, or is this something that should be uncommented later on?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the latter
Suggestions on the best place to put the docs? We don't get nice auto-gen in docs/cli like with the main cmd package. |
Edit 2024-05-24: I think the transport is at least at a proof of concept level now. Current status:
There are a bunch of TODOs and FIXMEs in the code. There's also a bunch of repeated code between the curl backend and the ssh backend that we can maybe clean up. Things that we also want to do:
Play with it:
git clone gittuf::git@github.com:gittuf/gittuf
for ssh,git clone gittuf::https://github.com/gittuf/gittuf
for httpsh/t @SantiagoTorres for insights on how this works!