Well this has been an interesting project. It all started with a need to get better password storage at work. We wound up looking heavily at a GPG-based solution. This prompted the question: how can we make it even more secure? Well, perhaps, smartcards. The theory is this: a smartcard holds your private keys in a highly-secure piece of hardware. The PC can never actually access the private keys. Signing and decrypting operations are done directly on the card to prevent the need to export the private key material to the PC. There are lots of standards to choose from (PKCS#11, PKCS#15, and OpenPGP card specs) that are relevant here. And there are ways to use SSH and OpenVPN with some of these keys too. Access to the card is protected by a passphrase (called a PIN in smartcard lingo, even though it need not be numeric). These smartcards might be USB sticks, or cards you pop into a reader. In any case, you can pop them out when not needed, pop them in to use them, and well, pretty nice, eh? So that s the theory. Let s talk a bit of reality. First of all, it is hard for a person like me to evaluate how secure my data is in hardware. There was a high-profile bug in the OpenPGP JavaCard applet used by Yubico that caused the potential to use keys without a PIN, for instance. And how well protected is the key in the physical hardware? Granted, in most of these cards you re talking serious hardware skill to compromise them, but still, this is unknown in absolute terms. Here s the bigger problem: compatibility. There are all sorts of card readers, but compatibility with pcsc-tools and pcscd on Linux seems pretty good. But the cards themselves oh my. PKCS#11 defines an interface API, but each vendor would provide their own .so or .dll file to interface. Some cards (for instance, the ACOS5-64 mentioned on the Debian wiki!) are made by vendors that charge $50 for the privilege of getting the drivers needed to make them work and they re closed-source proprietary drivers at that. Some attempts I ordered several cards to evaluate: the OpenPGP card, specifically designed to support GPG; the ACOS5-64 card, the JavaCOS A22, the Yubikey Neo, and a simple reader listed on the GPG smartcard howto. The OpenPGP card and ACOS5-64 are the only ones in the list that support 4096-bit RSA keys due to the computational demands of them. The others all support 2048-bit RSA keys. The JavaCOS requires the user to install a JavaCard applet to the card to make it useable. The Yubico OpenPGP applet works here, along with GlobalPlatform to install it. I am not sure just how solid it is. The Yubikey Neo has yet to arrive; it integrates some interesting OAUTH and TOTP capabilities as well. I found that Debian s wiki page for smartcards lists a bunch of them that are not really useable using the tools in main. The ACOS5-64 was such a dud. But I got the JavaCOS A22 working quite nicely. It s also NFC-enabled and works perfectly with OpenKeyChain on Android (looking like a Yubikey Neo to it, once the OpenPGP applet is installed). I m impressed! Here s a way to be secure with my smartphone without revealing everything all the time. Really the large amount of time is put into figuring out how all this stuff fits together. I m getting there, but I ve got a ways to go yet. Update: Corrected to read signing and decrypting rather than signing and encrypting operations are being done on the card. Thanks to Beno t Allard for catching this error.

If you wonder why it was so silent here over the last weeks, there is a simple explanation: I am on scientific freak weeks As you might know, in my main profession I am logician, mathematician, computer scientist at the Japan Advanced Institute of Science and Technology (btw, searching urgently for a new job, in case someone is interested!!!). The last weeks have been very busy with attenting and presenting at LICS 2015 (Logic in Computer Science), followed by a workshop on Proofs as Processes organized by myself, then a presentation at CCA 2015 (Conference on Computability and Complexity in Analysis), and now working with visitors on our hyper natural deduction system. Above all that, there is also my lecture on Logical Decision Procedures at JAIST that a colleague and I a creating on the fly. All in all a very busy July, but I hope that after the weekend, and another workshop at JAIST, things settle down around beginning of August.

I'm still working on the Norwegian version of the Free Culture book by Lawrence Lessig, and is now working on the final typesetting and layout. One of the features I want to get the structure similar to the original book is to typeset the footnotes as endnotes in the notes chapter. Based on the feedback from the Debian maintainer and the dblatex developer, I came up with this recipe I would like to share with you. The proposal was to create a new LaTeX class file and add the LaTeX code there, but this is not always practical, when I want to be able to replace the class using a make file variable. So my proposal misuses the latex.begindocument XSL parameter value, to get a small fragment into the correct location in the generated LaTeX File. First, decide where in the DocBook document to place the endnotes, and add this text there:

<?latex \theendnotes ?>

Next, create a xsl stylesheet file dblatex-endnotes.xsl to add the code needed to add the endnote instructions in the preamble of the generated LaTeX document, with content like this:

<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version='1.0'>
  <xsl:param name="latex.begindocument">
    <xsl:text>
\usepackage endnotes 
\let\footnote=\endnote
\def\enoteheading \mbox \par\vskip-\baselineskip  
\begin document 
    </xsl:text>
  </xsl:param>
</xsl:stylesheet>

Finally, load this xsl file when running dblatex, for example like this:

dblatex --xsl-user=dblatex-endnotes.xsl freeculture.nb.xml

The end result can be seen on github, where my book project is located.

While updating the maintainer's guide, I had faced with several issues to update it as it is, since it was based on the dh-make package and does not play nice with new features such as multi-arch etc. Also. the lack of capability to create a decent copyright information template was my concern.

Mostly a mental note as I've reinvented this the second time now. If you just quickly want to share some org-mode notes with some non-Emacs-users the built-in HTML export comes handy. However it has one Problem: All source syntax highlighting is derived from your current theme. Which of course is a bad idea if your editor has a dark background (say Emacs.reverseVideo: on). The same if your terminal's background color is dark. Running Emacs in batch mode and still getting colorful code formatting seems to be an unsolved problem. All that can be found on the Internet suggests adding a dark background to your HTML export (at least to the code blocks). Or maybe use an external style-sheet. Both not exactly the thing if you just want to scp snippets of HTML somewhere to share. However there's a working hack:

#!/usr/bin/make -f
%.html: %.org
	xvfb-run urxvt +rv -e emacs -nw --visit $< --funcall org-html-export-to-html --kill >/dev/null

So use a terminal you can easily force into light-background-mode (like urxvt +rv) so the emacs -nw runs in light-background-mode and wrap the thing in xvfb-run so you can properly run this over ssh (and don't get annoying windows pop up and disappear again when typing make)

Like each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In June, 73.50 work hours have been dispatched among 7 paid contributors. Their reports are available:

• Ben Hutchings did 14.75 hours.
• Guido G nther did 10 hours.
• Mike Gabriel did 8 hours.
• Rapha l Hertzog did 14.5 hours.
• Santiago Ruano Rinc n did 14.75 hours.
• Scott Kitterman did 4 hours.
• Thorsten Alteholz did 14.5 hours.

Evolution of the situation July has seen a nice increase in terms of sponsored hours (79.50 hours per month) but the trend is unlikely to continue for the next month, worse it might be negative. While most sponsors who joined us last year in July will renew their support, there are a few where I have no confirmation yet. Many thanks to those who confirmed early: Universit Lille 3, MyTux. Our first milestone of funding the equivalent of a half-time position is unlikely to be reached before DebConf or even this summer. If you want to prove me wrong, it s time to get in touch with your management and convince your company to contribute a small amount. In terms of security updates waiting to be handled, the situation is similar to last month: the dla-needed.txt file lists 24 packages awaiting an update (5 more than last month), the list of open vulnerabilities in Squeeze shows about 33 affected packages in total (3 less than last month). Thanks to our sponsors There are no new sponsors this month. But I decided to include the number of months that the sponsor has been with us. Since we value long-lasting relations, it seemed quite natural to add this.

• Gold sponsors:
• The Positive Internet (for 13 months already)
• Linode LLC
• Silver sponsors:
• David Ayers IntarS Austria (for 13 months already)
• Blablacar (for 12 months already)
• Domeneshop AS (for 12 months already)
• Universit Lille 3 (for 12 months already)
• Trollweb Solutions (for 10 months already)
• Gandi SAS (for 7 months already)
• University of Luxembourg (for 4 months already)
• Rentabiliweb Group
• Bronze sponsors:
• Offensive Security (for 13 months already)
• Seznam.cz, a.s. (for 13 months already)
• Evolix (for 12 months already)
• Freeside Internet Service (for 12 months already)
• MyTux (for 12 months already)
• Linuxhotel GmbH (for 10 months already)
• Nantes M tropole (for 10 months already)
• Intevation GmbH (for 9 months already)
• Daevel SARL (for 8 months already)
• FOSSter (for 8 months already)
• Bitfolk LTD (for 7 months already)
• Megaspace Internet Services GmbH (for 7 months already)
• Gree, Inc. (for 6 months already)
• Greenbone Networks GmbH (for 6 months already)
• NUMLOG (for 6 months already)
• WinGo AG (for 5 months already)
• Ecole Centrale de Nantes LHEEA

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

A new release of RcppEigen arrived on CRAN and in Debian yesterday. It synchronizes the Eigen code with the 3.2.5 upstream release. Once again, Yixuan Qiu did most of the heavy lifting in one very nice pull request, and I added some minor updates to keep R CMD check --as-cran happy. The NEWS file entry follows.

Changes in RcppEigen version 0.3.2.5.0 (2015-07-11)

• Updated to version 3.2.5 of Eigen
• Fixed some incorrect error messages stemming from Eigen code.
• Updated package to current R CMD check standards.

Courtesy of CRANberries, there is also a diffstat report for the most recent release.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

(In order to avoid any ambiguity here, this is a personal opinion. The Free Software Foundation's opinion on this matter is here)

Canonical have a legal policy surrounding reuse of Intellectual Property they own in Ubuntu, and you can find it here. It's recently been modified to handle concerns raised by various people including the Free Software Foundation[1], who have some further opinions on the matter here. The net outcome is that Canonical made it explicit that if the license a piece of software is under explicitly says you can do something, you can do that even if the Ubuntu IP policy would otherwise forbid it.

Unfortunately, "Canonical have made it explicit that they're not attempting to violate the GPL" is about the nicest thing you can say about this. The most troubling statement is Any redistribution of modified versions of Ubuntu must be approved, certified or provided by Canonical if you are going to associate it with the Trademarks. Otherwise you must remove and replace the Trademarks and will need to recompile the source code to create your own binaries.. The apparent aim here is to avoid situations where people take Ubuntu, modify it and continue to pass it off as Ubuntu. But it reaches far further than that. Cases where this may apply include (but are not limited to):

• Anyone producing a device that runs an operating system based on Ubuntu, even if it's entirely invisible to the user (eg, an embedded ARM device using Ubuntu as its base OS)
• Anyone producing containers based on Ubuntu
• Anyone producing cloud images (such as AMIs) based on Ubuntu

In each of these cases, a strict reading of the policy indicates that you are distributing a modified version of Ubuntu and therefore must either get it approved by Canonical or remove the trademarks and rebuild everything. The strange thing is that this doesn't limit itself to rebuilding packages that include Canonical's trademarks - there's a requirement that you rebuild all binaries.

Now obviously this is good engineering practice in a whole bunch of ways, but it's a huge pain in the ass. And to make things worse, Canonical won't clarify what they consider to be use of their trademarks. Many Ubuntu packages rebuilt from Debian include the word "ubuntu" in their version string. Many Ubuntu packages will contain the word "ubuntu" in maintainer email addresses. Many Ubuntu packages include references to Ubuntu (for instance, documentation might say "This configuration file is located under /etc/default in Debian and Ubuntu"). And many Ubuntu packages will include the compiler version string, which will include the word "ubuntu". Realistically, there's no risk of confusion by using the trademarks in this way, and as a consequence there would be no infringement under trademark law. But Canonical aren't using trademark law here. Canonical assert that they hold copyright over binaries that they have built form source, and require that for you to have permission to redistribute these binaries under copyright law you must remove the trademarks. This means that it doesn't matter whether your use of the trademarks would be infringing or not - you're required to remove them, because fuck you that's why.

This is a huge overreach. It's hostile to free software, in that it makes it significantly more difficult to produce derivative works of Ubuntu and doesn't benefit the community in the process. It's hostile to our understanding of IP law, in that it claims that the mechanical process of turning source code into binaries creates an independently copyrightable work. And in some cases it may make it impossible to create derivative works that interoperate with Ubuntu due to applications making assumptions about the presence of strings.

It'd be easy write this off as an over the top misinterpretation of the policy if it hadn't been confirmed by the Ubuntu Community Manager that any binaries shipped by Ubuntu under licenses that don't grant an explicit right to redistribute the binaries can't be redistributed without permission or rebuilding. When I asked for clarification from Canonical over a year ago, I got no response[2]. Perhaps Canonical don't want to force you to remove every single use of the word Ubuntu from derivative works, but their policy is written such that the natural reading is that they do, and they've refused every single opportunity they've been given to clarify the point.

So, we're left with a policy that makes it hugely impractical to redistribute modified versions of Ubuntu unless Canonical approve of it. That's not freedom, and it's certainly not Ubuntu. If Canonical are serious about participating in the free software community then they need to demonstrate their willingness to continue improving this policy to bring it closer to our goals. Failure to do so will give a strong indication of their priorities.

[1] While I'm a member of the FSF's board of directors, I'm not involved in the majority of the FSF's day to day activities and was not part of this process
[2] Nebula's OS was a mixture of binary packages we pulled straight from Ubuntu and packages we rebuilt, so we were obviously pretty interested in what the answer was

comments

Yesterday, Wammu 0.39 has been released. The list of changes is not really huge:

• Fixed connecting to phone with no SMSC set.
• Various code cleanups.
• Translation updates.

I will not make any promises for future releases (if there will be any) as the tool is not really in active development.

Filed under: English Gammu Wammu 0 comments

This was my second month as a Freexian sponsored LTS contributor. I was assigned 4 hours which was enough for me to update libclamunrar to the latest version we have, 0.98.5. This aligns libclamunrar with last month s clamav update and resolved a potentially concerning double free error. This is consistent with the way clamav and its components are updated for Debian supported releases through proposed-updates. This is covered under DLA 250-1. This update took longer than expected due to time spent wrestling with the git repository for the packaging, but that s resolved now, so if future updates are needed, it should be much easier.

I looked a bit more into the possible arguments to keep DHE alive once you support ECDHE and you only expect traffic from endusers with a real browser (machine2machine traffic with access from obscure libraries is a different matter). From the SSL Labs checks we can deduce the following components that support DHE but do not support ECDHE:

• Android 2.3.7
• Java 6

Windows XP does not support forward secrecy at all, and all other browsers beside IE (except for the first Chrome releases) bring their own TLS implementation. A very interesting data point is the cipher usage graphing provided by Wikimedia you can find on this dashboard. Currently I see roughly 4% of connections to be negotiated with some variant of a DHE cipher. That is after all not much, so I'm tempted to disable DHE for HTTPS where I've working ECDHE support soon. I'd first like to gather some stats from the BigIPs which I'm babysitting but that unfortunately is not that easy. As far as I can tell the only option is to insert a header a via an iRule and log the header on a backend system. Or you can setup HSL and log directly from the iRule.

In a comment to my previous post, Daniele asked the entirely reasonable question,

Would you like to comment on why you think that DNSSEC+DANE are not a possible and much better alternative?

Where DANE fails to be a feasible alternative to the current system is that it is not widely acknowledged to be superior in every possible way . A weak demonstration of this is that no browser has implemented DANE support, and very few other TLS-using applications have, either. The only thing I use which has DANE support that I m aware of is Postfix and SMTP is an application in which the limitations of DANE have far less impact. My understanding of the limitations of DANE, for large-scale deployment, are enumerated below.

DNS Is Awful Quoting Google security engineer Adam Langley:

But many (~4% in past tests) of users can t resolve a TXT record when they can resolve an A record for the same name. In practice, consumer DNS is hijacked by many devices that do a poor job of implementing DNS.

Consider that TXT records are far, far older than TLSA records. It seems likely that TLSA records would fail to be retrieved greater than 4% of the time. Extrapolate to the likely failure rate for lookup of TLSA records would be, and imagine what that would do to the reliability of DANE verification. It would either be completely unworkable, or else would cause a whole new round of just click through the security error training. Ugh. This also impacts DNSSEC itself. Lots of recursive resolvers don t validate DNSSEC, and some providers mangle DNS responses in some way, which breaks DNSSEC. Since OSes don t support DNSSEC validation by default (for example, by having the name resolution APIs indicate DNSSEC validation status), browsers would essentially have to ship their own validating resolver code. Some people have concerns around the single point of control for DNS records, too. While the weakest link nature of the CA model is terribad, there is a significant body of opinion that replacing it with a single, minimally-accountable organisation like ICANN isn t a great trade. Finally, performance is also a concern. Having to go out-of-band to retrieve TLSA records delays page generation, and nobody likes slow page loads.

DNSSEC Is Awful Lots of people don t like DNSSEC, for all sorts of reasons. While I don t think it is quite as bad as people make out (I ve deployed it for most zones I manage, there are some legitimate issues that mean browser vendors aren t willing to rely on DNSSEC. 1024 bit RSA keys are quite common throughout the DNSSEC system. Getting rid of 1024 bit keys in the PKI has been a long-running effort; doing the same for DNSSEC is likely to take quite a while. Yes, rapid rotation is possible, by splitting key-signing and zone-signing (a good design choice), but since it can t be enforced, it s entirely likely that long-lived 1024 bit keys for signing DNSSEC zones is the rule, rather than exception.

DNS Providers are Awful While we all poke fun at CAs who get compromised, consider how often someone s DNS control panel gets compromised. Now ponder the fact that, if DANE is supported, TLSA records can be manipulated in that DNS control panel. Those records would then automatically be DNSSEC signed by the DNS provider and served up to anyone who comes along. Ouch. In theory, of course, you should choose a suitably secure DNS provider, to prevent this problem. Given that there are regular hijackings of high-profile domains (which, presumably, the owners of those domains would also want to prevent), there is something in the DNS service provider market which prevents optimal consumer behaviour. Market for lemons, perchance?

Conclusion None of these problems are unsolvable, although none are trivial. I like DANE as a concept, and I d really, really like to see it succeed. However, the problems I ve listed above are all reasonable objections, made by people who have their hands in browser codebases, and so unless they re fixed, I don t see that anyone s going to be able to rely on DANE on the Internet for a long, long time to come.

The Debian Perl team had its first sprint in May and it was a success: 7 members met in Barcelona the weekend from May 22nd to May 24th to kick off the development around perl for Stretch and to work on QA tasks across the more than 3000 packages that the team maintains. Even though the participants enjoyed the beautiful weather and the food very much, a good amount of work was also done:

• 53 bugs were filed or worked on, 31 uploads were accepted.
• The current practice of patch management (quilt) was discussed and possible alternatives were shown (git-debcherry and git-dpm).
• Improvements were made in the Debian Perl Tools (dpt) and discussed how to get track of upstream git history and tags.
• Team's policies, documentation and recurring tasks were reviewed and updated.
• Perl 5.22 release was prepared and src:perl plans for Stretch were discussed.
• autopkgtest whitelists were reviewed, new packages added, and IRC notificacions by KGB were discussed.
• Outstanding migrations were reviewed.
• Reproducibility issues with POD_MAN_DATE were commented.

The full report was posted to the relevant Debian mailing lists. The participants would like to thank the Computer Architecture Department of the Universitat Polit cnica de Catalunya for hosting us, and all donors to the Debian project who helped to cover a large part of our expenses.

A new version of RcppGSL arrived on CRAN a couple of days ago. This package provides an interface from R to the GNU GSL using our Rcpp package. In the course of preparation for the higher-performance R via C++ course I gave in Zuerich last month, I overhauled this package, its embedded package (!!) showing how to build a package which uses R, C++ and the GSL (and which can serve as a fine example of how to build and R and C++ package using an external library), and also overhauled the vignette which discusses all these aspect. All examples now consistently use Rcpp Attributes. The NEWS file entries follows below:

Changes in version 0.2.5 (2015-07-05)

• The colnorm function in the included example package was rewritten to use Rcpp Attributes, the example package was updated and its version number increased to 0.0.3.
• The unit tests also use the updated version of the example package.
• The package, and the included example package, were updated throughout to conform to the current R CMD check standards.
• The RcppGSL-intro vignette was updated throughout.
• The Travis CI integration now uses r-cran-* packages which leads to faster tests.

Courtesy of CRANberries, a summary of changes to the most recent release is available. More information is on the RcppGSL page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Debian is undertaking a huge effort to develop a reproducible builds system. I'd like to thank you for that. This could be Debian's most important project, with how badly computer security has been going.

PerniciousPunk in Reddit's Ask me anything! to Neil McGovern, DPL. What happened in the reproducible builds effort this week: Toolchain fixes More tools are getting patched to use the value of the SOURCE_DATE_EPOCH environment variable as the current time:

• libxslt in #791815 (Dhole),
• texlive-bin via upstream (#792202) (akira),
• sphinx via upstream (Dmitry Shachnev).

In the reproducible experimental toolchain which have been uploaded:

• doxygen to support SOURCE_DATE_EPOCH (akira),
• debhelper now set SOURCE_DATE_EPOCH to the time of the latest debian/changelog entry when exporting build flags, patch sent as #791823 (Dhole),
• epydoc to support SOURCE_DATE_EPOCH (Reiner Herrmann),
• texlive-bin (akira) and libxslt (Dhole) with the aforementioned support for SOURCE_DATE_EPOCH.

Johannes Schauer followed up on making sbuild build path deterministic with several ideas. Packages fixed The following 311 packages became reproducible due to changes in their build dependencies : 4ti2, alot, angband, appstream-glib, argvalidate, armada-backlight, ascii, ask, astroquery, atheist, aubio, autorevision, awesome-extra, bibtool, boot-info-script, bpython, brian, btrfs-tools, bugs-everywhere, capnproto, cbm, ccfits, cddlib, cflow, cfourcc, cgit, chaussette, checkbox-ng, cinnamon-settings-daemon, clfswm, clipper, compton, cppcheck, crmsh, cupt, cutechess, d-itg, dahdi-tools, dapl, darnwdl, dbusada, debian-security-support, debomatic, dime, dipy, dnsruby, doctrine, drmips, dsc-statistics, dune-common, dune-istl, dune-localfunctions, easytag, ent, epr-api, esajpip, eyed3, fastjet, fatresize, fflas-ffpack, flann, flex, flint, fltk1.3, fonts-dustin, fonts-play, fonts-uralic, freecontact, freedoom, gap-guava, gap-scscp, genometools, geogebra, git-reintegrate, git-remote-bzr, git-remote-hg, gitmagic, givaro, gnash, gocr, gorm.app, gprbuild, grapefruit, greed, gtkspellmm, gummiboot, gyp, heat-cfntools, herold, htp, httpfs2, i3status, imagetooth, imapcopy, imaprowl, irker, jansson, jmapviewer, jsdoc-toolkit, jwm, katarakt, khronos-opencl-man, khronos-opengl-man4, lastpass-cli, lava-coordinator, lava-tool, lavapdu, letterize, lhapdf, libam7xxx, libburn, libccrtp, libclaw, libcommoncpp2, libdaemon, libdbusmenu-qt, libdc0, libevhtp, libexosip2, libfreenect, libgwenhywfar, libhmsbeagle, libitpp, libldm, libmodbus, libmtp, libmwaw, libnfo, libpam-abl, libphysfs, libplayer, libqb, libsecret, libserial, libsidplayfp, libtime-y2038-perl, libxr, lift, linbox, linthesia, livestreamer, lizardfs, lmdb, log4c, logbook, lrslib, lvtk, m-tx, mailman-api, matroxset, miniupnpd, mknbi, monkeysign, mpi4py, mpmath, mpqc, mpris-remote, musicbrainzngs, network-manager, nifticlib, obfsproxy, ogre-1.9, opal, openchange, opensc, packaging-tutorial, padevchooser, pajeng, paprefs, pavumeter, pcl, pdmenu, pepper, perroquet, pgrouting, pixz, pngcheck, po4a, powerline, probabel, profitbricks-client, prosody, pstreams, pyacidobasic, pyepr, pymilter, pytest, python-amqp, python-apt, python-carrot, python-django, python-ethtool, python-mock, python-odf, python-pathtools, python-pskc, python-psutil, python-pypump, python-repoze.tm2, python-repoze.what, qdjango, qpid-proton, qsapecng, radare2, reclass, repsnapper, resource-agents, rgain, rttool, ruby-aggregate, ruby-albino, ruby-archive-tar-minitar, ruby-bcat, ruby-blankslate, ruby-coffee-script, ruby-colored, ruby-dbd-mysql, ruby-dbd-odbc, ruby-dbd-pg, ruby-dbd-sqlite3, ruby-dbi, ruby-dirty-memoize, ruby-encryptor, ruby-erubis, ruby-fast-xs, ruby-fusefs, ruby-gd, ruby-git, ruby-globalhotkeys, ruby-god, ruby-hike, ruby-hmac, ruby-integration, ruby-jnunemaker-matchy, ruby-memoize, ruby-merb-core, ruby-merb-haml, ruby-merb-helpers, ruby-metaid, ruby-mina, ruby-net-irc, ruby-net-netrc, ruby-odbc, ruby-ole, ruby-packet, ruby-parseconfig, ruby-platform, ruby-plist, ruby-popen4, ruby-rchardet, ruby-romkan, ruby-ronn, ruby-rubyforge, ruby-rubytorrent, ruby-samuel, ruby-shoulda-matchers, ruby-sourcify, ruby-test-spec, ruby-validatable, ruby-wirble, ruby-xml-simple, ruby-zoom, rumor, rurple-ng, ryu, sam2p, scikit-learn, serd, shellex, shorewall-doc, shunit2, simbody, simplejson, smcroute, soqt, sord, spacezero, spamassassin-heatu, spamprobe, sphinxcontrib-youtube, splitpatch, sratom, stompserver, syncevolution, tgt, ticgit, tinyproxy, tor, tox, transmissionrpc, tweeper, udpcast, units-filter, viennacl, visp, vite, vmfs-tools, waffle, waitress, wavtool-pl, webkit2pdf, wfmath, wit, wreport, x11proto-input, xbae, xdg-utils, xdotool, xsystem35, yapsy, yaz. Please note that some packages in the above list are falsely reproducible. In the experimental toolchain, debhelper exported TZ=UTC and this made packages capturing the current date (without the time) reproducible in the current test environment. The following packages became reproducible after getting fixed:

• 389-admin/1.1.42-1 uploaded by Timo Aaltonen, original patch by Chris Lamb.
• aroarfw/0.1~beta5-2 uploaded by Patrick Matth i, original patch by akira.
• clfft/2.4-2 by Ghislain Antony Vaillant.
• custom-tab-width/1.0.1-3 by Daniel Kahn Gillmor.
• debirf/0.35 uploaded by Daniel Kahn Gillmor, original patch by Chris Lamb.
• enigmail/2:1.8.2-3 by Daniel Kahn Gillmor.
• flashproxy/1.7-4 by Ximin Luo.
• getdns/0.2.0-2 by Daniel Kahn Gillmor.
• glfw3/3.1.1-1 by James Cowgill, reported by akira.
• gpgme1.0/1.5.5-3 by Daniel Kahn Gillmor.
• jzmq/3.1.0-4 by Jan Niehusmann.
• libcommons-cli-java/1.3.1-1 by tony mancill.
• liblo/0.28-5 uploaded by Felipe Sateler, original patch by akira.
• libmoe/1.5.8-2 uploaded by TANIGUCHI Takaki, original patch by Chris Lamb.
• libnet-interface-perl/1.012-2 uploaded by gregor herrmann, original patch by Chris Lamb.
• libxmlenc-java/0.52+dfsg-4 by Emmanuel Bourg.
• lintian/2.5.33 by Niels Thykier.
• litecoin/0.10.2.2-1 uploaded by Dmitry Smirnov, original patch by Chris Lamb.
• node-ws/0.7.2+ds1.349b7460-1 by Ximin Luo.
• pyevolve/0.6~rc1+svn398+dfsg-7 uploaded by Christian Kastner, original patch by Juan Picca.
• sendmail/8.14.9-3 by Andreas Beckmann.
• uthash/1.9.9.1+git20150507-2 by Ilias Tsitsimpis, report by Jakub Wilk.

Ben Hutchings upstreamed several patches to fix Linux reproducibility issues which were quickly merged. Some uploads fixed some reproducibility issues but not all of them:

• apt-dater/1.0.2-1 uploaded by Patrick Matth i, original patch by Dhole, fixed upstream by Thomas Liske.
• argyll/1.7.0+repack-4 by J rg Frings-F rst.
• grads/2:2.0.2-4 by Alastair McKinstry.
• kfreebsd-10 by Steven Chamberlain.
• mariadb-10.0/10.0.20-2 by Otto Kek l inen.
• xtel/3.3.0-18 uploaded by Samuel Thibault, original patch by Dhole.

Uploads that should fix packages not in main:

• fglrx-driver/1:15.7-1 uploaded by Patrick Matth i, fixed by Andreas Beckmann.
• pycuda/2015.1.2-1 uploaded by Tomasz Rybak, patch by Juan Picca.

Patches submitted which have not made their way to the archive yet:

• #787675 on ricochet by Daniel Kahn Gillmor: use the debian/changelog date in the manpage.
• #791648 on fish by Chris Lamb: sort header files in documentation.
• #791691 on fritzing by Chris Lamb: sort the documentation author list using the C locale.
• #791834 on bitcoin by Reiner Herrmann: sort sources files using the C locale.
• #791845 on yacas by Reiner Herrmann: sort hints using the C locale.
• #791851 on scowl by Reiner Herrmann: sort dictionary files using the C locale.
• #791913 on ceph by Chris Lamb: sort configuration file names.
• #791923 on alpine by Chris Lamb: use debian/changelog date as build date and use debian as the builder hostname.
• #791960 on leveldb by Reiner Herrmann: sort sources files using th e C locale.
• #792054 on ben by Reiner Herrmann: use debian/changelog date as bui ld date.
• #792056 on val-and-rick by Reiner Herrmann: sort sources by filenames.

reproducible.debian.net A new package set has been added for lua maintainers. (h01ger) tracker.debian.org now only shows reproducibility issues for unstable. Holger and Mattia worked on several bugfixes and enhancements: finished initial test setup for NetBSD, rewriting more shell scripts in Python, saving UDD requests, and more debbindiff development Reiner Herrmann fixed text comparison of files with different encoding. Documentation update Juan Picca added to the commands needed for a local test chroot installation of the locales-all package. Package reviews 286 obsolete reviews have been removed, 278 added and 243 updated this week. 43 new bugs for packages failing to build from sources have been filled by Chris West (Faux), Mattia Rizzolo, and h01ger. The following new issues have been added: timestamps_in_manpages_generated_by_ronn, timestamps_in_documentation_generated_by_org_mode, and timestamps_in_pdf_generated_by_matplotlib. Misc. Reiner Herrmann has submitted patches for OpenWrt. Chris Lamb cleaned up some code and removed cruft in the misc.git repository. Mattia Rizzolo updated the prebuilder script to match what is currently done on reproducible.debian.net.

A small update to RcppRedis arrived on CRAN a few days ago. One of the unit tests failed as we (still) initialized the rredis package (loaded only for a comparison) in a form long-internalized by Bryan Lewis, its author. No actual changes to functionality were; the only other changes is cosmetic and in response a R CMD check requirement where the curl binary seemingly fails to follow redirects so we removed the (official !) redis.io URL.

Changes in version 0.1.4 (2015-07-04)

• Minor update to unit test setup for rredis.
• No longer list URLs to Redis as automated CRAN tests for URL validity choke on redirects.

Courtesy of CRANberries, there is also a diffstat report for the most recent release. More information is on the RcppRedis page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

A few days ago and while we were traveling, an updated release of our random package for truly (hardware-based) random numbers as provided by random.org arrived on CRAN. Brian Ripley had pointed out to us that some of the curl implementations (which must now be used as https is mandatory at random.org) did not follow redirects. Which was bad luck, given that I had used a shortform https://random.org as opposed to the fuller-length https://wwwrandom.org variant providing the service. This has been rectified, and we used the opportunity to also update the DESCRIPTION and NAMESPACE file as R CMD check --as-cran now mandates more explicit imports. Courtesy of CRANberries comes a diffstat report for this release. Current and previous releases are available here as well as on CRAN.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

The Independent reports that David Cameron wishes to ban the instant messaging application WhatsApp due its use of end-to-end encryption. That we might merely be pawns in manoeuvring for some future political compromise (or merely susceptible to cheap clickbait) should be cause for some concern, but what should worry us more is that if it takes scare stories about WhatsApp for our culture to awaken on the issues of privacy and civil liberties, then the central argument against surveillance was lost a long time ago. However, the situation worsens once you analyse the disapproval in more detail. One is immediately struck by a predominant narrative of technical considerations; a ban would be "unworkable" or "impractical". A robust defence of personal liberty or a warning about the insidious nature of chilling effects? Perhaps a prescient John Locke quote to underscore the case? No. An encryption ban would "cause security problems." The argument proceeds in a tediously predictable fashion: it was already difficult to keep track whether one should ipso facto be in favour of measures that benefit the economy, but we are suddenly co-opted as technocrats to consider the "damage" it could to do the recovery or the impact on a now-victimised financial sector. The coup-de-gr ce finally appeals to our already inflated self-regard and narcissism: someone could "steal your identity." Perhaps even more disappointing is the reaction from more technically-minded circles who, frankly, should know better. Here, they give the outward impression of metaphorically stockpiling copies of the GnuPG source code in their bunkers, perhaps believing the shallow techno-utopianist worldview that all social and cultural problems can probably be solved with Twitter and a JavaScript intepreter. The tragedy here is that I suspect that this isn't what the vast majority of people really believe. Given a hypothetical ban that could, somehow, bypass all of the stated concerns, I'm pretty upbeat and confident that most people would remain uncomfortable with it on some level. So what, exactly, does it take for us to oppose this kind of intervention on enduring principled grounds instead of transient and circumventable practical ones? Is the problem just a lack of vocabulary to discuss these issues on a social scale? A lack of courage? Whilst it's certainly easier to dissect illiberal measures on technical merit than to make an impassioned case for abstract freedoms, every time we gleefully cackle "it won't work" we are, in essence, conceding the central argument to the authoritarian and the censorious. If one is right but for the wrong reasons, were we even right to begin with?

Here's an odd thing about the git bisect command: It has only 1 option (--no-checkout). Compare with eg git commit, which has 36 options by my count. The difference is largely down to git having a pervasive culture of carefully edited history. We need lots of git commit options to carefully produce commits that look Just Right. Staging only some of the files we've edited, perhaps even staging only some of the changes within a file. Amend that commit if we notice we made a mistake. Create a whole series of beautiful commits, and use rebase later to remix them into a more beautiful whole. Beautiful fake histories. Because coding is actually messy; our actual edit history contains blind alleys and doublings back on itself; contains periods of many days the code isn't building properly. We want to sweep that complexity away, hide it under the rug. This works well except when it doesn't, when some detail airbrushed out of the only remaining history turns out to be important. Once we have these beautiful fake histories of changes, we can easily bisect them and find the commit that introduced a bug. So bisect doesn't need a lot of options to control how it works. I'd like to suggest a new option though. At least as a thought experiment. --merges-only would make bisect only check the merge commits in the range of commits being bisected. The bisection would result in not a single commit, but in the set of commits between two merges. I suspect this would be useful for faster bisecting some histories of the beautiful fake kind. But I know it would be useful when the history is messy and organic and full of false starts and points where the code doesn't build. Merges, in such histories, are often the points where things reach a certian level of beauty, where that messy feature branch got to the point it all built again (please let this happen today) and was merged into master. Bisecting such points in a messy organic history should work about as well as bisecting carefully gardened histories. I think I'll save the full rant about beautiful fake history vs messy real history for some other day. Or maybe I've already ranted that rant here before, I can't remember. Let's just say that I personally come down on the side of liking my git history to reflect the actual code I was working on, even if it was broken and even if I threw it away later. I've indeed taken this to extreme lengths with propellor; in its git history you can see every time I've ever run it, and the version of my config file and code at that point. Apologies to anyone who's been put off by that... But oddly, propellor gets by far more contributions from others than any of my other haskell programs. All in the form of beaufiully constructed commits, naturally.

It took me ages to finish Portal (1), but Portal 2 was different I moved through the games in high speed. Actually playing time was the same, but I played a bit more often then before More details below, but tl;dr: Nice extension of Portal, which feels a bit different. Graphics are great, but for my feeling the chambers are too easy and too short. Image by user browen2o on the Steam Portal community center. Portal 2, the successor of Portal, brings not only many new levels (test chambers) interspersed with funny running sequences and out of normal problems to solve, but adds also a set of new devices to solve the problems. But the basic mechanics are the same: Shoot portals to solve puzzles. The added devices are as follows (thanks to this blog): They include light-rings that carry you over empty space, and also lift you up (first and second icon), light reflectors (forth), jumping and running color (9th and 10th), catapults (12th), light bands to walk on (lower left) and of course enough turrets and other devices that might find you smashed, shot, or drowned. Things I liked at Portal 2:

• Great background voices (the helping head, )
• More devices to use
• Short chambers easy to play in short bursts
• Nice and funny

and what I didn t like too much was

• Too easy chambers being able to solve most riddles without much trial and error and lots of break, most of the time on first run, left the feeling of not being fully challenged. If I compare it to Talos which I am now playing, it is much harder.
• Short chambers it feels more relaxed, more rest places. Even if they were there in Portal 1, too, but if there is a rest-place somewhere within a level it is for me of a different quality. (But see also the good part of it above!)

What I haven t tried till now, unfortunately, is the cooperative mode. I need some partners, but my buddy is too many time zones away All in all, a really great game, and I enjoyed it a lot.