On using QubesOS MirageOS firewall

So I'm lucky to attend the 4th MirageOS hack retreat in Marrakesh this week, where I learned to build and use qubes-mirage-firewall, which is a MirageOS based (system) firewall for Qubes OS. The main visible effect is that this unikernel only needs 32 megabytes of memory, while a Debian (or Fedora) based firewall systems needs half a gigabyte. It's also said to be more secure, but I have not verified that myself ;-)

In the spirit of avoiding overhead I decided not to build with docker as the qubes-mirage-firewall's README.md suggests, but rather use a base Debian stretch system. Here's how to build natively:

sudo apt install git opam aspcud curl debianutils m4 ncurses-dev perl pkg-config time

git clone https://github.com/talex5/qubes-mirage-firewall
cd qubes-mirage-firewall/
opam init
# the next line is super useful if there is bad internet connectivity but you happen to have access to a local mirror
# opam repo add local http://10.0.0.2:8080
opam switch 4.04.2
eval `opam config env`
## in there:
opam install -y vchan xen-gnt mirage-xen-ocaml mirage-xen-minios io-page mirage-xen mirage mirage-nat mirage-qubes netchannel
mirage configure -t xen
make depend
make tar

Then follow the instructions in the README.md and switch some AppVMs to it, and then make it the default and shutdown the old firewall, if you are happy with the results, which currently I'm not sure I am because it doesn't allow updating template VMs...

Update: qubes-mirage-firewall allows this. Just the crashed qubes-updates-proxy service in sys-net prevented it, but that's another bug elsewhere.

I also learned that it builds reproducibly given the same build path and ignoring the issue of timestamps in the generated tarball, IOW, the unikernel (and the 3 other files) inside the tarball is reproducible. And I still need to compare a docker build with a build done the above way & and I really don't like having to edit the firewalls rules.ml file and then rebuilding it. More on this in another post later, hopefully.

Oh, I didn't mention it and won't say more here, but this hack retreat and it's organisation is marvellous! Many thanks to everyone here!

Posted Mon Dec 4 15:37:14 2017

Reproducible Builds Summit 3 next week in Berlin

Next week from Tuesday, the 31st of October until Thursday, November 2nd, we'll have the 3rd Reproducible Builds summit in Berlin, to improve collaboration both between and inside projects, expand the scope and reach of reproducible builds to more projects and to brainstorm designs on tools enabling users to get the most benefits from reproducible builds.

We're again expecting contributors from around twenty projects and we're still having some free seats available. If you want to join this meeting, please register by sending us a short mail briefly describing why (eg. by stating you involvement in some project). We also have some funding available to further rextend the diversity of our community, so please also contact us if you think you cannot make it for financial reasons!

Personally I'm much looking forward to this event. The reproducible builds crowd is really a lovely bunch of people and thus I expect us to have some great discussions, some cool ideas and also some concrete actionable plans as a result of it. Totally worth it!

Talk about Reproducible Builds at OSSE in Prague tomorrow

Tomorrow, Wednesday, October 25th I'll be giving a talk at OSSE in Prague about the current status of Reproducible Builds and why we are not 'there' yet. I'd be glad to have a chat with you if you are there!

Posted Tue Oct 24 12:18:52 2017

"Qubes OS from the POV of a Debian developer" and "Qubes OS user meetup at Bornhack"

I wrote the following while on my way home from Bornhack which was an awesome hacking camp on the Danish island of Bornholm, where about 200 people gathered for a week, with a nice beach in walking distance (and a not too cold Baltic Sea) and vegan and not so vegan grills, to give some hints why it was awesome. (Actually it was mostly awesome due to the people there, not the things, but anyway…)

And there were of course also talks and workshops, and one was a Qubes OS users meetup, which amazingly was attended by 20 Qubes OS users (and some Qubes OS users present were even missing), so in other words: Qubes OS had a >10% user base at this event! And I even found one heads user! ;-)

At DebConf17 I gave a talk titled "Qubes OS from the POV of a Debian developer" and while the video was immediatly available (thanks to the DebConf videoteam!) I've also now put my slides for it online.

Since then, I learned a few things:

  • I should have mentioned Standalone-VM (=non-template based VMs) in the talk, as those are also possible, and sometimes handy.
  • IPv6 works with manual fiddling… (but this is undocumented)
  • I've given Salt (for configuation management) a short try (with the help of an experienced Salt users, thanks nodens!) and I must say I'm not impressed yet. But Qubes 4.0 will bring huge changes to this area (including introducing an AdminVM), so while I will not use Salt for the time I'll still be using Qubes 3.2, I will come back and look at this later.
  • after adding a single line containing "iwldvm iwlwifi" to /rw/config/suspend-module-blacklist in the NetVM the wireless comes back nicely (on my X230) after Suspend/Resume.

I'm looking forward to more Qubes OS user meetups in future!

Posted Wed Aug 30 00:46:51 2017
Posted Sun Aug 27 15:49:03 2017

setting up a coreboot build environment, including an Ada compiler

So without much explaination, this is how lynxis told me how to setup a coreboot build environment, which contains an Ada compiler which is needed to build the free graphics initialisation for Intel cards (=so no binary VGA bios blob is needed).

The Ada compiler is build automatically by default if it's build depends are installed:

sudo apt install build-essential bison flex zlib1g-dev ncurses-dev gnat
git clone --recursive https://review.coreboot.org/p/coreboot.git
cd coreboot/
git submodule update --init --checkout 3rdparty/blobs   # for the x230 this only contains microcode updates
make iasl CPUS=$(nproc)
make gnumake CPUS=$(nproc)
make crossgcc-i386 CPUS=$(nproc)

coreboot is then build as usual:

make menuconfig
make

That's it.

(I've just left out the steps to choose the coreboot revision and validating it, as well as choosing a configurationwith make menuconfig as this is better documented elsewhere.)

Posted Sun Aug 27 14:55:41 2017

laser-cutter sprint

So I'm overcoming my jetlag after DebConf17 by helping to make the Alioth sprint happen, and while it's good to witness work on the upcoming git.debian.org replacement, I'm rather minding my own business instead of getting involved…

And so I got interested in this laser cutter, which since two months has been set up in the CCCHH hackerspace and which is nicely documentend (and set up), so I managed to learn how to do my first baby steps with the laser cutter in one evening:

Basically there is a hosted web application named 'LaserWeb4' for which a pre-configuration exists, so that one only needs to load an image, scale and position it and tune the laser settings a bit. The laser itself is inside a cage, which has a physical safety switch which will turn off the laser if the cage is opened. Obviously the setup is a lot more complex and there are many parameters to tune, and I basically just learned one thing, which is "printing images on wood", but "printing images on a laptop cover" should be pretty similar and something to learn in the future ;-)

And now I'm even teaching weasel how to use this thing (and he already made interesting new mistakes) and it looks like Ganneff & formorer are next. Fun fun fun!

Oh, and the Alioth sprint also seems to be quite productive, but I'll leave reporting about this to others.

Posted Sat Aug 19 18:14:53 2017

How to change irssi's timezone without restart

Happy birthday to all you lovely Debian people!

For my future self:

<Rhonda> | h01ger: /script exec $ENV{TZ} = 'Europe/Vienna';
Posted Wed Aug 16 23:02:01 2017

"packages should build reproducibly" - after 4 years this work of many is in debian-policy now

This post was written roughly 44h ago and now that the fix for #844431 has been merged into the git master branch, I'm publishing it - hoping you'll enjoy this as much as I do!

So today is the last (official) day of DebConf17 and it looks like #844431: "packages should build reproducibly" will be merged into debian-policy today! So I'm super excited, super happy, quite tired and a bit sad (DebConf is ending…) right now! :-)

Four years ago Lunar held a BoF at DebConf13 which started the initiative in Debian. I only got involved in September 2014 with setting up continuous tests, rebuilding each package twice with some variations and then comparing the results using diffoscope, which back then was still called debbindiff and which we renamed as part of our efforts to make Reproducible Builds the norm in Free Software.

Many people have worked on this, and I'm also very happy how visible this has been in our talk here yesterday. You people rock and I'm very thankful and proud to be part of this team. Thank you everyone!

And please understand: we are not 94% done yet (which our reproducibility stats might have made you think), rather more like half done or so. We still need tools and processes to enable anyone to indepently verify that a given binary comes from the sources it is said to be coming, this will involve distributing .buildinfo files and providing user interfaces in APT and elsewhere. And probably also systematic rebuilds by us and other parties. And 6 or 7% of the archive are a lot of packages still, eg in Buster we currently still have 273 unreproducible key packages and for a large part we don't have patches yet. So there is still a lot of work ahead.

This is what was added to debian-policy now:

Reproducibility
---------------

Packages should build reproducibly, which for the purposes of this
document [#]_ means that given

- a version of a source package unpacked at a given path;
- a set of versions of installed build dependencies;
- a set of environment variable values;
- a build architecture; and
- a host architecture,

repeatedly building the source package for the build architecture on
any machine of the host architecture with those versions of the build
dependencies installed and exactly those environment variable values
set will produce bit-for-bit identical binary packages.

It is recommended that packages produce bit-for-bit identical binaries
even if most environment variables and build paths are varied.  It is
intended for this stricter standard to replace the above when it is
easier for packages to meet it.

.. [#]
   This is Debian's precisification of the `reproducible-builds.org
   definition `_.

For now violating this part of policy may result in a severity: normal bug, though I think we should still only file them if we have patches, else it's probably better to just take a note in our notes.git, like we did before the policy change.

Finally one last comment: we could do reproducible security updates for Stretch now too, for those 94% of the packages which are reproducible. It just needs to be done by someones and the first step would be publishing those .buildinfo files from those builds…

Posted Mon Aug 14 18:53:57 2017

a media experiment: fcmc.tv / G20 not welcome

Our view currently every day and night:

No one is illegal!

No football for fascists!

The FC/MC is a collective initiative to change the perception of the G20 in Hamburg - the summit itself and the protests surrounding it. FC/MC is a media experiment, located in the stadium of the amazing St.Pauli football club. We will operate until this Sunday, providing live coverage (text, photos, audio, video), back stories and much much more. Another world is possible!

Disclaimer: I'm not involved in content generation, I'm just doing computer stuff as usual, but that said, I really like the work of those who are! :-)

Posted Thu Jul 6 16:54:01 2017

Changed defaults for vim in Stretch

So appearantly vim in Stretch comes with some new defaults, most notably the mouse is now enabled and there is incremental search, which I find… challenging.

As a reminder for my future self, these needs to go into ~/.vimrc (or /etc/vim/vimrc) to revert those changes:

set mouse=
set noincsearch
Posted Wed Jun 14 19:04:46 2017