Updated post
authorJoerg Jaspert <joerg@debian.org>
Wed, 11 Apr 2018 15:28:58 +0000 (17:28 +0200)
committerJoerg Jaspert <joerg@debian.org>
Wed, 11 Apr 2018 15:28:58 +0000 (17:28 +0200)
_posts/2018-04-09-debian-secureboot-sprint-2018.md

index e9649a0..7bd53bc 100644 (file)
@@ -4,16 +4,14 @@ title: Debian SecureBoot Sprint 2018
 categories:
 - debian
 - ftpmaster
-date: '2018-04-09 10:01:13 +0200'
+date: '2018-04-11 17: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.
+Monday morning I gave back the keys to [Office Factory
+Fulda](http://www.office-factory.net), who sponsored the location for
+the SecureBoot Sprint from Thursday, 4th April to Sunday, 8th April.
+Appearently we left a pretty positive impression (we managed to clean
+up), 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
@@ -28,12 +26,13 @@ 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.
+day just discussing and hashing out a specification. Plus some
+joining in virtually.
 
 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
+Friday to Sunday was 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
@@ -43,27 +42,54 @@ 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
+past, we pushed the hosts 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]
+made them appear.[^rootabuse] "Verified by ssh login" basically.
 
-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.
+With Salsa, we now add a service that has a different set of
+administrators added on top. And a big piece of software too, with a
+huge possibility of bugs, worst case allowing random users access to
+our repositories. Which is a way larger problem area than "git push
+via ssh" as in the past, and as such more likely to be bad. If we
+blindly pull from a repository on such shared space, the confirmation
+"a FTPMaster said this code is good" is gone.
 
-Luckily, I did not have to invent it all on my own,
+So it needs a way of adding that confirmation back, while still being
+able to use all the nice features that Salsa offers. Within Debian,
+whats better than using already established ways of trusting
+something, gnupg created signatures?!
+
+So how to go forward? I have been lucky, i did not need to entirely
+invent this 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]
+Unfortunately, for me, he deals with a Django app that listens
+somewhere and can be pushed to. No such thing for me, neither do I
+have Django nor do I have a service listening that I can tell about
+changes to fetch.
+
+We also have to take care when a database schema upgrade needs to be
+done, no automatic deployment on database-using FTPMaster hosts for
+that, a human needs to trigger this.
+
+So the actual implementation that I developed for us, and which is in
+use on all hosts that we maintain code on, is implemented in our
+standard framework for regular jobs, [cronscript](https://salsa.debian.org/ftp-team/dak/blob/master/config/debian/cronscript).[^cronscript]
+
+It turns out to live in multiple files (as usual with cronscript),
+where the actual code is in
+[deploy.functions](https://salsa.debian.org/ftp-team/dak/blob/master/config/deploy/deploy.functions),
+[deploy.variables](https://salsa.debian.org/ftp-team/dak/blob/master/config/deploy/deploy.variables),
+and the order to call things is defined in
+[deploy.tasks](https://salsa.debian.org/ftp-team/dak/blob/master/config/deploy/deploy.tasks).
+
+cronscript around it takes care to setup the environment and keep
+logs, and we now call the deploy every few minutes, securely getting
+our code deployed.
 
 
 [^rootabuse]: Or someone abused root rights, but if you do not trust