/usr/share/doc/fdroidserver/html/html

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- This manual is for the F-Droid repository server tools.

Copyright (C) 2010, 2011, 2012, 2013 Ciaran Gultnieks

Copyright (C) 2011 Henrik Tunedal, Michael Haas, John Sullivan

Copyright (C) 2013 David Black

Copyright (C) 2013, 2014 Daniel Martí

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License". -->
<!-- Created by GNU Texinfo 5.2, http://www.gnu.org/software/texinfo/ -->
<head>
<title>F-Droid Server Manual: Build Server</title>

<meta name="description" content="F-Droid Server Manual: Build Server">
<meta name="keywords" content="F-Droid Server Manual: Build Server">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link href="index.html#Top" rel="start" title="Top">
<link href="Index.html#Index" rel="index" title="Index">
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
<link href="index.html#Top" rel="up" title="Top">
<link href="Signing.html#Signing" rel="next" title="Signing">
<link href="Update-Processing.html#Update-Processing" rel="prev" title="Update Processing">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.smallquotation {font-size: smaller}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
div.indentedblock {margin-left: 3.2em}
div.lisp {margin-left: 3.2em}
div.smalldisplay {margin-left: 3.2em}
div.smallexample {margin-left: 3.2em}
div.smallindentedblock {margin-left: 3.2em; font-size: smaller}
div.smalllisp {margin-left: 3.2em}
kbd {font-style:oblique}
pre.display {font-family: inherit}
pre.format {font-family: inherit}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
pre.smalldisplay {font-family: inherit; font-size: smaller}
pre.smallexample {font-size: smaller}
pre.smallformat {font-family: inherit; font-size: smaller}
pre.smalllisp {font-size: smaller}
span.nocodebreak {white-space:nowrap}
span.nolinebreak {white-space:nowrap}
span.roman {font-family:serif; font-weight:normal}
span.sansserif {font-family:sans-serif; font-weight:normal}
ul.no-bullet {list-style: none}
-->
</style>


</head>

<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
<a name="Build-Server"></a>
<div class="header">
<p>
Next: <a href="Signing.html#Signing" accesskey="n" rel="next">Signing</a>, Previous: <a href="Update-Processing.html#Update-Processing" accesskey="p" rel="prev">Update Processing</a>, Up: <a href="index.html#Top" accesskey="u" rel="up">Top</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Index.html#Index" title="Index" rel="index">Index</a>]</p>
</div>
<hr>
<a name="Build-Server-1"></a>
<h2 class="chapter">9 Build Server</h2>

<p>The Build Server system isolates the builds for each package within a clean,
isolated and secure throwaway virtual machine environment.
</p>
<a name="Overview-2"></a>
<h3 class="section">9.1 Overview</h3>

<p>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 (&quot;you have updates available&quot;) fashion.
</p>
<p>Assume that an upstream source repository is compromised. A small selection
of things that an attacker could do in such a situation:
</p>
<ol>
<li> Use custom Ant build steps to execute virtually anything as the user doing
the build.
</li><li> Access the keystore.
</li><li> Modify the built apk files or source tarballs for other applications in the
repository.
</li><li> Modify the metadata (which includes build scripts, which again, also includes
the ability to execute anything) for other applications in the repository.
</li></ol>

<p>Through complete isolation, the repurcussions are at least limited to the
application in question. Not only is the build environment fresh for each
build, and thrown away afterwards, but it is also isolated from the signing
environment.
</p>
<p>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.
</p>
<p>All this is in addition to the obvious advantage of having a standardised
and completely reproducible environment in which builds are made. Additionally,
it allows for specialised custom build environments for particular
applications.
</p>
<a name="Setting-up-a-build-server"></a>
<h3 class="section">9.2 Setting up a build server</h3>

<p>In addition to the basic setup previously described, you will also need
a Vagrant-compatible Debian Testing base box called &rsquo;testing32&rsquo; (or testing64
for a 64-bit VM, if you want it to be much slower, and require more disk
space).
</p>
<p>You can use a different version or distro for the base box, so long as you
don&rsquo;t expect any help making it work. One thing to be aware of is that
working copies of source trees are moved from the host to the guest, so
for example, having subversion v1.6 on the host and v1.7 on the guest
would fail.
</p>
<p>Unless you&rsquo;re very trusting. you should create one of these for yourself
from verified standard Debian installation media. However, you could skip
over the next few paragraphs (and sacrifice some security) by downloading
<a href="https://f-droid.org/testing32.box">https://f-droid.org/testing32.box</a>.
</p>
<p>Documentation for creating a base box can be found at
<a href="http://docs.vagrantup.com/v1/docs/base_boxes.html">http://docs.vagrantup.com/v1/docs/base_boxes.html</a>.
</p>
<p>In addition to carefully following the steps described there, you should
consider the following:
</p>
<ol>
<li> It is advisable to disable udev network device persistence, otherwise any
movement of the VM between machines, or reconfiguration, will result in
broken networking.

<p>For a Debian/Ubuntu default install, just
<code>touch /etc/udev/rules.d/75-persistent-net-generator.rules</code> to turn
off rule generation, and at the same time, get rid of any rules it&rsquo;s
already created in <code>/etc/udev/rules.d/70-persistent-net.rules</code>.
</p></li><li> Unless you want the VM to become totally inaccessible following a failed
boot, you need to set <code>GRUB_RECORDFAIL_TIMEOUT</code> to a value other than
-1 in <code>/etc/grub/default</code> and then run <code>update-grub</code>.
</li></ol>


<p>With this base box available, you should then create <code>makebs.config.py</code>,
using <code>makebs.config.sample.py</code> as a reference - look at the settings and
documentation there to decide if any need changing to suit your environment.
There is a path for retrieving the base box if it doesn&rsquo;t exist, and an apt
proxy definition, both of which may need customising for your environment.
You can then go to the <code>fdroidserver</code> directory and run this:
</p>
<div class="example">
<pre class="example">./makebuildserver
</pre></div>

<p>This will take a long time, and use a lot of bandwidth - 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 you have a
working build server image, if the recipes change (e.g. when packages need
to be added) you can just run that script again and the existing one will
be updated in place.
</p>
<p>The main sdk/ndk downloads will automatically be cached to speed things
up the next time, but there&rsquo;s no easy way of doing this for the longer
sections which use the SDK&rsquo;s <code>android</code> tool to install platforms,
add-ons and tools. However, instead of allowing automatic caching, you
can supply a pre-populated cache directory which includes not only these
downloads, but also .tar.gz files for all the relevant additions. If the
provisioning scripts detect these, they will be used in preference to
running the android tools. For example, if you have
<code>buildserver/addons/cache/platforms/android-19.tar.gz</code> that will be
used when installing the android-19 platform, instead of re-downloading it
using <code>android update sdk --no-ui -t android-19</code>.
</p>
<p>Once it&rsquo;s complete you&rsquo;ll have a new base box called &rsquo;buildserver&rsquo; which is
what&rsquo;s used for the actual builds. You can then build packages as normal,
but with the addition of the <code>--server</code> flag to <code>fdroid build</code> to
instruct it to do all the hard work within the virtual machine.
</p>
<p>The first time a build is done, a new virtual machine is created using the
&rsquo;buildserver&rsquo; box as a base. A snapshot of this clean machine state is saved
for use in future builds, to improve performance. You can force discarding
of this snapshot and rebuilding from scratch using the <code>--resetserver</code>
switch with <code>fdroid build</code>.
</p>
<hr>
<div class="header">
<p>
Next: <a href="Signing.html#Signing" accesskey="n" rel="next">Signing</a>, Previous: <a href="Update-Processing.html#Update-Processing" accesskey="p" rel="prev">Update Processing</a>, Up: <a href="index.html#Top" accesskey="u" rel="up">Top</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Index.html#Index" title="Index" rel="index">Index</a>]</p>
</div>



</body>
</html>
fdroidserver 0.2.1-4 / usr / share / doc / fdroidserver / html / html_node / Build-Server.html
