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
F14078834: D18390.id44201.diff
Fri, Nov 22, 5:24 AM
Unknown Object (File)
Wed, Nov 20, 10:33 AM
Unknown Object (File)
Tue, Nov 12, 3:01 PM
Unknown Object (File)
Oct 18 2024, 6:23 PM
Unknown Object (File)
Oct 16 2024, 1:30 AM
Unknown Object (File)
Oct 14 2024, 9:45 PM
Unknown Object (File)
Oct 14 2024, 9:26 PM
Unknown Object (File)
Sep 20 2024, 12:19 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.