Diffs are most useful by a reviewer to provide a 2nd pair of eyes for outbound pushes. After a review process has concluded, the actual diff content is no longer interesting from a proxy or audit perspective. Persisting flagged content which may contain live production secrets makes git proxy a sensitive internal target for exploitation. Some ideas:
- Automatically redacted diffs once they are finished processing in real time.
- PENDING -> APPROVED -> FORWARDED, trigger redaction once push is sent
- REJECTED -> ACKNOWLEDGED (new status - a user has reviewed the content, acknowledged the content and no longer needs to review the failed push)
- Attach a TTL when a diff may expire and scrub it/zero it out on an interval as a scheduled background task.
- An on demand function in the admin page, a push record can be selected & scrubbing done in response to a user request.
Git is the source of truth for changes both from a git client and upstream POV. The proxy already saves the specific commit shas (which may become unreachable in a future state but unlikely - most is retained in version control) and the refs being pushed (branch/tag). Need to decide on how much "auditability" one gains from having the raw pushed content saved in an external database.
I personally lean towards option 1 as the most aggressive and secure mode. It's a trade off on visibility and history - but that's what the git repo(s) should be used for when tracing a changeset throughout its lifetime.
Diffs are most useful by a reviewer to provide a 2nd pair of eyes for outbound pushes. After a review process has concluded, the actual diff content is no longer interesting from a proxy or audit perspective. Persisting flagged content which may contain live production secrets makes git proxy a sensitive internal target for exploitation. Some ideas:
Git is the source of truth for changes both from a git client and upstream POV. The proxy already saves the specific commit shas (which may become unreachable in a future state but unlikely - most is retained in version control) and the refs being pushed (branch/tag). Need to decide on how much "auditability" one gains from having the raw pushed content saved in an external database.
I personally lean towards option 1 as the most aggressive and secure mode. It's a trade off on visibility and history - but that's what the git repo(s) should be used for when tracing a changeset throughout its lifetime.