Search Results: "ema"

6 July 2016

Mike Gabriel: [Arctica Project] Release of nx-libs (version 3.5.99.0)

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: 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: 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): Some other people have contributed, but have left the project already. Thanks for your work on nx-libs: 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: 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 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

4 July 2016

Paul Wise: Check All The thingS!

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: It runs all checks for the current distro/release except: 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: 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.

3 July 2016

Reproducible builds folks: Reproducible builds: week 61 in Stretch cycle

What happened in the Reproducible Builds effort between June 19th and June 25th 2016. Media coverage GSoC and Outreachy updates Toolchain fixes Other upstream fixes Emil Velikov searched on IRC for hints on how to guarantee unique values during build to invalidate shader caches in Mesa, when also no VCS information is available. A possible solution is a timestamp, which is unique enough for local builds, but can still be reproducible by allowing it to be overwritten with SOURCE_DATE_EPOCH. Packages fixed The following 9 packages have become reproducible due to changes in their build dependencies: cclib librun-parts-perl llvm-toolchain-snapshot python-crypto python-openid r-bioc-shortread r-bioc-variantannotation ruby-hdfeos5 sqlparse The following packages have become reproducible after being fixed: Some uploads have fixed some reproducibility issues, but not all of them: Patches submitted that have not made their way to the archive yet: Package reviews 139 reviews have been added, 20 have been updated and 21 have been removed in this week. New issues found: 53 FTBFS bugs have been reported by Chris Lamb, Santiago Vila and Mateusz ukasik. diffoscope development Quote of the week "My builds are so reproducible, they fail exactly every second time." Johannes Ziemke (@discordianfish) Misc. This week's edition was written by Chris Lamb (lamby), Reiner Herrmann and Holger Levsen and reviewed by a bunch of Reproducible builds folks on IRC.

Jonathan McDowell: Confirming all use of an SSH agent

For a long time I ve wanted an ssh-agent setup that would ask me before every use, so I could slightly more comfortably forward authentication over SSH without worrying that my session might get hijacked somewhere at the remote end (I often find myself wanting to pull authenticated git repos on remote hosts). I m at DebConf this week, which is an ideal time to dig further into these things, so I did so today. As is often the case it turns out this is already possible, if you know how. I began with a setup that was using GNOME Keyring to manage my SSH keys. This isn t quite what I want (eventually I want to get to the point that I can sometimes forward a GPG agent to remote hosts for signing purposes as well), so I set about setting up gpg-agent. I used Chris excellent guide to GnuPG/SSH Agent setup as a starting point and ended up doing the following: 
$ echo use-agent >> ~/.gnupg/options
$ echo enable-ssh-support >> ~/.gnupg/gpg-agent.conf
$ sudo sed -i.bak "s/^use-ssh-agent/# use-ssh-agent/" /etc/X11/Xsession.options
$ sudo rm /etc/xdg/autostart/gnome-keyring-ssh.desktop
The first 2 commands setup my local agent, and told it to do SSH agent foo. The next stopped X from firing up ssh-agent, and the final one prevents GNOME Keyring from being configured to be the SSH agent, without having to remove libpam-gnome-keyring as Chris did. After the above I logged out of and into X again, and could see ~/.gnupg/S.gpg-agent.ssh getting created and env grep SSH showing SSH_AUTH_SOCK pointing to it (if GNOME Keyring is still handling things it ends up pointing to something like /run/user/1000/keyring/ssh). [Update: Luca Capello emailed to point out this was a bad approach; there s thankfully no need to do the last 2 commands that require root. #767341 removed the need to edit Xsession.options and you can prevent GNOME Keyring starting on a per user basis with: 
(cat /etc/xdg/autostart/gnome-keyring-ssh.desktop ;
 echo 'X-GNOME-Autostart-enabled=false') > \
 ~/.config/autostart/gnome-keyring-ssh.desktop
] After this it turned out all I need to do was ssh-add -c <ssh keyfile>. The -c says confirm use and results in the confirm flag being appended to the end of ~/.gnupg/sshcontrol (so if you ve already done the ssh-add you can go and add the confirm if that s the behaviour you d like). Simple when you know how, but I ve had conversations with several people in the past who wanted the same thing and hadn t figured out how, so hopefully this is helpful to others.

2 July 2016

Jonathan Carter: So, that was DebCamp16!

Picture: Adrian Frith

University of Cape Town, host location to DebConf 16. Picture: Adrian Frith

What an amazingly quick week that was Our bid to host DebConf in Cape Town was accepted nearly 15 months ago. And before that, the bid itself was a big collective effort from our team. So it s almost surreal that the first half of the two weeks of DebCamp/DebConf is now over. Things have been going really well. The few problems we ve had so far were too small to even mention. It s a few degrees colder than it usually is this time of the year and there s already snow on the mountains, so Cape Town is currently quite chilly.
Hacking by the fire at the sports club

Gathering some heat by the fire at the sports club while catching up to the world the day before it all started.

All Kinds of Quality Time I really enjoyed working with the video team last year, but this year there was just 0 time for that. Working on the orga team means dealing with a constant torrent of small tasks, which is good in its own way because you get to deal with a wide variety of Debian people you might not usually get to interact with, but video team problems are more fun and interesting. Next year I hope to do a lot more video work again. If you re at DebConf over the next week, I can highly recommend that you get involved!
Video team hacking away at problems

Video team members hacking away at problems late at night during DebCamp

The first time I met Debian folk was early in 2004. I worked at the Shuttleworth Foundation as Open Source Technical Co-ordinator at the time, and Mark Shuttleworth had them over for one of the early Ubuntu sprints in Canonical s early days. I was so intimidated by them back then that I could hardly even manage to speak to them. I was already a big free software fan before working there, but little did I even dream to think that I would one day be involved in a project like Ubuntu or Debian. My manager back then encouraged me to go talk to them and get involved and become a Debian Developer and joked that I should become highvoltage@debian.org. I guess that was when the initial seeds got planted and since then I ve met many great people all over the world who have even became friends during UDS, DebConf, BTS and other hackfests where Debianites hang out. It gave me a really nice warm feeling to have all these amazing, talented and really friendly people from all over coming together in this little corner of the world to work together on projects that I think are really important.
Finding a warm space to work in the Happy Feet hack lab

Finding a warm space to work in the Happy Feet hack lab

Oh the Chicken Back at DebConf12, someone (I don t remember the exact history) brought a rubber chicken to DebConf who was simply called Pollito ( chicken in Spanish). Since then the chicken has grown into somewhat of a mascot for DebConf. Back in 2012 I already imagined that if we would ever host a DebConf, I d make a little of picture book story about Pollito. Last year after DC15, when bringing Pollito over, I created a little story called Pollito s first trip to Africa . I was recovering from flu while putting that together and didn t spend much time on it, but it turned out to be somewhat of a hit. I was surprised to see it in the #debconf topic ever since I posted it :) We gave a tour of the campus on the first and second days and it was quite time consuming and there was no way we could do it every day for the rest of DebCamp, so on the 2nd day I smacked together a new rush job called Pollito s Guide to DC16 . The idea was that newcommers could use it as a visual guide and rely on others who have been there for a while if they get stuck. I wish I had the time to make it a lot nicer, but I think the general idea is good and next year we can have a much nicer one that might not be quite as Pollito focused.
Pollito's Guide to DC16

Pollito s Guide to DC16

Debian Maintainer After all these years, I finally sat down and applied to become a Debian Maintainer, and the application was successful (approved yesterday \o/). Now just for the wait until my key is uploaded to the keyring. I haven t yet had time to properly process this but I think once the DebConf dust settles and I had some time to recover, I will be ecstatic. Some actual DebCampy work Everywhere I go, I see people installing a bunch of GNOME extensions on their Debian GNOME desktops shortly after installation using http://extensions.gnome.org/ (I noticed this even at DebCamp!). A few months ago I thought that it s really about time someone package up some of the really popular ones. So I started to put together some basic packaging for AIMS Desktop around a month ago. During the last few days of DebCamp, things were going well enough with the organisational tasks that I had some time to do some actual packaging work and improve these so that they re ready for upload to the Debian archives. The little DebCamp time I had ended up being my very own little extension fest :) I worked on the following packages which are ready for upload: I worked on the following packages which still need minor work, might be able to get them in uploadable state by the end of DebConf: The actual packaging of GNOME extensions is actually pretty trivial. It s mostly source-only JavaScript with some CSS and translations and maybe some gsettings schemas and dialogs. Or at least, it would be pretty trivial, but many extensions are without licenses, contain embedded code (often JavaScript) from other projects, or have no usable form of upstream tarball, to name a few of the problems. So I ve been contacting the upstream authors of these packages where there have been problems, and for the most part they ve been friendly and pretty quick to address the problems. So that s it, for now. I couldn t possibly sum up the last week and everything that lead up to it in a single blog post. All I can really say is thank you for letting me be a part of this very special project!

1 July 2016

Thorsten Alteholz: My Debian Activities in June 2016

FTP assistant This month I marked 233 packages for accept and rejected 29. I also sent 11 emails to maintainers asking questions. Currently there are 33 packages in NEW and the minimum this week has been as low as 24 packages. Come on you fellow developers, where are your packages? I am sure you can do better :-) . Debian LTS This was my twenty-fourth month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian. This month my all in all workload has been 18.75h. This resulted in patches for 13 CVEs and the following uploads: I also looked at mxml and libstruts1.2-java and marked CVEs for these packages as no-dsa . I also reviewed a patch of Salvatore for an embargoed CVE of xerces-c. Last but not least I looked at the remaining two CVEs for asterisk, but was not really able to create working patches This month I called again for testing php5. Thanks a lot to Stefan and anybody else who sent in their reports! As there are already new CVEs for php5 available, I am afraid I need your support again in July This month I also had another term of frontdesk work and answered questions or looked for CVEs that are important for Wheezy LTS or could be ignored. Other stuff I made some progress with the Alljoyn framework. Up to now the following packages are available: Unfortunately as some of those modules still need to be released in current versions, there are some gaps. Anyway, the next uploads will include an XMPP connector, to basically bridge a local AllJoyn bus to a remote AllJoyn bus over XMPP. Further, with the lighting module, real lamps can be switched on and off and much more. Also the Home Appliances and Entertainment Service Framework seems to be interesting as well. In the Javascript world I uploaded some new packages and uploaded new versions for the following packages:

Joachim Breitner: When to reroll a six

This is a story about counter-intuitive probabilities and how a small bit of doubt turned out to be very justified. It begins with the game To Court the King (German: Um Krone und Kragen ). It is a nice game with dice and cards, where you start with a few dice, and use your dice rolls to buy additional cards, which give you extra dice or special powers to modify the dice that you rolled. You can actually roll your dice many times, but every time, you have to set aside at least one die, which you can no longer change or reroll, until eventually all dice have been set aside. A few years ago, I have played this game a lot, both online (on yucata.de) as well as in real life. It soon became apparent that it is almost always better to go for the cards that give you an extra die, instead of those that let you modify the dice. Intuitively, this is because every additional die allows you to re-roll your dice once more. I concluded that if I have a certain number of dice (say, n), and I want to have a sum as high as possible at the end, then it may make sense to reroll as many dice as possible, setting aside only those showing a 6 (because that is the best you can get) or, if there is no dice showing a 6, then a single die with the best score. Besides for small number of dice (2 or 3), where even a 4 or 5 is worth keeping, this seemed to be a simple, obvious and correct strategy to maximize the expected outcome of this simplified game. It is definitely simple and obvious. But some doubt that it was correct remained. Having one more die still in the game (i.e. not set aside) definitely improves your expected score, because you can reroll the dice more often. How large is this advantage? What if it ever exceeds 6 then it would make sense to reroll a 6. The thought was strange, but I could not dismiss it. So I did what one does these days if one has a question: I posed it on the mathematics site of StackExchange. That was January 2015, and nothing happened. I tried to answer it myself a month later, or at least work towards at an answer, and did that by brute force. Using a library for probabilistic calculations for Haskell I could write some code that simply calculated the various expected values of n dice for up to n = 9 (beyond that, my unoptimized code would take too long): 
1:  3.50000 (+3.50000)
2:  8.23611 (+4.73611)
3: 13.42490 (+5.18879)
4: 18.84364 (+5.41874)
5: 24.43605 (+5.59241)
6: 30.15198 (+5.71592)
7: 35.95216 (+5.80018)
8: 41.80969 (+5.85753)
9: 47.70676 (+5.89707)
Note that this calculation, although printed as floating point numbers, is performed using fractions of unbounded integers, so there are no rounding issues that could skew the result. The result supported the hypothesis that there is no point in rolling a 6 again: The value of an additional die grows and approaches 6 from beyond, but judging from these number is never going to reach it. Then again nothing happened. Until 14 month later, when some Byron Schmuland came along, found this an interesting puzzle, and set out a 500 point bounty to whoever solved this problem. This attracted a bit attention, and a few not very successful attempts at solving this. Eventually it reached twitter, where Roman Cheplyaka linked to it. Coincidally a day later some joriki came along, and he had a very good idea: Why not make our life easier and think about dice with less sides, and look at 3 instead of 6. This way, and using a more efficient implementation (but still properly using rationals), he could do a similar calculation for up to 50 dice. And it was very lucky that he went to 50, and not just 25, because up to 27, the results were very much as expected, approaching value of +3 from below. But then it surpassed +3 and became +3.000000008463403. In other words: If you have roll 28 dice, and you have exactly two dice showing a 3, then it gives you better expected score if you set aside only one 3, and not both of them. The advantage is minuscule, but that does not matter it is there. From then on, the results behaved strangely. Between 28 and 34, the additional value was larger than 3. Then, from 35 on again lower than 2. It oscillated. Something similar could be observed when the game is played with coins. Eventually, joriki improved his code and applied enough tricks so that he could solve it also for the 6-sided die: The difference of the expected value of 198 dice and having 199 dice is larger than 6 (by 10 21...)! The optimizations that allowed him to calculate these numbers in a reasonable amount of time unfortunately was to assume that my original hypothesis (never rerolling a 6 is optimal), which held until n < 199. But this meant that for n > 199, the code did not yield correct results. What is the rationale of the story? Don t trust common sense when it comes to statistics; don t judge a sequence just from a few initial numbers; if you have an interesting question, post it online and wait for 16 months.

Rapha&#235;l Hertzog: My Free Software Activities in June 2016

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. Debian packaging Django and Python. I uploaded Django 1.9.7 and filed an upstream ticket (#26755) for a failure seen in its DEP-8 tests. I packaged/sponsored python-django-modeltranslation and python-paypal. I opened a pull request on model-translation to fix failing tests in the Debian package build. I packaged a new python-django-jsonfield (1.0.0), filed a bug and discovered some regression in its PostgreSQL support. I helped on the upstream ticket and I have been granted commit rights. I used this opportunity to do some bug triage and push a few fixes. I also discussed the future of the module and ended up starting a discussion on Django s developer list about the possibility to add a JSONField to the core. CppUTest. I uploaded a new upstream version (3.8) with more than a year of work. I found out that make install does not install a required header so I opened a ticket with a patch. The package ended up not compiling on quite a few architectures so I opened a ticket and prepared a fix for some of those failures with the help of the upstream developers. I also added a DEP-8 tests after having uploaded a broken (untested) package systemd support in net-snmp and postfix. I worked on adding native systemd service units to net-snmp (#782243) and postfix (#715188). In both cases, the maintainers have not been very reactive so far so I uploaded my changes as delayed NMU. pkg-security team. The team that I started quietly a few months ago is now growing, both with new members and new packages. I created the required Teams/pkg-security wiki page. I sponsored xprobe, hydra, made an upload of medusa to merge Kali changes into Debian (and at the same time submitting the patch to upstream). fontconfig. After having read Jonathan McDowell s analysis of a bug that I experienced multiple times (and that many Kali users had too), I opened bug #828037 to get it fixed once for all. Unfortunately, nothing happened yet. DebConf 16 I spent some time to prepare the 2 talks and the BoF that I will give/manage in Cape Town next week: Distro Tracker I continued to mentor Vladimir Likic who managed to finish his first patch. He is now working on documentation for new contributors based on his recent experience. I enhanced the tox configuration to run tests with Django 1.8 LTS with fatal warnings (python -Werror) so as to ensure that I m not relying on any deprecated feature and so that I can be sure that the codebase will work on the next Django LTS release (1.11). Thanks to this, I did discover quite a few places where I have been using deprecated API and I fixed them all (the JSONField update to 1.0.0 I mentionned above was precisely to fix such a warning). I also fixed a few more issues with folded mail headers that you can t inject back in a new Message object and with messages lacking the subject field. All those have been caught through real (spam) email generating exceptions wich are then mailed to me. Kali related work I uploaded a new live-boot (5.20160608) to Debian to fix a bug where the boot process was blocking on some timeout. I forwarded a Kali bug against libatk-wrapper-java (#827741) which turned out to be an OpenJDK bug. I filed #827749 against reprepro to request a way to remove selected internal file references. This is required if you want to be able to make a file disappear and if that file is part of a snapshot that you want to keep despite this. But in truth, my real need is to be able to replace the .orig.tar.gz used by Kali by the orig.tar.gz used by Debian those conflicts break the mirroring/import script. Salt I have been using salt to deploy a new service, and I developed patches for a few issues in salt formulas. I also created a new letsencrypt-sh formula to manage TLS certificates with the letsencrypt.sh ACME client. Thanks See you next month for a new summary of my activities.

No comment Liked this article? Click here. My blog is Flattr-enabled.

30 June 2016

Chris Lamb: Free software activities in June 2016

Here is my monthly update covering a large part of what I have been doing in the free software world (previously):
Debian My work in the Reproducible Builds project was covered in our weekly reports. (#58, #59 & #60)
Debian LTS

This month I have been paid to work 18 hours on Debian Long Term Support (LTS). In that time I did the following:
  • "Frontdesk" duties, triaging CVEs, etc.
  • Extended the lts-cve-triage.py script to ignore packages that are not subject to Long Term Support.

  • Issued DLA 512-1 for mantis fixing an XSS vulnerability.
  • Issued DLA 513-1 for nspr correcting a buffer overflow in a sprintf utility.
  • Issued DLA 515-1 for libav patching a memory corruption issue.
  • Issued DLA 524-1 for squidguard fixing a reflected cross-site scripting vulnerability.
  • Issued DLA 525-1 for gimp correcting a use-after-free vulnerability in the channel and layer properties parsing process.
Uploads
  • redis (2:3.2.1-1) New upstream bugfix release, plus subsequent upload to the backports repository.
  • python-django (1.10~beta1-1) New upstream experimental release.
  • libfiu (0.94-5) Misc packaging updates.
RC bugs

I also filed 170 FTBFS bugs against a7xpg, acepack, android-platform-dalvik, android-platform-frameworks-base, android-platform-system-extras, android-platform-tools-base, apache-directory-api, aplpy, appstream-generator, arc-gui-clients, assertj-core, astroml, bamf, breathe, buildbot, cached-property, calf, celery-haystack, charmtimetracker, clapack, cmake, commons-javaflow, dataquay, dbi, django-celery, django-celery-transactions, django-classy-tags, django-compat, django-countries, django-floppyforms, django-hijack, django-localflavor, django-markupfield, django-model-utils, django-nose, django-pipeline, django-polymorphic, django-recurrence, django-sekizai, django-sitetree, django-stronghold, django-taggit, dune-functions, elementtidy, epic4-help, fcopulae, fextremes, fnonlinear, foreign, fort77, fregression, gap-alnuth, gcin, gdb-avr, ggcov, git-repair, glance, gnome-twitch, gnustep-gui, golang-github-audriusbutkevicius-go-nat-pmp, golang-github-gosimple-slug, gprbuild, grafana, grantlee5, graphite-api, guacamole-server, ido, jless, jodreports, jreen, kdeedu-data, kdewebdev, kwalify, libarray-refelem-perl, libdbusmenu, libdebian-package-html-perl, libdevice-modem-perl, libindicator, liblrdf, libmail-milter-perl, libopenraw, libvisca, linuxdcpp, lme4, marble, mgcv, mini-buildd, mu-cade, mvtnorm, nose, octave-epstk, onioncircuits, opencolorio, parsec47, phantomjs, php-guzzlehttp-ringphp, pjproject, pokerth, prayer, pyevolve, pyinfra, python-asdf, python-ceilometermiddleware, python-django-bootstrap-form, python-django-compressor, python-django-contact-form, python-django-debug-toolbar, python-django-extensions, python-django-feincms, python-django-formtools, python-django-jsonfield, python-django-mptt, python-django-openstack-auth, python-django-pyscss, python-django-registration, python-django-tagging, python-django-treebeard, python-geopandas, python-hdf5storage, python-hypothesis, python-jingo, python-libarchive-c, python-mhash, python-oauth2client, python-proliantutils, python-pytc, python-restless, python-tidylib, python-websockets, pyvows, qct, qgo, qmidinet, quodlibet, r-cran-gss, r-cran-runit, r-cran-sn, r-cran-stabledist, r-cran-xml, rgl, rglpk, rkt, rodbc, ruby-devise-two-factor, ruby-json-schema, ruby-puppet-syntax, ruby-rspec-puppet, ruby-state-machine, ruby-xmlparser, ryu, sbd, scanlogd, signond, slpvm, sogo, sphinx-argparse, squirrel3, sugar-jukebox-activity, sugar-log-activity, systemd, tiles, tkrplot, twill, ucommon, urca, v4l-utils, view3dscene, xqilla, youtube-dl & zope.interface.
FTP Team

As a Debian FTP assistant I ACCEPTed 186 packages: akonadi4, alljoyn-core-1509, alljoyn-core-1604, alljoyn-gateway-1504, alljoyn-services-1504, alljoyn-services-1509, alljoyn-thin-client-1504, alljoyn-thin-client-1509, alljoyn-thin-client-1604, apertium-arg, apertium-arg-cat, apertium-eo-fr, apertium-es-it, apertium-eu-en, apertium-hbs, apertium-hin, apertium-isl, apertium-kaz, apertium-spa, apertium-spa-arg, apertium-tat, apertium-urd, arc-theme, argus-clients, ariba, beast-mcmc, binwalk, bottleneck, colorfultabs, dh-runit, django-modeltranslation, dq, dublin-traceroute, duktape, edk2, emacs-pdf-tools, eris, erlang-p1-oauth2, erlang-p1-sqlite3, erlang-p1-xmlrpc, faba-icon-theme, firefox-branding-iceweasel, golang-1.6, golang-defaults, golang-github-aelsabbahy-gonetstat, golang-github-howeyc-gopass, golang-github-oleiade-reflections, golang-websocket, google-android-m2repository-installer, googler, goto-chg-el, gr-radar, growl-for-linux, guvcview, haskell-open-browser, ipe, labplot, libalt-alien-ffi-system-perl, libanyevent-fcgi-perl, libcds-savot-java, libclass-ehierarchy-perl, libconfig-properties-perl, libffi-checklib-perl, libffi-platypus-perl, libhtml-element-library-perl, liblwp-authen-oauth2-perl, libmediawiki-dumpfile-perl, libmessage-passing-zeromq-perl, libmoosex-types-portnumber-perl, libmpack, libnet-ip-xs-perl, libperl-osnames-perl, libpodofo, libprogress-any-perl, libqtpas, librdkafka, libreoffice, libretro-beetle-pce-fast, libretro-beetle-psx, libretro-beetle-vb, libretro-beetle-wswan, libretro-bsnes-mercury, libretro-mupen64plus, libservicelog, libtemplate-plugin-datetime-perl, libtext-metaphone-perl, libtins, libzmq-ffi-perl, licensecheck, link-grammar, linux, linux-signed, lua-busted, magics++, mkalias, moka-icon-theme, neutron-vpnaas, newlisp, node-absolute-path, node-ejs, node-errs, node-has-flag, node-lodash-compat, node-strip-ansi, numba, numix-icon-theme, nvidia-graphics-drivers, nvidia-graphics-drivers-legacy-304xx, nvidia-graphics-drivers-legacy-340xx, obs-studio, opencv, pacapt, pgbackrest, postgis, powermock, primer3, profile-sync-daemon, pyeapi, pypandoc, pyssim, python-cutadapt, python-cymruwhois, python-fisx, python-formencode, python-hkdf, python-model-mommy, python-nanomsg, python-offtrac, python-social-auth, python-twiggy, python-vagrant, python-watcherclient, python-xkcd, pywps, r-bioc-deseq2, r-bioc-dnacopy, r-bioc-ensembldb, r-bioc-geneplotter, r-cran-adegenet, r-cran-adephylo, r-cran-distory, r-cran-fields, r-cran-future, r-cran-globals, r-cran-htmlwidgets, r-cran-listenv, r-cran-mlbench, r-cran-mlmrev, r-cran-pheatmap, r-cran-pscbs, r-cran-r.cache, refind, relatorio, reprotest, ring, ros-ros-comm, ruby-acts-as-tree, ruby-chronic-duration, ruby-flot-rails, ruby-numerizer, ruby-u2f, selenium-firefoxdriver, simgrid, skiboot, smtpping, snap-confine, snapd, sniffles, sollya, spin, subuser, superlu, swauth, swift-plugin-s3, syncthing, systemd-bootchart, tdiary-theme, texttable, tidy-html5, toxiproxy, twinkle, vmtk, wait-for-it, watcher, wcslib & xapian-core.

27 June 2016

Jonathan McDowell: Hire me!

It s rare to be in a position to be able to publicly announce you re looking for a new job, but as the opportunity is currently available to me I feel I should take advantage of it. That s especially true given the fact I ll be at DebConf 16 next week and hope to be able to talk to various people who might be hiring (and will, of course, be attending the job fair). I m coming to the end of my Masters in Legal Science and although it s been fascinating I ve made the decision that I want to return to the world of tech. I like building things too much it seems. There are various people I ve already reached out to, and more that are on my list to contact, but I figure making it more widely known that I m in the market can t hurt with finding the right fit. I m on LinkedIn and OpenHUB, which should give a bit more info on my previous experience and skill set. I know I m light on details here, so feel free to email me to talk about what I might be able to specifically bring to your organisation.

Alessio Treglia: A not exactly United Kingdom

Island of Ventotene Roman harbour

There once was a Kingdom strongly United, built on the honours of the people of Wessex, of Mercia, Northumbria and East Anglia who knew how to deal with the invasion of the Vikings from the east and of Normans from the south, to come to unify the territory under an umbrella of common intents. Today, however, 48% of them, while keeping solid traditions, still know how to look forward to the future, joining horizons and commercial developments along with the rest of Europe. The remaining 52%, however, look back and can not see anything in front of them if not a desire of isolation, breaking the European dream born on the shores of Ventotene island in 1944 by Altiero Spinelli, Ernesto Rossi and Ursula Hirschmann through the Manifesto for a free and united Europe . An incurable fracture in the country was born in a referendum on 23 June, in which just over half of the population asked to terminate his marriage to the great European family, bringing the UK back by 43 years of history. <Read More [by Fabio Marzocca]>

Paul Tagliamonte: Hello, Sense!

A while back, I saw a Kickstarter for one of the most well designed and pretty sleep trackers on the market. I fell in love with it, and it has stuck with me since. A few months ago, I finally got my hands on one and started to track my data. Naturally, I now want to store this new data with the rest of the data I have on myself in my own databases. I went in search of an API, but I found that the Sense API hasn't been published yet, and is being worked on by the team. Here's hoping it'll land soon! After some subdomain guessing, I hit on api.hello.is. So, naturally, I went to take a quick look at their Android app and network traffic, lo and behold, there was a pretty nicely designed API. This API is clearly an internal API, and as such, it's something that should not be considered stable. However, I'm OK with a fragile API, so I've published a quick and dirty API wrapper for the Sense API to my GitHub.. I've published it because I've found it useful, but I can't promise the world, (since I'm not a member of the Sense team at Hello!), so here are a few ground rules of this wrapper: This module is currently Python 3 only. If someone really needs Python 2 support, I'm open to minimally invasive patches to the codebase using six to support Python 2.7. Working with the API: First, let's go ahead and log in using python -m sense. 
$ python -m sense
Sense OAuth Client ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Sense OAuth Client Secret: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Sense email: paultag@gmail.com
Sense password: 
Attempting to log into Sense's API
Success!
Attempting to query the Sense API
The humidity is **just right**.
The air quality is **just right**.
The light level is **just right**.
It's **pretty hot** in here.
The noise level is **just right**.
Success!
Now, let's see if we can pull up information on my Sense: 
>>> from sense import Sense
>>> sense = Sense()
>>> sense.devices()
 'senses': [ 'id': 'xxxxxxxxxxxxxxxx', 'firmware_version': '11a1', 'last_updated': 1466991060000, 'state': 'NORMAL', 'wifi_info':  'rssi': 0, 'ssid': 'Pretty Fly for a WiFi (2.4 GhZ)', 'condition': 'GOOD', 'last_updated': 1462927722000 , 'color': 'BLACK' ], 'pills': [ 'id': 'xxxxxxxxxxxxxxxx', 'firmware_version': '2', 'last_updated': 1466990339000, 'battery_level': 87, 'color': 'BLUE', 'state': 'NORMAL' ]
Neat! Pretty cool. Look, you can even see my WiFi AP! Let's try some more and pull some trends out. 
>>> values = [x.get("value") for x in sense.room_sensors()["humidity"]][:10]
>>> min(values)
45.73904
>>> max(values)
45.985928
>>>
I plan to keep maintaining it as long as it's needed, so I welcome co-maintainers, and I'd love to see what people build with it! So far, I'm using it to dump my room data into InfluxDB, pulling information on my room into Grafana. Hopefully more to come! Happy hacking!

26 June 2016

Niels Thykier: Anti-declarative packaging top 15 build-helpers inserting maintscripts

Debian packages can run arbitrary code via maintainer scripts (sometimes shortened into maintscripts ) during installation/removal etc. While they certainly have their use cases, their failure modes causes exciting bugs like fails to install or the dreaded fails to remove . They also have other undesirable effects such as: Accordingly, I think we should aim for a more declarative packaging style. To help facilitate this, I have implemented 3 tracking tags in Lintian. With these, we were able to learn that 73.5% of all packages do not have any of these scripts. But I can now also produce a list of helpers that insert the most maintainer script snippets. The current top 15 is:
  1. dhpython with 3775 instances
    • This is an umbrella for all helpers using dh-python s python module, see #827774.
  2. dh_installmenu with 1861 instances
  3. dh_makeshlibs with 1396 remaining instances
  4. dh_installinit with 1224 instances
  5. dh_python2 with 1168 instances
  6. dh_installdebconf with 772 instances
  7. dh_installdeb with 754 instances
    • These are the dpkg-maintscript-helper snippets for rm_conffile , mv_conffile etc. Hopefully in the near future, dpkg will support these directly.
  8. dh_systemd_enable with 447 instances
  9. dh_installemacsen with 179 instances
  10. dh_icons with 165 instances
  11. dh_installtex with 137 instances
  12. dh_apache2 with 117 instances
  13. dh_installudev with 98 instances
  14. dh_installxfonts with 87 instances
  15. dh_systemd_start with 79 instances
With this list, it seems to me that some obvious focus areas would be: Eventually we will also have to dig through all the manual maintainer scripts. But I think we got plenty to start with.:) [1] For some, circular dependencies in itself is an issue. I can certainly appreciate them as being suboptimal, but most of the issues we have are probably caused by insufficient tooling rather than a theoretical issue (that is, if we remove all postinst scripts).
Filed under: Debhelper, Debian, Lintian

24 June 2016

Norbert Preining: Debian/TeX Live 2016.20160623-1

About one month has passed since we did release TeX Live 2016, and more than a month since the last Debian packages, so it is high time to ship out a new checkout of upstream. Nothing spectacular new here, just lots and lots of updates since the freeze. texlive2016-debian I am dedicating this release to those intelligent beings who voted against the stupid Brexit and for remaining in the EC! I am still optimist! New packages aucklandthesis, autobreak, cquthesis, getargs, hustthesis, ietfbibs, linop, markdown, olsak-misc, optidef, sanitize-umlaut, umbclegislation, wordcount, xcntperchap. Updated packages academicons, achemso, acmart, acro, animate, apa6, arabluatex, archaeologie, babel-hungarian, beamertheme-epyt, beebe, biblatex-abnt, biblatex-anonymous, biblatex-bookinother, biblatex-caspervector, biblatex-chicago, biblatex-manuscripts-philology, biblatex-morenames, biblatex-opcit-booktitle, biblatex-philosophy, biblatex-realauthor, biblatex-source-division, biblatex-subseries, bidi, bookcover, bxjscls, caption, chemformula, chemmacros, circuitikz, cloze, cochineal, context, csplain, cstex, datetime2, denisbdoc, dvipdfmx-def, epstopdf, erewhon, exsol, fbb, fibeamer, fithesis, fontawesome, fontspec, fonts-tlwg, geschichtsfrkl, getmap, glossaries, glossaries-extra, graphics, graphics-cfg, gregoriotex, gzt, he-she, hook-pre-commit-pkg, hyperref, ifluatex, keyvaltable, koma-script, l3build, latex, latex-bin, limap, lollipop, lshort-chinese, luaotfload, luatex85, luatex-def, luatexja, lua-visual-debug, marginnote, mcf2graph, media9, minted, mptopdf, msu-thesis, musixtex, navigator, nwejm, oberdiek, patchcmd, pdfcomment, pdftex-def, pdfx, pkuthss, platex, pstricks, ptex, ptex2pdf, ptex-base, ptex-ng, reledmac, repere, scheme-xml, sduthesis, showlabels, tableaux, tcolorbox, tex4ht, texinfo, texlive-scripts, tex-overview, textpos, tools, translations, tudscr, unicode-data, uplatex, uptex, xassoccnt, xcharter, xetex, xindy, yathesis, ycbook. Enjoy.

23 June 2016

Paul Wise: DebCamp16 day 0

Today is officially the first day of DebCamp 2016. The night wasn't as cold as I had feared. Woke at 5am for some reason. Noted the network still blocks port 6697 and 7000, worked around in IRC client configuration using 9999. Reply to network discussion to point that out. Minor changes to the empathy Debian RTC wiki page. Answer support@mentors.d.n bug email about shared company OpenPGP keys and suggest moving to individual keys. Review wiki RecentChanges. Comment on NetworkManager upstream bug #705545 that MAC address privacy is a complicated feature with many use cases. Warn another person that reporting Alioth to SpamCop does nothing and link to the unsubscription URL. Talk to Brown about IP address conflict sparc64 porters found with the setup of notker (sparc64 build machine). Filed Debian wishlist bug #827944 against at asking for support for using an editor to write at jobs. Woke up properly, discussed spam over breakfast. Notice Point Linux in the Distrowatch feed and invite them to the derivatives census. Point out reproducible builds in a discussion about source-only uploads. Commented that I encountered evolution upstream crash bug #680471 again. Reported gnome-shell upstream crash bug #767969. Joined the tour around the campus, enjoyed the view from the outdoor hacklab at the top of the hill. Confirmed that "Monkey Gland" from the pub menu is not in fact derived from monkeys in any way. Noted that Pollito did not eat chicken from the buffet. Beat head against VPN/SIP/WebRTC for a while but oncoming jetlag put me out of business for some hours. Pointed out the future Packages.gz removal in favour of Packages.xz to the popcon developers.

Jaminy Prabaharan: GSoC-Journey till Mid term

Hi readers,

Here comes my journey till the mid-term (June 21st) as a blog to share my experience.

I have previously worked on some social related projects such as smart guidance for blind and sensor based wireless controller . I have been selected as a speaker for FOSSASIA-16 (Asia s premier technological event)to talk on the project smart guidance for blind .FOSSASIA speakers. It was a great experience participating in the technological event in Singapore science centre.Got an opportunity to meet open source contributors from all over the world(even though it is an Asian event, participation was all over from the world). There were pre-meetups for FOSSASIA on the day before three-day event.I have attended the one organised by RedHat, Singapore.Discussed on many topics related to open source.

Three days of FOSSASIA event was a great experience.It was the second time as a speaker in an international conference.My talk was on the second day.Sharing is the best way to increase your knowledge. Talks and workshops were brainstorming.Learnt many new things and got the courage to contribute to the open source.Met Daniel Pocock in Debian exhibition table.Meeting awesome people can be the turning point of life.Had a discussion about the Debian projects and it motivated me for open source software.We have discussed about the Real Time Communication and was encouraged to apply for GSoC (Google Summer of Code). As per our discussion, prepared the project proposal on improving voice,video and chat communication with free software and submitted it for GSoC. I have been selected to contribute for Debian with stipend from Google.

This was my first application for GSoC and I have been selected to contribute for open source and free software. I would like to thank Google and Debian for giving this amazing experience.

Learning and coding have begun.Updated my laptop with Jessie, latest version of Debian.Get acquainted with the new platform.Got to learn many things about Real Time Communication.Learnt more about SIP, XMPP, peer-to-peer technology to work on my project.It s always better to be clear with theory before coding.When it comes to voice and video over IP, most people nowadays are quick to use Skype, Whatsapp, or Viber. My main goals of the project are helping people to avoid using proprietary communications tools like Skype, Viber and WhatsApp and simplifying the setup of free alternatives like Jitsi, Linphone, Ekiga, Tox (qtox), Mumble.Downloaded some of the already available open source VoIP to find the problems behind it and improve it further.Bootstrapping any business relevant network based on these free alternatives is still hard.

Would you like to list the senders, receivers and date of the messages in the inbox of your mail.Python has a library file IMAP which can be used to connect to an email account, examine every message in every folder and look at the To , From and CC headers of every email message in the folder.

Do you have phone numbers and other contact details in old emails? Would you like a quick way to data-mine your inbox to find them and help migrate them to your address book? Got the help from phonenumbers library for parsing, formatting, and validating international phone numbers.I would like to share how I imported this library file into my coding.Download the given library file and open the file in the terminal.Type

$ python setup.py install

to install the library file.Now you can call the functions by importing phonenumbers.

You can go through the code in my GitHub profile here.(Recently started committing my projects in GitHub)

Iain R. Learmonth joined my journey as a mentor.Helped in solving some issues in my coding through GitHub.

It was a wonderful journey till now.Will be working further to improve voice, video and chat communication with free software.Stay connected to know more about my further journey through GSoC.

download

22 June 2016

Andrew Cater: "But I'm a commercial developer / a government employee"

Following on:

Having seen some posts about this elsewhere on the 'Net:

  1. Your specific area of FLOSS expertise (or)
  2. Your time / hours in an area unrelated to your FLOSS expertise (or)
  3. A job that has no impact or bearing on your FLOSS expertise (or)
  4. Your time / hours only - and negotiate accordingly
Your employer may be willing to negotiate / grant you an opt-out clause to protect your FLOSS expertise / accept an additional non-exclusive licence to your FLOSS code / be prepared to sign an assignment e.g.

"You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: 
Yoyodyne, Inc., hereby disclaims all copyright
interest in the program  Gnomovision'
(which makes passes at compilers) written 
by James Hacker.

signature of Ty Coon, 1 April 1989
Ty Coon, President of Vice"
 
[http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html

If none of the above is feasible: don't contribute anything that crosses the streams and mingles commercial and FLOSS expertise, however much you're offered to do so.

Patents / copyrights

"In the 1980s I had not yet realized how confusing it was to speak of the issue of intellectual property . That term is obviously biased; more subtle is the fact that it lumps together various disparate laws which raise very different issues. Nowadays I urge people to reject the term intellectual property entirely, lest it lead others to suppose that those laws form one coherent issue. The way to be clear is to discuss patents, copyrights, and trademarks separately. See further explanation of how this term spreads confusion and bias."
[http://www.gnu.org/gnu/manifesto.en.html - footnote 8.]

If you want to assert a patent - it's probably not FLOSS. Go away :)

If you want to assert a trademark of your own - it's probably not FLOSS. Go away :)
[Trademarks may ordinarily be outside the scope of normal FLOSS legal considerations - but should be acknowledged wherever they occur both as a matter of law and as a matter of courtesy]

Copyright gives legal standing (locus standi in the terminology of English common law) to sue for infringement - that's the basis of licence enforcement actions.

Employees of governments and those doing government work
This is complex: some FLOSS contributors see a significant amount of this as immaterial to them in the same way that some indigenous populations do not acknowledge imposed colonial legal structures as valid - but both value systems can co-exist




Andrew Cater: Why I must use Free Software - and why I tell others to do so

My work colleagues know me well as a Free/Libre software zealot, constantly pointing out to them how people should behave, how FLOSS software trumps commercial software and how this is the only way forward. This for the last 20 odd years. It's a strain to argue this repeatedly: at various times, I have been asked to set out more clearly why I use FLOSS, what the advantages are, why and how to contribute to FLOSS software.

"We are creating a world that all may enter without privilege or prejudice accorded by race, economic power, military force, or station of birth.
We are creating a world where anyone, anywhere may express his or her beliefs, no matter how singular, without fear of being coerced into silence or conformity.
Your legal concepts of property, expression, identity, movement, and context do not apply to us. They are all based on matter, and there is no matter here
...
In our world, whatever the human mind may create can be reproduced and distributed infinitely at no cost. The global conveyance of thought no longer requires your factories to accomplish."
[John Perry Barlow - Declaration of the independence of cyberspace 1996 https://www.eff.org/cyberspace-independence]

That's some of it right there: I was seduced by a modem and the opportunities it gave. I've lived in this world since 1994, come to appreciate it and never really had the occasion to regret it.

I'm involved in the Debian community - which is very much a "do-ocracy" - and I've lived with Debian GNU Linux since 1995 and not had much cause to regret that either, though I do regret that force of circumstance has meant that I can't contribute as much as I'd like. Pretty much every machine I touch ends up running Debian, one way or the other, or should do if I had my way.
Digging through my emails since then on the various mailing lists - some of them are deeply technical, though fewer these days: some are Debian political: most are trying to help people with problems / report successes or, occasionally thanks and social chit chat. Most people in the project have never met me - though that's not unusual in an organisation with a thousand developers spread worldwide - and so the occasional chance to talk to people in real life is invaluable.

The crucial thing is that there is common purpose and common intelligence - however crazy mailing list flame wars can get sometimes - and committed, caring people. Some of us may be crazy zealots, some picky and argumentative - Debian is what we have in common, pretty much.

It doesn't depend on physical ability. Espy (Joel Klecker) was one of our best and brightest until his death at age 21: almost nobody knew he was dying until after his death. My own physical limitations are pretty much irrelevant provided I can type.

It does depend on collaboration and the strange, dysfunctional family that is our community and the wider FLOSS community in which we share and in which some of us have multiple identities in working with different projects.
This is going to end up too long for Planet Debian - I'll end this post here and then continue with some points on how to contribute and why employers should let their employers work on FLOSS.




Gunnar Wolf: Answering to a CACM Viewpoint : on the patent review process

I am submitting a comment to Wen Wen and Chris Forman's Viewpoint on the Communications of the ACM, titled Economic and business dimensions: Do patent commons and standards-setting organizations help navigate patent thickets?. I believe my comment is worth sharing a bit more openly, so here it goes. Nevertheless, please refer to the original article; it makes very interesting and valid points, and my comment should be taken as an extra note on a great text only! I was very happy to see an article with this viewpoint published. This article, however, mentions some points I believe should be further stressed out as problematic and important. Namely, still at the introduction, after mentioning that patents are intended to provide incentives for innovation by granting to inventors temporary monopoly rights , the next paragraph continues, The presence of patent thickets may create challenges for ICT producers. When introducing a new product, a firm must identify patents its product may infringe upon. The authors continue explaining the needed process But this simple statement should be enough to explain how the patent system is broken and needs repair. A requisite for patenting an invention was originally the inventive and non-obvious characteristics. Anything worth being granted a patent should be inventive enough, it should be non-obvious to an expert in the field. When we see huge bodies of awarded (and upheld) patents falling in the case the authors mention, it becomes clear that the patent applications were not thoroughly researched prior to their patent grant. Sadly, long gone are the days where the United States Patent and Trademarks Office employed minds such as Albert Einstein's; nowadays, the office is more a rubber-stamping bureaucracy where most patents are awarded, and this very important requisite is left open to litigation: If somebody is found in breach of a patent, they might choose to defend the issue that the patent was obvious to an expert. But, of course, that will probably cost more in legal fees than settling for an agreement with the patent holder. The fact that in our line of work we must take care to search for patents before releasing any work speaks a lot about the process. Patents are too easily granted. They should be way stricter; the occurence of an independent developer mistakenly (and innocently!) breaching a patent should be most unlikely, as patents should only be awarded to truly non-obvious solutions.

21 June 2016

Matthew Garrett: I've bought some more awful IoT stuff

I bought some awful WiFi lightbulbs a few months ago. The short version: they introduced terrible vulnerabilities on your network, they violated the GPL and they were also just bad at being lightbulbs. Since then I've bought some other Internet of Things devices, and since people seem to have a bizarre level of fascination with figuring out just what kind of fractal of poor design choices these things frequently embody, I thought I'd oblige.

Today we're going to be talking about the KanKun SP3, a plug that's been around for a while. The idea here is pretty simple - there's lots of devices that you'd like to be able to turn on and off in a programmatic way, and rather than rewiring them the simplest thing to do is just to insert a control device in between the wall and the device andn ow you can turn your foot bath on and off from your phone. Most vendors go further and also allow you to program timers and even provide some sort of remote tunneling protocol so you can turn off your lights from the comfort of somebody else's home.

The KanKun has all of these features and a bunch more, although when I say "features" I kind of mean the opposite. I plugged mine in and followed the install instructions. As is pretty typical, this took the form of the plug bringing up its own Wifi access point, the app on the phone connecting to it and sending configuration data, and the plug then using that data to join your network. Except it didn't work. I connected to the plug's network, gave it my SSID and password and waited. Nothing happened. No useful diagnostic data. Eventually I plugged my phone into my laptop and ran adb logcat, and the Android debug logs told me that the app was trying to modify a network that it hadn't created. Apparently this isn't permitted as of Android 6, but the app was handling this denial by just trying again. I deleted the network from the system settings, restarted the app, and this time the app created the network record and could modify it. It still didn't work, but that's because it let me give it a 5GHz network and it only has a 2.4GHz radio, so one reset later and I finally had it online.

The first thing I normally do to one of these things is run nmap with the -O argument, which gives you an indication of what OS it's running. I didn't really need to in this case, because if I just telnetted to port 22 I got a dropbear ssh banner. Googling turned up the root password ("p9z34c") and I was logged into a lightly hacked (and fairly obsolete) OpenWRT environment.

It turns out that here's a whole community of people playing with these plugs, and it's common for people to install CGI scripts on them so they can turn them on and off via an API. At first this sounds somewhat confusing, because if the phone app can control the plug then there clearly is some kind of API, right? Well ha yeah ok that's a great question and oh good lord do things start getting bad quickly at this point.

I'd grabbed the apk for the app and a copy of jadx, an incredibly useful piece of code that's surprisingly good at turning compiled Android apps into something resembling Java source. I dug through that for a while before figuring out that before packets were being sent, they were being handed off to some sort of encryption code. I couldn't find that in the app, but there was a native ARM library shipped with it. Running strings on that showed functions with names matching the calls in the Java code, so that made sense. There were also references to AES, which explained why when I ran tcpdump I only saw bizarre garbage packets.

But what was surprising was that most of these packets were substantially similar. There were a load that were identical other than a 16-byte chunk in the middle. That plus the fact that every payload length was a multiple of 16 bytes strongly indicated that AES was being used in ECB mode. In ECB mode each plaintext is split up into 16-byte chunks and encrypted with the same key. The same plaintext will always result in the same encrypted output. This implied that the packets were substantially similar and that the encryption key was static.

Some more digging showed that someone had figured out the encryption key last year, and that someone else had written some tools to control the plug without needing to modify it. The protocol is basically ascii and consists mostly of the MAC address of the target device, a password and a command. This is then encrypted and sent to the device's IP address. The device then sends a challenge packet containing a random number. The app has to decrypt this, obtain the random number, create a response, encrypt that and send it before the command takes effect. This avoids the most obvious weakness around using ECB - since the same plaintext always encrypts to the same ciphertext, you could just watch encrypted packets go past and replay them to get the same effect, even if you didn't have the encryption key. Using a random number in a challenge forces you to prove that you actually have the key.

At least, it would do if the numbers were actually random. It turns out that the plug is just calling rand(). Further, it turns out that it never calls srand(). This means that the plug will always generate the same sequence of challenges after a reboot, which means you can still carry out replay attacks if you can reboot the plug. Strong work.

But there was still the question of how the remote control works, since the code on github only worked locally. tcpdumping the traffic from the server and trying to decrypt it in the same way as local packets worked fine, and showed that the only difference was that the packet started "wan" rather than "lan". The server decrypts the packet, looks at the MAC address, re-encrypts it and sends it over the tunnel to the plug that registered with that address.

That's not really a great deal of authentication. The protocol permits a password, but the app doesn't insist on it - some quick playing suggests that about 90% of these devices still use the default password. And the devices are all based on the same wifi module, so the MAC addresses are all in the same range. The process of sending status check packets to the server with every MAC address wouldn't take that long and would tell you how many of these devices are out there. If they're using the default password, that's enough to have full control over them.

There's some other failings. The github repo mentioned earlier includes a script that allows arbitrary command execution - the wifi configuration information is passed to the system() command, so leaving a semicolon in the middle of it will result in your own commands being executed. Thankfully this doesn't seem to be true of the daemon that's listening for the remote control packets, which seems to restrict its use of system() to data entirely under its control. But even if you change the default root password, anyone on your local network can get root on the plug. So that's a thing. It also downloads firmware updates over http and doesn't appear to check signatures on them, so there's the potential for MITM attacks on the plug itself. The remote control server is on AWS unless your timezone is GMT+8, in which case it's in China. Sorry, Western Australia.

It's running Linux and includes Busybox and dnsmasq, so plenty of GPLed code. I emailed the manufacturer asking for a copy and got told that they wouldn't give it to me, which is unsurprising but still disappointing.

The use of AES is still somewhat confusing, given the relatively small amount of security it provides. One thing I've wondered is whether it's not actually intended to provide security at all. The remote servers need to accept connections from anywhere and funnel decent amounts of traffic around from phones to switches. If that weren't restricted in any way, competitors would be able to use existing servers rather than setting up their own. Using AES at least provides a minor obstacle that might encourage them to set up their own server.

Overall: the hardware seems fine, the software is shoddy and the security is terrible. If you have one of these, set a strong password. There's no rate-limiting on the server, so a weak password will be broken pretty quickly. It's also infringing my copyright, so I'd recommend against it on that point alone.

comment count unavailable comments

Next.

Previous.