Happy #ilovefs

Happy I love Free Software Day https://fsfe.org/campaigns/ilovefs/2016/!

http://ilovefs.org

My life has been full of Free Software for more than 15 years and listing all the software and projects I've used or interacted with would take a long post (and I would be sure to forget someone), so if you are reading this and are involved in Free Software: thank you! I may have used your work in the past, I may be using it some time in the future, or I may never use it personally, but you are making the world I live in a better place anyway.

Special thanks go to the local LUGs, where I've met my SO and to the @Debian project, where I've met a few people I can call friends.

@LIFO @Gruppo Linux Como #ilovefs

Today February 14th, the Free Software Foundation Europe (FSFE) celebrates the "I Love Free Software" day. I Love Free Software day is a day for Free Software users to appreciate and thank the contributors of their favourite software applications, projects and organisations. We take this opportunity to say "thank you" to all the Debian upstreams and downstreams, and all the Debian developers and contributors. Thanks for your work and dedication to free software! There are many ways to participate in this ILoveFS day and we encourage everybody to join in and celebrate. Show your love to Debian developers, contributors and teams virtually on social networks using the #ilovefs hashtag and spreading the word in your own social media circles, or by visiting the ILoveFS campaign website to find and use some of the promotional materials available such as postcards and banners. To learn more about the FSFE, you can read their announcement of this campaign or visit their general website.

Dear node.js/node-webkit people, what's the matter with you? I wanted to try out some stuff that requires node-webkit. So I try to use npm to download, build and install it, like CPAN would do. But then I see that the nodewebkit package is just a stub that downloads a 37MB file (using HTTP without TLS) containing pre-compiled binaries. Are you guys out of your minds? This is enough for me to never again get close to node.js and friends. I had already heard some awful stories, but this is just insane. Update: This was a rage post, and not really saying anything substantial, but I want to quote here the first comment reply from Christian as I think it is much more interesting:

I see a recurring pattern here: developers create something that they think is going to simplify distributing things by quite a bit, because what other people have been doing is way too complicated[tm]. In the initial iteration it usually turns out to have three significant problems:

• a nightmare from a security perspective
• there's no concern for stability, because the people working on it are devs and not people who have certain reliability requirements
• bundling other software is often considered a good idea, because it makes life so much easier[tm]

Given a couple of years they start to catch up where the rest of the world (e.g. GNU/Linux distributions) is - at least to some extent. And then their solution is actually of a similar complexity compared to what is in use by other people, because they slowly realize that what they're trying to do is actually not that simple and that other people who have done things before were not stupid and the complexity is actually necessary... Just give node.js 4 or 5 more years or so, then you won't be so disappointed. I've seen this pattern over and over again:

• the Ruby ecosystem was a catastrophe for quite some time (just ask e.g. the packages of Ruby software in distributions 4 or 5 years ago), and only now would I actually consider using things written in Ruby for anything productive
• docker and vagrant were initially not designed with security in mind when it came to downloading images - only in the last one or two years have there actually been solutions available that even do the most basic cryptographic verification
• the entire node.js ecosystem mess you're currently describing

Then the next new fad comes along in the development world and everything starts over again. The only thing that's unclear is what the next hype following this pattern is going to be.

And I also want to quote myself with what I think are some things you could do to improve this situation:

1. You want to make sure your build is reproducible (in the most basic sense of being re-buildable from scratch), that you are not building upon scraps of code that nobody knows where they came from, or which version they are. If possible, at the package level don't vendor dependencies, depend on the user having the other dependencies pre-installed. Building should be a mainly automatic task. Automation tools then can take care of that (cpan, pip, npm).
2. By doing this you are playing well with distributions, your software becomes available to people that can not live on the bleeding edge, and need to trust the traceability of the source code, stability, patching of security issues, etc.
3. If you must download a binary blob, for example what Debian non-free does for Adobe Flashplayer, then for the love of all that is sacred, use TLS and verify checksums!

8 comments

I have updated the openpht repository with builds of OpenPHT 1.5.1 for Debian/sid for both amd64 and i386 architecture. For those who have forgotten it, OpenPHT is the open source fork of Plex Home Theater that is used on RasPlex, see my last post concerning OpenPHT for details. sid and testing For sid use the following lines: You can also grab the binary for amd64 directly here for amd64 and i386, you can get the source package with jessie Builds for Debian stable release jessie are not done by now. The release file and changes file are signed with my official Debian key 0x860CDC13. Now be ready for enjoying the next movie!

Just over a year ago I implemented an optimization to the SPI core code in Linux that avoids some needless context switches to a worker thread in the main data path that most clients use. This was really nice, it was simple to do but saved a bunch of work for most drivers using SPI and made things noticeably faster. The code got merged in v4.0 and that was that, I kept on kicking a few more ideas for optimizations in this area around but that was that until the past month. What happened then was that for whatever reason people started picking up v4.0 and using it in production more. On some systems people started seeing problems when there was heavy SPI flash usage, often during things like distribution installation. In some cases the lockup detector fired, but the most entertaining error was that on Marvell Orion systems (which are single core) when the flash was being heavily used the SATA controller started having trouble handling interrupts. These problems all bisected down to the key commit in that series, 0461a4149836c79 (spi: Pump transfers inside calling context for spi_sync()). The problem is that there are a number of widely deployed SPI controllers out there that don t support DMA and instead require the CPU to explicitly read and write everything sent to and from registers in the controller. To make matters worse these accesses to the controller will usually take many CPU cycles to complete, each one stalling the CPU while they happen. This is fine for short transfers or if the CPU has nothing else to do but on a busy multitasking system it s an issue. Before the optimization the switches between the worker thread interacting with the hardware and the thread initiating the SPI operations provided breaks in this activity which allowed other things to switch in. Unfortunately when we optimize those away then if there s a lot of work for the controller being done from one thread then that thread can run for a long time without pause. The fix for affected drivers if there are no less CPU intensive ways of driving the hardware is to add some explicit sleeps into the driver itself, either at the end of the transfer_one() or perhaps in an unprepare_message() function. In a way I was quite pleased to see this, it was a clear demonstration that the optimization was having the intended effect though obviously users of affected systems will not find that so comforting. It s not the first time that making things faster or fixing a bug has revealed an underlying problem, I m sure it won t be the last.

More than 10 years ago, I launched Unhappy Birthday in a fit of copyrighteous exuberance. In the last decade, I have been interviewed on the CBC show WireTap and have received an unrelenting stream of hate mail from random strangers. With a recently announced settlement suggesting that Happy Birthday is on its way into the public domain, it s not possible for even the highest-protectionist in me to justify the continuation of the campaign in its original form. As a result, I ve suspended the campaign while I plan my next move. Here s the full text of the notice I posted on the Unhappy Birthday website:

Unfortunately, a series of recent legal rulings have forced us to suspend our campaign. In 2015, Time Warner s copyright claim to Happy Birthday was declared invalid. In 2016, a settlement was announced that calls for a judge to officially declare that the song is in the public domain. This is horrible news for the future of music. It is horrible news for anybody who cares that creators, their heirs, etc., are fairly remunerated when their work is performed. What incentive will there be for anybody to pen the next Happy Birthday knowing that less than a century after their deaths their estates and the large multinational companies that buy their estates might not be able to reap the financial rewards from their hard work and creativity? We are currently planning a campaign to push for a retroactive extension of copyright law to place Happy Birthday, and other works, back into the private domain where they belong! We believe this is a winnable fight. After all, copyright has been retroactively extended before! Stay tuned! In the meantime, we ll keep this page here for historical purposes.

Copyrighteous Benjamin Mako Hill (2016-02-11)

I found a bug in amanda-3.3.8 that was quickly fixed by upstream. Please upgrade to this version. The updates will go to collab-maint.The debs files for jessie are here: amanda-common_3.3.8-1_cal1_i386.deb amanda-server_3.3.8-1_cal1_i386.deb amanda-client_3.3.8-1_cal1_i386.deb Here comes the changelog:

amanda (1:3.3.8-1~cal1) unstable; urgency=low
  * New Upstream version
    * Changes for 3.3.8
      * s3 devices
          New NEARLINE S3-STORAGE-CLASS for Google storage.
          New AWS4 STORAGE-API
      * amcryptsimple
          Works with newer gpg2.
      * amgtar
          Default SPARSE value is NO if tar < 1.28.
          Because a bug in tar with some filesystem.
      * amstar
          support include in backup mode.
      * ampgsql
          Add FULL-WAL property.
      * Many bugs fix.
    * Changes for 3.3.7p1
      * Fix build in 3.3.7
    * Changes for 3.3.7
      * amvault
          new --no-interactivity argument.
          new --src-labelstr argument.
      * amdump
          compute crc32 of the streams and write them to the debug files.
      * chg-robot
          Add a BROKEN-DRIVE-LOADED-SLOT property.
      * Many bugs fix.
  * Refreshed patches.
  * Dropped patches that were applied by the upstream: fix-misc-typos,
    automake-add-missing, fix-amcheck-M.patch,
    fix-device-src_rait-device.c, fix-amreport-perl_Amanda_Report_human.pm
  * Change the email of the maintainer.
  * "wrap-and-sort -at" all control files.
  * swig is a new build depend.
  * Bump standard version to 3.9.6, no changes needed.
  * Replace deprecated dependency perl5 by perl, (Closes: #808209), thank
    you Gregor Herrmann for the NMU.
  * New patch fix-amgtar-exclude to fix amgtar when the exclude file don't
    exist.
 -- Jose M Calhariz <jose@calhariz.com>  Thu, 11 Feb 2016 17:52:08 +0000

Tails (The amnesic incognito live system) is a live OS based on Debian GNU/Linux which aims at preserving the user's privacy and anonymity by using the Internet anonymously and circumventing censorship. Installed on a USB device, it is configured to leave no trace on the computer you are using unless asked explicitly. As of today, the people the most needy for digital security are not computer experts. Being able to get started easily with a new tool is critical to its adoption, and even more in high-risk and stressful environments. That's why we wanted to make it faster, simpler, and more secure to install Tails for new users. One of the components of Tails, the Tails Installer is now in Debian thanks to the Debian Privacy Tools Maintainers Team. Tails Installer is a graphical tool to install or upgrade Tails on a USB stick from an ISO image. It aims at making it easier and faster to get Tails up and running. The previous process for getting started with Tails was very complex and was problematic for less tech-savvy users. It required starting Tails three times, and copying the full ISO image onto a USB stick twice before having a fully functional Tails USB stick with persistence enabled. This can now be done simply by installing Tails Installer in your existing Debian system, using sid, stretch or jessie-backports, plugging a USB stick and choosing if one wants to update the USB stick or to install Tails using a previously downloaded ISO image. Tails Installer also helps Tails users to create an encrypted persistent storage for personal files and settings in the rest of the available space.

Debian LTS January was the ninth month I contributed to Debian LTS under the Freexian umbrella. In total I spent 13 hours working on:

• LTS Frontdesk duties like the triaging of 34 CVEs. That was about twice as much CVEs coming as during December's frontdesk work.
• I looked into what needs to be done DLA wise when we move from Squeeze to Wheezy. For that I added a script do find discrepancies between Squeeze LTS and Wheezy.
• I uploaded giflib to squeeze-lts(DLA-389-1), wheezy(#812363) and jessie(#812362) proposed updates.
• I forward ported the fix for CVE-2015-5291 for polarssl to Wheezy adding autopkgtests on the way (#812420) (forward port to Jessie happend in February)
• I forward ported a patch for freetype fixing CVE-2014-9674 to wheezy(DSA-3461-1) - Jessie being not affected.
• Finally I added some basic autopkgtests to icu (#813338).

There was no progress on using the same nss in all suites. This will continue in February as does the Squeeze-lts Wheezy forward porting. Other Debian stuff

• I uploaded libvirt 1.3.1~rc1 and 1.3.1~rc2 to experimental and 1.3.1 final to unstable.
• Released git-buildpackage 0.7.2

One of the difficulties of being a kernel maintainer for a busy subsystem is that you will often end up getting a lot of mail that requires reading and handling which in turn requires sending a lot of mail out in reply. Some of that requires thought and careful consideration but a lot of it is quite routine and (perhaps surprisingly) there is often more challenge in doing a good job of handling these routine messages. For a long time I used to hand write every reply I sent but the problem with doing that is that sending the same message a lot of times tends to result in the messages getting more and more brief as the message becomes routine and practised. Your words become more optimised and if you ve stopped thinking about the message before you ve finished typing it then there s a desire to finish the typing and get on to the next thing. This is I think a lot of the reputation that kernel maintainers have for being terse and unhelpful comes from messages that are very practised for someone sending them all the time aren t always going to be obvious or helpful for someone who s not so intimately familiar with what s going on. The good part of it is that everyone is getting a personalised response and it s easy to insert a comment about that specific situation when you re already replying but it s not clear that the tradeoff is a good one. What I ve started doing instead for most things is keeping a set of pre-written paragraphs for common cases that I can just insert into a mail and edit as needed. Hopefully it s working well for people, it means the replies are that bit more verbose than they might otherwise be (mainly adding an explanation of why a given thing is being asked for) but can easily be adapted as needed. The one exception is the Applied, thanks mails I used to send when I apply a patch (literally just saying that). Those are now automatically generated by the script I use to sync my local git repository with kernel.org and very much more verbose:

From: Mark Brown <broonie@kernel.org>
To: $ CCS 
Cc: $ LIST 
Subject: $ SUBJECT 
In-Reply-To: $ MSGID 
The patch
   $ TITLE 
has been applied to the $ REPO  tree at
   $ URL  $ BRANCH 
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

(unfortunately this bit seems to be something that it s worth pointing out)

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark

(the script does try to CC relevant lists). As well as giving people more information this also means that the mails only get sent out when things actually get published to my public repositories which avoids some confusion that used to happen sometimes with people getting my replies before I d pushed, especially when I d been working with poor connectivity as often happens when travelling. On the down side it s very much an obvious form letter which some people don t like and which can make people glaze over. My hope with this is to make things easier on average for patch submitters and easier for me, feedback on the scripted e-mails appears to be good thus far and the goal with the pasted in content is that it should be less obvious that it s happening so I d expect less feedback there.

It's that time of the year where I go to FOSDEM (Free and Open Source Software Developers' European Meeting). The keynotes and the maintracks are very good, with good presentations and contents. It's very dificult to choose what talks to see, what talks to see later in video and what talks to loose. What I leave here is my selection of talks. This selection is representative of my tastes, not of the quality of the presentations. I will give links for material that is available now. I will do periodic updates when the new material is available: video or slides.

• Welcome to FOSDEM 2016

• systemd and Where We Want to Take the Basic Linux Userspace in 2016

• Ian Murdock - In Memoriam

• Putting 8 Million People on the Map

• Closing FOSDEM 2016

• Re-thinking Linux Distributions

• Beyond reproducible builds

• What Do Code Reviews at Microsoft and in Open Source Projects Have in Common?

• Rearchitecting Linux I/O towards Petascale Storage

• Digital Hardware Design: Why is it still so hard?

• Libreboot - free your BIOS today!

• How to design a Linux kernel API

• Scaling and Securing LibreOffice Online

• How containers work in Linux

• Micro-datacenter with Raspberry Pi and Kubernetes

• Live Migration of Virtual Machines From the Bottom Up

• Interesting Things You Can Do With ZFS

• ElectroBSD - Getting a reproducible BSD out of the door

• Reproducible builds in FreeBSD packages

• An introduction to LXD

• Filesystem defragmentation strategies

• CGroups: resources management inside and outside of a container

• Powering Twitter's infrastructure with containers

• Make backups and versions available easy.

This article describes how to use systemd-networkd on Debian Edu 8.x (aka jessie) notebooks. What we have to deal with? At the schools we support we have several notebooks running Debian Edu 8.x (aka jessie) in the field. For school notebooks (classroom sets) we install the Debian Edu Workstation Profile. Those machines are mostly used over wireless network. We know that Debian Edu also offers a Roaming Workstation Profile at installation time, but with that profile chosen, user logins create local user accounts and local home directories on the notebooks (package: libpam-mklocaluser). For our customers, we do not want that. People using the school notebooks shall always work on their NFS home directories. School notebooks shall not be usable outside of the school network. Our woes... The default setup on Debian Edu jessie workstations regarding networking is this:

• systemd runs as PID 1
• ifupdown manages static network interfaces (eth0, etc.)
• NetworkManager manages wireless network interfaces
• for our customers we configured NetworkManager with a system-wide WiFi (WPA2-PSK) profile

We have observed various problems with that setup:

• By default, network interface eth0 is managed by ifupdown (via /etc/network/interfaces):
  

  auto eth0
  iface eth0 inet dhcp
  

  Woe no. 1: In combination with systemd, this results in a 120sec delay at system startup.

read more

Note to myself so I don't have to search for it the next time I've to answer security audit questions. If you're lucky and you're running Debian you can install pgpdump and use

gpg --export-options export-minimal --export $KEYID   pgpdump

to retrieve a human friendly output. If you're unlucky you have to use

gpg --export-options export-minimal --export $KEYID   gpg --list-packets

and match the CIPHER_ALGO_ and DIGEST_ALGO_ numbers with those in include/cipher.h. Found the information in this thread. Update: anarcat suggested to take a look at the tools contained in hopenpgp-tools.

Johannes Bechberger, while working on his Bachelor s thesis supervised by my colleague Andreas Zwinkau, has developed a performance benchmark runner and results visualizer called temci , and used GHC as a guinea pig. You can read his elaborate analysis on his blog. This is particularly interesting given recent discussions about GHC itself becoming slower and slower, as for example observed by Johannes Waldmann and Anthony Cowley. Johannes Bechberger s take-away is that, at least for the programs at hand (which were taken from the The Computer Language Benchmarks Game, there are hardly any changes worth mentioning, as most of the observed effects are less than a standard deviation and hence insignificant. He tries hard to distill some useful conclusions from the data; the one he finds are:

• Compile time does not vary significantly.
• The compiler flag -O2 indeed results in faster code than -O.
• With -O (but not -O2), GHC 8.0.1 is better than GHC 7.0.1. Maybe some optimizations were promoted to -O?

If you are interested, please head over to Johannes s post and look at the gory details of the analysis and give him feedback on that. Also, maybe his tool temci is something you want to try out? Personally, I find it dissatisfying to learn so little from so much work, but as he writes: It s so easy to lie with statistics. , and I might add lie to yourself , e.g. by ignoring good advise about standard deviations and significance. I m sure my tool gipeda (which powers perf.haskell.org) is guilty of that sin. Maybe a different selection of test programs would yield more insight; the benchmark s games programs are too small and hand-optimized, the nofib programs are plain old and the fibon collection has bitrotted. I would love to see a curated, collection of real-world programs, bundled with all dependencies and frozen to allow meaningful comparisons, but updated to a new, clearly marked revision, on a maybe bi-yearly basis maybe Haskell-SPEC-2016 if that were not a trademark infringement.

As well as the simple reading of a musical score is sufficient to an experienced musician to recognize the most velvety harmonic variations of an orchestral piece, so the apparent coldness of a fragment of program code can stimulate emotions of ecstatic contemplation in the developer.

Don t be misled by the simplicity of the laconic definition of the code as a sequence of instructions to be given to a computer to solve a specific problem. Generally, a problem has multiple solutions, the most simple and fast to implement, the most economical from the point of view of machine cycles or memory, the elegant solution and the makeshift one.

However, there is always a poetic solution, the one that has a particular and unusual beauty and that is always generated by the inexhaustible forge of the human intuition .

[Read More ]

Last week was really focused on code cleanups. The biggest change was removal of PmaAbsoluteUri configuration directive, which has caused quite some pain in past and is not really needed these days (when browsers support relative paths in the Location HTTP header). This lead to cleanup in other parts as well - support for dead Mozilla Prism is gone, used HTTPS for OpenStreetMap tiles (the map layer now works on HTTPS as well), removed ForceSSL configuration directive as this is something what really needs to be handled at web server level. To improve test coverage, several tests no longer require runkit as the header() call is wrapped within Response class and can be overridden for testing without using runkit. The list of handled issues is not that impressive this week:

• #11913 Fix #11864 Move Noselect method to makegrid.js
• #11412 Wrong redirect from SECURE connection to INSECURE
• #17 Increase "max_input_vars" value

Filed under: English phpMyAdmin 0 comments

In the last week of January, the project IT-Zukunft Schule (Logo EDV-Systeme GmbH and DAS-NETZWERKTEAM) had visitors from Norway: Klaus Ade Johnstad and Linnea Skogtvedt from LinuxAvdelingen [1] came by for exchanging insights, knowledge, technology, stories regarding IT services at school in Norway and Nothern Germany. This was our schedule... Tuesday

• 3pm Arrival of Klaus Ade and Linnea, meet up at LOGO with coffee and cake
• 4pm Planning the workshop, coming up with an agenda for the next two days (Klaus Ade, Andreas, Mike)
• 5pm Preparing OPSI demo sites (Mike, Linnea)
• 8pm Gr nkohl and Rotkohl and ... at Traum GmbH, Kiel (Klaus Ade, Linnea, Andreas, Mike)

Wednesday

• 8.30am more work on the OPSI demo site (Mike, Linnea)
• 10am pfSense (esp. captive portal functionality), backup solutions (Klaus Ade, all)
• 11am ITZkS overlay packages, basic principles of Debian packaging (Mike, special guests: Torsten, Lucian, Benni)
• 12am-2pm lunch break
• 2pm OPSI demonstration, discussion, foundation of the OpsiPackages project [2] (Mike)
• 4pm Puppet (Linnea)
• 7pm dinner time (eating in, Thai fast food :-) )
• 20pm Sepiida hacking (Mike, Linnea), customer care (Andreas, Klaus Ade)
• 22:30pm zZzZzZ time...

Thursday

read more

Following up on the hack of Matthieu - A one-liner to catch'em all! - and the recent features of Debsources I got the idea to modify a bit the one liner in order to retrieve the license of foo.bar. The script will calculate the SHA256 hash of the file and then query the Debsources API in order to retrieve the license of that particular file. Save the following in a file as license-of and add it in your $PATH

#!/bin/bash
function license-of  
    readlink -f $1   xargs dpkg-query --search   awk -F ": " ' print $1 '   xargs apt-cache showsrc   grep-dctrl -s 'Package' -n ''   awk -v sha="$(sha256sum $1   awk '  print $1  ')" -F " " ' print "https://sources.debian.net/copyright/api/sha256/?checksum="sha"&packagename="$1"" '   xargs curl -sS
 
CMD="$1"
license-of $ CMD 

Then you can try something like:

    license-of /usr/lib/python2.7/dist-packages/pip/exceptions.py

Notes:

• if the checksum is not found in the DB (compiled file, modified file, not part of any package) this will fail
• if the debian/copyright file of the specific package is not machine readable then you are out of luck!
• if there are more than 1 versions of the package you will get all the available information. If you want to get just testing then add "&suite=testing" after the &packagename="$1" in the debsources link.