Analyze exceptions to the `git fsck` command
Problem
As more customers import legacy repositories into GitLab, they may run into issues with malformed commit messages. At present, we have a set of exceptions to git fsck
that can be configured on a per-instance basis. Therefore, our self-managed users can control which failures are allowed. However, for our SaaS offering, we currently have a standard set of allowed failures that may be more restrictive than necessary.
Analysis required
There are two aspects to this analysis that we need to consider before recommending changes to the GitLab.com platform's configuration around git fsck
failures. We should analyze all options here for the following two items:
- Does allowing the error open us to an abuse or attack vector? If so, we cannot allow the exception.
- If allowing the error is allowable from a security standpoint, we must also validate that allowing the exception does not have a downstream impact. For example, allowing malformed commit email addresses may not pose an attack vector, but may cause issues to other areas within GitLab that assume that all email addresses are properly formed.
Once we've completed this analysis, we should suggest an updated configuration for the GitLab.com configuration, as well as document our decisions publicly to avoid any further questions around this topc.