Page MenuHomePhabricator

Automatic auditing should ignore merges
Closed, InvalidPublic


I created a package and set myself as an owner. Then I enabled audit on the package. Now I get automatically notified when files in my package are touched and I haven't reviewed the changes, which is great.

Our team uses a workflow where master collects the next version's changes, but we have branches for maintaining current releases and the commits cascade down to master automatically. This means that every commit to fix a bug in a current release ends up triggering 2 audits - one for the branch in which it is actually made and one for master due to the merge. It would be great if the merges could be automatically ignored (or somehow rolled in) if there's already an audit that exists for the original change being merged.

Event Timeline

anton.vladimirov raised the priority of this task from to Needs Triage.
anton.vladimirov updated the task description. (Show Details)
anton.vladimirov added a subscriber: anton.vladimirov.
chad triaged this task as Wishlist priority.Nov 15 2014, 5:50 AM
chad added a project: Audit.

I'm going to merge this into T3917, which I think is the broadest description of this issue.

Note that if the commit is actually merged, audits won't re-trigger. They only re-trigger if the commit is changed, e.g., via cherry-pick or rebase. These commits should not be categorically ignored because use cases exist for auditing them.

I'm not sure that's the same issue. Broadly, T3917 seems to describe a situation where multiple commits with the same content have different identity due to rebases or cherry-picks. This situation has to do with the exact same commit being re-audited due to merge. I guess it technically possible to review individual commits, then merge them into another branch while also making additional changes, but I would guess that's generally not the case and there doesn't seem to be a lot of use in re-auditing all the changes that have been audited individually, but now as a whole. So in a nutshell what t his is asking for is to only trigger an (automatic) audit on merge commits if:

  • audit doesn't exist for all commits being merged
  • there is a non-empty diff between the top of the merged branch and the top of the merge destination. I.e. there are additional changes made during the merge.

I'm having some difficulty figuring out exactly what this and related reports are describing.

If you think this isn't covered, please file a new report which meets the modern standards of either Contributing Bug Reports or Contributing Feature Requests. In particular, we need step-by-step instructions to precisely recreate an example of the "merge", since I think this term may be getting used to describe a lot of different things between this, T5338, and T3917. A real merge, a --no-ff merge, a cherry-pick, and a rebase are all distinct but I think at least some of them are being conflated.

It is also very unlikely that we will adopt any rules which categorically exclude different commits (i.e., commits A and B have different hashes) from audit based on history or content similarity or any other kind of magic rules, because this opens windows for attackers to avoid audit. If you propose a rule, you should first analyze it from the point of view of an adversarial actor: could they use the rule you propose to slip evil code into the repository without audit? If so, the rule is not likely to be acceptable to the upstream.

It seems like T3917 is asking for content similarity search (or something similar) as you mention, although falls short of automatic exclusion rules. I don't think this case is covered by T3917, but I'll file another bug, which hopefully will be more descriptive, and I'll let you be the judge of that.

epriestley changed the task status from Duplicate to Invalid.Jan 18 2017, 8:44 PM

On re-reading T3917 I agree it has approximately nothing to do with this, but see also T5338, where I think I go through a flow like this and it doesn't trigger an audit.

I'm just going to relabel this as "Invalid" since I don't think I understand what's going on here. See previous comment for ways to move forward.