Skip to content

Home

Jump to bottom Edit New page
Abdullah Sarwar edited this page Dec 15, 2015 · 12 revisions

  1. What Is Totolly Secure?
  2. What Is Totolly Secure For?
  3. What Problem Does Totolly Secure Solve?
  4. What Design Principles Underlie Totolly Secure?
## What Is Totolly Secure?

Totolly Secure is a Version Control System checker.

Version Control systems are generally used to share code and track changes where multiple developers are collaborating on projects that will be updating the same code. The Version Control System allows for contributors to stay up to date with changes made by other contributors when adding new improvements and features.

History of Totolly Secure

Totolly Secure evolved out of the Seattle platform's free and community-driven implementation of TUF, a framework for securing legacy software update systems. Software update systems are vulnerable to many known attacks, including those that can result in clients being compromised or crashed. TUF handles security between the software update system and the client. The Totolly Secure handles security between the developer and the developer's team repository.

The following links provide more context around Totolly Secure and the challenges that it attempts to address:

## What Is Totolly Secure For?

Git is a distributed revision control system. In short, this means that anyone can have a copy of a repository to work on offline, in private. They may commit to their own repository and users may push/pull from each other. A central repository is unnecessary for distributed revision control systems, but may be used to provide an “official” hub that others can work on and clone from. Consequently, this also means that a repository floating around for project X may contain malicious code.

## What Problem Does Totolly Secure Solve?

For most projects there are a number of individuals or organizations that a developer may have inadvertently placed their trust in without fully considering the ramifications of such a decision. It is important to ensure that a commit by someone named "Foo Bar" with the correct e-mail address is actually a commit from that developer, much like it is important to assert that a tag signed with a developer's private key was actually tagged by that developer.

From the project author/maintainer's perspective it is easy to identify the developer in any reasonable manner. For example, if the developer works within the same internal network, perhaps they can trust that pushes from the internal IP are secure. If sending via e-mail, the developer can sign the patch using their GPG key. Unfortunately, these only extend this level of trust to the author/maintainer, not other users.

Therefor, implementing a pattern matching system for the version control system git is crucial for the developers to find any alterations in source code. Theses alterations made by other contributors can have a malicious effect on the program in the form of man-in-the-middle-attacks and many others. Proper code review and signing is the only way to prevent these attacks.

The goal is to enforce code review without making too many changes to the current workflow. Totolly Secure will also check if commits were properly signed, and attempt to verify the signatures.

## Git Background Information

Git Cases

The following are Git actions, concerns, and proposed metadata alterations:

  • Case 1: Commit When a developer commits code to the repository, Github will attach various attributes:

Repository name, Branch name, SHA-1 hash of current commit, SHA-1 hash of previous commit, timestamps of current commit, commit message, commit description, files modified (names only) Toto will use theses attributes to to generate new metadata in order to track changes made by developers.

  • Case 2: Branch When a developer branches, Toto ignores the branch unless the branch leads back to the head via merging. Branching follows the same rules as committing.

  • Case 3: Fork Follows the same rules for Branch.

  • Case 4: Merge When merging two branches, there should be no conflicts (github feature). Each commit between the two branches should have an appropriate signature. A check will be done on the signatures in order to validate the metadata of the merging branch to the parent branch that is not within the user’s personal/forked repository.

  • Case 5: Rebase Assumptions made for implementations plan: Timestamps If timestamp of a commit is newer than that of a following commit, than it was a rebase,

A Seattle Test-Bed Production

Lead Developer | Supporting Developer | Supporting Developer | Supporting Developer | Contributor

Clone this wiki locally