diff options
Diffstat (limited to 'contractor.md')
| -rw-r--r-- | contractor.md | 24 |
1 files changed, 8 insertions, 16 deletions
diff --git a/contractor.md b/contractor.md index 3b18b0b..430bd87 100644 --- a/contractor.md +++ b/contractor.md @@ -15,7 +15,8 @@ fundamentally the same. The process is roughly as follows: * run the software, perhaps as part of unit testing When the software is run, even if only a small unit of it, it can do -anything that the person running the build can do, in principle: +anything that the person running the build can do. For example, it can +do any and all of the following, unless guarded against: * delete files * modify files @@ -34,8 +35,6 @@ they work with don't do any of that. In both cases, they may be wrong: mistakes happen. It's a well-guarded secret among programmers that they sometimes, even if rarely, make catastrophic mistakes. -**FIXME**: reference the bug in Debian that removed the ld.so symlink - Accidents aside, mayhem and chaos may be intentional. Your own project may not have malware, and you may have vetted all your dependencies, and you trust them. But your dependencies have dependencies, which @@ -43,7 +42,7 @@ have further dependencies, which have dependencies of their own. You'd need to vet the whole dependency tree. Even decades ago, in the 1990s, this could easily be hundreds of thousands of lines of code, and modern systems a much larger. Note that build tools are themselves -dependencies, as is the whole operating system. Any code that is used +dependencies, as is the whole operating system. Any code that is invoked in the build process is a dependency. How certain are you that you can spot malicious code that's @@ -60,7 +59,7 @@ This risk affects every operating system and every programming language. The degree in which it exists varies, a lot. Some programming language ecosystems seem more vulnerable than others: the nodejs/npm one, for example, values tiny and highly focused packages, -which leads to immense dependency trees. The direct or indirect +which leads to immense dependency trees. The more direct or indirect dependencies there are, the higher the chance that one of them turns out to be bad. @@ -165,7 +164,7 @@ These requirements stem from the threat model above. * **DefaultBuilder**: The Contractor SHOULD be easy to set up and to use. It should not require extensive configuration. Running a build - should be as easy as running **make**(1) on the commadnd line. It + should be as easy as running **make**(1) on the command line. It should be feasible to expect developers to use the Contractor for their normal development work. @@ -244,9 +243,6 @@ This high-level design is chosen for the following reasons: technologies, although it doesn't do much to protect against virtualisation or hardware vulnerabilities (**HostProtection**) -**HOWEVER**, this architecture needs improvements, which will happen -soon. The current implementation is a proof of concept only. - ## Build process The architecture leads to a build process that would work roughly like @@ -268,7 +264,7 @@ this: * command line tool reports to the developer build success or failure and where build log and build artifacts are -## Implementation sketch +## Implementation sketch (FIXME: update) This is the current status, to be improved upon. @@ -455,20 +451,16 @@ abstract: | further things. It is becoming infeasible to vet the whole set of software running during a build. If a build includes running local tests (unit tests, some integration tests), the problem gets worse - in magintude, if not quality. + in magnitude, if not quality. Some software ecosystems are especially vulnerable to this (nodejs, Python, Ruby, Go, Rust), but it's true for anything that has dependencies on any code from outside its own code base, and even if all the dependencies come from a trusted source, such as the - operating system vendor. + operating system vendor or a Linux distribution. The Contractor is an attempt to be able to build software securely, by leveraging virtual machine technology. It attempts to be secure, convenient, and reasonably efficient. - The Contractor is not a replacement for a Continuous Integration - engine, but its technology will hopefully one day become part of the - Ick CI engine. - ... |