Migrating Nmap to Git

From SecWiki
Jump to: navigation, search

Nmap currently uses Subversion for change control. Several developers have expressed desire to use Git instead. This page intends to serve as a discussion board for this issue.

Open questions

  • How would switching to Git impact releases?
  • What are some concrete examples of places where SVN doesn't work? Can Git really fix these?
  • What development model would Nmap use after switching? Single branch, twin branch, gitworkflows?

Discussion points

Some of this discussion is happening on the Talk page, so check there, too.

Private branches

  • Currently, users can create private SVN branches which reside on the server. These are used by GSoC students to demonstrate work to mentors, and by core developers to try out new ideas without merging into the trunk.
    • Git branching is cheaper than SVN in terms of disk space and performance. Decentralization means that these branches will not necessarily be public, depending on how hosting and workflows will be arranged.
  • A pull request is a bit more accessible then the mailing list. Especially for developers that are not already on the mailing list. Features and scripts for one-off tasks are much more likely to end up in a pull request then a user signing up to the mailing list to post a patch.

Hosting

  • Currently, the Nmap project hosts its own SVN server. Git is decentralized, so it doesn't need a central server, but it could be helpful. Some ideas:
    • Third-party hosting: GitHub or similar. This would alleviate some of the backend maintenance burden, but it involves giving up some control. Git's decentralized architecture means that every developer has a copy of the whole repository, though, so the hosting provider couldn't destroy Nmap's source.
      • A more serious concern would be the alteration of the source, such as the injection of a backdoor. This can be obviated by signed commits, which would be a good practice no matter who is hosting the source: http://mikegerwitz.com/papers/git-horror-story (recall that Nmap's hosting provider has been compromised in the past).
    • Nmap-hosted Git: Git can use several transports (HTTPS, read-only git protocol, SSH), so a public read-only server could be used, with some private mechanism for commits (see Authentication). See also GitLab[1] which attempts to replicate much of GitHub but is OSS and self-hosted.

Authentication

  • Currently, SVN access is password-protected. These passwords are not always safely handled (my system stores it plaintext in home directory by default). Git can use SSH key authentication or username-password. [To be fair, you can setup svn to be exclusively accessible via ssh w/ PPK.]
    • There are add-on packages that can manage authentication for Git. Gitosis is one.
    • Third-party hosting could provide authentication, but some devs have objected to having yet another credential to manage.

Migrating

  • Migrating VCSs can be painful. The Metasploit project migrated from SVN to Git (on GitHub) within the last couple years, so they could probably help us out with the messier details.

ESR has a tool called reposurgeon[2] designed for lossless conversion.

Bug tracking

  • This is technically a different discussion, but implementing a bug tracker (also favored by several devs) could lock us in to whatever VCS we are using at the time. Metasploit project is currently split between 2 different bug trackers, so they may have opinions that are relevant.
    • Some third-party Git hosts have bug trackers built-in, but they may not meet every need.
    • GitLab (mentioned in Hosting section) has issue tracking.

Continuous Integration

  • If there was a move to Github then it would be simple to implement something like travis-ci adding continuous integration. This would mean simple errors can be captured by the committer, and a clean build can be a prerequisite to merging a change.

How people do it now with git-svn

The instructions at Using Git with Nmap get you most of the benefits of git. Downsides:

  1. Two different clones will have different commit hashes for the same commit.
  2. You don't have tags, e.g. for releases, on the server that you can rely on.
  3. Getting all the nmap-exp branches is fiddly because they are at different directory depths.

Votes

In addition to the above discussion, please leave your name (~~~~) below your vote below:

Stay with SVN

  • Your name here

Use Git

  • Bonsaiviking (talk) 11:37, 6 December 2013 (CST)
  • Sophron (talk) 11:40, 6 December 2013 (CST)
  • Todb (talk) 12:06, 6 December 2013 (CST) - incidentally, happy to help, since I did some of the heavy lifting on the SVN -> Git thing on Metasploit.
  • Balder (talk) 18:19, 6 December 2013 (UTC)
  • Batrick (talk) 21:28, 8 December 2013 (UTC)
  • Henri (talk) 08:53, 9 December 2013 (UTC)
  • D33tah (talk) 15:29, 12 December 2013 (CST)

Other

  • Your name and explanation here

See Also

Retrieved from "https://secwiki.org/mediawiki/index.php?title=Migrating_Nmap_to_Git&oldid=1568"