Initial draft of SB Sprint text
authorJoerg Jaspert <joerg@debian.org>
Mon, 9 Apr 2018 08:49:15 +0000 (10:49 +0200)
committerJoerg Jaspert <joerg@debian.org>
Mon, 9 Apr 2018 08:49:15 +0000 (10:49 +0200)
_posts/2018-04-09-debian-secureboot-sprint-2018.md [new file with mode: 0644]

diff --git a/_posts/2018-04-09-debian-secureboot-sprint-2018.md b/_posts/2018-04-09-debian-secureboot-sprint-2018.md
new file mode 100644 (file)
index 0000000..2e11ba3
--- /dev/null
@@ -0,0 +1,76 @@
+---
+layout: post
+title: Debian SecureBoot Sprint 2018
+categories:
+- debian
+- ftpmaster
+date: '2018-04-09 10:01:13 +0200'
+---
+
+Just gave back the keys to [Office Factory
+Fulda](http://www.office-factory.net), and despite the name, noone is
+actually building offices there - they are a offering office space and
+meeting rooms for people that don't need the hassle of a fully
+self-owned space. We had one of their rooms from Thursday, 4th April
+to Sunday, 08th April and left a pretty positive impression, so are
+welcome again for future sprints.
+
+The goal of this sprint was enabling SecureBoot in/for Debian, so that
+users who have SecureBoot enabled machines do not need to turn that
+off to be able to run Debian. That needs us to handle signing a
+certain set of packages in a defined way, handling it as automated as
+possible while ensuring that stuff is done in a safe/secure way.
+
+Now add details like secure handling of keys, only signing
+pre-approved sets (to make abusing it harder), revocations, key
+rollovers, combine it all with the infrastructue and situation we have
+in Debian, say dak, buildd, security archive with somewhat different
+rules of visibility, reproducability, a huge set of architectures only
+some of which do SecureBoot, proper audit logging of signatures and
+you end up with 7 people from different teams taking the whole first
+day just discussing and hashing out a specification.
+
+I'm not going into actual details of all that, as a sprint report will
+follow soon.
+
+Friday to Sunday was the used for actual implementation of the agreed
+solution. The actual dak changes turned out to not be too large, and
+thankfully Ansgar was on them, so I could take time to push the
+FTPTeams move to the new Salsa service forward. I still have a few of
+our less-important repositories to move, but thats a simple process I
+will be doing during this week, the most important step was coming up
+with a sane way of using Salsa.
+
+That does not mean the actual web interface, but getting code changes
+from there to the various Debian hosts we run our services on. In the
+past, we pushed those directly, so all code changes appearing on them
+meant that someone who was in the right unix group on that machine
+made them appear.[^rootabuse]
+
+With Salsa we add a service that has other administrators and users
+over which we have no control nor say, and it may have bugs that allow
+someone to put code into our repository in ways that the old setup
+didn't have. If we blindly pull that, the confirmation "a FTPMaster
+said this code is good" is gone.
+
+Luckily, I did not have to invent it all on my own,
+[Enrico](http://www.enricozini.org/blog/2018/debian/automatic-deploy-from-gitlab-salsa-ci/)
+had similar concerns for the New-Maintainer web pages. He setup CI to
+test his stuff and, if successful, installs the tested stuff on the NM
+machine, provided that the commit is signed by a key from a defined
+set.
+
+Unfortunately, for me, he uses Django, as that is in use anyways. No
+option for me, so while copying the basic ideas, I had to implement it
+myself to fit FTPMasters environment. Which means Shell, and my famous
+(it is, isn*t it?) [cronscript](https://salsa.debian.org/ftp-team/dak/blob/master/config/debian/cronscript)[^cronscript]
+
+
+[^rootabuse]: Or someone abused root rights, but if you do not trust
+    root, you lost anyways, and there is no reason to think that any
+    DSA-member would do this.
+[^cronscript]: A framework for FTPMaster scripts that ensures the same
+    basic setup everywhere and makes it easy to call functions and
+    stuff, with or without error checking, in background or
+    foreground. ALso easy to restart in the middle of a script run
+    after breakage, as it keeps track where it was.