Because of how Git tracks history, it's better suited for tracking a
series of small repositories, as opposed to one large one
- [#]_. Furthermore, most pre-existing tools and techniques for
- dealing with Debian packages in Git repositories (such as
- git-buildpackage_ or `VCS location information`_) are designed
- exclusively for this case.
+ [#]_. Furthermore, most preexisting tools and techniques for dealing
+ with Debian packages in Git repositories (such as git-buildpackage_
+ or `VCS location information`_) are designed exclusively for this
+ case.
* Synchronization between Git and APT repositories.
For the Invirt_ project's use of the Invirtibuilder, we adapted our
existing configuration mechanism. Our configuration file consists of a
-singls YAML_ file. Here is the snippet of configuration we use for our
+single YAML_ file. Here is the snippet of configuration we use for our
build configuration::
build:
using Git directly. However, we realized that what we actually wanted
was a separate build queue where each build request was handled and
processed independently of any requests before or after it. It's not
-possible to have these semantics using Git as a signalling mechanism
+possible to have these semantics using Git as a signaling mechanism
without breaking standard assumptions about how remote Git
repositories work.
Git repository. The remctl daemon then calls a script which validates
the build and adds it to the build queue. Because of the structure of
remctl's ACLs, we are able to have different ACLs depending on which
-pocket the build is destined for. This allows us to fulfil our design
+pocket the build is destined for. This allows us to fulfill our design
goal of having different ACLs for different pockets.
For simplicity, the queue itself is maintained as a directory of
Invirtibuilder to be used for both our trusted production environment
and our untrusted development environment. In order to be trusted for
the production environment, the Invirtibuilder needs to run in the
-production environment as well. However, it would be disasterous if
+production environment as well. However, it would be disastrous if
access to the development environment allowed a developer to insert
malicious packages into the production apt repository.
(e.g. qemubuilder_). However, we decided that the security risk didn't
justify the additional implementation effort or runtime overhead.
+Future Directions
+=================
+
+While the Invirtibuilder was written as a tool for the Invirt_
+project, taking advantage of infrastructure specific to Invirt, it was
+designed with the hope that it could one day be expanded to be useful
+outside of our infrastructure. Here we outline what we believe the
+next steps for development of the Invirtibuilder are.
+
+One deficiency that affects Invirt_ development already is the
+assumption that all packages are Debian-native [#]. Even for packages
+which have a non-native version number, the Invirtibuilder will create
+a Debian-native source package when the package is exported from Git
+as part of the `Build Execution`_. Correcting this requires a means to
+find and extract the upstream tarball from the Git repository. This
+could probably be done by involving the pristine-tar_ tool.
+
+The Invirtibuilder is currently tied to the configuration framework
+developed for the Invirt_ project. To be useful outside of Invirt, the
+Invirtibuilder needs its own, separate mechanism for providing and
+parsing configuration. It should not be difficult to use a separate
+configuration file but a similar YAML configuration mechanism for the
+Invirtibuilder. And of course, as part of that process, filesystem
+paths and the like that are currently hard-coded should be replaced
+with configuration options.
+
+The Invirtibuilder additionally relies on the authentication and
+authorization mechanisms used for Invirt_. Our RPC protocol of choice,
+remctl_, requires a functional Kerberos environment for
+authentication, limiting its usefulness for one-off projects not
+associated with an already existing Kerberos realm. We would like to
+provide support for some alternative RPC mechanism—possibly
+ssh. Additionally, there needs to be some way to expand the build ACLs
+for each pocket that isn't tied to Invirt's authorization
+framework. One option would be providing an executable in the
+configuration that, when passed a pocket as a command-line argument,
+prints out all of the principals that should have access to that
+pocket.
+
.. _config-package-dev: http://debathena.mit.edu/config-packages
.. _fakeroot: http://fakeroot.alioth.debian.org/
.. _git-buildpackage: https://honk.sigxcpu.org/piki/projects/git-buildpackage/
.. _grsecurity: http://www.grsecurity.net/
.. _Invirt: http://invirt.mit.edu
+.. _pristine-tar: http://joey.kitenet.net/code/pristine-tar/
.. _qemubuilder: http://wiki.debian.org/qemubuilder
.. _remctl: http://www.eyrie.org/~eagle/software/remctl/
.. _SIPB: http://sipb.mit.edu
create new tags for builds on pockets with
``allow_backtracking`` set to ``True`` either.
.. [#] http://kerneltrap.org/Linux/Abusing_chroot
+.. [#] http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#native_vs_non_native
projects / invirt/packages/invirt-dev.git / blobdiff