From: Ciaran Gultnieks Date: Fri, 24 Feb 2012 18:19:52 +0000 (+0000) Subject: Build server docs (partial) X-Git-Tag: 0.1~921 X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=commitdiff_plain;h=2d91c30806456674e75368167b302015f25c2d25;p=fdroidserver.git Build server docs (partial) --- diff --git a/README.buildserver b/README.buildserver deleted file mode 100644 index 2c2d83b4..00000000 --- a/README.buildserver +++ /dev/null @@ -1,16 +0,0 @@ - -Integrating the build server setup into the main scripts is a work in progress. Some things may -not work properly yet. Talk to CiaranG if you're trying to use this and have problems. - -Setting up a build server: - -1. Install VirtualBox, vagrant and vagrant-snap -2. Create (or get - ask CiaranG, or wait until I replace this with a download link!) a standard - Debian Squeeze vagrant-compatible base box called 'debian6-32' -3. Run makebuildserver.sh. This will take a long time. The end result is a new base box called - 'buildserver'. - -You should now be able to use the --server option on build.py and builds will -take place in the clean, secure, isolated environment of a fresh virtual -machine for each app built. - diff --git a/docs/fdroid.html b/docs/fdroid.html index b65217df..f72be7d0 100644 --- a/docs/fdroid.html +++ b/docs/fdroid.html @@ -63,6 +63,11 @@ Copyright (C) 2011 Henrik Tunedal, Michael Haas, John Sullivan
  • 6.13 Disabled
  • 6.14 Requires Root
    • +
  • 7 Build Server +
  • Appendix A GNU Free Documentation License
  • Index
    • @@ -101,8 +106,9 @@ Free Documentation License".
  • Simple Binary Repository
  • Building Applications
  • Metadata -
  • GNU Free Documentation License -
  • Index +
  • Build Server +
  • GNU Free Documentation License +
  • Index
    @@ -339,7 +345,7 @@ where normally it would be completely ignored.

    -Next: , +Next: , Previous: Building Applications, Up: Top @@ -783,11 +789,83 @@ Set this optional field to "Yes" if the application requires root privileges to be usable. This lets the client filter it out if the user so desires. +
    + +

    +Next: , +Previous: Metadata, +Up: Top + +
    + +

    7 Build Server

    + +

    The Build Server system isolates the builds for each package within a clean, +isolated and secure throwaway virtual machine environment. + +

    7.1 Rationale

    + +

    Building applications in this manner on a large scale, especially with the +involvement of automated and/or unattended processes, could be considered +a dangerous pastime from a security perspective. This is even more the case +when the products of the build are also distributed widely and in a +semi-automated ("you have updates available") fashion. + +

    Assume that an upstream source repository is compromised. A small selection +of things that an attacker could do in such a situation: + +

      +
    1. Use custom ant build steps to execute virtually anything as the user doing +the build. +
    2. Access the keystore. +
    3. Modify the built apk files or source tarballs for other applications in the +repository. +
    4. Modify the metadata (which includes build scripts, which again, also includes +the ability to execute anything) for other applications in the repository. +
    + +

    Through complete isolation, the repurcussions are at least limited to the +application in question. + +

    Aside from security issues, there are some applications which have strange +requirements such as custom versions of the NDK. It would be impractical (or +at least extremely messy) to start modifying and restoring the SDK on a +multi-purpose system, but within the confines of a throwaway single-use +virtual machine, anything is possible. + +

    7.2 Setting up a build server

    + +

    Integrating the build server setup into the main scripts is a work in progress. +Some things may not work properly yet. Talk to CiaranG if you're trying to use +this and have problems. + +

    In addition to the basic setup sets previously described, you will also need +a Vagrant-compatible Debian Squeeze base box called 'debian6-32'. You can +create one of these for yourself from standard Debian installation media, as +the specification for what's required to be Vagrant-compatible is very well +defined. This is the sensible and secure way to do it, since you know what's +in it. If you insist on taking a shortcut, ask CiaranG for his on the forum +or in IRC. + +

    With this base box installed, you can then do: + +

         ./makebuildserver.sh
+
    +

    This will take a long time - most of it spent installing the necessary parts +of the Android SDK for all the various platforms. Luckily you only need to +do it occasionally. + +

    Once it's complete you'll have a new base box called 'buildserver' which is +what's used for the actual builds. You can then build packages as normal, +but with the addition of the --server flag to build.py to +instruct it to do all the hard work within the virtual machine, which is +reset to a completely clean state for every package built. +

    Next: , -Previous: Metadata, +Previous: Build Server, Up: Top
    diff --git a/docs/fdroid.texi b/docs/fdroid.texi index 83af33f9..816ca4f7 100644 --- a/docs/fdroid.texi +++ b/docs/fdroid.texi @@ -45,6 +45,7 @@ Free Documentation License". * Simple Binary Repository:: * Building Applications:: * Metadata:: +* Build Server:: * GNU Free Documentation License:: * Index:: @end menu @@ -673,6 +674,78 @@ Set this optional field to "Yes" if the application requires root privileges to be usable. This lets the client filter it out if the user so desires. + +@node Build Server +@chapter Build Server + +The Build Server system isolates the builds for each package within a clean, +isolated and secure throwaway virtual machine environment. + +@section Rationale + +Building applications in this manner on a large scale, especially with the +involvement of automated and/or unattended processes, could be considered +a dangerous pastime from a security perspective. This is even more the case +when the products of the build are also distributed widely and in a +semi-automated ("you have updates available") fashion. + +Assume that an upstream source repository is compromised. A small selection +of things that an attacker could do in such a situation: + +@enumerate +@item +Use custom ant build steps to execute virtually anything as the user doing +the build. +@item +Access the keystore. +@item +Modify the built apk files or source tarballs for other applications in the +repository. +@item +Modify the metadata (which includes build scripts, which again, also includes +the ability to execute anything) for other applications in the repository. +@end enumerate + +Through complete isolation, the repurcussions are at least limited to the +application in question. + +Aside from security issues, there are some applications which have strange +requirements such as custom versions of the NDK. It would be impractical (or +at least extremely messy) to start modifying and restoring the SDK on a +multi-purpose system, but within the confines of a throwaway single-use +virtual machine, anything is possible. + +@section Setting up a build server + +Integrating the build server setup into the main scripts is a work in progress. +Some things may not work properly yet. Talk to CiaranG if you're trying to use +this and have problems. + +In addition to the basic setup sets previously described, you will also need +a Vagrant-compatible Debian Squeeze base box called 'debian6-32'. You can +create one of these for yourself from standard Debian installation media, as +the specification for what's required to be Vagrant-compatible is very well +defined. This is the sensible and secure way to do it, since you know what's +in it. If you insist on taking a shortcut, ask CiaranG for his on the forum +or in IRC. + +With this base box installed, you can then do: + +@example +./makebuildserver.sh +@end example + +This will take a long time - most of it spent installing the necessary parts +of the Android SDK for all the various platforms. Luckily you only need to +do it occasionally. + +Once it's complete you'll have a new base box called 'buildserver' which is +what's used for the actual builds. You can then build packages as normal, +but with the addition of the @code{--server} flag to @code{build.py} to +instruct it to do all the hard work within the virtual machine, which is +reset to a completely clean state for every package built. + + @node GNU Free Documentation License @appendix GNU Free Documentation License