Review: Night Moves, by Pat Green

Publisher:	Aquarius
Copyright:	2014
ISBN:	0-9909741-1-1
Format:	Kindle
Pages:	159

In the fall of 2012, Pat Green was a preacher of a failing church, out of a job, divorced for six months, and feeling like a failure at every part of his life. He was living in a relative's house and desperately needed work and his father had been a taxi driver. So he got a job as a 6pm to 6am taxi driver in his home town of Joliet, Illinois. That job fundamentally changed his understanding of the people who live in the night, how their lives work, and what it means to try to help them. This is nonfiction: a collection of short anecdotes about life as a cab driver and the people who have gotten a ride in Green's cab. They're mostly five or six pages long, just a short story or window into someone's life. I ran across Pat Green's writing by following a sidebar link from a post on Patheos (probably from Love, Joy, Feminism, although I no longer remember). Green has an ongoing blog on Patheos about raising his transgender son (who appears in this collection as a lesbian daughter; he wasn't out yet as transgender when this was published), which is both a good sample of his writing and occasionally has excerpts from this book. Green's previous writing experience, as mentioned at several points in this collection, was newspaper columns in the local paper. It shows: these essays have the succinct, focused, and bite-sized property of a good newspaper article (or blog post). The writing is a little rough, particularly the remembered dialogue that occasionally falls into the awkward valley between dramatic, constructed fictional dialogue and realistic, in-the-moment speech. But the stories are honest and heartfelt and have the self-reflective genuineness of good preaching paired with a solid sense of narrative. Green tries to observe and report first, both the other person and his own reactions, and only then try to draw more general conclusions. This book is also very hard to read. It's not a sugar-coated view of people who live in the night of a city, nor is it constructed to produce happy endings. The people who Green primarily writes about are poor, or alone, or struggling. The story that got me to buy this book, about taking a teenage girl to a secret liaison that turned out to be secret because her liaison was another girl, is heartwarming but also one of the most optimistic stories here. A lot of people die or just disappear after being regular riders for some time. A lot of people are desperate and don't have any realistic way out. Some people, quite memorably, think they have a way out, and that way out closes on them. The subtitle of this book is "An Ex-Preacher's Journey to Hell in a Taxi" and (if you followed the link above) you'll see that Green is writing in the Patheos nonreligious section. The other theme of this collection is the church and its effect on the lives of people who are trying to make a life on the outskirts of society. That effect is either complete obliviousness or an active attempt to make their lives even worse. Green lays out the optimism that he felt early in the job, the hope that he could help someone the way a pastor would, guide her to resources, and how it went horribly wrong when those resources turned out to not be interested in helping her at all. And those stories repeat, and repeat. It's a book that makes it very clear that the actual practice of Christianity in the United States is not about helping poor or marginalized people, but there are certainly plenty of Christian resources for judging, hurting people, closing doors, and forcing abused people back into abusive situations, all in the name of God. I do hope some Christians read this and wince very hard. (And lest the progressive Christians get too smug, one of the stories says almost as brutal things about liberal ministries as the stories of conservative ones.) I came away feeling even more convinced by the merits of charities that just give money directly to poor people. No paternalism, no assuming that rich people know what they need, no well-meaning intermediary organizations with endless rules, just resources delivered directly to the people who most need resources. Ideally done by the government and called universal basic income. Short of constructing a functional government that builds working public infrastructure, and as a supplement even if one has such a government (since infrastructure can't provide everything), it feels like the most moral choice. Individual people may still stay mired in awful situations, but at least that isn't compounded by other people taking their autonomy away and dictating life to them in complete ignorance. This is a fairly short and inexpensive book. I found it very much worth reading, and may end up following Green's blog as well. There are moments of joy and moments of human connection, and the details of the day-to-day worries and work style of a taxi driver (in this case, one who drives a company car) are pretty interesting. (Green does skip over some parts for various reasons, such as a lot of the routine fares and most of the stories of violence, but does mention what he's skipping over.) But it's also a brutal book, because so many people are hurting and there isn't much Green can do about it except bear witness and respect them as people in a way that religion doesn't. Recommended, but brace yourself. Rating: 8 out of 10

This morning I uploaded version 0.1 of SReview, my video review and transcoding system, to Debian experimental. There's still some work to be done before it'll be perfectly easy to use by anyone, but I do think I've reached the point by now where it should have basic usability by now. Quick HOWTO for how to use it:

• Enable Debian experimental
• Install the packages sreview-master, sreview-encoder, sreview-detect, and sreview-web. It's possible to install the four packages on different machines, but let's not go into too much detail there, yet.
• The installation will create an sreview user and database, and will start the sreview-web service on port 8080, listening only to localhost. The sreview-web package also ships with an apache configuration snippet that shows how to proxy it from the interwebs if you want to.
• Run sreview-config --action=dump. This will show you the current configuration of sreview. If you want to change something, either change it in /etc/sreview/config.pm, or just run sreview-config --set=variable=value --action=update.
• Run sreview-user -d --action=create -u <your email>. This will create an administrator user in the sreview database.
• Open a webbrowser, browse to http://localhost:8080/, and test whether you can log on.
• Write a script to insert the schedule of your event into the SReview database. Look at the debconf and fosdem scripts for inspiration if you need it. Yeah, that's something I still need to genericize, but I'm not quite sure yet how to do that.
• Either configure gridengine so that it will have the required queues and resources for SReview, or disable the qsub commands in the SReview state_actions configuration parameter (e.g., by way of sreview-config --action=update --set=state_actions=... or by editing /etc/sreview/config.pm).
• If you need notification, modify the state_actions entry for notification so that it sends out a notification (e.g., through an IRC bot or an email address, or something along those lines). Alternatively, enable the "anonreviews" option, so that the overview page has links to your talk.
• Review the inputglob and parse_re configuration parameters of SReview. The first should contain a filesystem glob that will find your raw assets; the second should parse the filename into room, year, month, day, hour, minute, and second, components. Look at the defaults of those options for examples (or just use those, and store your files as /srv/sreview/incoming/<room>/<year>-<month>-<day>/<hour>:<minute>:<second>.*).
• Provide an SVG file for opening credits, and point to it from the preroll_template configuration option.
• Provide an SVG or PNG file for closing credits, and point to it from the postroll_template resp postroll configuration option.
• Start recording, and watch SReview do its magic

There's still some bits of the above list that I want to make easier to do, and there's still some things that shouldn't be strictly necessary, but all in all, I think SReview has now reached a certain level of maturity that means I felt confident doing its first upload to Debian. Did you try it out? Let me know what you think!

Here's what happened in the Reproducible Builds effort between Sunday October 29 and Saturday November 4 2017: Past events

• From October 31st November 2nd we held the 3rd Reproducible Builds summit in Berlin, Germany. A full, in-depth report will be posted in the next week or so.

Upcoming events

• On November 8th Jonathan Bustillos Osornio (jathan) will present at CubaConf Havana.
• On November 17th Chris Lamb will present at Open Compliance Summit, Yokohama, Japan on how reproducible builds ensures the long-term sustainability of technology infrastructure.

Reproducible work in other projects

• Alan Pope linked to the status of "asset recording" in SnapCraft, a concept related to .buildinfo files.

Packages reviewed and fixed, and bugs filed

• Chris Lamb:
  • #880714 filed against cappuccino.
  • #880803 filed against python-kafka.
  • #880804 filed against debci.
  • #880827 filed against roundcube.
• Steve Langasek:
  • #880550 filed against g2.
• Juro:
  • curl (SOURCE_DATE_EPOCH)
  • OpenSSL (SOURCE_DATE_EPOCH)
• Bernhard M. Wiedemann:
  • openSUSE/ant (use SOURCE_DATE_EPOCH)
  • openSUSE/mariadb (drop INFO_BIN)
  • openSUSE/libsmbios (drop embedded build log)

Reviews of unreproducible packages 7 package reviews have been added, 43 have been updated and 47 have been removed in this week, adding to our knowledge about identified issues. Weekly QA work During our reproducibility testing, FTBFS bugs have been detected and reported by:

• Adrian Bunk (44)
• Andreas Moog (1)
• Lucas Nussbaum (7)
• Steve Langasek (1)

Documentation updates

• Ulrike Uhlig:
  • Add documentation about system images.
• Holger Levsen:
  • List all speakers of the DebConf17
  • Add news about the Berlin event
• Chris Lamb:
  • Add recent talks to resources.html.
  • Clarify link to full definition.
  • Cachebust CSS files.
• Bernhard M. Wiedemann:
  • Fix openSUSE website link

diffoscope development Version 88 was uploaded to unstable by Mattia Rizzolo. It included contributions (already covered by posts of the previous weeks) from:

• Mattia Rizzolo
  • tests/comparators/dtb: compatibility with version 1.4.5. (Closes: #880279)
• Chris Lamb
  • comparators:
    • binwalk: improve names in output of "internal" members. #877525
    • Omit misleading "any of" prefix when only complaining about one module in ImportError messages.
  • Don't crash on malformed "md5sums" files. (Closes: #877473)
  • tests/comparators:
    • ps: ps2ascii > 9.21 now varies on timezone, so skip this test for now.
    • dtby: only parse the version number, not any "-dirty" suffix.
  • debian/watch: Use HTTPS URI.
• Ximin Luo
  • comparators:
    • utils/file: Diff container metadata centrally. This fixes a last remaining bug in fuzzy-matching across containers. (Closes: #797759)
    • Fix all the affected comparators after the above change.
• Holger Levsen
  • Bump Standards-Version to 4.1.1, no changes needed.

strip-nondeterminism development Version 0.040-1 was uploaded to unstable by Mattia Rizzolo. It included contributions already covered by posts of the previous weeks, as well as new ones from:

• Mattia Rizzolo:
  • Declare that strip-nondeterminism doesn't need root to build
  • Add my key to debian/upstream/signing-key.asc m disorderfs development

---

Version 0.5.2-2 was uploaded to unstable by Holger Levsen. It included contributions already covered by posts of the previous weeks, as well as new ones from:

• Chris Lamb:
  • Add a reproducible builds example, highlighting the non-intuitive recommendation to sort instead of shuffle.
  • Add myself to AUTHORS.
  • debian/watch: Use HTTPS URI.
• Holger Levsen:
  • debian/control: use /git/ instead of /cgit/ URL for Vcs-Browser
  • debian/compat: Bump to compat level 10 & raise build-depends to debhelper >= 10.2.5~.
  • debian/control: Bump Standards-Version to 4.1.1.

reprotest development

• Ximin Luo:
  • Mention certificate expiry errors in documentation as a potential issue with faketime

buildinfo.debian.net development

• Chris Lamb:
  • Support UID filtering
  • Add initial "by-hash" API endpoint.

tests.reproducible-builds.org

• Mattia Rizzolo:
  • archlinux: enable schroot building on pb4 as well
  • archlinux: don't install the deprecated abs tool
  • archlinux: try to re-enable one schroot creation job
• lynxis
  • lede: replace TMPDIR -> RESULTSDIR
  • lede: openwrt_get_banner(): use locals instead of globals
  • lede: add newline to $CONFIG
  • lede: show git log -1 in jenkins log
• Holger Levsen:
  • lede: add very simple landing page
• Juliana Oliveira Rodrigues
  • archlinux: adds pacman-git dependencies
• kpcyrd
  • archlinux: disable signature verification when running in the future
  • archlinux: use pacman-git until the next release
  • archlinux: make pacman fail less early
  • archlinux: use sudo to prepare chroot
  • archlinux: remove -rf for regular file
  • archlinux: avoid possible TOCTOU issue
  • archlinux: Try to fix tar extraction
  • archlinux: fix sha1sums parsing

Misc. This week's edition was written by Bernhard M. Wiedemann, Chris Lamb, Mattia Rizzolo & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists.

Like many laptop users, I often plug my laptop into different monitor setups (multiple monitors at my desk, projector when presenting, etc.) Running xrandr commands or clicking through interfaces gets tedious, and writing scripts isn't much better. Recently, I ran across autorandr, which detects attached monitors using EDID (and other settings), saves xrandr configurations, and restores them. It can also run arbitrary scripts when a particular configuration is loaded. I've packed it, and it is currently waiting in NEW. If you can't wait, the deb is here and the git repo is here. To use it, simply install the package, and create your initial configuration (in my case, undocked):

 autorandr --save undocked

then, dock your laptop (or plug in your external monitor(s)), change the configuration using xrandr (or whatever you use), and save your new configuration (in my case, workstation):

autorandr --save workstation

repeat for any additional configurations you have (or as you find new configurations). Autorandr has udev, systemd, and pm-utils hooks, and autorandr --change should be run any time that new displays appear. You can also run autorandr --change or autorandr --load workstation manually too if you need to. You can also add your own ~/.config/autorandr/$PROFILE/postswitch script to run after a configuration is loaded. Since I run i3, my workstation configuration looks like this:

 #!/bin/bash
 xrandr --dpi 92
 xrandr --output DP2-2 --primary
 i3-msg '[workspace="^(1 4 6)"] move workspace to output DP2-2;'
 i3-msg '[workspace="^(2 5 9)"] move workspace to output DP2-3;'
 i3-msg '[workspace="^(3 8)"] move workspace to output DP2-1;'

which fixes the dpi appropriately, sets the primary screen (possibly not needed?), and moves the i3 workspaces about. You can also arrange for configurations to never be run by adding a block hook in the profile directory. Check it out if you change your monitor configuration regularly!

Yesterday, I printed the first draft of the first chapter when my little boy was here and he was impressed with this strange object called a "printer". Before I printed what I needed, I fired up LibreOffice and chose the biggest font size that was available and let him type his first name by himself. He was quicker than I thought with a keyboard. After seeing me print his first name, he was jumping up and down with joy of having created something and even showed grandma and grandpa what he had done. He, then, wanted more and I taught him how to use that backspace key, what it meant and he wanted to type his full name. I let him and taught him that there is a key called space that he should type every time he wants to start a new word and, in the end, he typed his first two names. To my surprise, he memorized the icon with the printer (which I must say that I have to hunt every time, since it seems so similar to the adjacent ones!) and pressed this new key called "Enter". When he pressed, he wasn't expecting the printer on his right to start making noises and printing his name. He was so excited and it was so nice to see his reaction full of joy to get a job done! I am thinking of getting a spare computer, building it with him and for him, so that he can call it his computer every time he comes to see daddy. As a serendipitous situation, Packt Publishing offered yesterday their title "Python Projects for Kids". Unfortunately, he does not yet know how to read, but I guess that the right age is coming soon, which is a good thing to make him be educated "the right way" (that is, with the best support, teaching and patience that I can give him). Anyway, I printed the first draft of the first chapter and today I have to turn it in. As I write this, I am downloading a virtual machine from Microsoft to try to install Java on it. Let me see if it works. I have none of the virtualization options used, tough the closest seems to be virtualbox. Let me cross my fingers. In other news, I updated some of the tags of very old posts of this blog, and I am seriously thinking about switching from [ikiwiki][0] to another blog platform. It is slow, very slow on my system with the repositories that I have, especially on my armel system. Some non-interpreted system would be best, but I don't know if such a thing even exists. But the killer problem is that it doesn't support easily the typing of Mathematics (even though a 3rd party plugin for MathJax exists). On the other hand, I just received an answer on twitter from @telegram and it was nice:

Hello, Telegram supports bold and italic. You can type **bold** and __italic__. On mobile, you can also highlight text for this as well.

It is nice that this works with telegram-desktop too. Besides that, I filed some bugs on Debian's BTS, responded to some issues on my projects on GitHub (I'm slowly getting back on maintaining things) and file wishlist bugs on some other projects. Oh, and I grabbed a copy of "Wonder woman" ("Mulher Maravilha") and "Despicable Me 3" ("Meu Malvado Favorito 3") dubbed in Brazilian Portuguese for my son. I have to convert the audio from AAC-LC in 6 channels to AC3 or to stereo. Otherwise, my TVs have problem with the videos (one refuses to play the entire file and another plays the audio with sounds of hiccups). Edit: After converting the VirtualBox image taken from Microsoft, I could easily use qemu/kvm to create screenshots of the installation of Java. The command that I used (for future reference) is: qemu-system-x86_64 -enable-kvm -m 4096 -smp 2 -net nic,model=e1000 -net user -soundhw ac97 -drive index=0,media=disk,cache=unsafe,file=win7.qcow2 Edit: Fixed some typos.

I started web development around late 1994. Some of my earliest paid web work is still online (dated June 1995). Clearly, that was a simpler time for content! I went on to be Webmaster (yes, for those joining us in the last decade, that was a job title once) for UWA, and then for Hartley Poynton/JDV.com at time when security became important as commerce boomed online. At the dawn of the web era, the consideration of backwards compatibility with older web clients (browsers) was deemed to be important; content had to degrade nicely, even without any CSS being applied. As the years stretched out, the legacy became longer and longer. Until now. In mid-2018, the Payment Card Industry (PCI) Data Security Standard (DSS) 3.2 comes into effect, requiring card holder environments to use (at minimum) TLS 1.2 for the encrypted transfer of data. Of course, that s also the maximum version typically available today (TLS 1.3 is in draft 21 at this point in time of writing). This effort by the PCI is forcing people to adopt new browsers that can do the TLS 1.2 protocol (and the encryption ciphers that permits), typically by running modern/recent Chrome, Firefox, Safari or Edge browsers. And for the majority of people, Chrome is their choice, and the majority of those are all auto-updating on every release. Many are pushing to be compliant with the 2018 PCI DSS 3.2 as early as possible; your logging of negotiated protocols and ciphers will show if your client base is ready as well. I ve already worked with one government agency to demonstrate they were ready, and have already helped disable TLS 1.0 and 1.1 on their public facing web sites (and previously SSL v3). We ve removed RC4 ciphers, 3DES ciphers, and enabled ephemeral key ciphers to provide forward secrecy. Web developers (writing Javascript and using various frameworks) can rejoice the age of having to support legacy MS IE 6/7/8/9/10 is pretty much over. None of those browsers support TLS 1.2 out of the box (IE 10 can turn this on, but for some reason, it is off by default). This makes Javascript code smaller as it doesn t have to have conditional code to work with the quirks of those older clients. But as we find ourselves with modern clients, we can now ask those clients to be complicit in our attempts to secure the content we serve. They understand modern security constructs such as Content Security Policies and other HTTP security-related headers. There s two tools I am currently using to help in this battle to improve web security. One is SSLLabs.com, the work of Ivan Risti (and now owned/sponsored by Qualys). This tool gives a good view of the encryption in flight (protocols, ciphers), chain of trust (certificate), and a new addition of checking DNS records for CAA records (which I and others piled on a feature request for AWS Route53 to support). The second tool is Scott Helm s SecurityHeaders.io, which looks at the HTTP headers that web content uses to ask browsers to enforce security on the client side. There s a really important reason why these tools are good; they are maintained. As new recommendations on ciphers, protocols, signature algorithms or other actions become recommended, they re updated on these tools. And these tools are produced by very small, but agile teams like one person teams, without the bureaucracy (and lag) associated with large enterprise tools. But these shouldn t be used blindly. These services make suggestions, and you should research them yourselves. For some, not all the recommendations may meet your personal risk profile. Personally, I m uncomfortable with Public-Key-Pins, so that can wait for a while indeed, Chrome has now signalled they will drop this. So while PCI is hitting merchants with their DSS-compliance stick (and making it plainly obvious what they have to do), we re getting a side-effect of having a concrete reason for drawing a line under where our backward compatibility must stretch back to, and the ability to have the web client assist in ensure security of content.

It has been a few years since Debian last had a working VHDL simulator in the archive. Its competitor Verilog has been covered by the iverilog and verilator simulator packages, but GHDL was the only option for VHDL in Debian and that has become broken, orphaned and was eventually removed. I have just submitted an ITP to make my work on it official. A lot has changed since the last Debian upload of GHDL. Upstream development is quite active and it has gained free reimplementations of the standard library definitions (the lack of which frustrated at least two attempts at adoption of the Debian package). It has gained additional backends, in addition to GCC it can now also use LLVM and its own custom mcode (x86 only) code generator. The mcode backend should provide faster compilation at the expense of lacking sophisticated optimization, hence it might be preferable over the other two for small projects. My intentions are to provide all three backends in separate packages which would also offer easier backend troubleshooting a user experiencing problems can simply install another package to try a different backend. The problem with that idea is that GHDL is not designed for that kind of parallel installation. The backend is chosen at build configure time and that configuration is built and installed. Parallel installation will probably need some development but if that would turn out to be much work I could always have the packages conflicting initially. Given all these changes I am redoing the Debianization from ground up and maybe take bits and pieces from the old packaging where suitable. Right now I m building the different backends to compare and see what files are backend specific and what can go into a common package.

Well Jacob, do you think we should set up our own pretend phone company in the house? We can DO THAT? Yes! Then yes. Yes! YES YES YESYESYESYES YES! Let s do it, dad! Not long ago, my parents had dug up the old phone I used back in the day. We still have a landline, and Jacob was having fun discovering how an analog phone works. I told him about the special number he could call to get the time and temperature read out to him. He discovered what happens if you call your own number and hang up. He figured out how to play Mary Had a Little Lamb using touchtone keys (after a slightly concerned lecture from me setting out some rules to make sure his musical dialing wouldn t result in any, well, dialing.) He was hooked. So I thought that taking it to the next level would be a good thing for a rainy day. I have run Asterisk before, though I had unfortunately gotten rid of most of my equipment some time back. But I found a great deal on a Cisco 186 ATA (Analog Telephone Adapter). It has two FXS lines (FXS ports simulate the phone company, and provide dialtone and ring voltage to a connected phone), and of course hooks up to the LAN. We plugged that in, and Jacob was amazed to see its web interface come up. I had to figure out how to configure it (unfortunately, it uses SCCP rather than SIP, and figuring out Asterisk s chan_skinny took some doing, but we got there.) I set up voicemail. He loved it. He promptly figured out how to record his own greetings. We set up a second phone on the other line, so he could call between them. The cordless phones in our house support SIP, so I configured one of them as a third line. He spent a long time leaving himself messages. Pretty soon we both started having ideas. I set up extension 777, where he could call for the time. Then he wanted a way to get the weather forecast. Well, weather-util generates a text-based report. With it, a little sed and grep tweaking, the espeak TTS engine, and a little help from sox, I had a shell script worked up that would read back a forecast whenever he called a certain extension. He was super excited! That s great, dad! Can it also read weather alerts too? Sure! weather-util has a nice option just for that. Both boys cackled as the system tried to read out the NWS header (their timestamps like 201711031258 started with two hundred one billion ) Then I found an online source for streaming NOAA Weather Radio feeds Jacob enjoys listening to weather radio and I set up another extension he could call to listen to that. More delight! But it really took off when I asked him, Would you like to record your own menu? You mean those things where it says press 1 or 2 for this or that? Yes. WE CAN DO THAT? Oh yes! YES, LET S DO IT RIGHT NOW! So he recorded a menu, then came and hovered by me while I hacked up extensions.conf, then eagerly went back to the phone to try it. Oh the excitement of hearing hisown voice, and finding that it worked! Pretty soon he was designing sub-menus ( OK Dad, so we ll set it up so people can press 2 for the weather, and then choose if they want weather radio or the weather report. I m recording that now. Got it? ) He has informed me that next Saturday we will build an intercom system like we have at school. I m going to have to have some ideas on how to tie Squeezebox in with Asterisk to make that happen, I think. Maybe this will do.

Here's what happened in the Reproducible Builds effort between Sunday October 22 and Saturday October 28 2017: Past Events

• On Tuesday 24th October, Chris Lamb presented at All Things Open 2017 in Raleigh, NC, USA.
• On Wednesday 25th October, Holger Levsen presented at the Open Source Summit Europe in Prague, Czech Republic.
• On Saturday 28th October, Chris Lamb presented at freenode.live in Bristol, UK.

Upcoming/current events

• From October 31st November 2nd we will be holding the 3rd Reproducible Builds summit in Berlin, Germany.
• On November 8th Jonathan Bustillos Osornio (jathan) will present at CubaConf Havana.

Documentation updates Bernhard Wiedemann started The Unreproducible Package which "is meant as a practical way to demonstrate the various ways that software can break reproducible builds using just low level primitives without requiring external existing programs that implement these primitives themselves. It is structured so that one subdirectory demonstrates one class of issues in some variants observed in the wild." Reproducible work in other projects Hush, a fork of ZCash, opened an issue into reproducible builds. A new tag was added to lintian (lint checker for Debian packages) to ensure that changelog entry timestamps are strictly increasing. This avoids certain real-world issues with identical timestamps, documented in Debian #843773. Packages reviewed and fixed, and bugs filed Patches sent upstream:

• Bernhard M. Wiedemann:
  • gtranslator, embedded build timestamps
  • libgda, embedded build timestamps
  • mariadb, embedded build timestamps
  • nim, embedded build timestamps

Debian bug reports:

• Chris Lamb:
  • #879569 filed against argagg.
  • #879913 filed against sdlgfx.
  • #879914 filed against fmtlib.

Reviews of unreproducible packages 14 package reviews have been added, 35 have been updated and 28 have been removed in this week, adding to our knowledge about identified issues. 1 issue type has been updated:

• Add nondeterministic_ordering_in_documentation_generated_by_doxygen.

Weekly QA work During our reproducibility testing, FTBFS bugs have been detected and reported by:

• Adrian Bunk (4)

strip-nondeterminism development Version 0.040-1 was uploaded to unstable by Mattia Rizzolo. It included contributions already covered by posts of the previous weeks, as well as new ones from:

• Mattia Rizzolo:
  • png.pm: Don't open the original file in write mode

reprotest development Development continued in git:

• Ximin Luo:
  • New features:
    • Support a domain_host variation.
    • Support a --print-sudoers feature.
  • Documentation:
    • Note some caveats about the existing git versions as a self-reminder not to release it yet.
    • Updates about our assumptions and rearrange sudo into its own section.
  • Bug fixes:
    • main: When dropping privs, make sure the user can still move in theroot.
    • tests: fix, need to preserve env for su
    • build: Don't fail when the build produces a broken symlink
    • main, presets: Properly drop privs when running the build. (Closes: #877813)
  • Code quality:
    • Improve logging to try to get to the bottom of the jenkins failures
    • Tweak tests to avoid some build dependencies
    • build: Name temporary directories after reprotest not autopkgtest

buildinfo.debian.net development Development continued in git:

• Chris Lamb:
  • New features:
    • Add API endpoint to fetch specific .buildinfo files for a certain package/version/architecture, and optimise it. (Closes: #25)
  • Bug fixes:
    • Always show SHA256, regardless of viewport size. (Closes: #27)
    • Actually filter by source package

reproducible-website development

• Holger Levsen:
  • RWS3 Berlin 2017:
    • Add CoyIM, Arch Linux, LEDE, LEAP, subuser.org, Bazel, coreboot.
    • Make some sponsors visible.
    • Add short paragraph explaining that registration is mandatory.

Misc. This week's edition was written by Ximin Luo, Chris Lamb, Bernhard M. Wiedemann and Holger Levsen & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists.

Today I spent some time in the morning seeing how one would install the JDK on Linux distributions. This is to create a little comparative tutorial to teach introductory Java. Installing the JDK is, thanks to the OpenJDK developers in Debian and Ubuntu (Matthias Klose and helpers), a very easy task. You simply type something like:

apt-get install openjdk-8-jdk

Since for a student it is better to have everything for experiments, I install the full version, not only the -headless version. Given my familiarity with Debian/Ubuntu, I didn't have to think about the way of installing it, of course. But as this is a tutorial meant to be as general as I can, I tried also to include instructions on how to install Java on other distributions. The first two that came to my mind were openSUSE and Fedora. Both use the RPM package format for their "native" packages (in the same sense that Debian uses DEB packages for "native" packages). But they use different higher-level tools to install such packages: Fedora uses a tool called dnf, while openSUSE uses zypper. To try these distributions, I got their netinstall ISOs and used qemu/kvm to install on a virtual machine. I used the following to install/run the virtual machines (the example below, is, of course, for openSUSE):

qemu-system-x86_64 -enable-kvm -m 4096 -smp 2 -net nic,model=e1000 -net user -drive index=0,media=disk,cache=unsafe,file=suse.qcow2 -cdrom openSUSE-Leap-42.3-NET-x86_64.iso

The names of the packages also change from one distribution to another. On Fedora, I had to use:

dnf install java-1.8.0-openjdk-devel

On openSUSE, I had to use:

zypper install java-1_8_0-openjdk-devel

Note that one distribution uses dots in the names of the packages while the other uses underscores. One interesting thing that I noticed with dnf was that, when I used it, it automatically refreshed the package lists from the network, something which I forgot, and it was a pleasant surprise. I don't know about zypper, but I guess that it probably had fresh indices when the installation finished. Both installations were effortless after I knew the names of the packages to install. Oh, BTW, in my 5 minute exploration with these distributions, I noticed that if you don't want the JDK, but only the JRE, then you omit the -devel suffix. It makes sense when you think about it, for consistency with other packages, but Debian's conventions also make sense (JRE with -jre suffix, JDK with -jdk suffix). I failed miserably to use Fedora's prebaked, vanilla cloud image, as I couldn't login on this image and I decided to just install the whole OS on a fresh virtual machine. I don't have instructions on how to install on Gentoo nor on Arch, though. I now see how hard it is to cover instructions/provide software for as many distributions as you wish, given the multitude of package managers, conventions etc.

Here is my monthly update covering what I have been doing in the free software world in October 2017 (previous month):

• Wrote and released python-gfshare, a Python library that implements Shamir s method for secret sharing, a cryptography technique to split a file into multiple parts. I blogged about it earlier in the month.
• Improved the new-style URL handling in the 2.x branch of the Django web framework to check for incorrectly migrated calls from the old system. [...]
• Added support for Python 3, Django 1.9 & Django 2.0 to django-auto-one-one-to-one, my library to cleanly manage related model instances.
• Proposed two small pull requests for Redisearch, a search engine module for the Redis key-value storage database:
  • Don't assume that not being Linux is OSX. [...]
  • Install the module into /usr/lib over /var/lib as the latter is for program state, not libraries or modules. [...]
• In Peter Bengtsson's new django-cache-memoize library, suggested an addition to the store_result documentation. [...]
• Made two pull requests for django-auditlog, a Django app that maintains an audit trail of changes in your application:
  • Add missing on_delete to the LogEntry initial migration to ensure compatibility with Django 2.x. [...]
  • Add missing python-dateutil to setup.py. [...]
• Yet more Lintian hacking (previously):
  • New features:
    • Warn when packages unnecessararily set dpkg-architecture(1) variables. (#793554)
    • Check for files that use content from the /etc/init.d/skeleton template. (#879152)
    • Warn about certain files under debian/* that contain trailing whitespace characters. (#748405)
    • Ignore embedded jQuery libraries for Doxygen. (#736360)
    • Warn about Django libraries that do not depend on Django itself. (#877292)
    • Check for Python modules with overly generic names such as tests or test. (#875964)
    • Warn if packages set CFLAGS if the value of DEB_BUILD_OPTIONS contains noopt. (#718640)
    • Ignore embedded jQuery libraries for Doxygen. (#736360)
    • Warn about empty fields in debian/control. (#744388)
    • Add bionic as known Ubuntu distribution. (#880115)
    • Warn if native systemd .service files only wrap the existing SysV/LSB init scripts. (#870704)
    • Emit new empty-section-field tag instead of uninitialized value warnings on an empty Section: field. (#878515)
    • Warn about debian/watch files using insecure URIs, similar to vcs-field-uses-insecure-uri. (#849515)
    • Include the offending URI in debian-watch-uses-insecure-uri output, not the line number.
    • Allow empty md5sums files. (#781372)
    • Move latest-debian-changelog-entry-without-new-date tag into a new check of type source. (#873612)
    • Add cwl-runner to the list of known interpreters. (#851126)
    • Also match packages named python2-* as relating to the Python 2.x migration.
  • Bug fixes:
    • Don't error out when AppStream metadata is invalid; emit appstream-metadata-invalid instead. (#879661)
    • Actually check for a dependency on sensible-utils before emitting script-needs-depends-on-sensible-utils. (#877439)
    • Avoid a false positives in debian-control-has-empty-field when the field is wrapped onto a new line. (#879977)
    • Drop README.source from files to check against file-contains-trailing-whitespace as it can include literal quotes from upstreams that would be ideally left intact.
    • Lower the severity of package-installs-java-bytecode from E: to W:. (#879862)
    • Do not trigger package-installs-java-bytecode if the path contains WEB-INF, demo, doc etc. (#879860)
    • Verify files triggering package-installs-java-bytecode files really are Java .class files. (#879861)
    • Check the Recommends field as well when testing scripts for script-needs-depends-on-sensible-utils. (#879953)
    • Ignore the "magic" http://sf.net/ redirector URI for the debian-watch-uses-insecure-uri tag. (#879206)
    • Revert addition of "none were" -> "none was" multiword spelling correction as it is "acceptable beyond serious criticism". (#878457)
    • Drop copyright-year-in-future; too error prone and time-consuming to maintain given the severity of the issues it can find. (#877766)
    • Exempt debian/copyright from the license-problem-non-free-RFC tag to avoid false-positives "meta" references. (#877999)
    • Ignore privacy breach violations within HTML/Javascript comments. (#877421)
    • Avoid warning for init.d-script-not-marked-as-conffile when the init.d script does not exist as we will already be alerted via the init.d-script-not-included-in-package tag.
    • Do not emit python-foo-but-no-python3-foo for packages ending with -common.
    • Add missing example-script-uses-deprecated-nodejs-location tag. (#877142)
    • Correct invalid link to upgrading-checklist in Standards-Version checks. (#878184)
  • Documentation:
    • Add a note to orig-tarball-missing-upstream-signature regarding support in pristine-tar and git-buildpackage.
    • Add example on how to remove trailing whitespace with sed.
  • Tests:
    • Split out checks for debconf-config-not-executable into a separate test protected by a Test-Requires now that dpkg 1.19.0 will bail out on that condition.
    • Correct Depends of python2.7 python3 in a Python 3 test package.
    • Add test for ignoring python-foo-doc packages for the Python 3 migration and correct short descriptions of test packages.
• Finally, I was interviewed by HostingAdvice about my role as Debian Project Leader.

---

Review: Waypoint Kangaroo, by Curtis C. Chen

Series:	Kangaroo #1
Publisher:	Thomas Dunne
Copyright:	June 2016
ISBN:	1-250-08179-3
Format:	Kindle
Pages:	312

Disclaimer: Curtis was a classmate of mine at Stanford and part of the same social circle. That was a surprisingly long time ago. Kangaroo is a spy (and, for this book, you should think James Bond). Agency training, fake identities, lots of gadgets, grumpy yet ridiculously competent support staff... the typical package. But Kangaroo also has a special power, which is the entire reason he ended up in the position he has. He's apparently the only person in the world who can open the pocket: a hole into another dimension, which can function as infinite storage and quite a bit more. Waypoint Kangaroo opens with the tail end of a mission and Kangaroo in action, as an introduction to Kangaroo's first-person narrative voice, job, and the capabilities of the pocket. But the real story starts when Kangaroo is sent on vacation. The office is being audited, Kangaroo hasn't had time off basically ever, and his boss insists on a trip to Mars on the space equivalent of a cruise ship. No work. An expense account. Just relax and have fun. Kangaroo isn't sure he knows how to not work. Or how to avoid boredom when trying hard to not work. It leads to probably ill-advised decisions like falling in love at first glance with the chief engineer, or going on entirely unauthorized spacewalks in the middle of the night. It's very lucky for him that the captain of this commercial cruise ship appears to also work for his agency. And it's good for his inability to stop working that there's a murder on board. For a first novel, this is refreshingly free of a lot of first novel problems. It's lean, well-structured, easy to follow, moves right along, and doesn't feel over-stuffed with exposition or world-building. There's an interplanetary war in the past background, and of course a lot of loving description of the precise mechanics of the pocket and the tricks with momentum and retrieval Kangaroo can do with it, but the book never falls into too much explanation. And the plot is satisfyingly twisty. It's an action story plot, to be clear: don't expect deep puzzles or complex deduction. But there are enough players and hidden motives to keep things interesting. The downside is that I didn't like Kangaroo very much. He's a bit of an ass. Some of this goes with the spy novel territory, and some of it is good (if occasionally grating) characterization. Kangaroo doesn't know how to turn off the part of his brain that makes everything a mission. But his flippant, know-it-all attitude got on my nerves after a book full of first-person narration, and while (full credit to Curtis here) the romance in this book is clearly consensual and stays well away from the creepy romances so common in spy stories, the love-at-first sight bits and some of Kangaroo's awkward reactions provoked more eye-rolling than enjoyment. A lot of this is just personal taste, but that's the peril of books told with first-person narration. The reader has to really like the protagonist to spend a whole book in their head. If that relationship doesn't click, the supporting characters have a harder time salvaging the experience. Waypoint Kangaroo avoids the problem of too many loving descriptions of guns, partly because it's a spy novel and instead has loving descriptions of spy equipment in a future that supports implanted devices. I think there was a smidgen too much of this, but it was within genre conventions and spy stuff is more interesting than guns. But (and I admit that this is probably idiosyncratic), it also had way too many loving descriptions of alcohol and one drunk scene. I don't care to ever read another book with a drunk protagonist (particularly first-person), and I care considerably less about alcohol than I do about spy equipment or guns. That said, I still liked this well enough that I'll probably buy the sequel. (No cliffhangers; Waypoint Kangaroo is a complete story. But this is a character who could easily support a long episodic series.) The pocket is a neat gimmick, the world background is at least mildly interesting, and some of the supporting characters were excellent. (Particularly the security chief and the engineer.) I might even warm to Kangaroo over time if subsequent stories stay more on his creative fast-talking rather than his drinking and awkward romances. I don't think this is quite good enough for me to recommend it, but if you're in the mood for a light and fast-moving first-person Bond-style story with science fiction trappings, it does deliver. Rating: 6 out of 10

Here's what happened in the Reproducible Builds effort between Sunday October 15 and Saturday October 21 2017:

• The Tails project published a report on how they made their ISO images reproducible.
• dpkg 1.19.0 was uploaded, including support for:
  • Ordering the "unused substitution" warnings to prevent superfluous differences between logs of package builds on the Reproducible Builds test framework. (#870221)
  • A new Build-Kernel-Version field in .buildinfo files that can be generated with a new dpkg-genbuildinfo --always-include-kernel option. (#873937)

Past events

• On Saturday 21st October, Holger Levsen presented at All Systems Go! in Berlin, Germany on reproducible builds. A video recording is available already.

Upcoming events

• On Tuesday 24th October, Chris Lamb will present at All Things Open 2017 in Raleigh, NC, USA.
• On Wednesday 25th October, Holger Levsen will present at the Open Source Summit Europe in Prague, Czech Republic.
• On Saturday 28th October, Chris Lamb will present at freenode.live in Bristol, UK.
• From October 31st November 2nd we will be holding the 3rd Reproducible Builds summit in Berlin, Germany. If you are working in the field of reproducible builds, you should definitely attend. Please see our public invitation mail and contact us if you have any questions.

New York University sessions A three week session will be held at New York University to work on reproducibilty issues in conjunction with the reproducible builds community. Students from the Application Security course will be working for two weeks to work on the reproducible builds effort.

• On Tuesday 24th Oct Ed Maste from FreeBSD will be presenting some reproducible builds work for students.
• On From Tuesday 24th of October to Monday 7th of November students will work on fixing reproducibility issues brought up by the community. A milestone presentation will be held by Santiago Torres-Arias and Preston Moore.
• On Tuesday 7th November Holger Levsen will join the NYU team to wrap up the work.

Packages reviewed and fixed, and bugs filed

• Adrian Bunk:
  • #878883 filed against stoken.
  • #878896 filed against liquidsoap.
  • #878980 filed against belenios.
  • #879042 filed against tuxpaint-config.
  • #879223 filed against websockify.
• Chris Lamb:
  • #878707 filed against python-amqp (randomness in documentation).
  • #878708 filed against geographiclib (build paths).
  • #879169 filed against live-build (timestamps).
• Gilles Filippini:
  • #878818 filed against ovito.

The following reproducible builds-related NMUs were accepted:

• Chris Lamb:
  • gerstensaft (#777414)
  • miniupnpd (#860266)
  • rest2web (#833438)

Patches sent upstream:

• Bernhard M. Wiedemann:
  • singularity (tar+gz)
  • redis (date)
  • tbb (date)
  • nested (sort)
  • nested (date)

Reviews of unreproducible packages 41 package reviews have been added, 119 have been updated and 54 have been removed in this week, adding to our knowledge about identified issues. 2 issue types were removed as they were fixed:

• too_much_input_for_diff
• docbook_to_man_one_byte_delta

Weekly QA work During our reproducibility testing, FTBFS bugs have been detected and reported by:

• Aaron M. Ucko (1)
• Adrian Bunk (49)
• Anthony DeRobertis (1)
• Daniel Schepler (1)
• Gilles Filippini (1)
• James Cowgill (1)
• Matthias Klose (1)
• Matthias Klumpp (1)
• Nobuhiro Iwamatsu (1)

diffoscope development

• Ximin Luo:
  • Tentative support for for parallel diffs

strip-nondeterminism development Version 0.039-1 was uploaded to unstable by Chris Lamb. It included contributions already covered by posts of the previous weeks, including:

• Chris Lamb:
  • Clojure considers the .class file to be stale if it shares the same timestamp of the .clj. We thus adjust the timestamps of the .clj to always be younger. (#877418)
  • dh_strip_nondeterminism: Log which handler processed a file. (#876140)
  • bin/strip-nondeterminism: Print a warning in --verbose mode if no canonical time specified.
  • Use HTTPS URI in debian/watch.

reprotest development

• Ximin Luo:
  • Hopefully fix the autopkgtest tests
• Santiago Torres-Arias:
  • An Arch Linux User Repository package for reprotest has been created.]

tests.reproducible-builds.org

• Holger Levsen:
  • Install rustc on Jenkins for the reproducible-html-build-path-prefix-map-spec job.
• Mattia Rizzolo:
  • health_check: Include the running kernel version when reporting multiple kernel installed in /boot.

Website updates

• Holger Levsen:
  • Berlin 2017:
    • add Qubes OS to participating projects
    • Add NetBSD and EdgeBSD to participating projects
    • Add repeatr.io to participating projects
    • Add disclaimer why only so few projects are listed
    • Add link to Google maps and name the 2nd next subway station on a different line
    • Add first 4 participating projects

Misc. This week's edition was written by Bernhard M. Wiedemann, Chris Lamb, Holger Levsen, Santiago Torres & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists.

Here s my weekly report for week 42 of 2017. In this week I have replaced my spacebar, failed to replace a HDD and begun the process to replace my YubiKey.

Debian Eariler in the week I blogged about powerline-taskwarrior . There is a new upstream version available that includes the patches I had produced for Python 2 support and I have filed #879225 to remind me to package this. The state of emscripten is still not great, and as I don t have the time to chase this up and I certainly don t have the time to fix it myself, I ve converted the ITP for csdr to an RFP. As I no longer have the time to maintain map.debian.net, I have released this domain name and published the sources behind the service.

• Bugs opened: #879225

Tor Project There was a request to remove the $ from family fingerprint on Atlas. These actually come from Onionoo and we have decided to fix this in Onionoo, but I did push a small fix for Atlas this week that makes sure that Atlas doesn t care if there are $ prefixes or not. I requested that a Trac component be created for metrics-bot. I wrote a seperate post about metrics-bot. I also attended the weekly metrics team meeting.

• Bugs opened: #23926, #23929, #23933, #23934, #23935, #23936, #23937, #23938, #23939, #23941

Sustainability I believe it is important to be clear not only about the work I have already completed but also about the sustainability of this work into the future. I plan to include a short report on the current sustainability of my work in each weekly report. I have not had any free software related expenses this week. The current funds I have available for equipment, travel and other free software expenses remains 60.52. I do not believe that any hardware I rely on is looking at imminent failure. I do not find it likely that I ll be travelling to Cambridge for the miniDebConf as the train alone would be around 350 and hotel accomodation a further 600 (to include both me and Ana).

Here's what happened in the Reproducible Builds effort between Sunday October 8 and Saturday October 14 2017: Upcoming events

• On Saturday 21st October, Holger Levsen will present at All Systems Go! in Berlin, Germany on reproducible builds.
• On Tuesday 24th October, Chris Lamb will present at All Things Open 2017 in Raleigh, NC, USA on reproducible builds.
• On Wednesday 25th October, Holger Levsen will present at the Open Source Summit Europe in Prague, Czech Republic on reproducible builds.
• From October 31st - November 2nd we will be holding the 3rd Reproducible Builds summit in Berlin. If you are working in the field of reproducible builds, you should totally be there. Please contact us if you have any questions! Quoting from the public invitation mail:

  These dates are inclusive, ie. the summit will be 3 full days from "9 to 5".
  Best arrive on Monday October 30th and leave on the evening of Thursday, 3rd
  at the earliest.
  Meeting content
  ===============
  The exact content of the meeting is going to be shaped by the
  participants, but here are the main goals:
   - Update & exchange about the status of reproducible builds in various
     projects.
   - Establish spaces for more strategic and long-term thinking than is possible
     in virtual channels.
   - Improve collaboration both between and inside projects.
   - Expand the scope and reach of reproducible builds to more projects.
   - Brainstorming / Designing several things, eg:
    - designing tools enabling end-users to get the most benefits from
      reproducible builds.
    - design of back-ends needed for that.
   - Work together and hack on solutions.
  There will be a huge variety of topics to be discussed. To give a few
  examples:
  - continuing design and development work on .buildinfo infrastructure
  - build-path issues everywhere
  - future directions for diffoscope, reprotest & strip-nondeterminism
  - reproducing signed artifacts such as RPMs
  - discussing formats and tools we can share
  - sharing proposals for standards and documentation helpful to spreading the
    reproducible effort
  - and many many more.
  Please think about what you want discuss, brainstorm & learn about at this
  meeting!
  Schedule
  ========
  Preliminary schedule for the three days:
  9:00 Welcome and breakfast
  9:30 Meeting starts
  12:30 Lunch
  17:00 End of the official schedule
  Gunner and Beatrice from Aspiration will help running the meeting. We will
  collect your input in subsequent emails to make the best of everyone's time.
  Feel free to start thinking about what you want to achieve there. We will also
  adjust topics as the meeting goes.
  Please note that we are very likely to spend large parts of the meeting away
  from laptops and closer to post-it notes. So make sure you've answered any
  critical emails *before* Tuesday morning! :)
  

Reproducible work in other projects Pierre Pronchery reported that that he has built the foundations for doing more reproducibility work in NetBSD. Packages fixed Upstream bugs and patches:

• Bernhard M. Wiedemann:
  • qutim used RANDOM which is unpredictable and unreproducible.
  • dpdk used locale-dependent sort.

Reproducibility non-maintainer uploads in Debian:

• Chris Lamb:
  • mailfront for bugs #777431 & #847020.
  • plib-doc for bugs #778971 & #557676.
  • ipsvd for bugs #777417 & #846890.
• Holger Levsen
  • keyutils for bug #828681.

QA fixes in Debian:

• Adrian Bunk:
  • #878329 filed against sonic-visualiser.
  • #878333 filed against tree-puzzle.

Reviews of unreproducible packages 6 package reviews have been added, 30 have been updated and 37 have been removed in this week, adding to our knowledge about identified issues. Weekly QA work During our reproducibility testing, FTBFS bugs have been detected and reported by:

• Adrian Bunk (40)
• Eric Valette (1)
• Markus Koschany (1)

diffoscope development

• Ximin Luo:
  • Containers: diff the metadata of containers in one central location in the code, so that deep-diff works between all combinations of different container types. This lets us finally close #797759.
  • Tests: add a complete set of cases to test all pairs of container types.
• Chris Lamb:
  • Temporarily skip the test for ps2ascii(1) in ghostscript > 9.21 which now outputs text in a slightly different format.
  • UI wording improvements.

reprotest development Version 0.7.3 was uploaded to unstable by Ximin Luo. It included contributions already covered by posts of the previous weeks, as well as new ones:

• Ximin Luo:
  • Add a --env-build option for testing builds under different sets of environment variables. This is meant to help the discussion over at #876055 about how we should deal with different types of environment variables in a stricter definition of reproducibility.
  • UI and logging tweaks and improvements.
  • Simplify the _shell_ast module and merge it into shell_syn.

Misc. This week's edition was written by Ximin Luo, Chris Lamb and Holger Levsen & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists.

Confession time: I started making these posts (eons ago) because a close friend did as well, and I enjoyed reading them. But the main reason why I continue is because the primary way I have to keep track of the books I've bought and avoid duplicates is, well, grep on these posts. I should come up with a non-bullshit way of doing this, but time to do more elegant things is in short supply, and, well, it's my blog. So I'm boring all of you who read this in various places with my internal bookkeeping. I do try to at least add a bit of commentary. This one will be more tedious than most since it includes five separate Humble Bundles, which increases the volume a lot. (I just realized I'd forgotten to record those purchases from the past several months.) First, the individual books I bought directly: Ilona Andrews Sweep in Peace (sff)
Ilona Andrews One Fell Sweep (sff)
Steven Brust Vallista (sff)
Nicky Drayden The Prey of Gods (sff)
Meg Elison The Book of the Unnamed Midwife (sff)
Pat Green Night Moves (nonfiction)
Ann Leckie Provenance (sff)
Seanan McGuire Once Broken Faith (sff)
Seanan McGuire The Brightest Fell (sff)
K. Arsenault Rivera The Tiger's Daughter (sff)
Matthew Walker Why We Sleep (nonfiction)
Some new books by favorite authors, a few new releases I heard good things about, and two (Night Moves and Why We Sleep) from references in on-line articles that impressed me. The books from security bundles (this is mostly work reading, assuming I'll get to any of it), including a blockchain bundle: Wil Allsop Unauthorised Access (nonfiction)
Ross Anderson Security Engineering (nonfiction)
Chris Anley, et al. The Shellcoder's Handbook (nonfiction)
Conrad Barsky & Chris Wilmer Bitcoin for the Befuddled (nonfiction)
Imran Bashir Mastering Blockchain (nonfiction)
Richard Bejtlich The Practice of Network Security (nonfiction)
Kariappa Bheemaiah The Blockchain Alternative (nonfiction)
Violet Blue Smart Girl's Guide to Privacy (nonfiction)
Richard Caetano Learning Bitcoin (nonfiction)
Nick Cano Game Hacking (nonfiction)
Bruce Dang, et al. Practical Reverse Engineering (nonfiction)
Chris Dannen Introducing Ethereum and Solidity (nonfiction)
Daniel Drescher Blockchain Basics (nonfiction)
Chris Eagle The IDA Pro Book, 2nd Edition (nonfiction)
Nikolay Elenkov Android Security Internals (nonfiction)
Jon Erickson Hacking, 2nd Edition (nonfiction)
Pedro Franco Understanding Bitcoin (nonfiction)
Christopher Hadnagy Social Engineering (nonfiction)
Peter N.M. Hansteen The Book of PF (nonfiction)
Brian Kelly The Bitcoin Big Bang (nonfiction)
David Kennedy, et al. Metasploit (nonfiction)
Manul Laphroaig (ed.) PoC GTFO (nonfiction)
Michael Hale Ligh, et al. The Art of Memory Forensics (nonfiction)
Michael Hale Ligh, et al. Malware Analyst's Cookbook (nonfiction)
Michael W. Lucas Absolute OpenBSD, 2nd Edition (nonfiction)
Bruce Nikkel Practical Forensic Imaging (nonfiction)
Sean-Philip Oriyano CEHv9 (nonfiction)
Kevin D. Mitnick The Art of Deception (nonfiction)
Narayan Prusty Building Blockchain Projects (nonfiction)
Prypto Bitcoin for Dummies (nonfiction)
Chris Sanders Practical Packet Analysis, 3rd Edition (nonfiction)
Bruce Schneier Applied Cryptography (nonfiction)
Adam Shostack Threat Modeling (nonfiction)
Craig Smith The Car Hacker's Handbook (nonfiction)
Dafydd Stuttard & Marcus Pinto The Web Application Hacker's Handbook (nonfiction)
Albert Szmigielski Bitcoin Essentials (nonfiction)
David Thiel iOS Application Security (nonfiction)
Georgia Weidman Penetration Testing (nonfiction)
Finally, the two SF bundles: Buzz Aldrin & John Barnes Encounter with Tiber (sff)
Poul Anderson Orion Shall Rise (sff)
Greg Bear The Forge of God (sff)
Octavia E. Butler Dawn (sff)
William C. Dietz Steelheart (sff)
J.L. Doty A Choice of Treasons (sff)
Harlan Ellison The City on the Edge of Forever (sff)
Toh Enjoe Self-Reference ENGINE (sff)
David Feintuch Midshipman's Hope (sff)
Alan Dean Foster Icerigger (sff)
Alan Dean Foster Mission to Moulokin (sff)
Alan Dean Foster The Deluge Drivers (sff)
Taiyo Fujii Orbital Cloud (sff)
Hideo Furukawa Belka, Why Don't You Bark? (sff)
Haikasoru (ed.) Saiensu Fikushon 2016 (sff anthology)
Joe Haldeman All My Sins Remembered (sff)
Jyouji Hayashi The Ouroboros Wave (sff)
Sergei Lukyanenko The Genome (sff)
Chohei Kambayashi Good Luck, Yukikaze (sff)
Chohei Kambayashi Yukikaze (sff)
Sakyo Komatsu Virus (sff)
Miyuki Miyabe The Book of Heroes (sff)
Kazuki Sakuraba Red Girls (sff)
Robert Silverberg Across a Billion Years (sff)
Allen Steele Orbital Decay (sff)
Bruce Sterling Schismatrix Plus (sff)
Michael Swanwick Vacuum Flowers (sff)
Yoshiki Tanaka Legend of the Galactic Heroes, Volume 1: Dawn (sff)
Yoshiki Tanaka Legend of the Galactic Heroes, Volume 2: Ambition (sff)
Yoshiki Tanaka Legend of the Galactic Heroes, Volume 3: Endurance (sff)
Tow Ubukata Mardock Scramble (sff)
Sayuri Ueda The Cage of Zeus (sff)
Sean Williams & Shane Dix Echoes of Earth (sff)
Hiroshi Yamamoto MM9 (sff)
Timothy Zahn Blackcollar (sff)
Phew. Okay, all caught up, and hopefully won't have to dump something like this again in the near future. Also, more books than I have any actual time to read, but what else is new.

Last saturday the Japanese TeX User Meeting took place in Fujisawa, Kanagawa. For those who have been at the TUG 2013 in Tokyo you will remember that the Japanese TeX community is quite big and vibrant. On Saturday about 50 users and developers gathered for a set of talks on a variety of topics. The first talk was by Keiichiro Shikano ( ) on using Markup text to generate (La)TeX and HTML. He presented a variety of markup formats, including his own tool xml2tex. The second talk was my Masamichi Hosoda ( ) on reducing the size of PDF files using PDFmark extraction. As a contributor to many projects including Texinfo and LilyPond, Masamichi Hosoda tells us horror stories about multiple font embedding in the manual of LilyPond, the permanent need for adaption to newer Ghostscript versions, and the very recent development in Ghostscript prohibiting the merge of font definitions in PDF files. Next up was Yusuke Terada ( ) on grading exams using TeX. Working through hundreds and hundreds of exams and do the grading is something many of us are used to and I think nobody really enjoys it. Yusuke Terada has combined various tools, including scans, pdf merging using pdfpages, to generate gradable PDF which were then checked on an iPad. On the way he did hit some limits in dvipdfmx on the number of images, but this was obviously only a small bump on the road. Now if that could be automatized as a nice application, it would be a big hit I guess! The forth talk was by Satoshi Yamashita ( ) on the preparation of slides using KETpic. KETpic is a long running project by Setsuo Takato ( ) for the generation of graphics, in particular using Cinderella. KETpic and KETcindy integrates with lots of algebraic and statistical programs (R, Maxima, SciLab, ) and has a long history of development. Currently there are activities to incorporate it into TeX Live. The fifth talk was by Takuto Asakura ( ) on programming TeX using expl3, the main building block of the LaTeX3 project and already adopted by many TeX developers. Takuto Asakura came to fame on this years TUG/BachoTeX 2017 when he won the W. J. Martin Prize for his presentation Implementing bioinformatics algorithms in TeX. I think we can expect great new developments from Takuto! The last talk was by myself on fmtutil and updmap, two of the main management programs in any TeX installation, presenting the changes introduced over the last year, including the most recent release of TeX Live. Details have been posted on my blog, and a lengthy article in TUGboat 38:2, 2017 is available on this topic, too. After the conference about half of the participants joined a social dinner in a nearby Izakaya, followed by a after-dinner beer tasting at a local craft beer place. Thanks to Tatsuyoshi Hamada for the organization. As usual, the Japanese TeX User Meetings are a great opportunity to discuss new features and make new friends. I am always grateful to be part of this very nice community! I am looking forward to the next year s meeting.

An earlier article showed that private key storage is an important problem to solve in any cryptographic system and established keycards as a good way to store private key material offline. But which keycard should we use? This article examines the form factor, openness, and performance of four keycards to try to help readers choose the one that will fit their needs. I have personally been using a YubiKey NEO, since a 2015 announcement on GitHub promoting two-factor authentication. I was also able to hook up my SSH authentication key into the YubiKey's 2048 bit RSA slot. It seemed natural to move the other subkeys onto the keycard, provided that performance was sufficient. The mail client that I use, (Notmuch), blocks when decrypting messages, which could be a serious problems on large email threads from encrypted mailing lists. So I built a test harness and got access to some more keycards: I bought a FST-01 from its creator, Yutaka Niibe, at the last DebConf and Nitrokey donated a Nitrokey Pro. I also bought a YubiKey 4 when I got the NEO. There are of course other keycards out there, but those are the ones I could get my hands on. You'll notice none of those keycards have a physical keypad to enter passwords, so they are all vulnerable to keyloggers that could extract the key's PIN. Keep in mind, however, that even with the PIN, an attacker could only ask the keycard to decrypt or sign material but not extract the key that is protected by the card's firmware.

Form factor The four keycards have similar form factors: they all connect to a standard USB port, although both YubiKey keycards have a capacitive button by which the user triggers two-factor authentication and the YubiKey 4 can also require a button press to confirm private key use. The YubiKeys feel sturdier than the other two. The NEO has withstood two years of punishment in my pockets along with the rest of my "real" keyring and there is only minimal wear on the keycard in the picture. It's also thinner so it fits well on the keyring. The FST-01 stands out from the other two with its minimal design. Out of the box, the FST-01 comes without a case, so the circuitry is exposed. This is deliberate: one of its goals is to be as transparent as possible, both in terms of software and hardware design and you definitely get that feeling at the physical level. Unfortunately, that does mean it feels more brittle than other models: I wouldn't carry it in my pocket all the time, although there is a case that may protect the key a little better, but it does not provide an easy way to hook it into a keyring. In the group picture above, the FST-01 is the pink plastic thing, which is a rubbery casing I received along with the device when I got it. Notice how the USB connectors of the YubiKeys differ from the other two: while the FST-01 and the Nitrokey have standard USB connectors, the YubiKey has only a "half-connector", which is what makes it thinner than the other two. The "Nano" form factor takes this even further and almost disappears in the USB port. Unfortunately, this arrangement means the YubiKey NEO often comes loose and falls out of the USB port, especially when connected to a laptop. On my workstation, however, it usually stays put even with my whole keyring hanging off of it. I suspect this adds more strain to the host's USB port but that's a tradeoff I've lived with without any noticeable wear so far. Finally, the NEO has this peculiar feature of supporting NFC for certain operations, as LWN previously covered, but I haven't used that feature yet. The Nitrokey Pro looks like a normal USB key, in contrast with the other two devices. It does feel a little brittle when compared with the YubiKey, although only time will tell how much of a beating it can take. It has a small ring in the case so it is possible to carry it directly on your keyring, but I would be worried the cap would come off eventually. Nitrokey devices are also two times thicker than the Yubico models which makes them less convenient to carry around on keyrings.

Open and closed designs The FST-01 is as open as hardware comes, down to the PCB design available as KiCad files in this Git repository. The software running on the card is the Gnuk firmware that implements the OpenPGP card protocol, but you can also get it with firmware implementing a true random number generator (TRNG) called NeuG (pronounced "noisy"); the device is programmable through a standard Serial Wire Debug (SWD) port. The Nitrokey Start model also runs the Gnuk firmware. However, the Nitrokey website announces only ECC and RSA 2048-bit support for the Start, while the FST-01 also supports RSA-4096. Nitrokey's founder Jan Suhr, in a private email, explained that this is because "Gnuk doesn't support RSA-3072 or larger at a reasonable speed". Its devices (the Pro, Start, and HSM models) use a similar chip to the FST-01: the STM32F103 microcontroller. Nitrokey also publishes its hardware designs, on GitHub, which shows the Pro is basically a fork of the FST-01, according to the ChangeLog. I opened the case to confirm it was using the STM MCU, something I should warn you against; I broke one of the pins holding it together when opening it so now it's even more fragile. But at least, I was able to confirm it was built using the STM32F103TBU6 MCU, like the FST-01. But this is where the comparison ends: on the back side, we find a SIM card reader that holds the OpenPGP card that, in turn, holds the private key material and does the cryptographic operations. So, in effect, the Nitrokey Pro is really a evolution of the original OpenPGP card readers. Nitrokey confirmed the OpenPGP card featured in the Pro is the same as the one shipped by the Free Software Foundation Europe (FSFE): the BasicCard built by ZeitControl. Those cards, however, are covered by NDAs and the firmware is only partially open source. This makes the Nitrokey Pro less open than the FST-01, but that's an inevitable tradeoff when choosing a design based on the OpenPGP cards, which Suhr described to me as "pretty proprietary". There are other keycards out there, however, for example the SLJ52GDL150-150k smartcard suggested by Debian developer Yves-Alexis Perez, which he prefers as it is certified by French and German authorities. In that blog post, he also said he was experimenting with the GPL-licensed OpenPGP applet implemented by the French ANSSI. But the YubiKey devices are even further away in the closed-design direction. Both the hardware designs and firmware are proprietary. The YubiKey NEO, for example, cannot be upgraded at all, even though it is based on an open firmware. According to Yubico's FAQ, this is due to "best security practices": "There is a 'no upgrade' policy for our devices since nothing, including malware, can write to the firmware." I find this decision questionable in a context where security updates are often more important than trying to design a bulletproof design, which may simply be impossible. And the YubiKey NEO did suffer from critical security issue that allowed attackers to bypass the PIN protection on the card, which raises the question of the actual protection of the private key material on those cards. According to Niibe, "some OpenPGP cards store the private key unencrypted. It is a common attitude for many smartcard implementations", which was confirmed by Suhr: "the private key is protected by hardware mechanisms which prevent its extraction and misuse". He is referring to the use of tamper resistance. After that security issue, there was no other option for YubiKey NEO users than to get a new keycard (for free, thankfully) from Yubico, which also meant discarding the private key material on the key. For OpenPGP keys, this may mean having to bootstrap the web of trust from scratch if the keycard was responsible for the main certification key. But at least the NEO is running free software based on the OpenPGP card applet and the source is still available on GitHub. The YubiKey 4, on the other hand, is now closed source, which was controversial when the new model was announced last year. It led the main Linux Foundation system administrator, Konstantin Ryabitsev, to withdraw his endorsement of Yubico products. In response, Yubico argued that this approach was essential to the security of its devices, which are now based on "a secure chip, which has built-in countermeasures to mitigate a long list of attacks". In particular, it claims that:

A commercial-grade AVR or ARM controller is unfit to be used in a security product. In most cases, these controllers are easy to attack, from breaking in via a debug/JTAG/TAP port to probing memory contents. Various forms of fault injection and side-channel analysis are possible, sometimes allowing for a complete key recovery in a shockingly short period of time.

While I understand those concerns, they eventually come down to the trust you have in an organization. Not only do we have to trust Yubico, but also hardware manufacturers and designs they have chosen. Every step in the hidden supply chain is then trusted to make correct technical decisions and not introduce any backdoors. History, unfortunately, is not on Yubico's side: Snowden revealed the example of RSA security accepting what renowned cryptographer Bruce Schneier described as a "bribe" from the NSA to weaken its ECC implementation, by using the presumably backdoored Dual_EC_DRBG algorithm. What makes Yubico or its suppliers so different from RSA Security? Remember that RSA Security used to be an adamant opponent to the degradation of encryption standards, campaigning against the Clipper chip in the first crypto wars. Even if we trust the Yubico supply chain, how can we trust a closed design using what basically amounts to security through obscurity? Publicly auditable designs are an important tradition in cryptography, and that principle shouldn't stop when software is frozen into silicon. In fact, a critical vulnerability called ROCA disclosed recently affects closed "smartcards" like the YubiKey 4 and allows full private key recovery from the public key if the key was generated on a vulnerable keycard. When speaking with Ars Technica, the researchers outlined the importance of open designs and questioned the reliability of certification:

Our work highlights the dangers of keeping the design secret and the implementation closed-source, even if both are thoroughly analyzed and certified by experts. The lack of public information causes a delay in the discovery of flaws (and hinders the process of checking for them), thereby increasing the number of already deployed and affected devices at the time of detection.

This issue with open hardware designs seems to be recurring topic of conversation on the Gnuk mailing list. For example, there was a discussion in September 2017 regarding possible hardware vulnerabilities in the STM MCU that would allow extraction of encrypted key material from the key. Niibe referred to a talk presented at the WOOT 17 workshop, where Johannes Obermaier and Stefan Tatschner, from the Fraunhofer Institute, demonstrated attacks against the STMF0 family MCUs. It is still unclear if those attacks also apply to the older STMF1 design used in the FST-01, however. Furthermore, extracted private key material is still protected by user passphrase, but the Gnuk uses a weak key derivation function, so brute-forcing attacks may be possible. Fortunately, there is work in progress to make GnuPG hash the passphrase before sending it to the keycard, which should make such attacks harder if not completely pointless. When asked about the Yubico claims in a private email, Niibe did recognize that "it is true that there are more weak points in general purpose implementations than special implementations". During the last DebConf in Montreal, Niibe explained:

If you don't trust me, you should not buy from me. Source code availability is only a single factor: someone can maliciously replace the firmware to enable advanced attacks.

Niibe recommends to "build the firmware yourself", also saying the design of the FST-01 uses normal hardware that "everyone can replicate". Those advantages are hard to deny for a cryptographic system: using more generic components makes it harder for hostile parties to mount targeted attacks. A counter-argument here is that it can be difficult for a regular user to audit such designs, let alone physically build the device from scratch but, in a mailing list discussion, Debian developer Ian Jackson explained that:

You don't need to be able to validate it personally. The thing spooks most hate is discovery. Backdooring supposedly-free hardware is harder (more costly) because it comes with greater risk of discovery. To put it concretely: if they backdoor all of them, someone (not necessarily you) might notice. (Backdooring only yours involves messing with the shipping arrangements and so on, and supposes that you specifically are of interest.)

Since that, as far as we know, the STM microcontrollers are not backdoored, I would tend to favor those devices instead of proprietary ones, as such a backdoor would be more easily detectable than in a closed design. Even though physical attacks may be possible against those microcontrollers, in the end, if an attacker has physical access to a keycard, I consider the key compromised, even if it has the best chip on the market. In our email exchange, Niibe argued that "when a token is lost, it is better to revoke keys, even if the token is considered secure enough". So like any other device, physical compromise of tokens may mean compromise of the key and should trigger key-revocation procedures.

Algorithms and performance To establish reliable performance results, I wrote a benchmark program naively called crypto-bench that could produce comparable results between the different keys. The program takes each algorithm/keycard combination and runs 1000 decryptions of a 16-byte file (one AES-128 block) using GnuPG, after priming it to get the password cached. I assume the overhead of GnuPG calls to be negligible, as it should be the same across all tokens, so comparisons are possible. AES encryption is constant across all tests as it is always performed on the host and fast enough to be irrelevant in the tests. I used the following:

• Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz running Debian 9 ("stretch"/stable amd64), using GnuPG 2.1.18-6 (from the stable Debian package)
• Nitrokey Pro 0.8 (latest firmware)
• FST-01, running Gnuk version 1.2.5 (latest firmware)
• YubiKey NEO OpenPGP applet 1.0.10 (not upgradable)
• YubiKey 4 4.2.6 (not upgradable)

I ran crypto-bench for each keycard, which resulted in the following:

Algorithm	Device	Mean time (s)
ECDH-Curve25519	CPU	0.036
	FST-01	0.135
RSA-2048	CPU	0.016
	YubiKey-4	0.162
	Nitrokey-Pro	0.610
	YubiKey-NEO	0.736
	FST-01	1.265
RSA-4096	CPU	0.043
	YubiKey-4	0.875
	Nitrokey-Pro	3.150
	FST-01	8.218

There we see the performance of the four keycards I tested, compared with the same operations done without a keycard: the "CPU" device. That provides the baseline time of GnuPG decrypting the file. The first obvious observation is that using a keycard is slower: in the best scenario (FST-01 + ECC) we see a four-fold slowdown, but in the worst case (also FST-01, but RSA-4096), we see a catastrophic 200-fold slowdown. When I presented the results on the Gnuk mailing list, GnuPG developer Werner Koch confirmed those "numbers are as expected":

With a crypto chip RSA is much faster. By design the Gnuk can't be as fast - it is just a simple MCU. However, using Curve25519 Gnuk is really fast.

And yes, the FST-01 is really fast at doing ECC, but it's also the only keycard that handles ECC in my tests; the Nitrokey Start and Nitrokey HSM should support it as well, but I haven't been able to test those devices. Also note that the YubiKey NEO doesn't support RSA-4096 at all, so we can only compare RSA-2048 across keycards. We should note, however, that ECC is slower than RSA on the CPU, which suggests the Gnuk ECC implementation used by the FST-01 is exceptionally fast. In discussions about improving the performance of the FST-01, Niibe estimated the user tolerance threshold to be "2 seconds decryption time". In a new design using the STM32L432 microcontroller, Aurelien Jarno was able to bring the numbers for RSA-2048 decryption from 1.27s down to 0.65s, and for RSA-4096, from 8.22s down to 3.87s seconds. RSA-4096 is still beyond the two-second threshold, but at least it brings the FST-01 close to the YubiKey NEO and Nitrokey Pro performance levels. We should also underline the superior performance of the YubiKey 4: whatever that thing is doing, it's doing it faster than anyone else. It does RSA-4096 faster than the FST-01 does RSA-2048, and almost as fast as the Nitrokey Pro does RSA-2048. We should also note that the Nitrokey Pro also fails to cross the two-second threshold for RSA-4096 decryption. For me, the FST-01's stellar performance with ECC outshines the other devices. Maybe it says more about the efficiency of the algorithm than the FST-01 or Gnuk's design, but it's definitely an interesting avenue for people who want to deploy those modern algorithms. So, in terms of performance, it is clear that both the YubiKey 4 and the FST-01 take the prize in their own areas (RSA and ECC, respectively).

Conclusion In the above presentation, I have evaluated four cryptographic keycards for use with various OpenPGP operations. What the results show is that the only efficient way of storing a 4096-bit encryption key on a keycard would be to use the YubiKey 4. Unfortunately, I do not feel we should put our trust in such closed designs so I would argue you should either stick with 2048-bit encryption subkeys or keep the keys on disk. Considering that losing such a key would be catastrophic, this might be a good approach anyway. You should also consider switching to ECC encryption: even though it may not be supported everywhere, GnuPG supports having multiple encryption subkeys on a keyring: if one algorithm is unsupported (e.g. GnuPG 1.4 doesn't support ECC), it will fall back to a supported algorithm (e.g. RSA). Do not forget your previously encrypted material doesn't magically re-encrypt itself using your new encryption subkey, however. For authentication and signing keys, speed is not such an issue, so I would warmly recommend either the Nitrokey Pro or Start, or the FST-01, depending on whether you want to start experimenting with ECC algorithms. Availability also seems to be an issue for the FST-01. While you can generally get the device when you meet Niibe in person for a few bucks (I bought mine for around \$30 Canadian), the Seeed online shop says the device is out of stock at the time of this writing, even though Jonathan McDowell said that may be inaccurate in a debian-project discussion. Nevertheless, this issue may make the Nitrokey devices more attractive. When deciding on using the Pro or Start, Suhr offered the following advice:

In practice smart card security has been proven to work well (at least if you use a decent smart card). Therefore the Nitrokey Pro should be used for high security cases. If you don't trust the smart card or if Nitrokey Start is just sufficient for you, you can choose that one. This is why we offer both models.

So far, I have created a signing subkey and moved that and my authentication key to the YubiKey NEO, because it's a device I physically trust to keep itself together in my pockets and I was already using it. It has served me well so far, especially with its extra features like U2F and HOTP support, which I use frequently. Those features are also available on the Nitrokey Pro, so that may be an alternative if I lose the YubiKey. I will probably move my main certification key to the FST-01 and a LUKS-encrypted USB disk, to keep that certification key offline but backed up on two different devices. As for the encryption key, I'll wait for keycard performance to improve, or simply switch my whole keyring to ECC and use the FST-01 or Nitrokey Start for that purpose.

---

[The author would like to thank Nitrokey for providing hardware for testing.] This article first appeared in the Linux Weekly News.

FOSDEM is a free software event that offers open source communities a place to meet, share ideas and collaborate. It is renown for being highly developer-oriented and brings together 8000+ participants from all over the world. It is held in the city of Brussels (Belgium). FOSDEM 2018 will take place during the weekend of February 3rd-4th 2018. More details about the event can be found at http://www.fosdem.org Call for Participation The Retrocomputing DevRoom is a first-timer at FOSDEM, with talks about use of older computing hardware and software in modern times. Presentation topics could include but are not limited to:

• Emulation of old systems to run videogames, legacy software, etc
• Open source software emulation/simulation
• Open hardware
• Operating systems/executives for retrocomputers/retrosystems
• Uses of retrocomputing today
• Other retrosystems topics
• Opportunities in retrocomputing
• Round tables

You are not limited to slide presentations, of course. Be creative. However, FOSDEM is an open source conference, therefore we ask you to stay clear of marketing presentations. We are not afraid of technical stuff: devrooms are a place for development teams to meet, discuss, hack and publicly present their project s latest improvements and future directions. If you will have special needs for your talk (e. g. because you will need to plug some sort of a system), please note that clearly in your proposal so that we can provide it. You can use the Wikipedia definition of retrocomputing as a reference definition to see if you talk qualifies, although it is not exclusive: https://en.wikipedia.org/wiki/Retrocomputing Important dates

• 25 Nov 2017: submission deadline for talk proposals
• 15 Dec 2017: announcement of the final schedule
• 4 Feb 2018: Retrocomputing dev room

Useful information Use the FOSDEM Pentabarf tool to submit your proposal: https://penta.fosdem.org/submission/FOSDEM18 If necessary, create a Pentabarf account and activate it. Please reuse your account from previous years if you have already created it. Details on submission:

• In the Person section, provide First name, Last name (in the General tab), Email (in the Contact tab) and Bio ( Abstract field in the Description tab).
• Submit a proposal by clicking on Create event .
• Important! Select the Retrocomputing DevRoom track (on the General tab). If you do not select a track, then nobody, from any track, will look at your submission!
• Provide the title of your talk ( Event title in the General tab).
• Provide a description of the subject of the talk and the intended audience (in the Abstract field of the Description tab)
• Provide a rough outline of the talk or goals of the session (a short list of bullet points covering topics that will be discussed) in the Full description field in the Description tab
• Provide an expected length of your talk in the Duration field, including discussion. The default duration is 30 minutes.

Please note neither FOSDEM nor the Retrocomputing DevRoom will reimburse any expenses you incur Recording of talks The FOSDEM organizers plan to have live streaming and recording fully working, both for remote/later viewing of talks, and so that people can watch streams in the hallways when rooms are full. This requires speakers to consent to being recorded and streamed. If you plan to be a speaker, please understand that by doing so you implicitly give consent for your talk to be recorded and streamed. The recordings will be published under the same license as all FOSDEM content (CC-BY). Contact The Retrocomputing DevRoom is managed by Pau Garcia Quiles (retrocomputing-devroom-manager@fosdem.org). A mailing list of speakers, audience and the curious is available, please subscribe at https://lists.fosdem.org/listinfo/retrocomputing-devroom Hope to hear from you soon! And please forward this announcement.