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)
Thu, Jul 25, 3:06 PM
Unknown Object (File)
Mon, Jul 22, 11:46 AM
Unknown Object (File)
Sun, Jul 21, 12:04 PM
Unknown Object (File)
Wed, Jul 17, 12:26 PM
Unknown Object (File)
Sat, Jul 13, 4:05 AM
Unknown Object (File)
Wed, Jul 10, 12:57 PM
Unknown Object (File)
Mon, Jul 8, 1:43 AM
Unknown Object (File)
Mon, Jul 1, 2:24 PM
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.