Hello from a snowy Montr al! My life has been pretty busy lately¹ so please forgive this late report. On November 19th, our local Debian User Group met at Montreal's most prominent hackerspace, Foulab. We've been there a few times already, but since our last visit, Foulab has had some membership/financial troubles. Happy to say things are going well again and a new team has taken over the space. This meetup wasn't the most productive day for me (something about being exhausted apparently makes it hard to concentrate), but other people did a bunch of interesting stuff :)

• Kienan & Gabriel worked on the libinfluxdb-http-perl package (now in Sid!), which is needed for smokeping.
• J r me worked on updating JRuby to the latest upstream version.
• I failed to update monitoring-plugins-systemd to the latest upstream version. It seems the entire test suite has been re-written and I couldn't make it work in sbuild...
• Tiago and Tassia worked on the Debian Contributors website. More specifically, they added a DSA domains data source and created a scheduler on dcf.debian.net to make daily updates on the data sources in the dc-sources repository.
• Michael worked on the 2024 NorthSec badge.
• Gerard worked on debugging his broken AirGradient board.

Pictures Here are a bunch of pictures I took! Foulab is always a great place to snap quirky things :)

The following contributors got their Debian Developer accounts in the last two months:

• Sahil Dhiman (sahil)
• Jakub Ru i ka (jru)

The following contributors were added as Debian Maintainers in the last two months:

• Josenilson Ferreira da Silva
• Ileana Dumitrescu
• Douglas Kosovic
• Israel Galadima
• Timothy Pearson
• Blake Lee
• Vasyl Gello
• Joachim Zobel
• Amin Bandali

Congratulations!

Our local Debian user group gathered on Sunday October 30th to chat, work on Debian and do other, non-Debian related hacking :) This time around, we met at EfficiOS's¹ offices. As you can see from the following picture, it's a great place and the view they have is pretty awesome. Many thanks for hosting us! This was our 4th meeting this year and once again, attendance was great: 10 people showed up to work on various things. Following our bi-monthly schedule, our next meeting should be in December, but I'm not sure it'll happen. December can be a busy month here and I will have to poke our mailing list to see if people have the spoons for an event. This time around, I was able to get a rough log of the Debian work people did: pollo:

• followed up with the DPL for upcoming Debian Python Team Sprint
• opened a wishlist bug (#1023140) on the devscripts package for uscan to verify git tags signed with SSH keys
• updated python-mediafile and mutagen to the latest upstream version

mjeanson:

• fixed RC bug #1022419 on babeltrace
• kindly hosted us, with the help of Mathieu Desnoyers

viashimo:

• started updating puppet-strings to 3.0.1
• was blocked in the process by tests requiring ruby-mdl, which is not packaged yet
• was blocked in packaging ruby-mdl by rubocop not being >= ~1.2x

lavamind:

• updated jnffi to 1.3.9, as part of the work on jruby he's been doing

anarcat:

• updated g10k to latest upstream

babelouest:

• updated node-jose to 4.10.4
• worked on bug #1021779 in libical3

tvaz:

• worked on updating apticron

As always, thanks to the Debian project for granting us a budget to buy some food!

I built my last desktop computer what seems like ages ago. In 2011, I was in a very different place, both financially and as a person. At the time, I was earning minimum wage at my school's caf to pay rent. Since the caf was owned by the school cooperative, I had an employee discount on computer parts. This gave me a chance to build my first computer from spare parts at a reasonable price. After 10 years of service¹, the time has come to upgrade. Although this machine was still more than capable for day to day tasks like browsing the web or playing casual video games, it started to show its limits when time came to do more serious work. Old computer specs: I first started considering an upgrade in September 2020: David Bremner was kindly fixing a bug in ledger that kept me from balancing my books and since it seemed like a class of bug that would've been easily caught by an autopkgtest, I decided to add one. After adding the necessary snippets to run the upstream testsuite (an easy task I've done multiple times now), I ran sbuild and ... my computer froze and crashed. Somehow, what I thought was a simple Python package was maxing all the cores on my CPU and using all of the 8GB of memory I had available.² A few month later, I worked on jruby and the builds took 20 to 30 minutes long enough to completely disrupt my flow. The same thing happened when I wanted to work on lintian: the testsuite would take more than 15 minutes to run, making quick iterations impossible. Sadly, the pandemic completely wrecked the computer hardware market and prices here in Canada have only recently started to go down again. As a result, I had to wait more time than I would've liked not to pay scalper prices. New computer specs: The difference between the two machines is pretty staggering: I've gone from a CPU with 2 cores and 8 threads, to one with 12 cores and 24 threads. Not only that, but single-threaded performance has also vastly increased in those 10 years. A good example would be building grammalecte, a package I've recently sponsored. I feel it's a good benchmark, since the build relies on single-threaded performance for the normal Python operations, while being threaded when it compiles the dictionaries. On the old computer: And as you can see, on the new computer the build time has been significantly reduced: Same goes for things like the lintian testsuite. Since it's a very multi-threaded workload, it now takes less than 2 minutes to run; a 750% improvement. All this to say I'm happy with my purchase. And lo and behold I can now build ledger without a hitch, even though it maxes my 24 threads and uses 28GB of RAM. Who would've thought...

Here s my (sixteenth) monthly update about the activities I ve done in the F/L/OSS world.

Debian

This was my 25th month of contributing to Debian. I became a DM in late March 2019 and a DD on Christmas 19! \o/ This month was bat-shit crazy. Why? We ll come to it later, probably 15th of this month?
Anyway, besides being crazy, hectic, adventerous, and the first of 2021, this month I was super-insanely busy. With what? Hm, more about this later this month! ^_^ However, I still did some Debian stuff here and there. Here are the following things I worked on:

Uploads and bug fixes:

• ruby-rack (2.1.1-6) - Fixing CVE-2020-8184/bug #963477.
• ruby-faye-websocket (0.11.0-1) - Fixing CVE-2020-15133/bug #967061.
• ruby-faye (1.4.0-1) - Fixing CVE-2020-11020/bug #959392 and CVE-2020-15134/bug #967063.
• ruby-rack (2.1.4-2) - Fix failing tests and new upstream version, v2.1.4.
• ruby-rake-ant (1.0.4-1) - Initial release, bug #979498.
• libgit2 (1.1.0+dfsg.1-4) - Source-only upload for migration.
• ruby-scanf (1.0.0-1) - Initial release, bug #979497.
• polybar (3.5.4-1) - New upstream version, v3.5.4.
• fpc (3.2.0+dfsg-10) - Severe crash fix for bugs #979850, #979853, #979862, and #979851.
• ruby-em-redis (0.3.0+gh-3) - Fixing FTBFS, bug #978975, as requested by Holger! :)
• gdebi (0.9.5.7+nmu4) - Fixing FTBFS, bug #951923, as requested by Holger! :)
• ruby-redcarpet (3.4.0-4+deb10u1) - Fixing CVE-2020-26298/bug #980057.
• ruby-in-parallel (0.1.17-1.2) - Fixing autopkgtest, bug #979700.
• ruby-in-parallel (0.1.17-1.3) - Fixing random test failures, bug #980585.
• python-bottle (0.12.15-2+deb10u1) - Fixing CVE-2020-28473.

Other $things:

• Attended the Debian Ruby team meeting.
• Mentoring for newcomers.
• Moderation of -project mailing list.
• Sponsored golang-github-gorilla-css for Fedrico.

---

Debian (E)LTS

Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success. And Debian Extended LTS (ELTS) is its sister project, extending support to the Jessie release (+2 years after LTS support). This was my sixteenth month as a Debian LTS and seventh month as a Debian ELTS paid contributor.
I was assigned 26.00 hours for LTS and 36.75 hours for ELTS and worked on the following things:
(however, I worked extra for 9 hours for LTS and 9 hours for ELTS this month, which I intend to balance from the next month!)

LTS CVE Fixes and Announcements:

• Issued DLA 2518-1, fixing CVE-2020-35492, for cairo.
  For Debian 9 Stretch, these problems have been fixed in version 1.14.8-1+deb9u1.
• Issued DLA 2525-1, fixing CVE-2018-19840, CVE-2018-19841, CVE-2019-11498, CVE-2019-1010315, CVE-2019-1010317, CVE-2019-1010319, and CVE-2020-35738, for wavpack.
  For Debian 9 Stretch, these problems have been fixed in version 5.0.0-2+deb9u3.
• Issued DLA 2526-1, fixing CVE-2020-26298, for ruby-redcarpet.
  For Debian 9 Stretch, these problems have been fixed in version 3.3.4-2+deb9u1.
• Prepared DSA 4831-1, fixing CVE-2020-26298, for ruby-redcarpet. For Debian 10 Buster, these problems have been fixed in version 3.4.0-4+deb10u1. The announcement was released by the Security Team.
• Issued DLA 2528-1, fixing CVE-2021-3185, for gst-plugins-bad1.0.
  For Debian 9 Stretch, these problems have been fixed in version 1.10.4-1+deb9u1.
• Issued DLA 2529-1, fixing CVE-2021-3181, for mutt.
  For Debian 9 Stretch, these problems have been fixed in version 1.7.2-1+deb9u5.
• Issued DLA 2531-1), fixing CVE-2020-28473, for python-bottle.
  For Debian 9 Stretch, these problems have been fixed in version 0.12.13-1+deb9u1.
• Released buster-pu update, fixing CVE-2020-28473, for python-bottle. For Debian 10 Buster, these problems have been fixed in version 0.12.15-2+deb10u1.

ELTS CVE Fixes and Announcements:

• Issued ELA 344-1, fixing CVE-2020-27350, for apt.
  For Debian 8 Jessie, these problems have been fixed in version 1.0.9.8.7.
• Issued ELA 346-1, fixing CVE-2016-10169, CVE-2018-19840, CVE-2019-1010319, and CVE-2020-35738, for wavpack.
  For Debian 8 Jessie, these problems have been fixed in version 4.70.0-1+deb8u1.
• Issued ELA 347-1, fixing CVE-2020-26298, for ruby-redcarpet.
  For Debian 8 Jessie, these problems have been fixed in version 3.1.2-1+deb8u1.
• Issued ELA 348-1, fixing CVE-2021-3185, for gst-plugins-bad1.0.
  For Debian 8 Jessie, these problems have been fixed in version 1.4.4-2.1+deb8u3.
• Issued ELA 349-1, fixing CVE-2021-3181, for mutt.
  For Debian 8 Jessie, these problems have been fixed in version 1.5.23-3+deb8u5.
• Issued ELA 350-1, fixing CVE-2020-28473, for python-bottle.

Other (E)LTS Work:

• Front-desk duty from 28-12 until 03-01 and from 25-01 until 31-01 for both LTS and ELTS.
• Triaged dropbear, gst-plugins-bad1.0, phpmyadmin, qemu, firefox-esr, thunderbird, openldap, libdatetime-timezone-perl, tzdata, jasper, ckeditor, liblivemedia, wavpack, and ruby-redcarpet.
• Marked CVE-2019-12953/dropbear as postponed for jessie.
• Marked CVE-2019-12953/dropbear as postponed for stretch.
• Marked CVE-2018-19841/wavpack as not-affected for jessie.
• Marked CVE-2019-1010315/wavpack as not-affected for jessie.
• Marked CVE-2019-1010317/wavpack as not-affected for jessie.
• Marked CVE-2021-21252/phpmyadmin as no-dsa for stretch.
• Marked CVE-2021-20196/qemu as postponed for stretch.
• Marked CVE-2021-21252/phpmyadmin as no-dsa for jessie.
• Marked CVE-2021-20196/qemu as postponed for jessie.
• Marked CVE-2020-11947/qemu as postponed for jessie.
• Marked CVE-2021-3326/glibc as no-dsa for jessie.
• Marked CVE-2021-3326/glibc as no-dsa for stretch.
• Marked CVE-2020-35517/qemu as not-affected instead of postponed for jessie.
• Marked CVE-2021-2627 1,2 /ckeditor as postponed for jessie.
• Marked CVE-2020-24027/liblivemedia as no-dsa for stretch.
• Marked CVE-2021-2627 1,2 /ckeditor as postponed for stretch.
• Auto EOL ed csync2, firefox-esr, linux, thunderbird, collabtive, activemq, and xen for jessie.
• Got my first ever CVE assigned - CVE-2021-3181 for mutt. Weeeehooooo! \o/
• Attended the monthly LTS meeting. Logs here.
• General discussion on LTS private and public mailing list.

---

Interesting Bits!

• This January, on 23rd and 24th, we had Mini DebConf India 2021 online.
  I had a talk as well, titled, Why Point Releases are important and how you can help prepare them?". It was a fun and a very short talk, where I just list out the reasons and ways to help in the preparation of point releases . I did some experimentation with this talk, figuring out what works for the audience and what doesn t and where can I improve for the next time I talk about this topic! \o/
  You can listen to the talk here and let me know if you have any feedback! Anyway, the conference lasted for 2 days and I also did some volunteering (talk director, talk miester) in Hindi and English, both! It was all so fun and new. Anyway, here s the picture we took:
• In another exciting news, I got my first CVE assigned!!! \o/
  No, it is not something that I found, it was discovered by Tavis Ormandy. I just assigned this a CVE ID, CVE-2021-3181.
  This is my first, so I am very excited about this! ^_^
• Besides, there s something more that is in the pipelines. Can t talk about it now, shh. But hopefully very sooooooon!

---

Other $things! \o/ This month was tiresome, with most of the time being spent on the Debian stuff, I did very little work outside it, really. The issues and patches that I sent are:

• Issue #700 for redcarpet, asking for a reproducer for CVE-2020-26298 and some additional patch related queries.
• Issue #7 for in-parallel, asking them to not use relative paths for tests.
• Issue #8 for in-parallel, reporting a test failure for the library.
• Issue #2 for rake-ant, asking them to bump their dependencies to a newer version.
• PR #3 for rake-ant, bumping the dependencies to a newer version, fixing the above issue, heh.
• Issue #4 for rake-ant, requesting to drop git from their gemspec.
• PR #5 for rake-ant, dropping git from gemspec, fixing the above issue, heh.
• Issue #95 for WavPack, asking for a review of past security vulnerabilites wrt v4.70.0.
• Reviewed PR #128 for ruby-openid, addressing the past regression with CVE fix merge.
• Reviewed PR #63 for cocoapods-acknowledgements, updating redcarpet to v3.5.1, as a safety measure due to recently discovered vulnerability.
• Issue #1331 for bottle, asking for relevant commits for CVE-2020-28473 and clarifying other things.
• Issue #5 for em-redis, reporting test failures on IPv6-only build machines.
• Issue #939 for eventmachine, reporting test failures for em-redis on IPv6-only build machines.

---

Until next time.
:wq for today.

I have been a Puppet user for a couple of years now, first at work, and eventually for my personal servers and computers. Although it can have a steep learning curve, I find Puppet both nimble and very powerful. I also prefer it to Ansible for its speed and the agent-server model it uses. Sadly, Puppet Labs hasn't been the most supportive upstream and tends to move pretty fast. Major versions rarely last for a whole Debian Stable release and the upstream .deb packages are full of vendored libraries.¹ Since 2017, Apollon Oikonomopoulos has been the one doing most of the work on Puppet in Debian. Sadly, he's had less time for that lately and with Puppet 5 being deprecated in January 2021, Thomas Goirand, Utkarsh Gupta and I have been trying to package Puppet 6 in Debian for the last 6 months. With Puppet 6, the old ruby Puppet server using Passenger is not supported anymore and has been replaced by puppetserver, written in Clojure and running on the JVM. That's quite a large change and although puppetserver does reuse some of the Clojure libraries puppetdb (already in Debian) uses, packaging it meant quite a lot of work. Work in the Clojure team As part of my efforts to package puppetserver, I had the pleasure to join the Clojure team and learn a lot about the Clojure ecosystem. As I mentioned earlier, a lot of the Clojure dependencies needed for puppetserver were already in the archive. Unfortunately, when Apollon Oikonomopoulos packaged them, the leiningen build tool hadn't been packaged yet. This meant I had to rebuild a lot of packages, on top of packaging some new ones. Since then, thanks to the efforts of Elana Hashman, leiningen has been packaged and lets us run the upstream testsuites and create .jar artifacts closer to those upstream releases. During my work on puppetserver, I worked on the following packages:

List of packages

• backport9
• bidi-clojure
• clj-digest-clojure
• clj-helper
• clj-time-clojure
• clj-yaml-clojure
• cljx-clojure
• core-async-clojure
• core-cache-clojure
• core-match-clojure
• cpath-clojure
• crypto-equality-clojure
• crypto-random-clojure
• data-csv-clojure
• data-json-clojure
• data-priority-map-clojure
• java-classpath-clojure
• jnr-constants
• jnr-enxio
• jruby
• jruby-utils-clojure
• kitchensink-clojure
• lazymap-clojure
• liberator-clojure
• ordered-clojure
• pathetic-clojure
• potemkin-clojure
• prismatic-plumbing-clojure
• prismatic-schema-clojure
• puppetlabs-http-client-clojure
• puppetlabs-i18n-clojure
• puppetlabs-ring-middleware-clojure
• puppetserver
• raynes-fs-clojure
• riddley-clojure
• ring-basic-authentication-clojure
• ring-clojure
• ring-codec-clojure
• shell-utils-clojure
• ssl-utils-clojure
• test-check-clojure
• tools-analyzer-clojure
• tools-analyzer-jvm-clojure
• tools-cli-clojure
• tools-reader-clojure
• trapperkeeper-authorization-clojure
• trapperkeeper-clojure
• trapperkeeper-filesystem-watcher-clojure
• trapperkeeper-metrics-clojure
• trapperkeeper-scheduler-clojure
• trapperkeeper-webserver-jetty9-clojure
• url-clojure
• useful-clojure
• watchtower-clojure

If you want to learn more about packaging Clojure libraries and applications, I rewrote the Debian Clojure packaging tutorial and added a section about the quirks of using leiningen without a dedicated dh_lein tool. Work left to get puppetserver 6 in the archive Unfortunately, I was not able to finish the puppetserver 6 packaging work. It is thus unlikely it will make it in Debian Bullseye. If the issues described below are fixed, it would be possible to to package puppetserver in bullseye-backports though. So what's left? jruby Although I tried my best (kudos to Utkarsh Gupta and Thomas Goirand for the help), jruby in Debian is still broken. It does build properly, but the testsuite fails with multiple errors:

• ruby-psych is broken (#959571)
• there are some random java failures on a few tests (no clue why)
• tests ran by raklelib/rspec.rake fail to run, maybe because the --pattern command line option isn't compatible with our version of rake? Utkarsh seemed to know why this happens.

jruby testsuite failures aside, I have not been able to use the jruby.deb the package currently builds in jruby-utils-clojure (testsuite failure). I had the same exact failure with the (more broken) jruby version that is currently in the archive, which leads me to think this is a LOAD_PATH issue in jruby-utils-clojure. More on that below. To try to bypass these issues, I tried to vendor jruby into jruby-utils-clojure. At first I understood vendoring meant including upstream pre-built artifacts (jruby-complete.jar) and shipping them directly. After talking with people on the #debian-mentors and #debian-ftp IRC channels, I now understand why this isn't a good idea (and why it's not permitted in Debian). Many thanks to the people who were patient and kind enough to discuss this with me and give me alternatives. As far as I now understand it, vendoring in Debian means "to have an embedded copy of the source code in another package". Code shipped that way still needs to be built from source. This means we need to build jruby ourselves, one way or another. Vendoring jruby in another package thus isn't terribly helpful. If fixing jruby the proper way isn't possible, I would suggest trying to build the package using embedded code copies of the external libraries jruby needs to build, instead of trying to use the Debian libraries.² This should make it easier to replicate what upstream does and to have a final .jar that can be used. jruby-utils-clojure This package is a first-level dependency for puppetserver and is the glue between jruby and puppetserver. It builds fine, but the testsuite fails when using the Debian jruby package. I think the problem is caused by a jruby LOAD_PATH issue. The Debian jruby package plays with the LOAD_PATH a little to try use Debian packages instead of downloading gems from the web, as upstream jruby does. This seems to clash with the gem-home, gem-path, and jruby-load-path variables in the jruby-utils-clojure package. The testsuite plays around with these variables and some Ruby libraries can't be found. I tried to fix this, but failed. Using the upstream jruby-complete.jar instead of the Debian jruby package, the testsuite passes fine. This package could clearly be uploaded to NEW right now by ignoring the testsuite failures (we're just packaging static .clj source files in the proper location in a .jar). puppetserver jruby issues aside, packaging puppetserver itself is 80% done. Using the upstream jruby-complete.jar artifact, the testsuite fails with a weird Clojure error I'm not sure I understand, but I haven't debugged it for very long. Upstream uses git submodules to vendor puppet (agent), hiera (3), facter and puppet-resource-api for the testsuite to run properly. I haven't touched that, but I believe we can either:

• link to the Debian packages
• fix the Debian packages if they don't include the right files (maybe in a new binary package that just ships part of the source code?)

Without the testsuite actually running, it's hard to know what files are needed in those packages. What now Puppet 5 is now deprecated. If you or your organisation cares about Puppet in Debian,³ puppetserver really isn't far away from making it in the archive. Very talented Debian Developers are always eager to work on these issues and can be contracted for very reasonable rates. If you're interested in contracting someone to help iron out the last issues, don't hesitate to reach out via one of the following:

• the debian-puppet mailing list
• the debian-jobs mailing list
• the Debian Consultants index
• fossjobs.net

As for I, I'm happy to say I got a new contract and will go back to teaching Economics for the Winter 2021 session. I might help out with some general Debian packaging work from time to time, but it'll be as a hobby instead of a job. Thanks The work I did during the last 6 weeks would be not have been possible without the support of the Wikimedia Foundation, who were gracious enough to contract me. My particular thanks to Faidon Liambotis, Moritz M hlenhoff and John Bond. Many, many thanks to Rob Browning, Thomas Goirand, Elana Hashman, Utkarsh Gupta and Apollon Oikonomopoulos for their direct and indirect help, without which all of this wouldn't have been possible.

Here s my (thirteenth) monthly update about the activities I ve done in the F/L/OSS world.

Debian

This was my 22nd month of contributing to Debian. I became a DM in late March last year and a DD last Christmas! \o/ Whilst busy with my undergrad, I could still take some time out for contributing to Debian (I always do!). Here are the following things I did in Debian this month:

Uploads and bug fixes:

• ruby-mini-magick (4.10.1-1) - Fixing FTBFS, bug #966936.
• ruby2.7 (2.7.1-4) - Fixing CVE-2020-25613.
• net-tools (1.60+git20181103.0eebece-1) - Fixing bug #812886, #653117, #621752, and #549397.
• libgit2 (1.0.1+dfsg.1-1) - New upstream version, v1.0.1.
• rails (2:6.0.3.4+dfsg-1) - Fixing CVE-2020-8264/bug #971988.
• ruby2.7 (2.7.2-1) - New upstream version, v2.7.2.
• bundler (2.1.4-3) - Fixing bug #962463.
• ruby2.5 (2.5.5-3+deb10u3) - Fixing CVE-2020-25613.
• ruby2.7 (2.7.2-2) - Fixing bug #970469, #969130, and #968203.
• ruby3.0 (3.0.0~preview1-1) - Introducing ruby3.0, FTW!
• ruby-mysql2 (0.5.3-1) - Fixing FTBFS, bug #923727.
• ruby-rubocop-packaging (0.5.1-1) - Make it compatible with RuboCop v1.0.

Other $things:

• Attended the Debian Ruby team meeting. Logs here.
• Mentoring for newcomers.
• FTP Trainee reviewing.
• Moderation of -project mailing list.
• Sponsored phpmyadmin, php-bacon-baconqrcode, twig, php-dasprid-enum, sql-parser, and mariadb-mysql-kbs for William.

---

Debian (E)LTS

Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success. And Debian Extended LTS (ELTS) is its sister project, extending support to the Jessie release (+2 years after LTS support). This was my thirteenth month as a Debian LTS and fourth month as a Debian ELTS paid contributor.
I was assigned 20.75 hours for LTS and 30.00 hours for ELTS and worked on the following things:
(for ELTS, I worked for 5.25 hours extra, so my total hours this month for ELTS were 35.25!)

LTS CVE Fixes and Announcements:

• Issued DLA 2389-1, fixing CVE-2019-18978, for ruby-rack-cors.
  For Debian 9 Stretch, these problems have been fixed in version 0.4.0-1+deb9u2.
• Issued DLA 2390-1, fixing CVE-2019-18848, for ruby-json-jwt.
  For Debian 9 Stretch, these problems have been fixed in version 1.6.2-1+deb9u2.
• Issued DLA 2391-1, fixing CVE-2020-25613, for ruby2.3.
  For Debian 9 Stretch, these problems have been fixed in version 2.3.3-1+deb9u9.
• Issued DLA 2392-1, fixing CVE-2020-25613, for jruby.
  For Debian 9 Stretch, these problems have been fixed in version 1.7.26-1+deb9u3.
• Uploaded ruby2.5 to buster, fixing CVE-2020-25613. For Debian 10 Buster, these problems have been fixed in version 2.5.5-3+deb10u3.
• Uploaded ruby2.7 to unstable, fixing CVE-2020-25613. For Debian Sid, these problems have been fixed in version 2.7.1-4.
• Uploaded rails to unstable, fixing CVE-2020-8264. For Debian Sid, these problems have been fixed in version 2:6.0.3.4+dfsg-1.

ELTS CVE Fixes and Announcements:

• Issued ELA 290-1, fixing CVE-2020-25613, for ruby2.1.
  For Debian 8 Jessie, these problems have been fixed in version 2.1.5-2+deb8u11.
• Issued ELA 292-1, fixing CVE-2020-26159, for libonig.
  For Debian 8 Jessie, these problems have been fixed in version 5.9.5-3.2+deb8u5.
• Issued ELA 297-1, fixing CVE-2020-16121 and CVE-2020-16122, for packagekit.
  For Debian 8 Jessie, these problems have been fixed in version 1.0.1-2+deb8u1.
• Issued ELA 298-1, fixing CVE-2020-14355, for spice.
  For Debian 8 Jessie, these problems have been fixed in version 0.12.5-1+deb8u8.
• Issued ELA 299-1, fixing CVE-2020-14355, for spice-gtk.
  For Debian 8 Jessie, these problems have been fixed in version 0.25-1+deb8u2.
• Started working on openldap vulnerabilities, CVEs are yet to be assigned.

Other (E)LTS Work:

• Front-desk duty from 28-09 to 04-10 and from 26-10 until 01-10 for both LTS and ELTS.
• Triaged libproxy, libvirt, libonig, ant, erlang, ruby2.3, jruby, dpdk, php7.0, spice, spice-gtk, wireshark, djangorestframework, python-urllib3, python-cryptography, qtsvg-opensource-src, and open-build-service.
• Marked CVE-2020-26137/python-urllib3 as no-dsa for Stretch and Jessie.
• Marked CVE-2020-1437 4,5,6,7,8 /dpdk as no-dsa for Stretch.
• Marked CVE-2020-2586 2,3 /wireshark as postponed for Stretch.
• Marked CVE-2020-25626/djangorestframework as no-dsa for Stretch.
• Marked CVE-2020-11979/ant as not-affected for Jessie.
• Marked CVE-2020-25623/erlang as not-affected for Jessie.
• Marked CVE-2020-25659/python-cryptography as no-dsa for Stretch and Jessie.
• Auto EOL ed jruby, libjs-handlebars, linux, pluxml, mupdf, and djangorestframework for Jessie.
• [E/LTS] Worked on putting survey online, deployed LTS Team Pages \o/
• [ELTS] Fix suite-name in ela-needed file and fix other tags and ordering of triages to fix errors in the security tracker.
• [LTS] Sent out invitations for the meeting.
• Attended the sixth private LTS meeting.
• General discussion on LTS private and public mailing list.

---

Until next time.
:wq for today.

Here is my transparent report for my work on the Debian Long Term Support (LTS) and Debian Extended Long Term Support (ELTS), which extend the security support for past Debian releases, as a paid contributor. In July, the monthly sponsored hours were split evenly among contributors depending on their max availability - I was assigned 25.25h for LTS (out of 30 max; all done) and 13.25h for ELTS (out of 20 max; all done). We shifted suites: welcome Stretch LTS and Jessie ELTS. The LTS->ELTS switch happened at the start of the month, but the oldstable->LTS switch happened later (after finalizing and flushing proposed-updates to a last point release), causing some confusion but nothing major. ELTS - Jessie

• New local build setup
• ELTS buildds: request timezone harmonization
• Reclassify in-progress updates from jessie-LTS to jessie-ELTS
• python3.4: finish preparing update, security upload ELA 239-1
• net-snmp: global triage: bisect CVE-2019-20892 to identify affected version, jessie/stretch not-affected
• nginx: global triage: clarify CVE-2013-0337 status; locate CVE-2020-11724 original patch and regression tests, update MITRE
• nginx: security upload ELA-247-1 with 2 CVEs

LTS - Stretch

• Reclassify in-progress/needed updates from stretch/oldstable to stretch-LTS
• rails: upstream security: follow-up on CVE-2020-8163 (RCE) on upstream bug tracker and create pull request for 4.x (merged), hence getting some upstream review
• rails: global security: continue coordinating upload in multiple Debian versions, prepare fixes for common stretch/buster vulnerabilities in buster
• rails: security upload DLA-2282 fixing 3 CVEs
• python3.5: security upload DLA-2280-1 fixing 13 pending non-critical vulnerabilities, and its test suite
• nginx: security upload DLA-2283 (cf. common ELTS work)
• net-snmp: global triage (cf. common ELTS work)
• public IRC monthly team meeting
• reach out to clarify the intro from last month's report, following unsettled feedback during meeting

Documentation/Scripts

• ELTS/README.how-to-release-an-update: fix typo
• ELTS buildd: attempt to diagnose slow perfs, provide comparison with Debian and local builds
• LTS/Meetings: improve presentation
• SourceOnlyUpload: clarify/de-dup pbuilder doc
• LTS/Development: reference build logs URL, reference proposed-updates issue during dists switch, reference new-upstream-versioning discussion, multiple jessie->stretch fixes and clean-ups
• LTS/Development/Asan: drop wheezy documentation
• Warn about jruby mis-triage
• Provide feedback for ksh/CVE-2019-14868
• Provide feedback for condor update
• LTS/TestsSuites/nginx: test with new request smuggling test cases

Here is my monthly update covering what I have been doing in the free and open source software world during July 2020 (previous month):

• Opened a pull request to make the build reproducible in PyERFA, a set of Python bindings for various astronomy-related utilities (#45), as well as one for PeachPy assembler to make the output of codecode/x86_64.py reproducible (#108).

• As part of being on the board of directors of the Open Source Initiative and Software in the Public Interest I attended their respective monthly meetings and participated in various licensing and other discussions occurring on the internet, as well as the usual internal discussions regarding logistics and policy etc. This month, it was SPI's Annual General Meeting and the OSI has been running a number of remote strategy sessions for the board.
• Fixed an issue in my tickle-me-email library that implements Getting Things Done (GTD)-like behaviours in IMAP inboxes to ensure that all messages have a unique Message-Id header. [...]
• Reviewed and merged even more changes by Pavel Dolecek into my Strava Enhancement Suite, a Chrome extension to improve the user experience on the Strava athletic tracker.
• Updated travis.debian.net, my hosted service for projects that host their Debian packaging on GitHub, to use the Travis CI continuous integration platform) to fix a compatibility issue with the latest version of mk-build-deps. [...][...]

For Lintian, the static analysis tool for Debian packages:

• Update the regular expression to search for all the released versions in a .changes file. [...]
• Avoid false-positives when matching sensible-utils utilities such as i3-sensible-pager. (#966022)
• Rename the send-patch tag to patch-not-forwarded-upstream. [...]
• Drop reminders from 26 tags that false-positives should be reported to Lintian as this is implicit in all our tags. [...]

Reproducible Builds One of the original promises of open source software is that distributed peer review and transparency of process results in enhanced end-user security. However, whilst anyone may inspect the source code of free and open source software for malicious flaws, almost all software today is distributed as pre-compiled binaries. This allows nefarious third-parties to compromise systems by injecting malicious code into ostensibly secure software during the various compilation and distribution processes. The motivation behind the Reproducible Builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised. The project is proud to be a member project of the Software Freedom Conservancy. Conservancy acts as a corporate umbrella allowing projects to operate as non-profit initiatives without managing their own corporate structure. If you like the work of the Conservancy or the Reproducible Builds project, please consider becoming an official supporter. This month, I:

• Opened pull requests to make the build reproducible in pyerfa (#45) as well as one for PeachPy to make the output of codecode/x86_64.py reproducible (#108).
• In Debian:
  • Submitted the following patches to fix reproducibility-related toolchain issues within Debian:
    • dh-fortran-mod: Please make the output reproducible. (#965255)
    • gem2deb: should not install mkmf.log files. (#964772)
    • nmap: Please make the obfuscated nmap_service.exe file reproducible. (#964369)
  • I also submitted 13 patches to fix specific reproducibility issues in flit, gmap, jskeus, libtpms, logilab-common, mrbayes, numpydoc, pyerfa, python-cooler, python-peachpy, python-pyxs, sratom & weather-util.
  • When investigating packages, I discovered and reported that dolfinx was running its test suite even when the nocheck build profile was set. (#965946)
  • Kept isdebianreproducibleyet.com up to date. [...]
• Categorised a large number of packages and issues in the Reproducible Builds 'notes' repository.
• Drafted, published and publicised our monthly report.

• Updated the main Reproducible Builds website and documentation to drop a number of unused Javascript files [...][...][...] and added unminified versions of Bootstrap and jQuery [...] and fixed a number of broken URLs [...][...].
• strip-nondeterminism is our tool to remove specific non-deterministic results from a completed build. This month, I made sure that we did not install the internal handler documentation generated from Perl POD documents [...] and fixed a trivial typo [...].

diffoscope Elsewhere in our tooling, I made the following changes to diffoscope, including preparing and uploading versions 150, 151, 152, 153 & 154 to Debian:

• New features:
  • Add support for flash-optimised F2FS filesystems. (#207)
  • Don't require zipnote(1) to determine differences in a .zip file as we can use libarchive. [...]
  • Allow --profile as a synonym for --profile=-, ie. write profiling data to standard output. [...]
  • Increase the minimum length of the output of strings(1) to eight characters to avoid unnecessary diff noise. [...]
  • Drop some legacy argument styles: --exclude-directory-metadata and --no-exclude-directory-metadata have been replaced with --exclude-directory-metadata= yes,no . [...]
• Bug fixes:
  • Pass the absolute path when extracting members from SquashFS images as we run the command with working directory in a temporary directory. (#189)
  • Correct adding a comment when we cannot extract a filesystem due to missing libguestfs module. [...]
  • Don't crash when listing entries in archives if they don't have a listed size such as hardlinks in ISO images. (#188)
• Output improvements:
  • Strip off the file offset prefix from xxd(1) and show bytes in groups of 4. [...]
  • Don't emit javap not found in path if it is available in the path but it did not result in an actual difference. [...]
  • Fix ... not available in path messages when looking for Java decompilers that used the Python class name instead of the command. [...]
• Logging improvements:
  • Add a bit more debugging info when launching libguestfs. [...]
  • Reduce the --debug log noise by truncating the has_some_content messages. [...]
  • Fix the compare_files log message when the file does not have a literal name. [...]
• Codebase improvements:
  • Rewrite and rename exit_if_paths_do_not_exist to not check files multiple times. [...][...]
  • Add an add_comment helper method; don't mess with our internal list directly. [...]
  • Replace some simple usages of str.format with Python 'f-strings' [...] and make it easier to navigate to the main.py entry point [...].
  • In the RData comparator, always explicitly return None in the failure case as we return a non-None value in the success one. [...]
  • Tidy some imports [...][...][...] and don't alias a variable when we don't end up using. [...]
  • Clarify the use of a separate NullChanges quasi-file to represent missing data in the Debian package comparator [...] and clarify use of a 'null' diff in order to remember an exit code. [...]
• Misc:
  • Profile the launch of libguestfs filesystems. [...]
  • Clarify and correct our contributing info. [...][...][...][...][...][...]

Debian In Debian, I made the following uploads this month:

• Redis (6.0.6-1) New upstream release.
• Django:
  • 2.2.14-1 New upstream bugfix release.
  • 3.1~rc1-1 New upstream release candidate.
• lastpass-cli (1.3.3-4) Fix a build failure under GCC 10. (#957416)

Debian LTS This month I have worked 18 hours on Debian Long Term Support (LTS) and 12 for the Extended LTS project. This included:

• Frontdesk duties, including responding to user/developer questions, reviewing packages, participating in mailing list discussions, offering comments on our survey and attended our IRC contributor meeting. I also made some changes to tools after the move from the Debian version supported [...].
• Investigated and triaged atril, ceph, cimg, ffmpeg, golang-github-seccomp-libseccomp-golang, gosa, http-parser, jruby, json-c, jupyter-notebook, keystone, ksh, libjpeg-turbo, libopenmpt, libpam-radius-auth, log4net, mailman, milkytracker, mupdf, pillow, poppler, puma, python-rtslib-fb, roundcube, ruby-zip, salt, slirp, sqlite3, transmission & wordpress.
• Issued DLA 2273-1 for shiro, first to fix a path-traversal issue where a specially-crafted request could cause an authentication bypass (CVE-2020-1957) and then to fix an encoding issue introduced in the handling of the previous CVE-2020-1957 path-traversal issue which itself could have also caused an authentication bypass (CVE-2020-11989).
• Issued DLA 2274-1 to fix a possible signature verification issue in the fwupd firmware update tool as the return value of gpgme_op_verify_result was not being checked.
• Issued DLA 2299-1 and ELA 252-1 in order to prevent a privilege escalation vulnerability discovered in Net-SNMP, a set of tools for collecting and organising information about devices on computer networks.
• Issued DLA 2300-1 as it was discovered that there was an issue where kdepim-runtime would default to using unencrypted POP3 communication despite the user interface indicating that encryption was in use.

You can find out more about the project via the following video:

Because posting private keys on the Internet is a bad idea, some people like to redact their private keys, so that it looks kinda-sorta like a private key, but it isn t actually giving away anything secret. Unfortunately, due to the way that private keys are represented, it is easy to redact a key in such a way that it doesn t actually redact anything at all. RSA private keys are particularly bad at this, but the problem can (potentially) apply to other keys as well. I ll show you a bit of Inside Baseball with key formats, and then demonstrate the practical implications. Finally, we ll go through a practical worked example from an actual not-really-redacted key I recently stumbled across in my travels.

The Private Lives of Private Keys Here is what a typical private key looks like, when you come across it:

-----BEGIN RSA PRIVATE KEY-----
MGICAQACEQCxjdTmecltJEz2PLMpS4BXAgMBAAECEDKtuwD17gpagnASq1zQTYEC
CQDVTYVsjjF7IQIJANUYZsIjRsR3AgkAkahDUXL0RSECCB78r2SnsJC9AghaOK3F
sKoELg==
-----END RSA PRIVATE KEY-----

Obviously, there s some hidden meaning in there computers don t encrypt things by shouting BEGIN RSA PRIVATE KEY! , after all. What is between the BEGIN/END lines above is, in fact, a base64-encoded DER format ASN.1 structure representing a PKCS#1 private key. In simple terms, it s a list of numbers very important numbers. The list of numbers is, in order:

• A version number (0);
• The public modulus , commonly referred to as n ;
• The public exponent , or e (which is almost always 65,537, for various unimportant reasons);
• The private exponent , or d ;
• The two private primes , or p and q ;
• Two exponents, which are known as dmp1 and dmq1 ; and
• A coefficient, known as iqmp .

Why Is This a Problem? The thing is, only three of those numbers are actually required in a private key. The rest, whilst useful to allow the RSA encryption and decryption to be more efficient, aren t necessary. The three absolutely required values are e, p, and q. Of the other numbers, most of them are at least about the same size as each of p and q. So of the total data in an RSA key, less than a quarter of the data is required. Let me show you with the above toy key, by breaking it down piece by piece¹:

• MGI DER for this is a sequence
• CAQ version (0)
• CxjdTmecltJEz2PLMpS4BX n
• AgMBAA e
• ECEDKtuwD17gpagnASq1zQTY d
• ECCQDVTYVsjjF7IQ p
• IJANUYZsIjRsR3 q
• AgkAkahDUXL0RS dmp1
• ECCB78r2SnsJC9 dmq1
• AghaOK3FsKoELg== iqmp

Remember that in order to reconstruct all of these values, all I need are e, p, and q and e is pretty much always 65,537. So I could redact almost all of this key, and still give all the important, private bits of this key. Let me show you:

-----BEGIN RSA PRIVATE KEY-----
..............................................................EC
CQDVTYVsjjF7IQIJANUYZsIjRsR3....................................
........
-----END RSA PRIVATE KEY-----

Now, I doubt that anyone is going to redact a key precisely like this but then again, this isn t a typical RSA key. They usually look a lot more like this:

-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAu6Inch7+mWtKn+leB9uCG3MaJIxRyvC/5KTz2fR+h+GOhqj4
SZJobiVB4FrE5FgC7AnlH6qeRi9MI0s6dt5UWZ5oNIeWSaOOeNO+EJDUkSVf67wj
SNGXlSjGAkPZ0nRJiDjhuPvQmdW53hOaBLk5udxPEQbenpXAzbLJ7wH5ouLQ3nQw
HwpwDNQhF6zRO8WoscpDVThOAM+s4PS7EiK8ZR4hu2toon8Ynadlm95V45wR0VlW
zywgbkZCKa1IMrDCscB6CglQ10M3Xzya3iTzDtQxYMVqhDrA7uBYRxA0y1sER+Rb
yhEh03xz3AWemJVLCQuU06r+FABXJuY/QuAVvQIDAQABAoIBAFqwWVhzWqNUlFEO
PoCVvCEAVRZtK+tmyZj9kU87ORz8DCNR8A+/T/JM17ZUqO2lDGSBs9jGYpGRsr8s
USm69BIM2ljpX95fyzDjRu5C0jsFUYNi/7rmctmJR4s4uENcKV5J/++k5oI0Jw4L
c1ntHNWUgjK8m0UTJIlHbQq0bbAoFEcfdZxd3W+SzRG3jND3gifqKxBG04YDwloy
tu+bPV2jEih6p8tykew5OJwtJ3XsSZnqJMwcvDciVbwYNiJ6pUvGq6Z9kumOavm9
XU26m4cWipuK0URWbHWQA7SjbktqEpxsFrn5bYhJ9qXgLUh/I1+WhB2GEf3hQF5A
pDTN4oECgYEA7Kp6lE7ugFBDC09sKAhoQWrVSiFpZG4Z1gsL9z5YmZU/vZf0Su0n
9J2/k5B1GghvSwkTqpDZLXgNz8eIX0WCsS1xpzOuORSNvS1DWuzyATIG2cExuRiB
jYWIJUeCpa5p2PdlZmBrnD/hJ4oNk4oAVpf+HisfDSN7HBpN+TJfcAUCgYEAyvY7
Y4hQfHIdcfF3A9eeCGazIYbwVyfoGu70S/BZb2NoNEPymqsz7NOfwZQkL4O7R3Wl
Rm0vrWT8T5ykEUgT+2ruZVXYSQCKUOl18acbAy0eZ81wGBljZc9VWBrP1rHviVWd
OVDRZNjz6nd6ZMrJvxRa24TvxZbJMmO1cgSW1FkCgYAoWBd1WM9HiGclcnCZknVT
UYbykCeLO0mkN1Xe2/32kH7BLzox26PIC2wxF5seyPlP7Ugw92hOW/zewsD4nLze
v0R0oFa+3EYdTa4BvgqzMXgBfvGfABJ1saG32SzoWYcpuWLLxPwTMsCLIPmXgRr1
qAtl0SwF7Vp7O/C23mNukQKBgB89DOEB7xloWv3Zo27U9f7nB7UmVsGjY8cZdkJl
6O4LB9PbjXCe3ywZWmJqEbO6e83A3sJbNdZjT65VNq9uP50X1T+FmfeKfL99X2jl
RnQTsrVZWmJrLfBSnBkmb0zlMDAcHEnhFYmHFuvEnfL7f1fIoz9cU6c+0RLPY/L7
n9dpAoGAXih17mcmtnV+Ce+lBWzGWw9P4kVDSIxzGxd8gprrGKLa3Q9VuOrLdt58
++UzNUaBN6VYAe4jgxGfZfh+IaSlMouwOjDgE/qzgY8QsjBubzmABR/KWCYiRqkj
qpWCgo1FC1Gn94gh/+dW2Q8+NjYtXWNqQcjRP4AKTBnPktEvdMA=
-----END RSA PRIVATE KEY-----

People typically redact keys by deleting whole lines, and usually replacing them with [...] and the like. But only about 345 of those 1588 characters (excluding the header and footer) are required to construct the entire key. You can redact about 4/5ths of that giant blob of stuff, and your private parts (or at least, those of your key) are still left uncomfortably exposed.

But Wait! There s More! Remember how I said that everything in the key other than e, p, and q could be derived from those three numbers? Let s talk about one of those numbers: n. This is known as the public modulus (because, along with e, it is also present in the public key). It is very easy to calculate: n = p * q. It is also very early in the key (the second number, in fact). Since n = p * q, it follows that q = n / p. Thus, as long as the key is intact up to p, you can derive q by simple division.

Real World Redaction At this point, I d like to introduce an acquaintance of mine: Mr. Johan Finn. He is the proud owner of the GitHub repo johanfinn/scripts. For a while, his repo contained a script that contained a poorly-redacted private key. He since deleted it, by making a new commit, but of course because git never really deletes anything, it s still available. Of course, Mr. Finn may delete the repo, or force-push a new history without that commit, so here is the redacted private key, with a bit of the surrounding shell script, for our illustrative pleasure:

#Add private key to .ssh folder
cd /home/johan/.ssh/
echo  "-----BEGIN RSA PRIVATE KEY-----
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
 
MIIJKgIBAAKCAgEAxEVih1JGb8gu/Fm4AZh+ZwJw/pjzzliWrg4mICFt1g7SmIE2
TCQMKABdwd11wOFKCPc/UzRH/fHuQcvWrpbOSdqev/zKff9iedKw/YygkMeIRaXB
fYELqvUAOJ8PPfDm70st9GJRhjGgo5+L3cJB2gfgeiDNHzaFvapRSU0oMGQX+kI9
ezsjDAn+0Pp+r3h/u1QpLSH4moRFGF4omNydI+3iTGB98/EzuNhRBHRNq4oBV5SG
Pq/A1bem2ninnoEaQ+OPESxYzDz3Jy9jV0W/6LvtJ844m+XX69H5fqq5dy55z6DW
sGKn78ULPVZPsYH5Y7C+CM6GAn4nYCpau0t52sqsY5epXdeYx4Dc+Wm0CjXrUDEe
Egl4loPKDxJkQqQ/MQiz6Le/UK9vEmnWn1TRXK3ekzNV4NgDfJANBQobOpwt8WVB
rbsC0ON7n680RQnl7PltK9P1AQW5vHsahkoixk/BhcwhkrkZGyDIl9g8Q/Euyoq3
eivKPLz7/rhDE7C1BzFy7v8AjC3w7i9QeHcWOZFAXo5hiDasIAkljDOsdfD4tP5/
wSO6E6pjL3kJ+RH2FCHd7ciQb+IcuXbku64ln8gab4p8jLa/mcMI+V3eWYnZ82Yu
axsa85hAe4wb60cp/rCJo7ihhDTTvGooqtTisOv2nSvCYpcW9qbL6cGjAXECAwEA
AQKCAgEAjz6wnWDP5Y9ts2FrqUZ5ooamnzpUXlpLhrbu3m5ncl4ZF5LfH+QDN0Kl
KvONmHsUhJynC/vROybSJBU4Fu4bms1DJY3C39h/L7g00qhLG7901pgWMpn3QQtU
4P49qpBii20MGhuTsmQQALtV4kB/vTgYfinoawpo67cdYmk8lqzGzzB/HKxZdNTq
s+zOfxRr7PWMo9LyVRuKLjGyYXZJ/coFaobWBi8Y96Rw5NZZRYQQXLIalC/Dhndm
AHckpstEtx2i8f6yxEUOgPvV/gD7Akn92RpqOGW0g/kYpXjGqZQy9PVHGy61sInY
HSkcOspIkJiS6WyJY9JcvJPM6ns4b84GE9qoUlWVF3RWJk1dqYCw5hz4U8LFyxsF
R6WhYiImvjxBLpab55rSqbGkzjI2z+ucDZyl1gqIv9U6qceVsgRyuqdfVN4deU22
LzO5IEDhnGdFqg9KQY7u8zm686Ejs64T1sh0y4GOmGsSg+P6nsqkdlXH8C+Cf03F
lqPFg8WQC7ojl/S8dPmkT5tcJh3BPwIWuvbtVjFOGQc8x0lb+NwK8h2Nsn6LNazS
0H90adh/IyYX4sBMokrpxAi+gMAWiyJHIHLeH2itNKtAQd3qQowbrWNswJSgJzsT
JuJ7uqRKAFkE6nCeAkuj/6KHHMPsfCAffVdyGaWqhoxmPOrnVgECggEBAOrCCwiC
XxwUgjOfOKx68siFJLfHf4vPo42LZOkAQq5aUmcWHbJVXmoxLYSczyAROopY0wd6
Dx8rqnpO7OtZsdJMeBSHbMVKoBZ77hiCQlrljcj12moFaEAButLCdZFsZW4zF/sx
kWIAaPH9vc4MvHHyvyNoB3yQRdevu57X7xGf9UxWuPil/jvdbt9toaraUT6rUBWU
GYPNKaLFsQzKsFWAzp5RGpASkhuiBJ0Qx3cfLyirjrKqTipe3o3gh/5RSHQ6VAhz
gdUG7WszNWk8FDCL6RTWzPOrbUyJo/wz1kblsL3vhV7ldEKFHeEjsDGroW2VUFlS
asAHNvM4/uYcOSECggEBANYH0427qZtLVuL97htXW9kCAT75xbMwgRskAH4nJDlZ
IggDErmzBhtrHgR+9X09iL47jr7dUcrVNPHzK/WXALFSKzXhkG/yAgmt3r14WgJ6
5y7010LlPFrzaNEyO/S4ISuBLt4cinjJsrFpoo0WI8jXeM5ddG6ncxdurKXMymY7
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::.::
:::::::::::::::::::::::::::.::::::::::::::::::::::::::::::::::::
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLlL
 
 
 
YYYYYYYYYYYYYYYYYYYYYyYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
gff0GJCOMZ65pMSy3A3cSAtjlKnb4fWzuHD5CFbusN4WhCT/tNxGNSpzvxd8GIDs
nY7exs9L230oCCpedVgcbayHCbkChEfoPzL1e1jXjgCwCTgt8GjeEFqc1gXNEaUn
O8AJ4VlR8fRszHm6yR0ZUBdY7UJddxQiYOzt0S1RLlECggEAbdcs4mZdqf3OjejJ
06oTPs9NRtAJVZlppSi7pmmAyaNpOuKWMoLPElDAQ3Q7VX26LlExLCZoPOVpdqDH
KbdmBEfTR4e11Pn9vYdu9/i6o10U4hpmf4TYKlqk10g1Sj21l8JATj/7Diey8scO
sAI1iftSg3aBSj8W7rxCxSezrENzuqw5D95a/he1cMUTB6XuravqZK5O4eR0vrxR
AvMzXk5OXrUEALUvt84u6m6XZZ0pq5XZxq74s8p/x1JvTwcpJ3jDKNEixlHfdHEZ
ZIu/xpcwD5gRfVGQamdcWvzGHZYLBFO1y5kAtL8kI9tW7WaouWVLmv99AyxdAaCB
Y5mBAQKCAQEAzU7AnorPzYndlOzkxRFtp6MGsvRBsvvqPLCyUFEXrHNV872O7tdO
GmsMZl+q+TJXw7O54FjJJvqSSS1sk68AGRirHop7VQce8U36BmI2ZX6j2SVAgIkI
9m3btCCt5rfiCatn2+Qg6HECmrCsHw6H0RbwaXS4RZUXD/k4X+sslBitOb7K+Y+N
Bacq6QxxjlIqQdKKPs4P2PNHEAey+kEJJGEQ7bTkNxCZ21kgi1Sc5L8U/IGy0BMC
PvJxssLdaWILyp3Ws8Q4RAoC5c0ZP0W2j+5NSbi3jsDFi0Y6/2GRdY1HAZX4twem
Q0NCedq1JNatP1gsb6bcnVHFDEGsj/35oQKCAQEAgmWMuSrojR/fjJzvke6Wvbox
FRnPk+6YRzuYhAP/YPxSRYyB5at++5Q1qr7QWn7NFozFIVFFT8CBU36ktWQ39MGm
cJ5SGyN9nAbbuWA6e+/u059R7QL+6f64xHRAGyLT3gOb1G0N6h7VqFT25q5Tq0rc
Lf/CvLKoudjv+sQ5GKBPT18+zxmwJ8YUWAsXUyrqoFWY/Tvo5yLxaC0W2gh3+Ppi
EDqe4RRJ3VKuKfZxHn5VLxgtBFN96Gy0+Htm5tiMKOZMYAkHiL+vrVZAX0hIEuRZ
JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
-----END RSA PRIVATE KEY-----" >> id_rsa

Now, if you try to reconstruct this key by removing the obvious garbage lines (the ones that are all repeated characters, some of which aren t even valid base64 characters), it still isn t a key at least, openssl pkey doesn t want anything to do with it. The key is very much still in there, though, as we shall soon see. Using a gem I wrote and a quick bit of Ruby, we can extract a complete private key. The irb session looks something like this:

>> require "derparse"
>> b64 = <<EOF
MIIJKgIBAAKCAgEAxEVih1JGb8gu/Fm4AZh+ZwJw/pjzzliWrg4mICFt1g7SmIE2
TCQMKABdwd11wOFKCPc/UzRH/fHuQcvWrpbOSdqev/zKff9iedKw/YygkMeIRaXB
fYELqvUAOJ8PPfDm70st9GJRhjGgo5+L3cJB2gfgeiDNHzaFvapRSU0oMGQX+kI9
ezsjDAn+0Pp+r3h/u1QpLSH4moRFGF4omNydI+3iTGB98/EzuNhRBHRNq4oBV5SG
Pq/A1bem2ninnoEaQ+OPESxYzDz3Jy9jV0W/6LvtJ844m+XX69H5fqq5dy55z6DW
sGKn78ULPVZPsYH5Y7C+CM6GAn4nYCpau0t52sqsY5epXdeYx4Dc+Wm0CjXrUDEe
Egl4loPKDxJkQqQ/MQiz6Le/UK9vEmnWn1TRXK3ekzNV4NgDfJANBQobOpwt8WVB
rbsC0ON7n680RQnl7PltK9P1AQW5vHsahkoixk/BhcwhkrkZGyDIl9g8Q/Euyoq3
eivKPLz7/rhDE7C1BzFy7v8AjC3w7i9QeHcWOZFAXo5hiDasIAkljDOsdfD4tP5/
wSO6E6pjL3kJ+RH2FCHd7ciQb+IcuXbku64ln8gab4p8jLa/mcMI+V3eWYnZ82Yu
axsa85hAe4wb60cp/rCJo7ihhDTTvGooqtTisOv2nSvCYpcW9qbL6cGjAXECAwEA
AQKCAgEAjz6wnWDP5Y9ts2FrqUZ5ooamnzpUXlpLhrbu3m5ncl4ZF5LfH+QDN0Kl
KvONmHsUhJynC/vROybSJBU4Fu4bms1DJY3C39h/L7g00qhLG7901pgWMpn3QQtU
4P49qpBii20MGhuTsmQQALtV4kB/vTgYfinoawpo67cdYmk8lqzGzzB/HKxZdNTq
s+zOfxRr7PWMo9LyVRuKLjGyYXZJ/coFaobWBi8Y96Rw5NZZRYQQXLIalC/Dhndm
AHckpstEtx2i8f6yxEUOgPvV/gD7Akn92RpqOGW0g/kYpXjGqZQy9PVHGy61sInY
HSkcOspIkJiS6WyJY9JcvJPM6ns4b84GE9qoUlWVF3RWJk1dqYCw5hz4U8LFyxsF
R6WhYiImvjxBLpab55rSqbGkzjI2z+ucDZyl1gqIv9U6qceVsgRyuqdfVN4deU22
LzO5IEDhnGdFqg9KQY7u8zm686Ejs64T1sh0y4GOmGsSg+P6nsqkdlXH8C+Cf03F
lqPFg8WQC7ojl/S8dPmkT5tcJh3BPwIWuvbtVjFOGQc8x0lb+NwK8h2Nsn6LNazS
0H90adh/IyYX4sBMokrpxAi+gMAWiyJHIHLeH2itNKtAQd3qQowbrWNswJSgJzsT
JuJ7uqRKAFkE6nCeAkuj/6KHHMPsfCAffVdyGaWqhoxmPOrnVgECggEBAOrCCwiC
XxwUgjOfOKx68siFJLfHf4vPo42LZOkAQq5aUmcWHbJVXmoxLYSczyAROopY0wd6
Dx8rqnpO7OtZsdJMeBSHbMVKoBZ77hiCQlrljcj12moFaEAButLCdZFsZW4zF/sx
kWIAaPH9vc4MvHHyvyNoB3yQRdevu57X7xGf9UxWuPil/jvdbt9toaraUT6rUBWU
GYPNKaLFsQzKsFWAzp5RGpASkhuiBJ0Qx3cfLyirjrKqTipe3o3gh/5RSHQ6VAhz
gdUG7WszNWk8FDCL6RTWzPOrbUyJo/wz1kblsL3vhV7ldEKFHeEjsDGroW2VUFlS
asAHNvM4/uYcOSECggEBANYH0427qZtLVuL97htXW9kCAT75xbMwgRskAH4nJDlZ
IggDErmzBhtrHgR+9X09iL47jr7dUcrVNPHzK/WXALFSKzXhkG/yAgmt3r14WgJ6
5y7010LlPFrzaNEyO/S4ISuBLt4cinjJsrFpoo0WI8jXeM5ddG6ncxdurKXMymY7
EOF
>> b64 += <<EOF
gff0GJCOMZ65pMSy3A3cSAtjlKnb4fWzuHD5CFbusN4WhCT/tNxGNSpzvxd8GIDs
nY7exs9L230oCCpedVgcbayHCbkChEfoPzL1e1jXjgCwCTgt8GjeEFqc1gXNEaUn
O8AJ4VlR8fRszHm6yR0ZUBdY7UJddxQiYOzt0S1RLlECggEAbdcs4mZdqf3OjejJ
06oTPs9NRtAJVZlppSi7pmmAyaNpOuKWMoLPElDAQ3Q7VX26LlExLCZoPOVpdqDH
KbdmBEfTR4e11Pn9vYdu9/i6o10U4hpmf4TYKlqk10g1Sj21l8JATj/7Diey8scO
sAI1iftSg3aBSj8W7rxCxSezrENzuqw5D95a/he1cMUTB6XuravqZK5O4eR0vrxR
AvMzXk5OXrUEALUvt84u6m6XZZ0pq5XZxq74s8p/x1JvTwcpJ3jDKNEixlHfdHEZ
ZIu/xpcwD5gRfVGQamdcWvzGHZYLBFO1y5kAtL8kI9tW7WaouWVLmv99AyxdAaCB
Y5mBAQKCAQEAzU7AnorPzYndlOzkxRFtp6MGsvRBsvvqPLCyUFEXrHNV872O7tdO
GmsMZl+q+TJXw7O54FjJJvqSSS1sk68AGRirHop7VQce8U36BmI2ZX6j2SVAgIkI
9m3btCCt5rfiCatn2+Qg6HECmrCsHw6H0RbwaXS4RZUXD/k4X+sslBitOb7K+Y+N
Bacq6QxxjlIqQdKKPs4P2PNHEAey+kEJJGEQ7bTkNxCZ21kgi1Sc5L8U/IGy0BMC
PvJxssLdaWILyp3Ws8Q4RAoC5c0ZP0W2j+5NSbi3jsDFi0Y6/2GRdY1HAZX4twem
Q0NCedq1JNatP1gsb6bcnVHFDEGsj/35oQKCAQEAgmWMuSrojR/fjJzvke6Wvbox
FRnPk+6YRzuYhAP/YPxSRYyB5at++5Q1qr7QWn7NFozFIVFFT8CBU36ktWQ39MGm
cJ5SGyN9nAbbuWA6e+/u059R7QL+6f64xHRAGyLT3gOb1G0N6h7VqFT25q5Tq0rc
Lf/CvLKoudjv+sQ5GKBPT18+zxmwJ8YUWAsXUyrqoFWY/Tvo5yLxaC0W2gh3+Ppi
EDqe4RRJ3VKuKfZxHn5VLxgtBFN96Gy0+Htm5tiMKOZMYAkHiL+vrVZAX0hIEuRZ
EOF
>> der = b64.unpack("m").first
>> c = DerParse.new(der).first_node.first_child
>> version = c.value
=> 0
>> c = c.next_node
>> n = c.value
=> 80071596234464993385068908004931... # (etc)
>> c = c.next_node
>> e = c.value
=> 65537
>> c = c.next_node
>> d = c.value
=> 58438813486895877116761996105770... # (etc)
>> c = c.next_node
>> p = c.value
=> 29635449580247160226960937109864... # (etc)
>> c = c.next_node
>> q = c.value
=> 27018856595256414771163410576410... # (etc)

What I ve done, in case you don t speak Ruby, is take the two chunks of plausible-looking base64 data, chuck them together into a variable named b64, unbase64 it into a variable named der, pass that into a new DerParse instance, and then walk the DER value tree until I got all the values I need. Interestingly, the q value actually traverses the split in the two chunks, which means that there s always the possibility that there are lines missing from the key. However, since p and q are supposed to be prime, we can sanity check them to see if corruption is likely to have occurred:

>> require "openssl"
>> OpenSSL::BN.new(p).prime?
=> true
>> OpenSSL::BN.new(q).prime?
=> true

Excellent! The chances of a corrupted file producing valid-but-incorrect prime numbers isn t huge, so we can be fairly confident that we ve got the real p and q. Now, with the help of another one of my creations we can use e, p, and q to create a fully-operational battle key:

>> require "openssl/pkey/rsa"
>> k = OpenSSL::PKey::RSA.from_factors(p, q, e)
=> #<OpenSSL::PKey::RSA:0x0000559d5903cd38>
>> k.valid?
=> true
>> k.verify(OpenSSL::Digest::SHA256.new, k.sign(OpenSSL::Digest::SHA256.new, "bob"), "bob")
=> true

and there you have it. One fairly redacted-looking private key brought back to life by maths and far too much free time. Sorry Mr. Finn, I hope you re not still using that key on anything Internet-facing.

What About Other Key Types? EC keys are very different beasts, but they have much the same problems as RSA keys. A typical EC key contains both private and public data, and the public portion is twice the size so only about 1/3 of the data in the key is private material. It is quite plausible that you can redact an EC key and leave all the actually private bits exposed.

What Do We Do About It? In short: don t ever try and redact real private keys. For documentation purposes, just put KEY GOES HERE in the appropriate spot, or something like that. Store your secrets somewhere that isn t a public (or even private!) git repo. Generating a dummy private key and sticking it in there isn t a great idea, for different reasons: people have this odd habit of reusing demo keys in real life. There s no need to encourage that sort of thing.

---

1. Technically the pieces aren t 100% aligned with the underlying DER, because of how base64 works. I felt it was easier to understand if I stuck to chopping up the base64, rather than decoding into DER and then chopping up the DER.

Welcome to gambaru.de. Here is my monthly report that covers what I have been doing for Debian. If you re interested in Android, Java, Games and LTS topics, this might be interesting for you. Debian Android

• I sponsored a new package for Seamlik called android-platform-tools-analytics-library.

Debian Games

• We have entered the final straight for Stretch, so I kept a close eye on new game releases and bug reports in packages which I think should be part of the next stable release. Bzflag is certainly one of them, a tank battling game that can be played in the first-person perspective and which has arrived in version 2.4.8. I also packaged new releases of trigger-rally, a racing game, Renpy, pygame-sdl2 and Minetest.
• B lint R czey introduced libopenhmd to Debian a while ago and asked me in #845657 to enable OpenHMD support for neverball. Neverball is now the first game in the archive, at least as far as I know, that is ready for virtual reality. I have never tried it though because I don t own the necessary gear from Oculus myself but it sounds like a cool feature.
• A user of caveexpress reported a bug (#847147) in one level that prevented him from finishing it. I forwarded this one to upstream and he was able to quickly fix the issue and I could release 2.4+git20160609-3 later.
• I triaged several RC bugs which were reported against our D language games and it turned out that the bug was in gdc (#845377).
• I also made some small improvements to monopd s packaging and applied a patch from Laurent Bigonville to Freeciv that corrected a problem with AppData files (#848720).
• I worked around another RC FTBFS bug in spring (#846921) which is apparently a regression in binutils (#847356) but its maintainer does not consider this to be release critical.
• I tried to fix #848063 in ri-li but it seems to surface again under special circumstances. Since compilation works on all buildds for all release architectures and on my systems I downgraded the severity to important.
• I uploaded Bullet 2.85.1 to experimental. It is currently waiting in the NEW queue due to the SONAME bump and because I decided to simplify the packaging. I don t think it is longer worth it to provide several standalone binary packages. All Bullet 2 and 3 core libraries can be found in libbullet2.85 now while all the extra stuff is part of libbullet-extras2.85.
• Last but not least I released debian-games 1.7 and updated the list of games. Castle Combat was removed this month from Debian.

Debian Java

• I promised to complete my work on Netbeans and spent several hours on completing this goal. Although I am aware of the package s obstacles by now it never ceases to amaze me how many build failures occur due to the apparent mismatch between Debian (build-)dependencies and the ones upstream is using. This time I got stuck when several core modules could not be built from source because they required classes from OpenJDK 9. Since JDK 9 will not be released with Stretch I am afraid to say that Netbeans 8.2 won t be part of it. I worked around these issues by replacing the modules with versions from 8.1 but this is obviously just a very crude hack. Nevertheless the new package is available in experimental now.
• New upstream releases this month: activemq, netbeans, libnb-platform18-java, svnclientadapter, jackrabbit, jboss-xnio, undertow.
• Package updates: jboss-classfilewriter, jboss-logging, libpicocontainer-java.
• RC bug fixes: jruby-maven-plugins (#844841), vorbis-java (#844753), jackson-datatype-guava (#849449), triaged libhamcrest-java (#846116).
• I sponsored freeplane 1.5.18-1 for Felix Natter.

Debian LTS This was my tenth month as a paid contributor and I have been paid to work 13,5 hours on Debian LTS, a project started by Rapha l Hertzog. In that time I did the following:

• From 12. December until 18. December I was in charge of our LTS frontdesk. I triaged bugs in jasper, openjdk-6, bluez, game-music-emu, simplesamlphp, imagemagick, nagios3, most, rabbitmq-server, html5lib and dcmtk.
• DLA-742-1. Issued a security update for chrony fixing 1 CVE. This update was prepared by Vincent Blut.
• DLA-745-1. Issued a security update for most fixing 1 CVE.
• DLA-746-1. Issued a security update for tomcat6 fixing 1 CVE and two regressions from previous updates which were reported to Debian s bug tracker.
• DLA-747-1. Issued a security update for libupnp fixing 1 CVE.
• DLA-748-1. Issued a security update for libupnp4 fixing 1 CVE.
• DLA-746-2. Issued a regression update for tomcat6.
• DLA-753-1. Issued a security update for tomcat7 fixing 1 CVE and three regressions that were similar in nature to the ones fixed in Tomcat 6.
• DLA-761-1. Issued a security update for python-bottle fixing 1 CVE.
• DLA-763-1. Issued a security update for squid3 fixing 1 CVE.
• DLA-766-1. Issued a security update for libcrypto++ fixing 1 CVE.
• I also worked on two CVEs for Asterisk, an Open Source PBX and telephony toolkit. The work is done and can currently be found at this location. I asked on the debian-lts mailing list for feedback and testing and already got some positive feedback. I will wait a few more days before I release the security update.

Non-maintainer uploads

• I did two NMUs this month. I sponsored an upload of libtorrent for Peter Pentchev fixing #828414 and I fixed a trivial bug in gnash myself (#845847).

Jessie was released one year ago now and the Java Team has been busy preparing the next release. Here is a quick summary of the current state of the Java packages:

• A total of 136 packages have been added, 63 removed, 213 upgraded to a new upstream release, and 145 updated. We are now maintaining 892 packages (+12.34%).
• OpenJDK 8 is now the default Java runtime in testing/unstable. OpenJDK 7 has been removed, as well as several packages that couldn't be upgraded to work with OpenJDK 8 (avian, eclipse).
• OpenJDK 9 is available in experimental. As a reminder, it won't be part of the next release; OpenJDK 8 will be the only Java runtime supported for Stretch.
• Netbeans didn't make it into Jessie, but it is now back and up to date.
• The main build tools are close to their latest upstream releases, especially Maven and Gradle which were seriously lagging behind.
• Scala has been upgraded to the version 2.11. We are looking for Scala experts to maintain the package and its dependencies.
• Freemind has been removed due to lack of maintenance, Freeplane is recommended instead.
• The reproducibility rate has greatly improved, climbing from 50% to 75% in the past year.
• Backports are continuously provided for the key packages and applications: OpenJDK 8, OpenJFX, Ant, Maven, Gradle, Tomcat 7 & 8, Jetty 8 & 9, jEdit.
• The transition to Maven 3 has been completed, and packages are no longer built with Maven 2.
• We replaced several obsolete libraries and transitioned them to their latest versions - for example, asm2, commons-net1 and commons-net2. Groovy 1.x was replaced with Groovy 2, and we upgraded BND, an important tool to develop with OSGi, and more than thirty of its reverse-dependencies from the 1.x series to version 2.4.1.
• New packaging tools have been created to work with Gradle (gradle-debian-helper) and Ivy (ivy-debian-helper).

Outlook, goals and request for help

• We have several difficult transitions ahead: BND 3, Tomcat 7 to 8, Jetty 8 to 9, ASM 5, and of course Java 9. Any help would be welcome.
• Eclipse is severely outdated and currently not part of testing. We would like to update this important piece of software and its corresponding modules to the latest upstream release, but we need more active people who want to maintain them. If you care about the Eclipse ecosystem, please get in touch with us.
• We still are in the midst of removing old libraries like asm3, commons-httpclient and the servlet 2.5 API, which is part of the Tomcat 6 source package.
• Want to see Azureus/Vuze in Stretch again? Packaging is almost complete but we are looking for someone who can clarify remaining licensing issues with upstream and wants to maintain the software for the foreseeable future.
• Do you have more ideas and want to get involved with the Java Team? Just send your suggestions to debian-java@lists.debian.org or chat with us on IRC at irc.debian.org, #debian-java.

Java and Friends

• The Java Team is not the only team that maintains Java software in Debian. DebianMed, DebianScience and the Android Tools Maintainers rely heavily on Java. By helping the Java Team and working together, you can improve the Java ecosystem and further the efforts of multiple other fields of endeavor all at once.

Package updates The packages listed below detail the changes in jessie-backports and testing. Libraries and Debian specific tools have been excluded. Packages added to jessie-backports:

• ant (1.9.7)
• elasticsearch (1.6.2)
• gradle (2.10)
• groovy2 (2.4.5)
• japi-compliance-checker (1.5)
• jedit (5.3.0)
• jetty8 (8.1.19)
• jetty9 (9.2.14)
• maven (3.3.9)
• openjdk-7-jre-dcevm (7u79)
• openjdk-8 (8u72-b15)
• openjfx (8u60-b27)
• tomcat7 (7.0.69)
• tomcat8 (8.0.32)

Packages removed from testing:

• avian
• clojure1.2
• clojure1.4
• eclipse-cdt
• eclipse-cdt-pkg-config
• eclipse-egit
• eclipse-linuxtools
• eclipse-mercurialeclipse
• eclipse-mylyn
• eclipse-mylyn-tasks-github
• eclipse-ptp
• eclipse-subclipse
• eclipse-wtp
• freemind
• groovy
• maven2
• openjdk-7
• openjdk-7-jre-dcevm

Packages added to testing:

• apache-directory-server (2.0.0~M15)
• dokujclient (3.8.1)
• elasticsearch (1.7.3)
• ivyplusplus (1.14)
• jetty9 (9.2.16)
• netbeans (8.1)
• openjdk-8 (8u91-b14)
• openjdk-8-jre-dcevm (8u74)
• openjfx (8u60-b27)

Packages upgraded in testing:

• activemq (5.13.2)
• ant (1.9.7)
• aspectj (1.8.9)
• bnd (2.4.1)
• checkstyle (6.15)
• eclipse-gef (3.9.100)
• electric (9.06)
• felix-main (5.0.0)
• findbugs (3.0.1)
• fop (2.1)
• freeplane (1.3.15)
• gant (1.9.11)
• gradle (2.10)
• groovy2 (2.4.5)
• hsqldb (2.3.3)
• icedtea-web (1.6.2)
• ivy (2.4.0)
• jajuk (1.10.9)
• jakarta-jmeter (2.13)
• japi-compliance-checker (1.7)
• jasmin-sable (2.5.0)
• java-common (0.57)
• java-package (0.61)
• jedit (5.3.0)
• jetty8 (8.1.19)
• jftp (1.60)
• jgit (3.7.1)
• jruby (1.7.22)
• jtreg (4.2-b01)
• libapache-mod-jk (1.2.41)
• maven (3.3.9)
• nailgun (0.9.1)
• pleiades (1.6.0)
• proguard (5.2.1)
• robocode (1.9.2.5)
• sablecc (3.7)
• scala (2.11.6)
• service-wrapper-java (3.5.26)
• simplyhtml (0.16.13)
• svnkit (1.8.12)
• sweethome3d-textures-editor (1.4)
• tomcat-native (1.1.33)
• tomcat7 (7.0.69)
• tomcat8 (8.0.32)
• triplea (1.8.0.9)
• uimaj (2.8.1)
• weka (3.6.13)
• zookeeper (3.4.8)

Here is my monthly update covering a large part of what I have been doing in the free software world (previously):

• Released try.diffoscope.org, a hosted version of the diffoscope in-depth and content aware diff utility. Thanks to Bytemark for sponsoring the hardware.
• Announced travis.debian.net, a hosted script to easily test and build Debian packages on Travis CI.
• Wrote an Chrome extension for the FastMail web interface that reminds you if you neglect to attach a file if you mention one in the body. (Repo)
• Added graphical image comparison using to diffoscope using libcaca. (commit)
• Did further work on a free-software healthcare project.
• Added the ability to hide Zwift activities in my Strava Enhancement Suite Chrome extension. (#40)
• Updated the Django web framework documentation to discourage the use of filenames in /tmp with predictable names. (#5864)
• Corrected a Python 3.5-ism and a double-encoding issue in django-slack.
• Increased the size of the search form on codesearch.debian.net. (#59)
• Added support for filenames alongside the existing URL support for book cover images in my media database. (code)
• Corrected a trivial typo in FreeBSD's pkg package management tool. (#1353)
• Attended the 32nd Chaos Communication Congress.

---

What happened about the reproducible builds effort for this week: Presentations On May 26th,Holger Levsen presented reproducible builds in Debian at CCC Berlin for the Datengarten 52. The presentation was in German and the slides in English. Audio and video recordings are available. Toolchain fixes

• Dmitry Shachnev uploaded pyqt5/5.4.1+dfsg-3 which makes pyuic output imports in stable order. Original patch by Reiner Herrmann.
• Lunar uploaded mozilla-devscripts/0.41 which uses the UTC timezone when calling zip or unzip.

Niels Thykier fixed the experimental support for the automatic creation of debug packages in debhelper that being tested as part of the reproducible toolchain. Lunar added to the reproducible build version of dpkg the normalization of permissions for files in control.tar. The patch has also been submitted based on the main branch. Daniel Kahn Gillmor proposed a patch to add support for externally-supplying build date to help2man. This sparkled a discussion about agreeing on a common name for an environment variable to hold the date that should be used. It seems opinions are converging on using SOURCE_DATE_UTC which would hold a ISO-8601 formatted date in UTC) (e.g. 2015-06-05T01:08:20Z). Kudos to Daniel, Brendan O'Dea, Ximin Luo for pushing this forward. Lunar proposed a patch to Tar upstream adding a --clamp-mtime option as a generic solution for timestamp variations in tarballs which might also be useful for dpkg. The option changes the behavior of --mtime to only use the time specified if the file mtime is newer than the given time. So far, upstream is not convinced that it would make a worthwhile addition to Tar, though. Daniel Kahn Gillmor reached out to the libburnia project to ask for help on how to make ISO created with xorriso reproducible. We should reward Thomas Schmitt with a model upstream trophy as he went through a thorough analysis of possible sources of variations and ways to improve the situation. Most of what is missing with the current version in Debian is available in the latest upstream version, but libisoburn in Debian needs help. Daniel backported the missing option for version 1.3.2-1.1. akira submitted a new issue to Doxygen upstream regarding the timestamps added to the generated manpages. Packages fixed The following 49 packages became reproducible due to changes in their build dependencies: activemq-protobuf, bnfc, bridge-method-injector, commons-exec, console-data, djinn, github-backup, haskell-authenticate-oauth, haskell-authenticate, haskell-blaze-builder, haskell-blaze-textual, haskell-bloomfilter, haskell-brainfuck, haskell-hspec-discover, haskell-pretty-show, haskell-unlambda, haskell-x509-util, haskelldb-hdbc-odbc, haskelldb-hdbc-postgresql, haskelldb-hdbc-sqlite3, hasktags, hedgewars, hscolour, https-everywhere, java-comment-preprocessor, jffi, jgit, jnr-ffi, jnr-netdb, jsoup, lhs2tex, libcolor-calc-perl, libfile-changenotify-perl, libpdl-io-hdf5-perl, libsvn-notify-mirror-perl, localizer, maven-enforcer, pyotherside, python-xlrd, python-xstatic-angular-bootstrap, rt-extension-calendar, ruby-builder, ruby-em-hiredis, ruby-redcloth, shellcheck, sisu-plexus, tomcat-maven-plugin, v4l2loopback, vim-latexsuite. The following packages became reproducible after getting fixed:

• afterstep/2.2.12-6 uploaded by Robert Luberda, original patch by Juan Picca.
• birdfont/2.8.0-2 by Hideki Yamane.
• bzr/2.6.0+bzr6602-1 by Jelmer Vernooij.
• cassiopee/1.0.3+dfsg-2 uploaded by Olivier Sallou, original patch by akira.
• dhcp-helper/1.1-3 by Simon Kelley.
• elog/3.1.0-2-1 by Roger Kalt.
• flashcache/3.1.3+git20150513-1 uploaded by Liang Guo, original patch by Reiner Herrmann.
• fonts-kiloji/1:2.1.0-21 by Hideki Yamane.
• inspircd/2.0.20-2 by Guillaume Delacour.
• jd/1:2.8.9-150226-3 by Hideki Yamane.
• jruby-joni/2.1.6-2 by Hideki Yamane.
• libaqbanking/5.6.0beta-1 by Micha Lenk.
• libencode-hanextra-perl/0.23-4 fixed and uploaded by Niko Tyni.
• libencode-jis2k-perl/0.02-3 by Niko Tyni.
• libjide-oss-java/3.6.9+dfsg-1 by Markus Koschany.
• librpc-xml-perl/0.78-3 upload by Niko Tyni, original patch by Reiner Herrmann.
• libterm-readkey-perl/2.32-2 by Niko Tyni.
• mkgmap-splitter/0.0.0+svn421-1 by Bas Couwenberg.
• mod-authn-webid/0~20110301-3 by Clint Adams, original patch by Chris Lamb.
• ossim/1.8.16-4 uploaded by Bas Couwenberg, original patch by Juan Picca.
• psfex/3.17.1+dfsg-2 by Ole Streicher.
• socket-wrapper/1.1.3-2 uploaded by Laszlo Boszormenyi, original patch by Jelmer Vernooij.
• stiff/2.4.0-2 by Ole Streicher.
• testng/6.9.4-2 by Eugene Zhukov.
• wcwidth/0.1.4-2 by Sebastian Ramacher.

Some uploads fixed some reproducibility issues but not all of them:

• ant/1.9.5-1 by Emmanuel Bourg.
• gcin/2.8.3+dfsg1-2 by ChangZhuo Chen.
• grcompiler/4.2-5 by Hideki Yamane.
• python2.7/2.7.10-2 uploaded by Matthias Klose, based on a patch by Lunar.
• python3.4/3.4.3-7 uploaded by Matthias Klose, based on a patch by Lunar.
• python3.5/3.5.0~b2-1 uploaded by Matthias Klose, based on a patch by Lunar.
• wml/2.0.12ds1-9 by Axel Beckert.

Patches submitted which did not make their way to the archive yet:

• #787327 on vim by Reiner Herrmann: set a constant user and set modified-by option.
• #787650 on lush by Daniel Kahn Gillmor: remove __DATE__ and __TIME__ macros from source.
• #787669 on cloc by Daniel Kahn Gillmor: use time of latest debian/changelog entry in manpage.
• #787675 on ricochet by Daniel Kahn Gillmor: patch configure to allow an external build date and set it to the time of latest debian/changelog entry.
• #787804 on clipper by akira: set HTML_TIMESTAMP to NO in Doxygen configuration.
• #787829 on colobot by akira: set HTML_TIMESTAMP to NO in Doxygen configuration.
• #787865 on fastjet by akira: call Doxygen with HTML_TIMESTAMP set to NO.
• #787916 on cal3d by akira: remove $datetime from the file api_footer.html.
• #787918 on dime by akira: remove $datetime from the file footer.html.

Daniel Kahn Gilmor also started discussions for emacs24 and the unsorted lists in generated .el files, the recording of a PID number in lush, and the reproducibility of ISO images in grub2. reproducible.debian.net Notifications are now sent when the build environment for a package has changed between two builds. This is a first step before automatically building the package once more. (Holger Levsen) jenkins.debian.net was upgraded to Debian Jessie. (Holger Levsen) A new variation is now being tested: $PATH. The second build will be done with a /i/capture/the/path added. (Holger Levsen) Holger Levsen with the help of Alexander Couzens wrote extra job to test the reproducibility of coreboot. Thanks James McCoy for helping with certificate issues. Mattia Rizollo made some more internal improvements. strip-nondeterminism development Andrew Ayer released strip-nondeterminism/0.008-1. This new version fixes the gzip handler so that it now skip adding a predetermined timestamp when there was none. Holger Levsen sponsored the upload. Documentation update The pages about timestamps in manpages generated by Doxygen, GHC .hi files, and Jar files have been updated to reflect their status in upstream. Markus Koschany documented an easy way to prevent Doxygen to write timestamps in HTML output. Package reviews 83 obsolete reviews have been removed, 71 added and 48 updated this week. Meetings A meeting was held on 2015-06-03. Minutes and full logs are available. It was agreed to hold such a meeting every two weeks for the time being. The time of the next meeting should be announced soon.

I'm getting the hang of the more or less daily RC bug fixing again. below you find what I did this week. as a side note: as you can see, quite a few of the patches are taken from ubuntu; it's great that someone over there already took the time to come up with a fix; thanks! not so great is that only one of them was in the BTS. guys, you have already been better at forwarding your patches to the debian BTS, please try to get back into this good habit :)

• #709908 src:make-dfsg: "make-dfsg: FTBFS with automake1.13: automatic de-ANSI-fication support has been removed"
  change build dependency like done in Ubuntu by Colin Watson, upload to DELAYED/2
• #710609 src:spring: "spring: FTBFS: CScopedTimer.h:39:31: error: expected unqualified-id before numeric constant"
  add Ubuntu patches (Colin Watson, Dmitrijs Ledkovs), upload to DELAYED/2
• #711572 src:libhtml-widget-perl: "libhtml-widget-perl: FTBFS with perl 5.18: test failure"
  add patch to fix hash randomisation issue with perl 5.18 (pkg-perl)
• #713159 src:jruby: "jruby: FTBFS: build.xml:313: The archive nailgun-0.7.1.jar doesn't exist"
  add modified patches from Ubuntu / Julian Taylor (pkg-java)
• #713393 src:libzip: "libzip: FTBFS: dh_auto_test: make -j1 check returned exit code 2"
  add autotools patch from upstream via Ubuntu / Bjoern Michaelsen, upload to DELAYED/2
• #713559 src:libfakekey: "libfakekey: FTBFS: ld: fakekey-test.o: undefined reference to symbol 'XOpenDisplay'"
  add fix from Ubuntu / Daniel T Chen (link against missing lib), upload to DELAYED/2
• #713628 src:prelink: "prelink: FTBFS: (.text+0x1d8): undefined reference to pthread_atfork'"
  sponsor QA upload prepapred by Andreas Moog
• #723964 src:devtodo: "devtodo: FTBFS: required file './compile' not found"
  prepare two alternative debdiffs
• #728588 libhttp-async-perl: "libhttp-async-perl: FTBFS: test requires internet connectivity"
  skip test that requires internet access (pkg-perl)
• #728646 src:libfilesys-smbclient-perl: "libfilesys-smbclient-perl: FTBFS: libsmbclient.h: No such file or directory"
  prepare patches (pkg-perl)

For a (german) talk I ll be giving soon I was interested in a list of open source projects which use Jenkins. Jenkins is a great open source continuous integration server. I was wondering whether such a list exists but since it doesn t exist yet I created my own and Kohsuke Kawaguchi (creator of Hudson/Jenkins) suggested to blog about it. There we go.

• Apache
• Bazar
• cocos2d-x
• coreboot
• Creativecommons
• Django CMS
• Doom Port Build Service
• Eclipse Communication Framework
• Freeswitch
• Grml
• iceScrum
• JBoss
• Jenkins
• JMRI
• JRuby
• KDE
• Linaro
• Mahara
• Mozilla
• Nuxeo
• OpenQuake
• Pentaho
• Piwik
• Plone
• PODAM
• Pylons Project
• Saiku
• Scala-Tools
• SQLAlchemy
• SQLAlchemy-migrate
• Tapestry 5 modules breadcrumbs + tagselect
• TYPO3
• UTGB (University of Tokyo Genome Browser) Toolkit
• Wicket Stuff
• Zikula

Open source projects using Jenkins, though Jenkins service not accessible for the public (yet):

• ConfigureMe
• DistributeMe
• Evolvis
• Fusionforge
• Icinga
• Joomla
• OpenJDK 7 for OS/X
• Openstack
• sip:provider CE

And Cloudbees hosts some OSS projects providing Jenkins as a service. Update [2011-08-29]: thanks for all the feedback, I ve updated the list accordingly.
If you re aware of another open source project using Jenkins please leave it in the comments, I ll update the list accordingly then.

I have finally reached a decision regarding my involvement in the Debian Ruby packaging efforts. I have decided to stop. This has been a very hard decision to make. I have invested huge amounts of time in that work over the years. I still love the language, and will continue to use it on a daily basis for my own developments. I still hope that it will succeed. I know that some people will be disappointed by that decision (and that others will think your work was useless anyway, people should use RVM and rubygems ). But I also know that I won t be able to push for all the required changes alone. I just don t have the time, nor the motivation. For the record, here are the changes I would have liked to see in the Ruby community. The core Ruby development community should mature.
The core Ruby development community is still dominated by Japanese developers. While not a bad thing in itself, it is easily explained by the fact that the main development mailing list, where most of the important decisions are taken, is in japanese. ruby-dev@ should be closed, and all the technical discussions should happen on the english-speaking ruby-core@ list instead. The release management process should also improve. Currently, it looks like a total mess. The following Ruby development branches are actively maintained:
ruby_1_8 (106 commits over the last six months)
ruby_1_8_6 (4 commits over the last six months)
ruby_1_8_7 (35 commits over the last six months)
ruby_1_9_1 (4 commits over the last six months)
ruby_1_9_2 (227 commits over the last six months)
trunk (1543 commits over the last six months) While the state of the ruby_1_8_6 and ruby_1_9_1 branches is clear (very important bugfixes only), the state of all of the other branches is rather unclear.
What s the stable Ruby branch? 1.8 or 1.9? If it s 1.9, why are people still actively developing in the ruby_1_8 branch? How long will they continue to be maintained in parallel, dividing the manpower? Is a Ruby 1.8.8 release to be expected? Will it be ABI/API compatible with 1.8.7? Is the ruby_1_8_7 branch really bugfixes-only? How much testing of it has been done? If it s bugfixes-only and regression-free, I should push it to Debian squeeze, due to be released in a few weeks. But would you recommend that? Due to past breakages in the ruby_1_8_7 branch, it s unlikely that we will do it.
Is the ruby_1_9_2 a regression-free, bugfix-only branch? If yes, isn t 227 commits over 6 months a lot? What will be the version of the next release of trunk ? When is it expected? Will it be ABI-compatible with the current ruby_1_9_2 branch? API-compatible?
New releases in the 1.8.7 and 1.9.2 branches were done on december 25th. Why were they no betas or RCs allowing wider testing? How much testing has been done behind the scenes? Most of those questions have no clear answer. The Ruby development community should build a common understanding of the status of the various branches, and of their release expectations. Releasing on december 25th of each year sounds fun, but is releasing when everybody is on vacation really a good idea? It would be fantastic to have something similar to Python Enhancement Proposals in the Ruby community. But having open discussions in english about the major issues would already be great. Ruby is not just the interpreter.
The Ruby development community should clearly define what the Ruby platform is. There are some big players, like Rails, and newer interpreter releases should not be done before ensuring that those big players still work. Also, since we have alternative Ruby interpreters, like JRuby, Rubinius and MacRuby, we need a clear process on how they integrate with the rest of the ecosystem. For example, having each of them rely on their own outdated fork of the whole stdlib is ridiculous, since it s not where they compete. The Ruby community should acknowledge that RVM and Rubygems are not for everybody. People who say so should be laughed at. Of course, RVM and Rubygems are nice tools for some people. But it is completely wrong to believe that compiling from source using RVM should be the standard way of installing Ruby, or that all people interested in installing Redmine should know that Ruby has its own specific packaging system. The Ruby community should work with their target platforms to improve how Ruby is distributed instead of reinventing the wheel. That includes Debian, but also RedHat-based distros, for example. It is likely that it won t be possible to reach a one-size-fits-all situation. But that s real life. Some people in the Ruby community should stop behaving like assholes. As one of the Debian Ruby maintainers, I have been routinely accused of creating crippled packages on purpose (FTR, I don t think that the Debian packages are crippled, despite what the rumors says). Debian is not the only target of that. Just yesterday, someone called for abandonning YARV (the new Ruby VM in Ruby 1.9), calling it Yet Another Random Vailure. This kind of comments is really hurting the people who are investing their free time in Ruby, and is turning away people who consider getting involved. In Debian, we have had a lot of problems getting people to help with Ruby maintenance since they are getting shit from the community all the time. So, what s the future for Ruby in Debian?

• For the interpreter, the two other maintainers, Akira Yamada and Daigo Moriwaki, are of course free to continue their work, and I wish them good luck.
• For the pkg-ruby-extras team, which maintains most of the Ruby libraries and applications, the future is less clear. The team was already badly understaffed, and I feel that I should probably clean up its status by orphaning/removing the packages that are unmaintained otherwise. This won t affect all the packages that the team maintains: some packages (like redmine) are actively maintained, and will stay.
• For me, it just means I will have more time for other things (possibly not Free Software-related). If things improve dramatically, I might also come back to Ruby packaging at some point.

Update: there s also a number of interesting comments about this post on this site.
Update 2: First, thanks a lot for all the interesting comments. I will make some follow-up posts trying to summarize what was said. It seems that this post also triggered some reactions on ruby-core@, with Charles Olivier explaining the JRuby stdlib fork, and Yui Naruse clarifying that all questions are welcomed on ruby-core@. This is great, really.

Richard Tibbetts has called me out for conflating Web 2.0 startups with all startups in my recent blog posting, Google has a problem retaining great engineers? Bullcrap . His complaint was that I was over generalizing from Web 2.0 startups to all startups. He s right, of course. The traditional technology startup by definition does have a large amount technology work that needs to be done, in addition to the business development work. However, things have changed a lot even for technology startups. Consider a company like Sequent Computer Systems, which started in 1983. At the time the founders had a key idea, which was to use multiple commodity intel CPU s to create first SMP, and then later, NUMA minicomputers. But in order to do that, they had to design, build and manufacture a huge mount of hardware, as well as develop a whole new Unix-derived operating system, just to bring that core idea to market. These days, the founder or founders will have a core idea, which they will hopefully patent, to prevent competitors from replicating their work, just as before. However, these days there is a huge selection of open source software so there is much less technology that needs to be re-developed / re-invented in order to bring that idea to market. From Linux and BSD at the operating system level, to databases like MySQL, Apache web servers, etc., there is an awful lot for the startup to chose from. This is all goodness, of course. But it means that most of the technology developed in a typical startup will tend to be focused on supporting the core idea that was developed by the founder. If a company is focused on databases, they probably won t be interested in supporting me to do my file system work. Why should they? There s lots of open source file systems they can use; one of them will probably meet their needs. So while it s obvious that you can do technology at large variety of companies, of different sizes, I don t think it s arrogance to say that there are certain types of technology that can only be done at Google, or maybe at a very small subset of other companies. I m pretty confident, for example, that Google has the world s largest number of computers in its various data centers around the world. That means there are certain things that don t make sense at other companies, but which absolutely makes sense at our scale. In addition, Google s business model means allows us to pursue open source projects such as Chrome and Android that wouldn t make sense at other companies. With Android in particular, it means that multiple firmware updates for any given handset model, if it causes people to use the web more and drive more advertising revenue, makes sense and so it s something we can pursue in comparison to Nokia, which gets its revenue from hardware sales, so a firmware update that extends the life of a handset is actually a bad thing for them; better to force you to upgrade an handset every year or two. So I think Richard misunderstood me if he thought I was trying to make the argument that Google is the only place where you can do interesting technical work. That s obviously not true, of course. But I do think there are many examples of technical work which don t make business sense to do at smaller companies, and startups in particular have to be very much focused on bringing the founder s idea to market, and all else has to be subordinated to that goal. And one of the most interesting developments is how the combination of commoditized and standardized hardware, and comoditized software in the form of open source, has changed the game for startups. For most startups, though, open source software is something that they will use, but not necessarily develop except in fairly small ways. Many of the economic arguments in favor of releasing code as open source, and dedicating a significant fraction of an engineer s time to serve as a OSS project maintainer or kernel subsystem maintainer, are ones that make much more sense at a very large company like Google or IBM. That s not because startups are evil, or deficient in any way; just the economic realities that at a successful startup, everything has to be subordinated to the central goal of proving that they have a sustainable, scalable business model and that they have a good product/market fit. Everything else, and that includes participating in an open source community, is very likely a distraction from that central goal. No related posts.

There s some hype in the Ruby community about RVM (Ruby Version Manager). It s a tool that allows to switch between Ruby versions on the same system (much like what the alternatives system provides for Java on Debian, except that RVM does it either system-wide or per-user). However, when you look at it, RVM looks quite scary. The recommended installation instruction is:
bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head ).
That script doesn t use set -e, and actually does a git clone behind the scenes. Without first checking that git is installed. But if you don t have git installed, it s not a problem: there s another script later on the page that downloads and compiles it for you. After installing RVM itself, you need to install rubies (different ruby implementations). Use rvm install ree,1.9.2-head,jruby. That will automatically download and build the various versions in your homedir. It s interesting to note the the compilation messages were probably too scary, and are not displayed. But how does it handle the switch between different versions ? First, you need to add some magic to your .bashrc:
[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"
or, for a system-wide install of rvm:
[[ -s "/usr/local/rvm/scripts/rvm" ]] && . "/usr/local/rvm/scripts/rvm"
And then, you can select your ruby implementation using rvm --default 1.9.2, for example. That works by redefining $PATH:
# echo $PATH
/usr/local/rvm/gems/ruby-1.9.2-p0/bin:/usr/local/rvm/gems/ruby-1.9.2-p0@global/bin:/usr/local/rvm/rubies/ruby-1.9.2-p0/bin:/usr/local/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 Of course, that s quite fragile: if you are in one of the cases where bash doesn t read .bashrc, or if you happen to be using dash, you lose. Looking at the code of RVM itself, it is also very fragile: it s pure bash, without any error handling. During my test (in a chroot), I often got error messages about missing commands that were apparently ignored. The installer insists on using colors, and spews lots of error messages if executed without a controlling tty. There are also some interesting code snippets like perl -e 'sleep 0.5'. So, where do we go from here? Well, obviously, with my Debian hat, I m not going to advocate a solution that makes everything possible to avoid the distribution s packaging system, and I don t see RVM being packaged in Debian anytime soon.
In Debian, we already provide co-installability of Ruby 1.8 and 1.9.2, and users are free to choose which one to use on a per-script basis, by running them with version-suffixed ruby executables. The ruby executable itself still points to 1.8, as it s clearly too early to make 1.9.2 the default. Many Ruby libraries are provided for both 1.8 and 1.9.2, and we plan to discuss changes in the packaging system to be able to make it easier to provide packages for both versions. There s also recent work on packaging JRuby, but it s quite hard as it requires removing all the non-free or undistributable parts, and packaging them separately.

I last wrote about Jacob s new computer back in April. He has had fun with it, but is still a little young to appreciate it a whole lot. It s a fun thing, but not yet a favorite. Yesterday, though, I introduced Jacob to several bits of technology that really got him excited. We have a pair of FRS radios. These are low-power Family Radio Service devices, with a maximum practical range of maybe a mile, and are about as cheap a radio as you can buy that still has any sort of practical use. Anyhow, the receive circuit on one broke. I ordered a pair of TriSquare digital radios to replace them, which are incompatible. So, I have two radios, one with a broken receive circuit. What to do? GIVE THEM TO JACOB! I explained that one radio is the talking radio (the broken one) and the other is the listening radio. Then I demonstrated how I could use the talking radio and he could hear me on the listening radio. That was great fun. I encouraged him to go to the kitchen and see if he could still hear me in the next room. Cackles of laughter gave me the answer. Then he discovered the call button would make the other radio sound like a telephone, which was all the more exciting. He and I took turns with the talking and listening radios. Then I used the belt clip and attached the listening radio to the back of his shirt. I pointed out to him that this was sort of like a loudspeaker. Anything he said into the talking radio while holding town the transmit button would sound louder because it would also come out the radio on his back. Much cackling followed, and he ran around the house yelling MEOW! at the top of his lungs into the radio, then saying, Dad, did you hear THAT? It was VERY loud! He has spent hours listening to himself, listening to me, and generally enjoying life with radios. Jacob s second discovery was a cassette tape player. Awhile back, Terah rescued an old cassette tape player that was being thrown out, and bought a few 15-cent tapes for Jacob at a thrift store. The idea is that we can just let him play, and not care if he smashes it to bits. He enjoys it, but like the computer, didn t really get excited about it. Until yesterday, when we had this conversation: Me: Jacob, would you like to record your own voice on a tape? Jacob: (excited) Sure! Me: OK, bring me your tape recorder. Jacob: (exasperated) Dad, it s not a tape RECORDER. It s a tape PLAYER. Me: Jacob, it is a tape player, but it s also a tape recorder too. Jacob: (paused for about 5 seconds, then ) Ooooo! That is silly! (scampers off to find it) He found it, and I helped him put some tape over the write-protect tab on a cassette he had. Then he recorded his voice. He eventually figured out the stop, rewind, play, and record buttons with my help. But he s still confused: while he s recording, why doesn t he hear anything? Our first recording had me asking him some questions, and then telling him to press the stop button when he was done. He listened to it dozens of times, and each time my recorded voice asked a question, he answered it a little before his recorded voice did. And each time my recorded voice told him to press the stop button, he would say, I don t want to while his recorded voice asked is this it? He pretty well understands what the radios are about, but doesn t really get the tape recorder yet. Nevertheless, it has just become a far more exciting device in his eyes. Terah has been rolling her eyes at me today as I ve been trying to think up what other broken or old bits of technology we might have that Jacob would enjoy. My latest plan involves adapting his broken old batte
ry-operated fan into some sort of lego-related car. I think he d have fun working on it with me too. All this reminds me of things I did as a kid. My dad worked with a semi-retired man (Herb Miller) that loved to build weird contraptions. One of my favorites was a ball shooter made out of an old vacuum cleaner with a cardboard tube attached to the output spot. I also remember building a motorized car out of an erector set that sort of bent the rules at a school science class project. The idea was to launch a vehicle down a ramp and person whose vehicle went the farthest got a prize. There were no rules against using batteries and a scavenged motor to get that extra little edge over gravity. My car was the only one to manage to crash into the wall on the far side of the gymnasium. The science teacher, in a bit of fast thinking perhaps, announced my car the winner of the electric division. For some reason, I seem to be poised to encourage this sort of thinking in Jacob