Page MenuHomePhabricator

Stop populating or updating working copies in observed Mercurial repositories
ClosedPublic

Authored by epriestley on Aug 11 2017, 12:49 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Mar 26, 2:39 PM
Unknown Object (File)
Tue, Mar 26, 12:33 PM
Unknown Object (File)
Thu, Mar 21, 12:24 AM
Unknown Object (File)
Mar 16 2024, 9:41 AM
Unknown Object (File)
Mar 1 2024, 8:33 PM
Unknown Object (File)
Mar 1 2024, 2:55 AM
Unknown Object (File)
Feb 22 2024, 11:37 AM
Unknown Object (File)
Feb 21 2024, 10:19 AM
Subscribers

Details

Summary

Ref T12961. Fixes T4416. Currently, for observed Mercurial repositories, we build a working copy with pull -u (for "update").

This should be unnecessary, and we don't do it for hosted Mercurial repositories. We also stopped doing it years ago for Git repositories. We also don't clone Mercurial repositories with a working copy.

It's possible something has slipped through the cracks here so I'll hold this until after the release cut, but I believe there are no actual technical blockers here.

Test Plan
  • Observed a public Mercurial repository on Bitbucket.
  • Let it import.
  • Browsed commits, branches, file content, etc., without any apparent issues.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Aug 11 2017, 12:50 AM
This revision was automatically updated to reflect the committed changes.

I'm cherry-picking and hotfixing this because you can use an Mercurial repository with a Git or Subversion SSH subrepository to execute the attack across version control systems via hg pull -u. Mercurial does not appear to pass ui.ssh to GIT_SSH so we lose the protection offered by ssh-connect once we cross the VCS boundary.