I recently checked the Debian PHP 5.4 changelog and found out this message (5.4.45-0+deb7u3 and 5.4.45-0+deb7u4):

* most patches taken from https://github.com/kaplanlior/php-src
Thanks a lot to Lior Kaplan for providing them.

I was very pleased to see my work being used, and I hope this would save other time while providing PHP long term support. Also, while others do similar work (e.g. Remi from RedHat), it seems I m the only when that make this over GIT and with full references (e.g. commit info, CVE info and bug number). Comments and suggestions are always welcome either mail or even better a pull request.
Filed under: Debian GNU/Linux, PHP

The best known smart bulb setups (such as the Philips Hue and the Belkin Wemo) are based on Zigbee, a low-energy, low-bandwidth protocol that operates on various unlicensed radio bands. The problem with Zigbee is that basically no home routers or mobile devices have a Zigbee radio, so to communicate with them you need an additional device (usually called a hub or bridge) that can speak Zigbee and also hook up to your existing home network. Requests are sent to the hub (either directly if you're on the same network, or via some external control server if you're on a different network) and it sends appropriate Zigbee commands to the bulbs.

But requiring an additional device adds some expense. People have attempted to solve this in a couple of ways. The first is building direct network connectivity into the bulbs, in the form of adding an 802.11 controller. Go through some sort of setup process[1], the bulb joins your network and you can communicate with it happily. Unfortunately adding wifi costs more than adding Zigbee, both in terms of money and power - wifi bulbs consume noticeably more power when "off" than Zigbee ones.

There's a middle ground. There's a large number of bulbs available from Amazon advertising themselves as Bluetooth, which is true but slightly misleading. They're actually implementing Bluetooth Low Energy, which is part of the Bluetooth 4.0 spec. Implementing this requires both OS and hardware support, so older systems are unable to communicate. Android 4.3 devices tend to have all the necessary features, and modern desktop Linux is also fine as long as you have a Bluetooth 4.0 controller.

Bluetooth is intended as a low power communications protocol. Bluetooth Low Energy (or BLE) is even lower than that, running in a similar power range to Zigbee. Most semi-modern phones can speak it, so it seems like a pretty good choice. Obviously you lose the ability to access the device remotely, but given the track record on this sort of thing that's arguably a benefit. There's a couple of other downsides - the range is worse than Zigbee (but probably still acceptable for any reasonably sized house or apartment), and only one device can be connected to a given BLE server at any one time. That means that if you have the control app open while you're near a bulb, nobody else can control that bulb until you disconnect.

The quality of the bulbs varies a great deal. Some of them are pure RGB bulbs and incapable of producing a convincing white at a reasonable intensity[2]. Some have additional white LEDs but don't support running them at the same time as the colour LEDs, so you have the choice between colour or a fixed (and usually more intense) white. Some allow running the white LEDs at the same time as the RGB ones, which means you can vary the colour temperature of the "white" output.

But while the quality of the bulbs varies, the quality of the apps doesn't really. They're typically all dreadful, competing on features like changing bulb colour in time to music rather than on providing a pleasant user experience. And the whole "Only one person can control the lights at a time" thing doesn't really work so well if you actually live with anyone else. I was dissatisfied.

I'd met Mike Ryan at Kiwicon a couple of years back after watching him demonstrate hacking a BLE skateboard. He offered a couple of good hints for reverse engineering these devices, the first being that Android already does almost everything you need. Hidden in the developer settings is an option marked "Enable Bluetooth HCI snoop log". Turn that on and all Bluetooth traffic (including BLE) is dumped into /sdcard/btsnoop_hci.log. Turn that on, start the app, make some changes, retrieve the file and check it out using Wireshark. Easy.

Conveniently, BLE is very straightforward when it comes to network protocol. The only thing you have is GATT, the Generic Attribute Protocol. Using this you can read and write multiple characteristics. Each packet is limited to a maximum of 20 bytes. Most implementations use a single characteristic for light control, so it's then just a matter of staring at the dumped packets until something jumps out at you. A pretty typical implementation is something like:

0x56,r,g,b,0x00,0xf0,0x00,0xaa

where r, g and b are each just a single byte representing the corresponding red, green or blue intensity. 0x56 presumably indicates a "Set the light to these values" command, 0xaa indicates end of command and 0xf0 indicates that it's a request to set the colour LEDs. Sending 0x0f instead results in the previous byte (0x00 in this example) being interpreted as the intensity of the white LEDs. Unfortunately the bulb I tested that speaks this protocol didn't allow you to drive the white LEDs at the same time as anything else - setting the selection byte to 0xff didn't result in both sets of intensities being interpreted at once. Boo.

You can test this out fairly easily using the gatttool app. Run hcitool lescan to look for the device (remember that it won't show up if anything else is connected to it at the time), then do gatttool -b deviceid -I to get an interactive shell. Type connect to initiate a connection, and once connected send commands by doing char-write-cmd handle value using the handle obtained from your hci dump.

I did this successfully for various bulbs, but annoyingly hit a problem with one from Tikteck. The leading byte of each packet was clearly a counter, but the rest of the packet appeared to be garbage. For reasons best known to themselves, they've implemented application-level encryption on top of BLE. This was a shame, because they were easily the best of the bulbs I'd used - the white LEDs work in conjunction with the colour ones once you're sufficiently close to white, giving you good intensity and letting you modify the colour temperature. That gave me incentive, but figuring out the protocol took quite some time. Earlier this week, I finally cracked it. I've put a Python implementation on Github. The idea is to tie it into Ulfire running on a central machine with a Bluetooth controller, making it possible for me to control the lights from multiple different apps simultaneously and also integrating with my Echo.

I'd write something about the encryption, but I honestly don't know. Large parts of this make no sense to me whatsoever. I haven't even had any gin in the past two weeks. If anybody can explain how anything that's being done there makes any sense at all[3] that would be appreciated.

[1] typically via the bulb pretending to be an access point, but also these days through a terrifying hack involving spewing UDP multicast packets of varying lengths in order to broadcast the password to associated but unauthenticated devices and good god the future is terrifying

[2] For a given power input, blue LEDs produce more light than other colours. To get white with RGB LEDs you either need to have more red and green LEDs than blue ones (which costs more), or you need to reduce the intensity of the blue ones (which means your headline intensity is lower). Neither is appealing, so most of these bulbs will just give you a blue "white" if you ask for full red, green and blue

[3] Especially the bit where we calculate something from the username and password and then encrypt that using some random numbers as the key, then send 50% of the random numbers and 50% of the encrypted output to the device, because I can't even

comments

A year ago I ve blogged about people requesting CVE without letting upstream know. On the other hand, per requests from Debian, I m working on improving PHP upstream CVE request process. For the last few release this means I ask the security list members which issues they think should have CVE and ask for them in parallel to the release being made (usually in the space between the release being tagged publicly and is actually announced). In the last week, I ve encountered a case where a few CVE were assigned to old PHP issues without any public notice. The fixes for these issues have been published a year ago (August 2015). And I find out about these assignment through warning published by the distributions (mostly Debian, which I m close to). Sometimes things fall between the chairs, and it s perfectly OK to ask for CVE to make sure security issues do get attention even if time has passed. But after the issues (and fixes) are public, I don t see a reason to do so without making the request itself public as well. And even if the request wasn t public, at least notify upstream so this info can be added to the right places. Most of these bug were found out when I started to add sequential number into the CVE search after getting an a notice from Debian for two of the issues.

• CVE-2015-8873 for PHP #69793
• CVE-2015-8874 for PHP #66387
• CVE-2015-8876 for PHP #70121
• CVE-2015-8877 for PHP #70064
• CVE-2015-8878 for PHP #70002
• CVE-2015-8879 for PHP #69975
• CVE-2015-8880 for PHP aa8cac57 (Dec 2015)

And while working on processing these issues for PHP, I also notice they weren t updated for libGD where appropriate (including recent issues). Beyond keeping the eco-system up to date, another aspect of publicity is getting opinions from other parties. For example, in the case of CVE-2015-8879, RedHat doesn t agree with the classification of the bug as security. To give an example of a way things should happen is the request of CVE for PHP 5.5.34 in April, in which the Gentoo security team asked for assignment without upstream knowledge, Debian representative CCs upstream (Thanks!) and also asks CVE for issues covered by Ubuntu, to which the Ubuntu guy then adds some details. I hope this blog post will reach the anonymous people behind these CVE requests, and also the people assigning them. Without transparency and keeping things in synchronization, the idea of having a centralized location for security warning is not going to accomplish its goals.
Filed under: Debian GNU/Linux, PHP

Several years ago I've complained about uTidylib not being maintained upstream. Since that time I've occasionally pushed some fixes to my GitHub repository with uTidylib code, but without any clear intentions to take it over. Time has gone and there was still no progress and I started to consider becoming upstream maintainer as well. I quickly got approval from Cory Dodt, who was the original author of this code, unfortunately he is not owner of the PyPI entry and the claim request seems to have no response (if you know how to get in touch with "cntrlr" or how to take over PyPI module please let me know). Anyway the amount of patches in my repository is big enough to warrant new release. Additionally Debian bug report about supporting new HTML tidy library came in and that made me push towards releasing 0.3 version of the uTidylib. As you might guess, the amount of changes against original uTidylib is quite huge, to name the most important ones:

• Various compatiblity fixes (eg. with 64-bit machines)
• Various code cleanups
• New test suite
• New documentation
• Support for new HTML 5 tidy library

Anyway as I can not update PyPI entry, the downloads are currently available only on my website: https://cihar.com/software/utidylib/

Filed under: Debian English uTidylib 0 comments

shell-monad is a small project, done over a couple days and not needing many changes since, but I'm covering it separately because it was a bit of a milestone for me. As I learned Haskell, I noticed that the libraries were excellent and did things to guide their users that libraries in other languages don't do. Starting with using types and EDSLs and carefully constrained interfaces, but going well beyond that, as far as applying category theory. Using these libraries push you toward good solutions. shell-monad was a first attempt at building such a library. The shell script it generates should always be syntactically valid, and never forgets to quote a shell variable. That's only the basics. It goes further by making it impossible to typo the name of a shell variable or shell function. And it uses phantom types so that the Haskell type checker can check the types of shell variables and functions match up. So I think shell-monad is pretty neat, and I certianly learned a lot about writing Haskell libraries making it. Including how much I still have to learn! I have not used shell-monad much, but keep meaning to make propellor and git-annex use it for some of their shell script needs. And ponder porting etckeeper to generate its shell scripts using it. Next: twenty years of free software -- part 11 concurrent-output

Over the past year I ve been refining my understanding of the core claims of Kantian ethics. I ve realised that I have deeply Kantian intuitions about a lot of issues, and I understand these intuitions better now that I can put them in Kantian terms. Consider two exercises of state power: riot police suppressing protesters by non-lethal means, and soldiers shooting protesters to death. I feel more uncomfortable thinking about the first: there s something altogether more sinister about it than the second, even though the second is much more sad. I think that the reason is that non-lethal weaponry is designed to take away people s agency, and it often achieves this aim by means of emotional manipulation. Riot police use so-called baton charges to incite fearful retreat. Protesters have reasoned that in their political situation, they have a duty to resist the incumbent government. Riot police seek to unseat this conviction and cause fear to determine what the protesters will do. In Kantian terms, the riot police fail to respect the moral agency of the protesters by seeking to unseat the moral personality s determination of what the protester will do. A controversial example that Kant uses to make this point is the axe murderer case. Kant asks us to imagine that someone bangs on our front door and begs us to hide him in our house, because someone who wishes to kill him is coming up behind them. We do so. When the axe murderer arrives, he goes door-to-door and asks us whether the intended victim is in each house. Kant says that it is morally wrong to lie to the axe murderer and say that the victim is not in your house. How could this be? Surely there is a moral duty to protect the victim from being killed? Indeed there is, but when it comes into conflict with the duty not to lie, that second duty wins out. That s because respecting the moral agency of individuals is paramount. In this case, we would fail to respect the murderer s agency if we didn t allow him to take the decision to murder or not murder the victim; by lying to him we (disrespectfully) bypass his choice as to whether to do it. It s obviously crazy to say that we are morally required to give up the victim. Kant gives the wrong answer in this case. However, the case definitely reveals a requirement to respect other people s view of what they should do, and give them a chance to do it. Similarly it seems like we shouldn t give semi-automatics to our riot police, but there s something wrong with a lot of what they do. During the recent campaigns about Britain s EU referendum, some criticised Jeremy Corbyn s campaigning on the grounds that he failed to make an emotional appeal, instead asking people to make their own rational decision when they come to cast their vote. So he lost out the emotional appeals other people were making. It seems that he was successfully respecting individual agency. You ve got to give people a chance to live up to their own idea of what they should do. I m not sure how to reconcile these various ideas, and I m not sure what it says about me that I find non-lethal weaponry as uncomfortable as I do.

Yesterday, I tried to unlock a HTC Desire HD phone, and it proved to be a slight challenge. Here is the recipe if I ever need to do it again. It all started by me wanting to try the recipe to set up an hardened Android installation from the Tor project blog on a device I had access to. It is a old mobile phone with a broken microphone The initial idea had been to just install CyanogenMod on it, but did not quite find time to start on it until a few days ago. The unlock process is supposed to be simple: (1) Boot into the boot loader (press volume down and power at the same time), (2) select 'fastboot' before (3) connecting the device via USB to a Linux machine, (4) request the device identifier token by running 'fastboot oem get_identifier_token', (5) request the device unlocking key using the HTC developer web site and unlock the phone using the key file emailed to you. Unfortunately, this only work fi you have hboot version 2.00.0029 or newer, and the device I was working on had 2.00.0027. This apparently can be easily fixed by downloading a Windows program and running it on your Windows machine, if you accept the terms Microsoft require you to accept to use Windows - which I do not. So I had to come up with a different approach. I got a lot of help from AndyCap on #nuug, and would not have been able to get this working without him. First I needed to extract the hboot firmware from the windows binary for HTC Desire HD downloaded as 'the RUU' from HTC. For this there is is a github project named unruu using libunshield. The unshield tool did not recognise the file format, but unruu worked and extracted rom.zip, containing the new hboot firmware and a text file describing which devices it would work for. Next, I needed to get the new firmware into the device. For this I followed some instructions available from HTC1Guru.com, and ran these commands as root on a Linux machine with Debian testing:

adb reboot-bootloader
fastboot oem rebootRUU
fastboot flash zip rom.zip
fastboot flash zip rom.zip
fastboot reboot

The flash command apparently need to be done twice to take effect, as the first is just preparations and the second one do the flashing. The adb command is just to get to the boot loader menu, so turning the device on while holding volume down and the power button should work too. With the new hboot version in place I could start following the instructions on the HTC developer web site. I got the device token like this:

fastboot oem get_identifier_token 2>&1   sed 's/(bootloader) //'

And once I got the unlock code via email, I could use it like this:

fastboot flash unlocktoken Unlock_code.bin

And with that final step in place, the phone was unlocked and I could start stuffing the software of my own choosing into the device. So far I only inserted a replacement recovery image to wipe the phone before I start. We will see what happen next. Perhaps I should install Debian on it. :)

I was assigned another 15 hours of work by Freexian's Debian LTS initiative and carried over 5 from last month. I worked a total of 19 hours, carrying over 1. I spent a week in the Front Desk role and triaged many new security issues for wheezy. I prepared the Linux 3.2.81 stable update, sent it out for review and finally released it. I then rebased the wheezy-security branch on top of that and added some later security fixes that were not yet suitable for a kernel.org update. I uploaded to wheezy-security and issued DLA-516-1. I started working on the next Linux stable updates (3.2.82 and the next wheezy LTS update) and on an update for imagemagick, but haven't uploaded anything for them yet.

My monthly report covers what I have been doing for Debian. I write it for Debian s Long Term Support sponsors but also for the wider free software community in the hope that it might inspire people to get more involved with Debian or free software in general. Debian Android

• We (the Android Tools Maintainers and our three GSoC students) started our regular IRC meetings on Thursday.
• I am mostly involved in answering packaging questions, reviewing package updates and uploading them to the archive.
• I sponsored new versions of android-platform-build, android-platform-external-libselinux, android-platform-external-libunwind, android-platform-frameworks-base, android-platform-system-core and android-platform-system-extras.
• I sponsored a new revision of apktool prepared by Chirayu Desai and myself that fixed the decoding issue from last month and three other bugs. Thanks to Paul Wise for the reports and Chirayu for fixing two bugs and creating a separate android-framework-res binary package on which we could depend on. It seems decoding works now as intended but we still need to tackle the building problem.

Debian Games

• I packaged CaveExpress and CavePacker for Debian. CaveExpress is a remake of the old Amiga classic Ugh! In this game you control a pedal-powered flying machine and pick up packages from your clients. An interesting aspect of CaveExpress is its physics-based gameplay. The packages must be delivered to a collection point and their movement is quite realistic thanks to the excellent Box2d physics engine. The other game, CavePacker, based on the same engine as CaveExpress is a Sokoban-like game. Both games feature dozens of levels and if you have nothing better to do, you should definitely check them out.
• This month I also packaged a new upstream release of Netpanzer. Apparently there is new upstream activity.
• Blockattack 2.0 was released and is now available in Debian.
• I also updated the following packages: kball, pathogen, ceferino, slimevolley, pangzero and airstrike.
• I adopted abe, berusky and berusky-data, updated the packages to use modern debian helpers and also packaged version 1.7 of berusky, a great Sokoban-like game by the way.
• June also saw a new release of debian-games, several metapackages that make it much easier to install a subset of games or even the finest.
• I sponsored RC-bug fixes for parsec47, tumiki-fighters, mu-cade and tatan all prepared by Peter De Wachter who keeps our D (yes, that s a language) games alive. But we will face more issues in the post Stretch future. Apparently the D language people intend to remove parts of their API and of course all our D-based games are affected. Peter has announced more information about that. I think all these games are pretty unique and real gems. If you know a little D and want to help out, please get involved.

Debian Java

• I sponsored a new package for Tobias Ilte, stegosuite, a steganography tool to hide information in image files.
• I packaged new upstream releases of jboss-logmanager, jboss-modules, jboss-xnio, activemq and undertow.
• Together with Emmanuel Bourg I prepared a security update for Tomcat 8 fixing 8 CVEs. (DSA-3609-1)
• I backported the lastest stable release of mysql-connector-java to Jessie to fix CVE-2015-2575. A DSA is pending.
• I blogged about the default Java switch in Wheezy.

Debian LTS This was my fifth month as a paid contributor and I have been paid to work 19,75 hours on Debian LTS. In that time I did the following:

• DLA-501-1. Salvatore Bonaccorso from Debian s Security Team discovered that the original fix for CVE-2015-7552 (DLA-450-1) was incomplete. I prepared and uploaded a new revision of gdk-pixbuf and issued the DLA.
• DLA-502-1. Issued a security update for graphicsmagick fixing 1 CVE.
• DLA-504-1. Issued a security update for libxstream-java fixing 1 CVE which was prepared by Emmanuel Bourg.
• DLA-505-1. Issued a security update for libpdfbox-java fixing 1 CVE.
• DLA-508-1. Issued a security update for expat fixing 2 CVE.
• DLA-511-1. Issued a security update for libtorrent-rasterbar fixing 1 CVE.
• DLA-526-1. Issued a security update for mysql-connector-java fixing 1 CVE. I also prepared the update for Jessie which is still pending to be reviewed by the Security Team.
• DLA-528-1. Issued a security update for libcommons-fileupload-java fixing 1 CVE.
• DLA-529-1. Issued a security update for tomcat7 fixing 1 CVE.
• DLA-530-1. As previously announced I switched the default Java implementation from OpenJDK 6 to OpenJDK 7.
• DLA-537-1. Issued a security update for roundcube fixing 1 CVE. I triaged CVE-2016-5103, CVE-2015-2180 and CVE-2015-2181 and marked them as not-vulnerable .
• I triaged 22 CVEs for libarchive and marked two of them as not-vulnerable . You can find my preliminary work for libarchive on the wheezy branch in Debian s git repository. I expect a security update very soon.
• From 13 June to 19. June I was responsible for Wheezy s LTS frontdesk. It was a rather calm week on the debian-lts mailing list and in our IRC channel. I triaged CVE-2016-4970 (netty), CVE-2016-3189 (bzip2), CVE-2016-1621 (libvpx) and CVE-2016-4493, CVE-2016-4492, CVE-2016-4491, CVE-2016-4490, CVE-2016-4489, CVE-2016-4488, CVE-2016-4487, CVE-2016-2226 which were all minor issues in developer tools or in the gcc toolchain.
• I commented on Ola s question about open security issues in phpmyadmin.

QA uploads

• I fixed pygccxml that threatened to remove spring.
• I completely overhauled gl-117, fixed four bugs and closed two obsolete ones. gl-117 always reminds me a little of the Falcon series from the early 90ies.

Six members of the Debian Perl team met in Zurich over the weekend from May 19 to May 22 to continue the development around perl for Stretch and to work on QA across 3000+ packages. The participants had a good time, met friends from local groups and even found some geocaches. Obviously, the sprint was productive this time too:

• 36 bugs were filed or worked on, 28 uploads were accepted.
• The plan to get Perl 5.24 transition into Stretch was confirmed, and a test rebuild server was set up.
• Cross building XS modules was demoed, and the conditions where it is viable were discussed.
• Several improvements were made in the team packaging tools, and new features were discussed and drafted.
• A talk on downstream distribution aimed at CPAN authors was proposed for YAPC::EU 2016.

The full report was posted to the relevant Debian mailing lists. The participants would like to thank the ETH Zurich for hosting us, and all donors to the Debian project who helped to cover a large part of our expenses.

ey dad sometimes asks when I'll finish git-annex. The answer is "I don't know" because software like that doesn't have a defined end point; it grows and changes in response to how people use it and how the wider ecosystem develops. But other software has a well-defined end point and can be finished. Some of my smaller projects that are more or less done include electrum-mnemonic, brainfuck-monad, scroll, yesod-lucid haskell-mountpoints. Studies of free software projects have found that the average free software project was written entirely by one developer, is not very large, and is not being updated. That's often taken to mean it's a failed or dead project. But all the projects above look that way, and are not failures, or dead. It's good to actually finish some software once in a while! Next: twenty years of free software -- part 10 shell-monad

Introduction NX is a software suite which implements very efficient compression of the X11 protocol. This increases performance when using X applications over a network, especially a slow one. NX (v3) has been originally developed by NoMachine and has been Free Software ever since. Since NoMachine obsoleted NX (v3) some time back in 2013/2014, the maintenance has been continued by a versatile group of developers. The work on NX (v3) is being continued under the project name "nx-libs". History Until January 2015, nx-libs was more mainly a redistribution approach of the original NX (v3) software. We (we as in mainly a group of X2Go developers) kept changes applied to the original NoMachine sources as minimal as possible. We also kept the original files and folders structure. Patches had been maintained via the quilt utility on top of a Git repository, the patches had always been kept separate. That was the 3.5.0.x series of nx-libs. In January 2015, the characteristics of nx-libs as maintained by the X2Go project between 2011 and 2015 changed. A decision was reached:

• Drop quilt patching approach
• Apply all already used patches to the code via Git
• Clean-up the complete source code tree
• Start backporting code from X.org
• Add new features, upgrade API/ABI and X11 extensions

This effort is now about to be released as "nx-libs 3.6.0.0". Contributors Since 2011, the nx-libs code base has to a great extent been maintained in the context of the X2Go Project [1]. Qindel Group joining in... In 2014, developers from the Qindel Group [2] joined the nx-libs maintenance. They found X2Go's work on nx-libs and suggested joining forces as best as possible on hacking nx-libs. The Arctica Project comming up... Starting in January 2015, the development on the 3.6.x branch of the project was moved into a new project called the Arctica Project [3]. Development Funding by Qindel In September 2015, a funding project was set up at Qindel. Since then, the Qindel group greatly supports the development of nx-libs 3.6.x monetarily and with provided man power. The funding project officially is a cooperation between Qindel and DAS-NETZWERKTEAM (business run by Mike Gabriel, long term maintainer of nx-libs). The funding is split into two subprojects and lasts until August 2017:

• Work on nx-libs (coordinated by DAS-NETZWERKTEAM, Mike Gabriel)
• Work on multimedia support in remote graphical sessions (coordinated by Guangzhou Nianguan Electronics Technology Co.,Ltd)

The current nx-libs development effort is coordinated in the context of the Arctica Project (by Mike Gabriel), with use cases in Arctica, X2Go and TheQVD (VDI product worked on at Qindel) in mind. People involved There are various people involved in nx-libs 3.6.x maintenance and development, some of them shall be explicitly named here (in alphabetical order of surnames):

• Mario Becroft (long term NX contributor)
• Nicolas Arenas Alonso (funding project coordinator at Qindel)
• Mike DePaulo (CVE hunter)
• Salvador Fandi o (developer, code reviewer, provided by Qindel)
• Mike Gabriel (development coordination, developer, packager)
• The GZNGET FLOSS Team (Arctica Project developer, advisory)
• Jordi Marqu s (Arctica Project infrastructure maintainer)
• Mihai Moldovan (developer, code reviewer)
• Ulrich Sibiller (developer, code reviewer)
• Vadim Troshchinskiy (developer, code reviewer, provided by Qindel)

Some other people have contributed, but have left the project already. Thanks for your work on nx-libs:

• Fernando Carvajal (contributor, provided by Qindel)
• Reinhard Tartler (contributor to X2Go)

A big thanks to everyone involved!!! Special thanks go to Stefan Baur for employing Mihai Moldovan and handling all the bureaucracy, so that Mihai can work on this project and get funded for his work. Achievements of nx-libs 3.5.99.0 We are very close to our self-defined release goal 3.6.0. The below tasks have already been (+/-) completed for version 3.5.99.0:

• CVE security audit (complete)
• remove unused code (+/- complete)
• no bundled non-X11 libraries anymore (complete)
• complete imake cleanup (+/- complete)
• replace as many libNX_X - libraries by X.org's libX - libraries (complete, only remaining library: libNX_X11)
• support for iOS (nxproxy, complete)
• Unix file socket communication for nxproxy -C <-> nxproxy -S connections (complete)
• allow Unix file sockets as channel endpoints (complete)
• new RandR based Xinerama extension (+/- complete, more QA needed)
• nxcomp protocol clean-up (complete)
• RandR Xserver extension upgrade to protocol version 1.5 (complete, from version 1.2)
• Composite Xserver extension upgrade to proto version 0.4 (complete, from version 0.2)
• various ABI/API updates (with respect to X.org), so that extension backporting should be easy now (+/- complete)

In a previous blog post [4], the code reduction in nx-libs has already been discussed. With this announcement, we want to give a status update about our effort of shrinking the nx-libs code base:

    [mike@minobo nx-libs (3.6.x)]$ cloc --match-f '.*\.(c cpp h)' .
        1896 text files.
        1896 unique files.                                          
        7430 files ignored.
    http://cloc.sourceforge.net v 1.60  T=5.88 s (307.3 files/s, 143310.5 lines/s)
    -------------------------------------------------------------------------------
    Language                     files          blank        comment           code
    -------------------------------------------------------------------------------
    C                              958          68574          74891         419638
    C/C++ Header                   730          25683          33957         130418
    C++                            120          17007          11721          61292
    -------------------------------------------------------------------------------
    SUM:                          1808         111264         120569         611348
    -------------------------------------------------------------------------------

The previous statistics had these sums in the last line. First the nx-libs 3.5.0.x code tree (where we came from):

    -------------------------------------------------------------------------------
    SUM:                          5614         329279         382337        1757743
    -------------------------------------------------------------------------------

Then the nx-libs 3.6.x status as it was on May 9th 2016:

    -------------------------------------------------------------------------------
    SUM:                          1922         118581         126783         662635
    -------------------------------------------------------------------------------

Another 50.000 lines of code have been removed over the past two months. Work pending for the final 3.6.0 release goal

• allow embedding of nxproxy into other windows (work pending)
• Fix the Composite extension in nx-X11 Xserver (work pending)
• nxcomp logging clean-up (work pending)
• optimizing documentation: how to tune NX connections (work pending)
• XServer extension upgrades:
  • XInput 1.3 -> 1.4 (work pending)
  • Xfixes 3.0 -> 5.0 (work in progress)
  • Damage 1.0 -> 1.1 (work pending)
  • Xres 1.0 -> 2.0 (work pending)
  • Sync 1.0 -> 3.0 (work pending)
  • Render 0.10 -> 0.11 (work pending)
• Drop as many X11 related proto headers as possible

Known Issues There are several open issues on the nx-libs Github project space, see https://github.com/ArcticaProject/nx-libs/issues. Testing the nx-libs 3.5.99.0 We are currently working on provisioning release builds and nightly builds of nx-libs for various recent Linux distributions. Please stay tuned and watch Mike Gabriel's blog [5]. We already have nightly builds of nx-libs for Debian and Ubuntu [6], but there are more to come soon. Until now, please use the build recipes provided in the README.md file of the nx-libs source tree [7]. References

• [1] http://wiki.x2go.org
• [2] http://www.qindel.com
• [3] https://arctica-project.org
• [4] https://sunweavers.net/blog/node/39
• [5] https://sunweavers.net
• [6] https://sunweavers.net/blog/node/20
• [7] https://github.com/ArcticaProject/nx-libs/blob/3.6.x/README.md

There is this long-running workshop series Haskell in Leipzig, which is a meeting of all kinds of Haskell-interested folks (beginners, experts, developers, scientists), and for year s instance, HaL 2016, I have the honour of being the program committee chair. The original deadline passed last week, and after looking through the submissions it became clear that although the quality was good, the quantitiy was still lacking. I therefore extended the submission deadline by two weeks, until July 15th. So if you have something worth talking about, please do submit a proposal¹ and come to Leipzig!. Why should you submit here? Because it gives you a platform to talk about your ideas to an audience that usually does not consist just of your fellow speakers, as it is often with purely academic workshops, but real listeners of various kinds. And it is a fun event. And why should you come to Leipzig? Because of all the interesting talks and tutorials! Of course I cannot say a lot here yet, besides that our invited speaker Alejandro Russo from Chalmers and Gothenburg University will present his work on information-flow control in Haskell (i.e., SecLib, LIO, MAC, HLIO).

Last week, I worked on linking the D_BUS with the client and implement MAP on my callback smartInfo to push all my information in only one parameter.
This week I wanted to display my first real information in my client. I choose to begin with the frame rate to help another person in Savoir Faire Linux who work on the encoding and decoding of the video. So I worked on the video part of the daemon trying to understand how the daemon sends frames to LRC. All the frames are decoded in the same place so I just pull the number of frames per second for the local and remote video and put it on my callback smartInfo.
Next week, I will change my architecture a little bit. Ring can handle several calls with different information and my implementation don't take care of this. I need to search and implement a new architecture to link my callback with the call.

github-backup is an attempt to take something I don't like -- github's centralization of what should be a decentralized techology -- and find a constrictive way to make it at least meet my baseline requirements for centralized systems. Namely that when they go away, I don't lose data. So, it was written partly with my ArchiveTeam hat on. A recent bug filed on it, Backup fails for repositories unavailable due to DMCA takedown made me happy, because it shows github-backup behaving more or less as intended, although perhaps not in the optimal way. By the way, this is the only one of my projects that uses github for issue tracking. Intentionally ironically. It was my second real Haskell program (after git-annex) and so also served as a good exercise in applying what I'd learned about writing Haskell up to that point. Next: twenty years of free software -- part 9 small projects

I've been tweaking the video review system which we're using here at debconf over the past few days so that videos are being published automatically after review has finished; and I can happily announce that as of a short while ago, the first two files are now visible on the meetings archive. Yes, my own talk is part of that. No, that's not a coincidence. However, the other talks should not take too long Future plans include the addition of a video RSS feed, and showing the videos on the debconf16 website. Stay tuned.

With more than 10 million users, the Scratch online community is the largest online community where kids learn to program. Since it was created, a central goal of the community has been to promote remixing the reworking and recombination of existing creative artifacts. As the video above shows, remixing programming projects in the current web-based version of Scratch is as easy is as clicking on the see inside button in a project web-page, and then clicking on the remix button in the web-based code editor. Today, close to 30% of projects on Scratch are remixes. Remixing plays such a central role in Scratch because its designers believed that remixing can play an important role in learning. After all, Scratch was designed first and foremost as a learning community with its roots in the Constructionist framework developed at MIT by Seymour Papert and his colleagues. The design of the Scratch online community was inspired by Papert s vision of a learning community similar to Brazilian Samba schools (Henry Jenkins writes about his experience of Samba schools in the context of Papert s vision here), and a comment Marvin Minsky made in 1984:

Adults worry a lot these days. Especially, they worry about how to make other people learn more about computers. They want to make us all computer-literate. Literacy means both reading and writing, but most books and courses about computers only tell you about writing programs. Worse, they only tell about commands and instructions and programming-language grammar rules. They hardly ever give examples. But real languages are more than words and grammar rules. There s also literature what people use the language for. No one ever learns a language from being told its grammar rules. We always start with stories about things that interest us.

In a new paper titled Remixing as a pathway to Computational Thinking that was recently published at the ACM Conference on Computer Supported Collaborative Work and Social Computing (CSCW) conference, we used a series of quantitative measures of online behavior to try to uncover evidence that might support the theory that remixing in Scratch is positively associated with learning. Of course, because Scratch is an informal environment with no set path for users, no lesson plan, and no quizzes, measuring learning is an open problem. In our study, we built on two different approaches to measure learning in Scratch. The first approach considers the number of distinct types of programming blocks available in Scratch that a user has used over her lifetime in Scratch (there are 120 in total) something that can be thought of as a block repertoire or vocabulary. This measure has been used to model informal learning in Scratch in an earlier study. Using this approach, we hypothesized that users who remix more will have a faster rate of growth for their code vocabulary. Controlling for a number of factors (e.g. age of user, the general level of activity) we found evidence of a small, but positive relationship between the number of remixes a user has shared and her block vocabulary as measured by the unique blocks she used in her non-remix projects. Intriguingly, we also found a strong association between the number of downloads by a user and her vocabulary growth. One interpretation is that this learning might also be associated with less active forms of appropriation, like the process of reading source code described by Minksy. The second approach we used considered specific concepts in programming, such as loops, or event-handling. To measure this, we utilized a mapping of Scratch blocks to key programming concepts found in this paper by Karen Brennan and Mitchel Resnick. For example, in the image below are all the Scratch blocks mapped to the concept of loop . We looked at six concepts in total (conditionals, data, events, loops, operators, and parallelism). In each case, we hypothesized that if someone has had never used a given concept before, they would be more likely to use that concept after encountering it while remixing an existing project. Using this second approach, we found that users who had never used a concept were more likely to do so if they had been exposed to the concept through remixing. Although some concepts were more widely used than others, we found a positive relationship between concept use and exposure through remixing for each of the six concepts. We found that this relationship was true even if we ignored obvious examples of cutting and pasting of blocks of code. In all of these models, we found what we believe is evidence of learning through remixing. Of course, there are many limitations in this work. What we found are all positive correlations we do not know if these relationships are causal. Moreover, our measures do not really tell us whether someone has understood the usage of a given block or programming concept.However, even with these limitations, we are excited by the results of our work, and we plan to build on what we have. Our next steps include developing and utilizing better measures of learning, as well as looking at other methods of appropriation like viewing the source code of a project.

This blog post and the paper it describes are collaborative work with Sayamindu Dasgupta, Andr s Monroy-Hern ndez, and William Hale. The paper is released as open access so anyone can read the entire paper here. This blog post was also posted on Sayamindu Dasgupta s blog and on Medium by the MIT Media Lab.

check-all-the-things (aka cats, Meow!) is a tool that aims to make it easy to know which tools can be used to check a directory tree and to make it easy to run those tools on the directory tree. The tree could either be a source tree or a build tree or both. It aims to check as much of the tree as possible so the output can be very verbose and have many false positives. It is not for the busy, lazy or noise intolerant. It runs the checks by matching file names and MIME types against those registered for a list of checks. Each check has a set of dependencies, flags, filename wildcards, MIME type wildcards, comments and prerequisite commands. By default it:

• doesn't check file MIME types as this is slower
• shows which command is currently running
• limits check output to 10 lines
• hides checks that output nothing
• kills checks when interrupted with Ctrl+C
• exits when interrupted twice in quick succession
• outputs various remarks at the end

It runs all checks for the current distro/release except:

• dangerous ones that execute code in the current dir
• ones that modify files in the current dir
• ones that access the network (if there is no default route)
• ones that need work to be usable
• ones that need a human to run them

There are command-line options to customise the behaviour and automatic bash shell completion via argcomplete. There are 177 checks (including TODO ones) in 73 different categories. There are an additional 224 not-well-specified TODO items for new checks in comments. It is exceptionally easy to add new checks once one knows how to use the tool one wants to add. At this point in time it is probably not a good idea to run it in an untrusted directory tree for several reasons:

• there could be unknown vulnerabilities in the tools used
• there could be unknown interactions with interpreters (known ones worked around)
• there could be some commands doing unknown code execution
• there could be other weirdness in some layers
• there is no automatic sandboxing at all yet

The project initially started as really hacky wiki page full of commands to run. At some point I figured it was time to make this actually be maintainable and started on a project to do that. At around the same time Jakub Wilk was working on maquack to replace the wiki page. Somehow I found out about it and talked to him about it. It was vastly less hacky than my version so I ended up taking it over and continuing it under the check-all-the-things name. I polished it for the last two years and finally released it into Debian unstable during DebCamp16.