Richard 'RichiH' Hartmann Release Critical Bug report for Week 30

I have been asked to publish bug stats from time to time. Not exactly sure about the schedule yet, but I will try and stick to Fridays, as in the past; this is for the obvious reason that it makes historical data easier to compare. "Last Friday of each month" may or may not be too much. Time will tell.

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1511
    • Affecting Jessie: 431 That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 383 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 44 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 20 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
        • 319 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
      • Affecting Jessie only: 48 Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 0 bugs are in packages that are unblocked by the release team.
        • 48 bugs are in packages that are not unblocked.

Graphical overview of bug stats thanks to azhag:

Posted 2014-07-25--23-52-56-CEST Tags:

Quoth joeyh:

Note that recent versions of git-annex have a reinit command that makes this much simpler:

git clone /existing/repo.annex

git annex info # to refresh your memory about uuid or description of lost repo

git annex reinit uuid|description

Old Post:

Another half a blog post, half a reminder for my future self.

Turns out that pulling an external 3.5" disk off of your nightstand with the help of a tangled USB cable is a surprisingly efficient way to kill a it. On the plus side, this yields instant results and complete success.

On the other hand, I kinda lost well over one TiB of personal photographs and other data which I didn't really appreciate a whole lot.

Thankfully, all data was annexed and I always maintain at least three copies of all files at all times, so the fix is as easy as getting two new disks and running

badblocks /dev/foo -swo $manufacturer-$model-$(date '+%F--%H-%M-%S-%Z').badblocks-swo # assuming you keep a git repo of this data

followed by partitioning, mkfs etc and

cd /existing/repo.annex
git annex info # not the UUID you need
cd /new/disk
git clone /existing/repo.annex
cd repo.annex
vim .git/config # add the [annex] block and _copy over the UUID of the lost repo_
git annex get # assuming you want a full copy, which I always do for data archival repos
git annex sync

and done. By running git annex get before git annex sync, I managed to avoid (potentially) saving information about missing data; I simply made sure it was all in place before synching again.

The second external disk allows me to always get one local disk up to speed and another one off-site. I am able to learn from experience ;)

Posted 2014-05-15--13-48-49-CEST Tags:
Richard 'RichiH' Hartmann Interesting debate

It's nice to see that the overall tone of some key debates is slowly changing. The stance of not securing the whole stack piece by piece because some unrelated part in the stack is leaking information as well is steadily losing ground.

Another impact of this whole mess is that you can't really be certain why some parties are arguing against pervasive encryption any more. On the plus side, that makes defaulting to safety simpler.

Posted 2014-05-15--12-41-50-CEST Tags:
Richard 'RichiH' Hartmann higher security

Instant classic


NO, there were errors:
The certificate does not apply to the given host
The certificate authority's certificate is invalid
The root certificate authority's certificate is not trusted for this purpose
The certificate cannot be verified for internal reasons

Signature Algorithm: md5WithRSAEncryption
    Issuer: C=XY, ST=Snake Desert, L=Snake Town, O=Snake Oil, Ltd, OU=Certificate Authority, CN=Snake Oil CA/emailAddress=ca@snakeoil.dom
        Not Before: Oct 21 18:21:51 1999 GMT
        Not After : Oct 20 18:21:51 2001 GMT
    Subject: C=XY, ST=Snake Desert, L=Snake Town, O=Snake Oil, Ltd, OU=Webserver Team, CN=www.snakeoil.dom/emailAddress=www@snakeoil.dom
            X509v3 Subject Alternative Name: 

For your own pleasure:

openssl s_client -connect -showcerts

or just run

echo '
' | openssl x509 -noout -text

At least they're secure against heartbleed.

Posted 2014-04-18--12-15-49-CEST Tags:
Richard 'RichiH' Hartmann secure password storage

Dear lazyweb,

for obvious reaons I am in the process of cycling out a lot of passwords.

For the last decade or so, I have been using openssl.vim to store less-frequently-used passwords and it's still working fine. Yet, it requires some manual work, not least of which manually adding random garbage at the start of the plain text (and in other places) every time I save my passwords. In the context of changing a lot of passwords at once, this has started to become tedious. Plus, I am not sure if a tool of the complexity and feature-set of Vim is the best choice for security-critical work on encrypted files.

Long story short, I am looking for alternatives. I did some research but couldn't come up with anything I truly liked; as there's bound to be tools which fit the requirements of like-minded people, I decided to ask around a bit.

My personal short-list of requirements is:

  • Strong crypto
  • CLI-based
  • Must add random padding at the front of the plain text and ideally in other places as well
  • Should ideally pad the stored file to a few kB so size-based attacks are foiled
  • Must not allow itself to be swapped out, etc
  • Must not be hosted, cloud-based, as-a-service, or otherwise compromised-by-default
  • Should offer a way to search in the decrypted plain text, nano- or vi-level of comfort are fine
  • Both key-value storage or just a large free-form text area would be fine with a slight preference for free-form text

Any and all feedback appreciated. Depending on the level of feedback, I may summarize my own findings and suggestions into a follow-up post.

Posted 2014-04-16--08-27-49-CEST Tags:

This is half a blog post and half a reminder for my future self.

So let's say you used the following commands:

git add foo
git annex add bar
git annex sync
# move to different location with different remotes available
git add quux
git annex add quuux
git annex sync

what I wanted to happen was to simply sync the already committed stuff to the other remotes. What happened instead was git annex sync's automagic commit feature (which you can not disable, it seems) doing its job: Commit what was added earlier and use "git-annex automatic sync" as commit message.

This is not a problem in and as of itself, but as this is my my master annex and as I managed to maintain clean commit messages for the last few years, I felt the need to clean this mess up.

Changing old commit messages is easy:

git rebase --interactive HEAD~3

pick the r option for "reword" and amend the two commit messages. I did the same on my remote and all the branches I could find with git branch -a. Problem is, git-annex pulls in changes from refs which are not shown as branches; run git annex sync and back are the old commits along with a merge commit like an ugly cherry on top. Blegh.

I decided to leave my comfort zone and ended up with the following:

# always back up before poking refs
git clone --mirror repo backup

git reset --hard 1234
git show-ref | grep master
# for every ref returned, do:
  git update-ref $ref 1234

rinse repeat for every remote, git annex sync, et voilĂ . And yes, I avoided using an actual loop on purpose; sometimes, doing things slowly and by hand just feels safer.

For good measure, I am running

git fsck && git annex fsck

on all my remotes now, but everything looks good up to now.

Posted 2014-04-15--00-12-49-CEST Tags:
Richard 'RichiH' Hartmann Train them to submit

And today from our ever-growing collection of what the fuck is wrong with you people?!...

This is wrong on so many levels, I can't even begin to describe it. Sadly, it seems that this will get funded. And if it does not, technology will only become cheaper over time...

Posted 2014-03-25--15-06-48-CET Tags:
Richard 'RichiH' Hartmann Lenovo X1 Carbon

Christine's accidential blog spam on planet.d.o just now gave me the chance to re-read the comments in her post.

The state from back then is still the current state on up-to-date Debian unstable:

  • Microphone button does nothing.
  • USB 3.0 docking station's display does not work thanks to the content mafiaa with an admittedly small petition trying to fix this. Obviously it is going to be ignored.
  • No one using Debian seems to care about the fingerprint reader.
  • UMTS/WWAN modem works fine on Windows, but Linux loses connection to the USB device all the time. As a result, UMTS does not work

The last item has the most impact on me. The need to tether when you have a dedicated SIM card, built-in modem, and good antennas in your laptop is... infuriating. Especially as it's working as intended on Windows.

As an added benefit, even though I saved the PIN in network manager, it asks me for the PIN every time I log in and every time after hibernating. For a device which I can't use in the first place. Argh!

Posted 2014-03-22--07-45-09-CET Tags:

In February, Linux Magazine contacted me, asking if I would be willing to accept the Linux New Media Award 2014 in the main category "Outstanding Contribution to Open Source/Linux/Free Software" on behalf of the Git community due to my involvement with evangelizing and vcsh. Needless to say, I was thrilled.

I managed to poke Junio via someone at Google and he agreed. We also reached out within the German Git community and two maintainers of git submodule, Jens Lehmann and Heiko Voigt, joined in as well. While we didn't manage to hammer out interoperability issues of vcsh and git submodule due to time constraints and too much beer, we are planning to follow up on that.

Git beat OpenStack, Python, and Ubuntu by a huge margin; sadly I don't have exact numbers (yet).

More details and a rather crummy photo can be found in Linux Magazine's article. A video of the whole thing will uploaded to this page soonish. If it appears that we kept our "speech" very short, that was deliberate after the somewhat prolonged speeches beforehand ;)

The aftershow event was nice even though the DJ refused to turn down the music down to tolerable levels; his reaction to people moving father away, and asking him to turn down the volume a bit, was to turn it up... Anyway, given the mix of people present during the award ceremony, very interesting discussions ensued. While I failed to convert Klaus Knopper to zsh and git, at least there's a chance that Cornelius Schuhmacher will start using vcsh and maybe even push for a separation of configuration and state in KDE.

The most interesting tidbits of the evening were shared by Abhisek Devkota of cyanogenmod fame. Without spilling any secrets it's safe to say that the future of cyanogenmod is looking extremely bright and that there are surprises in the works which will have quite the impact.

Last but not least, here's the physical prize:

Glass trophy held by your's truly

Posted 2014-03-14--23-50-09-CET Tags:
Richard 'RichiH' Hartmann Panem et congressūs

There's a German joke about Germans:

Q: How can you find Germans abroad?
A: You stand outside a bakery and wait until someone starts cussing.

I am constantly reminded of this joke, abroad and back home, as we do tend to take our bread seriously...

As an additional data point supporting this, the German local team just spent 20 minutes discussing bread. I somehow doubt you could make an off-hand comment about bread and garner much interest in most communities; in a German one, this works.

In mildly related news, this is what will pick up soon:

During the DebConf committee meeting, it has been decided that the 16th annual Debian Conference, DebConf15, will be held in Germany next year.

Thanks to the Belgian and Swedish teams; we are looking forward to their renewed bids for future DebConfs!

Specifics as to location and date are still being nailed down and we will keep Debian as a whole informed about our progress.

A dedicated (English-language) mailing list has been created for the organization and we welcome interested people to subscribe and join the discussion.