Planet Debian

Subscribe to Planet Debian feed
Planet Debian - http://planet.debian.org/
Updated: 2 min 39 sec ago

Russ Allbery: Review: Pawn of Prophecy

29 December, 2016 - 10:21

Review: Pawn of Prophecy, by David Eddings

Series: The Belgariad #1 Publisher: Del Rey Copyright: April 1982 Printing: August 1990 ISBN: 0-345-33551-1 Format: Mass market Pages: 258

I hit a period in November when I felt like reading something entirely undemanding and fun, something that was predictable, comfortable, and guaranteed to be a happy ending. There are times in life for books like that. I've been vaguely thinking of re-reading the Belgariad for a while, which I'd not read since I was in college, and that seemed to fit the bill.

Garion is a farm-boy in Sendaria, a quiet and industrious kingdom full of farmers. His only family is his Aunt Pol, who ran the kitchen at Faldor's farm. His life has all the hallmarks of being entirely unremarkable, despite occasional visits by a traveling vagabond, Wolf, who clearly knows his Aunt Pol. But then something extremely important is stolen elsewhere, Wolf and Pol have to leave to pursue it for reasons that are quite murky to Garion, and Pol is unwilling to leave Garion behind. This begins Garion's great adventure, in which he becomes far more important and powerful than he would have ever imagined.

That's the promise, at least, and the stock plot of every series like this. And let me be clear up front: the Belgariad is very stock. That's part of what I was in the mood for, but don't come to this series looking for interesting differentiation. It's clearly in the center of the secondary world chosen one fantasy genre, with a great evil, forces of good arrayed against it, and someone who unknowingly has the power to stop evil but has to learn how to use it. If you're in the mood for this, every note will be comfortably familiar; if not, it might be boringly predictable.

Unfortunately, this particular book does not cast the Belgariad in a good light. Garion's introduction to this story is intensely irritating, almost entirely because no one will tell him what's going on. Pol is excessively protective (smotheringly so), but shuts down any questions he has and doesn't explain why she's freaking out. (This doesn't become entirely clear until towards the end of the second book.) What little scraps Garion picks up, he has to get by eavesdropping. Even by the end of this book, when Garion has met royalty and started helping with larger political issues (albeit mostly by accident), everyone is keeping him in the dark and he doesn't believe the hints he's gotten. I can't remember how I reacted to this the first time I read this series, but the second time through, it was extremely frustrating.

The frustration is stronger because any regular reader of this genre knows exactly what Garion is, although not precisely how the story will play out, and can make fairly good guesses about Pol and Wolf from early in the story. Everyone playing coy doesn't even add legitimate suspense or set up a big reveal. It just made me irritated at Garion's blindness (it's mildly understandable given how foreign the idea is to his life, but he seems remarkably dense even with that), and even more irritated at Wolf and, in particular, Aunt Pol for keeping him so thoroughly in the dark. Garion is very attached to his aunt; on this re-reading, I wasn't entirely sure why. She occasionally shows love and support, and she's certainly wise, but for most of the book she treats him with brusque condescension and tries to keep him as ignorant as possible.

Garion's weird entanglement with a black rider that he'd seen for most of his life doesn't make this any better. It's creepy and disturbing, it's not entirely resolved in this book, and Garion is clearly in danger, which wasn't the vibe that I was looking for when starting this re-read. And it's hard to escape the feeling that Garion might have managed to tell someone if all the adult figures in his life weren't so secretive, dismissive, and excessively controlling.

So, all in all, an inauspicious beginning. It was good enough to keep me reading when I first read the series, and it was good enough on this re-read, but just barely. The saving grace is Silk and Barak, when the story finally meets them. Those who have read this series will know that they're just the beginning of the party-building process that will take up much of this series (so many Lord of the Rings resonances), but the one thing I will give Eddings is that he writes entertaining supporting characters. Both of them are a bit stereotyped, but they add so much to this story. Silk in particular is a delight and remains a delight throughout the series, adding a much-needed level of snark and sneaky enjoyment that lightens so many of the serious episodes of this story.

The Belgariad in general is highly derivative map exploration fantasy, and you shouldn't expect anything deeper. It is, however, enjoyable map exploration fantasy with some entertaining supporting cast members. Sadly, only the glimmers of that are visible from this book. Pawn of Prophecy is mostly an irritating tour of bad parenting techniques, refusal to talk to teenagers, sneaking around to get information that should have been legitimately shared, and taking forever to get around to the mythology that we all know is coming.

I therefore can't recommend this book, although one does have to read it in order to read the rest of the series, which as I recall gets considerably better.

Followed by Queen of Sorcery.

Rating: 5 out of 10

Wouter Verhelst: NBD talk at FOSDEM 2017

28 December, 2016 - 15:35

You may have noticed (but you probably did not), but on 2017-02-04, at 14:00, in room UB2.252A (aka "Lameere"), which at that point in time will be the Virtualisation and IaaS devroom, I'll be giving a talk on the Network Block Device protocol.

Having been involved in maintaining NBD in one way or another for over fifteen years now, I've never seen as much activity around the concept as I have in the past few years. The result of that has been that we've added a number of new features to the protocol, to allow it to be used in settings where it was not as useful or as attractive as it would have been before. As a result, these are exciting times for those who care about NBD, and I thought it would be about time that I'd speak about it somewhere. The Virtualisation/IaaS devroom seemed like the right fit today (even though I wouldn't have thought so a mere two years ago), and so I'm happy they agreed to have me.

While I still have to start writing my slides, and therefore don't really know (yet) exactly what I'll be talking about, the schedule already contains an outline.

See you there?

Clint Adams: Sigil Loma Saturnina Reed-Stuewe

28 December, 2016 - 12:04

“Are they from Gresham?” I asked.

“Nope,” he said, “Sigil is Portland proper, Fritz is Eugene, Elfbreath is somewhere in a trailer on the coast.”

Posted on 2016-12-28 Tags: umismu

Dominique Dumont: New dzil command to install author dependencies as Debian packages

27 December, 2016 - 17:59

Hello

Dist::Zilla is a great tool to limit tedious tasks while working on Perl modules. For instance, dzil provides tools like dzil authordeps or dzil listdeps to list dependencies.
This list of Perl modules can then be installed with cpanm:

dzil authordeps --missing | cpanm
dzil listdeps --missing | cpanm

On a Debian system, one may prefer to install Perl modules using Debian packages. Installing build dependencies can be done with apt build-dep, but apt does not handle Dist::Zilla author dependencies.

The new authordebs Dist::Zilla sub-command was wriiten to fill this gap. When run in a directory containing the source of a Perl module that uses Dist::Zilla, you can run dzil installdebs to list the Debian packages required to run the dzil command. You can also run dzil installdebs -install to install author dependencies (using sudo under the hood).

See:

On Debian, authordebs is provided by libdist-zilla-app-command-authordebs-perl

All the best


Tagged: debian, dist-zilla, Perl

Joey Hess: multi-terminal applications

27 December, 2016 - 11:58

While learning about and configuring weechat this evening, I noticed a lot of complexity and unsatisfying tradeoffs related to its UI, its mouse support, and its built-in window system. Got to wondering what I'd do differently, if I wrote my own IRC client, to avoid those problems.

The first thing I realized is, it is not a good idea to think about writing your own IRC client. Danger will robinson..

So, let's generalize. This blog post is not about designing an IRC client, but about exploring simpler ways that something like an IRC client might handle its UI, and perhaps designing something general-purpose that could be used by someone else to build an IRC client, or be mashed up with an existing IRC client.

What any modern IRC client needs to do is display various channels to the user. Maybe more than one channel should be visible at a time in some kind of window, but often the user will have lots of available channel and only want to see a few of them at a time. So there needs to be an interface for picking which channel(s) to display, and if multiple windows are shown, for arranging the windows. Often that interface also indicates when there is activity on a channel. The most recent messages from the channel are displayed. There should be a way to scroll back to see messages that have already scrolled by. There needs to be an interface for sending a message to a channel. Finally, a list of users in the channel is often desired.

Modern IRC clients implement their own UI for channel display, windowing, channel selection, activity notification, scrollback, message entry, and user list. Even the IRC clients that run in a terminal include all of that. But how much of that do they need to implement, really?

Suppose the user has a tabbed window manager, that can display virtual terminals. The terminals can set their title, and can indicate when there is activity in the terminal. Then an IRC client could just open a bunch of terminals, one per channel. Let the window manager handle channel selection, windowing (naturally), and activity notification.

For scrollback, the IRC client can use the terminal's own scrollback buffer, so the terminal's regular scrollback interface can be used. This is slightly tricky; can't use the terminal's alternate display, and have to handle the UI for the message entry line at the bottom.

That's all the UI an IRC client needs (except for the user list), and most of that is already implemented in the window manager and virtual terminal. So that's an elegant way to make an IRC client without building much new UI at all.

But, unfortunately, most of us don't use tabbed window managers (or tabbed terminals). Such an IRC client, in a non-tabbed window manager, would be a many-windowed mess. Even in a tabbed window manager, it might be annoying to have so many windows for one program.

So we need fewer windows. Let's have one channel list window, and one channel display window. There could also be a user list window. And there could be a way to open additional, dedicated display windows for channels, but that's optional. All of these windows can be seperate virtual terminals.

A potential problem: When changing the displayed channel, it needs to output a significant number of messages for that channel, so that the scrollback buffer gets populated. With a large number of lines, that can be too slow to feel snappy. In some tests, scrolling 10 thousand lines was noticiably slow, but scrolling 1 thousand lines happens fast enough not to be noticiable.

(Terminals should really be faster at scrolling than this, but they're still writing scrollback to unlinked temp files.. sigh!)

An IRC client that uses multiple cooperating virtual terminals, needs a way to start up a new virtual terminal displaying the current channel. It could run something like this:

x-terminal-emulator -e the-irc-client --display-current-channel

That would communicate with the main process via a unix socket to find out what to display.

Or, more generally:

x-terminal-emulator -e connect-pty /dev/pts/9

connect-pty would simply connect a pty device to the terminal, relaying IO between them. The calling program would allocate the pty and do IO to it. This may be too general to be optimal though. For one thing, I think that most curses libraries have a singleton terminal baked into them, so it might be hard to have a single process control cursors on multiple pty's. And, it might be innefficient to feed that 1 thousand lines of scrollback through the pty and copy it to the terminal.

Less general than that, but still general enough to not involve writing an IRC client, would be a library that handled the irc-client-like channel display, with messages scrolling up the terminal (and into the scrollback buffer), a input area at the bottom, and perhaps a few other fixed regions for status bars and etc.

Oh, I already implemented that! In concurrent-output, over a year ago: a tiling region manager for the console

I wonder what other terminal applications could be simplified/improved by using multiple terminals? One that comes to mind is mutt, which has a folder list, a folder view, and an email view, that all are shoehorned, with some complexity, into a single terminal.

Gunnar Wolf: Giving up on the Drupal 8 debianization ☹

27 December, 2016 - 10:03

I am sad (but feel my duty) to inform the world that we will not be providing a Drupal 8 package in Debian.

I filed an Intent To Package bug a very long time ago, intending to ship it with Jessie; Drupal 8 was so deep a change that it took their community overly long to achieve and stabilize. Still, Drupal 8 was released over a year ago today.

I started working on debianizing the package shortly afterwards. There is also some online evidence – As my call for help sent through this same blog.

I have been too busy this last year. I let the packaging process lay dormant for too long, without even touching it for even half a year. Then, around September, I started working with the very nice guys of Indava, David and Enrique, and did very good advances. They clearly understood Debian's needs when it comes to full source inclusion (as D8 ships many minified Javascript libraries), attribution (as additionally to all those, many third-party PHP projects are bundled in the infamous vendor/ directory), and system-wide dependency management (as Drupal builds on some frameworks and libraries already available within Debian, chiefly Symfony, Doctrine, Twig... Even more, most of them appeared to work at the version levels we will be shipping, so all was dandy and for some weeks, I was quite optimistic on finishing the package on time and with the needed quality and testing. Yay!

But... Reality bites.

When I started testing my precious package... It broke in horrible ways. Uncomprehensible PHP errors (and I have to add here, I am a PHP newbie and am reluctant to learn better a language that strikes me as so inconsistent, so ugly), which we spent some time tackling... Of course, configuration changes are more than expected...

But, just as we Debianers learnt some important lessons after the way-too-long Sarge freeze (ten years ago, many among you won't remember those frustrating days), Drupal learnt as well. They changed their release strategy — Instead of describing it, those interested can read it at its source.

What it meant for me, sadly, is that this process does not align with the Debian maintenance model. This means: The Drupal API stays mostly-stable between 8.0.x, 8.1.x, 8.2.x, etc. However, Drupal will incorporate new versions of their bundled libraries. I understood the new versions would be incorporated at minor-level branches, but if I read correctly some of my errors, some dependencies change even at patch-level updates.

And... Well, if you update a PHP library, and the invoking PHP code (that is, Drupal) relies in this new version... Sadly, it makes it unmaintainable for Debian.

So, long story short: I have decided to drop Drupal8 support in Debian. Of course, if somebody wants to pick up the pieces, the Git repository is still there (although I do plan on erasing it in a couple of weeks, as it means useless waste of project resources otherwise), and you could probably even target unstable+backports in a weird way (as it's software that, given our constraints, shouldn't enter testing, at least during a freeze).

So... Sigh, a tear is dropped for every lost hour of work, and my depeest regrets to David and Enrique who put their work as well to make D8 happen in Debian. I will soon be closing the ITP and... Forgetting about the whole issue? ☹

Russ Allbery: Apologies for RSS feed duplicates

27 December, 2016 - 06:16

Sorry about the duplicates showing up in your feed or in e-mail, for those who saw them. I changed the canonical URLs of my journal entries to use https instead of http and forgot that would confuse a lot of RSS readers. Didn't mean to suddenly give you all a replay of the last 15 entries!

This should be a one-time change and not happen again. (Although I need to find or fix a good broken link checker and then track down the rest of the URLs in my web site that aren't using https.)

Francois Marier: Using iptables with NetworkManager

27 December, 2016 - 05:05

I used to rely on ifupdown to bring up my iptables firewall automatically using a config like this in /etc/network/interfaces:

allow-hotplug eth0
iface eth0 inet dhcp
    pre-up /sbin/iptables-restore /etc/network/iptables.up.rules
    pre-up /sbin/ip6tables-restore /etc/network/ip6tables.up.rules

allow-hotplug wlan0
iface wlan0 inet dhcp
    pre-up /sbin/iptables-restore /etc/network/iptables.up.rules
    pre-up /sbin/ip6tables-restore /etc/network/ip6tables.up.rules

but that doesn't seem to work very well in the brave new NetworkManager world.

What does work reliably is a "pre-up" NetworkManager script, something that gets run before a network interface is brought up. However, despite what the documentation says, a dispatcher script in /etc/NetworkManager/dispatched.d/ won't work on my Debian and Ubuntu machines. Instead, I had to create a new iptables script in /etc/NetworkManager/dispatcher.d/pre-up.d/:

#!/bin/sh

LOGFILE=/var/log/iptables.log

if [ "$1" = lo ]; then
    echo "$0: ignoring $1 for \`$2'" >> $LOGFILE
    exit 0
fi

case "$2" in
    pre-up)
        echo "$0: restoring iptables rules for $1" >> $LOGFILE
        /sbin/iptables-restore /etc/network/iptables.up.rules >> $LOGFILE 2>&1
        /sbin/ip6tables-restore /etc/network/ip6tables.up.rules >> $LOGFILE 2>&1
        ;;
    *)
        echo "$0: nothing to do with $1 for \`$2'" >> $LOGFILE
        ;;
esac

exit 0

and then make that script executable:

chmod a+x /etc/NetworkManager/dispatcher.d/pre-up.d/iptables

With this in place, I can put my iptables rules in the usual place (/etc/network/iptables.up.rules and /etc/network/ip6tables.up.rules) and use the handy iptables-apply and ip6tables-apply commands to test any changes to my firewall rules.

Russ Allbery: Review: The Kingdom of Gods

27 December, 2016 - 04:21

Review: The Kingdom of Gods, by N.K. Jemisin

Series: Inheritance #3 Publisher: Orbit Copyright: 2011 Printing: April 2012 ISBN: 0-316-04394-X Format: Mass market Pages: 567

The Kingdom of Gods is the third and final book of the Inheritance trilogy and rests very heavily on the events of The Hundred Thousand Kingdoms and The Broken Kingdoms. I think it's the best book of the trilogy as well, but this isn't the place to start. The build-up from the previous books is very important to this story.

The first book of this series followed Yeine in her introduction to the highly political, abusive, and exploitative world of the Arameri, and her deeper introduction to the complex theology and mythology of Jemisin's constructed world. The second involved fewer theological fireworks and more day-to-day decisions, but it followed the implications of the first book's climax and revealed another important lurking weapon from the past. The Kingdom of Gods returns to a theological focus, this time putting Sieh front and center, and is once again concerned with the fate of the entire world, or even reality itself.

Sieh played a significant role in the first book, but only seen from Yeine's perspective. He's the trickster god, the god of childhood, of play and whim and unfairness and practical jokes, of all the chaos and lack of impulse control and impudence of childhood. The Kingdom of Gods opens with him encountering two Arameri children in the abandoned areas under Sky and making an unlikely and impulsive pledge of friendship. One that leads to an unexplained catastrophe, a long blackout, and possibly the end of his existence, since Sieh starts aging. And growing up directly undermines his power.

One of the two children turns out to be the heir of the haughty, devious, and deeply racist Arameri, whose position atop the hierarchy of the world has been weakened by earlier events but not shaken entirely. Her relationship with Sieh is much more fraught and complex when both of them are teenagers and Sieh is struggling badly to remain true to himself. But what drives the plot is a deadly new form of magic that is targeting the Arameri family and threatening to bring back world-wide war.

This is my favorite book of the trilogy, not so much because it brings a relatively satisfying conclusion (The Hundred Thousand Kingdoms wasn't bad at that either), but because for once I like all of the main characters. Yeine and Nahadoth are hit and miss (the second two books of the trilogy make it clear that Nahadoth can be a real asshole), and as mentioned in the review of The Broken Kingdoms, I found Shiny exasperating. But Sieh is fun, even when he's being obnoxious, and both of the kids he befriends are complex and multifaceted. Shahar, with her hard and complex relationship with her mother, is probably my favorite character in the book, but her brother certainly has his moments.

I did not like Sieh's maturation process. There are parts of this story that are squirm-inducing, and not in a good way (at least for me). And he does tend to get whiny in places. But he knows everyone in Jemisin's complex mythology, he has a great first-person narrative voice, and there are some very fun moments of interaction with his sibling gods. It says something that I really enjoyed this story even though books about slow, ongoing illness and diminution are rather far from my favorites (and Sieh's aging falls into that category).

While there are some beautiful set-pieces here once the shit starts to hit the fan in earnest, the concluding fireworks didn't really work for me. The final confrontation was too abstracted, too indescribable, and too full of ancillary carnage to be the ending I was looking for. (Perhaps because of what I've been playing recently, I keep thinking of it as one of those chaotic, floating, dream-like cut-scene disasters in a Final Fantasy game that's trying to hint at indescribable magic.) But the denouement made me happy, and it fit the characters. And don't miss the glossary at the end of the book that Sieh has scribbled all over.

This book includes, as a bonus, a short story:

"Not the End": This is the ending that The Broken Kingdoms actually needed. It (plus some key bits in the rest of The Kingdom of Gods) made me feel much better about the end of that book, and added a much-needed light note to the rather heavy bits at the end of this book. And I do love Oree. It's very short, and it's not in any way a standalone story (more of a belated epilogue to the previous novel), but that's all that was needed. (8)

Rating: 8 out of 10

Lucas Nussbaum: The Linux 2.5, Ruby 1.9 and Python 3 release management anti-pattern

26 December, 2016 - 20:32

There’s a pattern that comes up from time to time in the release management of free software projects.

To allow for big, disruptive changes, a new development branch is created. Most of the developers’ focus moves to the development branch. However at the same time, the users’ focus stays on the stable branch.

As a result:

  • The development branch lacks user testing, and tends to make slower progress towards stabilization.
  •  Since users continue to use the stable branch, it is tempting for developers to spend time backporting new features to the stable branch instead of improving the development branch to get it stable.

This situation can grow up to a quasi-deadlock, with people questioning whether it was a good idea to do such a massive fork in the first place, and if it is a good idea to even spend time switching to the new branch.

To make things more unclear, the development branch is often declared “stable” by its developers, before most of the libraries or applications have been ported to it.

This has happened at least three times.

First, in the Linux 2.4 / 2.5 era. Wikipedia describes the situation like this:

Before the 2.6 series, there was a stable branch (2.4) where only relatively minor and safe changes were merged, and an unstable branch (2.5), where bigger changes and cleanups were allowed. Both of these branches had been maintained by the same set of people, led by Torvalds. This meant that users would always have a well-tested 2.4 version with the latest security and bug fixes to use, though they would have to wait for the features which went into the 2.5 branch. The downside of this was that the “stable” kernel ended up so far behind that it no longer supported recent hardware and lacked needed features. In the late 2.5 kernel series, some maintainers elected to try backporting of their changes to the stable kernel series, which resulted in bugs being introduced into the 2.4 kernel series. The 2.5 branch was then eventually declared stable and renamed to 2.6. But instead of opening an unstable 2.7 branch, the kernel developers decided to continue putting major changes into the 2.6 branch, which would then be released at a pace faster than 2.4.x but slower than 2.5.x. This had the desirable effect of making new features more quickly available and getting more testing of the new code, which was added in smaller batches and easier to test.

Then, in the Ruby community. In 2007, Ruby 1.8.6 was the stable version of Ruby. Ruby 1.9.0 was released on 2007-12-26, without being declared stable, as a snapshot from Ruby’s trunk branch, and most of the development’s attention moved to 1.9.x. On 2009-01-31, Ruby 1.9.1 was the first release of the 1.9 branch to be declared stable. But at the same time, the disruptive changes introduced in Ruby 1.9 made users stay with Ruby 1.8, as many libraries (gems) remained incompatible with Ruby 1.9.x. Debian provided packages for both branches of Ruby in Squeeze (2011) but only changed the default to 1.9 in 2012 (in a stable release with Wheezy – 2013).

Finally, in the Python community. Similarly to what happened with Ruby 1.9, Python 3.0 was released in December 2008. Releases from the 3.x branch have been shipped in Debian Squeeze (3.1), Wheezy (3.2), Jessie (3.4). But the ‘python’ command still points to 2.7 (I don’t think that there are plans to make it point to 3.x, making python 3.x essentially a different language), and there are talks about really getting rid of Python 2.7 in Buster (Stretch+1, Jessie+2).

In retrospect, and looking at what those projects have been doing in recent years, it is probably a better idea to break early, break often, and fix a constant stream of breakages, on a regular basis, even if that means temporarily exposing breakage to users, and spending more time seeking strategies to limit the damage caused by introducing breakage. What also changed since the time those branches were introduced is the increased popularity of automated testing and continuous integration, which makes it easier to measure breakage caused by disruptive changes. Distributions are in a good position to help here, by being able to provide early feedback to upstream projects about potentially disruptive changes. And distributions also have good motivations to help here, because it is usually not a great solution to ship two incompatible branches of the same project.

(I wonder if there are other occurrences of the same pattern?)

Steve Kemp: I finally made something worthwhile.

26 December, 2016 - 14:45

So for once I made something useful.

Oiva Adam Kemp.

Happy Christmas, if you believe in that kind of thing.

Steinar H. Gunderson: Cracking a DataEase password

26 December, 2016 - 04:21

I recently needed to get access to a DataEase database; the person I helped was the legitimate owner of the data, but had forgotten the password, as the database was largely from 1996. There are various companies around the world that seem to do this, or something similar (like give you an API), for a usually unspecified fee; they all have very 90s homepages and in general seem like they have gone out of business a long time ago. And I wasn't prepared to wait.

For those of you who don't know DataEase, it's a sort-of relational database for DOS that had its heyday in the late 80s and early 90s (being sort of the cheap cousin of dBase); this is before SQL gained traction as the standard query language, before real multiuser database access, and before variable-width field storage.

It is also before reasonable encryption. Let's see what we can do.

DataEase has a system where tables are mapped through the data dictionary, which is a table on its own. (Sidenote: MySQL pre-8.0 still does not have this.) This is the file RDRRTAAA.DBM; I don't really know what RDRR stands for, but T is the “database letter” in case you wanted more than one database in the same directory, and AAA, AAB, AAC etc. is a counter so that a table grows to be too big for one file. (There's also .DBA files for structure of non-system tables, and then some extra stuff for indexes.)

DBM files are pretty much the classical, fixed-length 80s-style database files; each row has some flags (I believe these are for e.g. “row is deleted”) and then just the rows in fixed format right after each other. For instance, here's one I created as part of testing (just the first few lines of the hexdump are shown):

00000000: 0e 00 01 74 65 73 74 62 61 73 65 00 00 00 00 00  ...testbase.....
00000010: 00 00 00 00 00 00 00 73 46 cc 29 37 00 09 00 00  .......sF.)7....
00000020: 00 00 00 00 00 43 3a 52 44 52 52 54 41 41 41 2e  .....C:RDRRTAAA.
00000030: 44 42 4d 00 00 01 00 0e 00 52 45 50 4f 52 54 20  DBM......REPORT 
00000040: 44 49 52 45 43 54 4f 52 59 00 00 00 00 00 1c bd  DIRECTORY.......
00000050: d4 1a 27 00 00 00 00 00 00 00 00 00 43 3a 52 45  ..'.........C:RE
00000060: 50 4f 54 41 41 41 2e 44 42 4d 00 00 01 00 0e 00  POTAAA.DBM......
00000070: 52 65 6c 61 74 69 6f 6e 73 68 69 70 73 00 00 00  Relationships...

Even without going in-depth, we can see the structure here; there's “testbase” which maps to C:RDRRTAA.DBM (the RDRR itself), there's a table called “REPORT DIRECTORY” that maps to C:REPOTAAA.DBM, and then more stuff after that, and so on.

However, other tables are not so easily read, because you can ask DataEase to encrypt a table. Let's look at such an encrypted table, like the “Users” table (containing usernames, passwords—not password hashes—and some extra information like access level), which is always encrypted:

00000000: 0c 01 9f ed 94 f7 ed 34 ba 88 9f 78 21 92 7b 34  .......4...x!.{4
00000010: ba 88 0f d9 94 05 1e 34 ba 88 a0 78 21 92 7b 34  .......4...x!.{4
00000020: e2 88 9f 78 21 92 7b 34 ba 88 9f 78 21 92 7b 34  ...x!.{4...x!.{4
00000030: ba 88 9f 78 21 92 7b 34 ba 88 9f 78 21 92 7b     ...x!.{4...x!.{

Clearly, this isn't very good encryption; it uses a very short, repetitive key of eight bytes (64 bits). (The data is mostly zero padding, which makes it much easier to spot this.) In fact, in actual data tables, only five of these bytes are set to a non-zero value, which means we have a 40-bit key; export controls?

My first assumption here was of course XOR, but through some experimentation, it turned out what you need is actually 8-bit subtraction (with wraparound). The key used is derived from both a database key and a per-table key, both stored in the RDRR; again, if you disassemble, I'm sure you can find the key derivation function, but that's annoying, too. Note, by the way, that this precludes making an attack by just copying tables between databases, since the database key is different.

So let's do a plaintext attack. If you assume the plaintext of the bottom row is all padding, that's your key and here's what you end up with:

00000000: 52 79 00 75 73 65 72 00 00 00 00 00 00 00 00 00  Ry.user.........
00000010: 00 00 70 61 73 73 a3 00 00 00 01 00 00 00 00 00  ..pass..........
00000020: 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  (...............
00000030: 00 00 00 00 00 00 00 00                          ........ 

Not bad, eh? Actually the first byte of the key here is wrong as far as I know, but it didn't interfere with the fields, so we have what we need to log in. (At that point, we've won, because DataEase will helpfully decrypt everything transparent for us.)

However, there's a twist; if the password is longer than four characters, the entire decryption of the Users table changes. Of course, we could run our plaintext attack against every data table and pick out the information by decoding the structure, but again; annoying. So let's see what it looks like if we choose “passs” instead:

00000000: 0e 01 9f 7a ae 9e 21 f5 08 63 07 6d a3 a1 17 5d  ...z..!..c.m...]
00000010: 70 cb df 36 7e 7c 91 c5 d8 33 d8 3d 73 71 e7 2d  p..6~|...3.=sq.-
00000020: 7b 9b 3f a5 db d9 4f 95 a8 03 a7 0d 43 41 b7 fd  {.?...O.....CA..
00000030: 10 6b 0f 75 ab a9 1f 65 78 d3 77 dd 13 11 87     .k.u...ex.w....

Distinctly more confusing. At this point, of course, we know at which byte positions the username and password start, so if we wanted to, we could just try setting the start byte of the password to every possible byte in turn until we hit 0x00 (DataEase truncates fields at the first zero byte), which would allow us to get in with an empty password. However, I didn't know the username either, and trying two bytes would mean 65536 tries, and I wasn't up for automating macros through DOSBox. So an active attack wasn't too tempting.

However, we can look at the last hex byte (where we know the plaintext is 0); it goes 0x5d, 0x2d, 0xfd... and some other bytes go 0x08, 0xd8, 0xa8, 0x78, and so on. So clearly there's an obfuscation here where we have a per-line offset that decreases with 0x30 per line. (Actually, the increase/decrease per line seems to be derived from the key somehow, too.) If we remove that, we end up with:

00000000: 0e 01 9f 7a ae 9e 21 f5 08 63 07 6d a3 a1 17 5d  ...z..!..c.m...]
00000010: a0 fb 0f 66 ae ac c1 f5 08 63 08 6d a3 a1 17 5d  ...f.....c.m...]
00000020: db fb 9f 05 3b 39 af f5 08 63 07 6d a3 a1 17 5d  ....;9...c.m...]
00000030: a0 fb 9f 05 3b 39 af f5 08 63 07 6d a3 a1 17     ....;9...c.m...

Well, OK, this wasn't much more complicated; our fixed key is now 16 bytes long instead of 8 bytes long, but apart from that, we can do exactly the same plaintext attack. (Also, it seems to change per-record now, but we don't see it here, since we've only added one user.) Again, assume the last line is supposed to be all 0x00 and thus use that as a key (plus the last byte from the previous line), and we get:

00000000: 6e 06 00 75 73 65 72 00 00 00 00 00 00 00 00 00  n..user.........
00000010: 00 00 70 61 73 73 12 00 00 00 01 00 00 00 00 00  ..pass..........
00000020: 3b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ;...............
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     ...............

Well, OK, it wasn't perfect; we got “pass\x12” instead of “passs”, so we messed up somehow. I don't know exactly why the fifth character gets messed up like this; actually, it cost me half an hour of trying because the password looked very real but the database wouldn't let me in, but eventually, we just guessed at what the missing letter was supposed to be.

So there you have it; practical small-scale cryptanalysis of DOS-era homegrown encryption. Nothing advanced, but the user was happy about getting the data back after a few hours of work. :-)

Russ Allbery: krb5-strength 3.1

26 December, 2016 - 04:18

krb5-strength provides password strength checking plugins and programs for MIT Kerberos and Heimdal, and a password history implementation for Heimdal. This is the first new upstream release since I left Stanford, since I don't personally use the package any more. But it's easy enough to maintain, and it was overdue for merging some contributed patches.

This release adds a new configuration directive, cracklib_maxlen, which can be used to not run longer passwords through CrackLib (whose concepts of password strength were not designed for longer passwords and which can spuriously reject passphrases). It also allows require_classes to require a certain number of character classes in a password, not just specific classes. There are also a variety of portability and cleanup fixes. Thanks to Jorj Bauer, Toby Blake, and Bernt Jernberg for their contributions.

I've merged into the embedded CrackLib all the relevant security patches that have come out, although none of them turned out to be relevant for this package due to how CrackLib was called. I also applied a patch from Mark Sirota to fix mkdict and packer to force C locale, which keeps them from creating corrupted dictionaries.

Finally, configuration instructions for the plugin are now installed as a new krb5-strength man page, and configuration instructions are included in the heimdal-history and heimdal-strength man pages, instead of just being in the README file. This makes them more accessible after the package is installed.

You can get the latest version from the krb5-strength distribution page.

Russ Allbery: krb5-strength 3.1

26 December, 2016 - 04:18

krb5-strength provides password strength checking plugins and programs for MIT Kerberos and Heimdal, and a password history implementation for Heimdal. This is the first new upstream release since I left Stanford, since I don't personally use the package any more. But it's easy enough to maintain, and it was overdue for merging some contributed patches.

This release adds a new configuration directive, cracklib_maxlen, which can be used to not run longer passwords through CrackLib (whose concepts of password strength were not designed for longer passwords and which can spuriously reject passphrases). It also allows require_classes to require a certain number of character classes in a password, not just specific classes. There are also a variety of portability and cleanup fixes. Thanks to Jorj Bauer, Toby Blake, and Bernt Jernberg for their contributions.

I've merged into the embedded CrackLib all the relevant security patches that have come out, although none of them turned out to be relevant for this package due to how CrackLib was called. I also applied a patch from Mark Sirota to fix mkdict and packer to force C locale, which keeps them from creating corrupted dictionaries.

Finally, configuration instructions for the plugin are now installed as a new krb5-strength man page, and configuration instructions are included in the heimdal-history and heimdal-strength man pages, instead of just being in the README file. This makes them more accessible after the package is installed.

You can get the latest version from the krb5-strength distribution page.

Gregor Herrmann: RC bugs 2016/46-51

26 December, 2016 - 02:05

it's amazing how many new bugs appear; luckily in the Debian Perl Group we're not too bad at fixing them as well. – here's the list of my contributions over the last weeks:

  • #828387 – src:libcrypt-openssl-rsa-perl: "libcrypt-openssl-rsa-perl: FTBFS with openssl 1.1.0"
    add patch from Sebastian Andrzej Siewior (pkg-perl)
  • #839322 – src:libmoops-perl: "libmoops-perl: FTBFS: build-dependency not installable: libkavorka-perl"
    close, as dependency is fixed (pkg-perl)
  • #840305 – src:libatteanx-store-memorytriplestore-perl: "libatteanx-store-memorytriplestore-perl: depends on unavailable AtteanX::RDFQueryTranslator"
    investigate (pkg-perl)
  • #842753 – libnet-sip-perl: "FTBFS: test failures"
    import new upstream release (pkg-perl)
  • #844141 – src:libsys-cpuaffinity-perl: "libsys-cpuaffinity-perl: FTBFS: Failed test 'bind to all processors successful 18446744073709551615 == 18446744073709551616-1'"
    import new upstream release, later reopen & downgrade (pkg-perl)
  • #844538 – src:libdbd-mysql-perl: "libdbd-mysql-perl: FTBFS on some architectures"
    import new upstream release (pkg-perl)
  • #844950 – src:libdatetime-format-duration-perl: "libdatetime-format-duration-perl must build-depend on libparams-validate-perl"
    add missing (build) dependency, upload to DELAYED/5
  • #846059 – src:libmath-bigint-gmp-perl: "libmath-bigint-gmp-perl: FTBFS: Failed 1/12 test programs (t/bigintpm.t)"
    import new upstream release (pkg-perl)
  • #846721 – src:libaudio-mpd-perl: "libaudio-mpd-perl: FTBFS: Test failures"
    skip a brittle test (pkg-perl)
  • #846731 – src:libbio-scf-perl: "libbio-scf-perl: FTBFS: Test failures"
    add patch from ntyni (pkg-perl)
  • #847176 – libbusiness-ismn-perl: "libbusiness-ismn-perl: FTBFS: t/prereq.t failure"
    import new upstream release (pkg-perl)
  • #847188 – libtest-data-perl: "libtest-data-perl: FTBFS: t/prereq.t failure"
    import new upstream release (pkg-perl)
  • #847189 – libbusiness-issn-perl: "libbusiness-issn-perl: FTBFS: t/prereq.t failure"
    import new upstream release (pkg-perl)
  • #847397 – src:libimager-perl: "libimager-perl FTBFS on mips/mipsel: Failed 10/66 test programs"
    build with -O0 on mips/mipsel (pkg-perl)
  • #848060 – src:libx11-protocol-other-perl: "libx11-protocol-other-perl: FTBFS randomly (failing tests)"
    disable fragile test (pkg-perl)
  • #848266 – src:libparanoid-perl: "libparanoid-perl: FTBFS: tests timeout"
    skip a test (pkg-perl)
  • #848346 – libio-socket-ssl-perl: "libio-socket-ssl-perl: default certificate path lost with libssl1.1"
    import new upstream release (pkg-perl)
  • #848427 – libanyevent-perl: "libanyevent-perl: FTBFS with openssl 1.1: t/80_ssltest.t failure"
    apply upstream patch (pkg-perl)

Russ Allbery: DocKnot 1.01

26 December, 2016 - 01:43

This is the second release of my new documentation generation system for my packages. It's still probably not of much interest to anyone other than me, particularly since the metadata format is still rapidly evolving so I've not documented it yet. But the templates are getting fleshed out and it's generating more and more of my package documentation, which will make releases much easier.

This release adds generation of build and test instructions for my packages from templates and metadata, with some support for adding a bit of custom wording. It also offers a few new options for expanding license notices, and for annotating packages with additional bootstrap requirements.

You can get the latest version from the DocKnot distribution page.

Russ Allbery: DocKnot 1.01

26 December, 2016 - 01:43

This is the second release of my new documentation generation system for my packages. It's still probably not of much interest to anyone other than me, particularly since the metadata format is still rapidly evolving so I've not documented it yet. But the templates are getting fleshed out and it's generating more and more of my package documentation, which will make releases much easier.

This release adds generation of build and test instructions for my packages from templates and metadata, with some support for adding a bit of custom wording. It also offers a few new options for expanding license notices, and for annotating packages with additional bootstrap requirements.

You can get the latest version from the DocKnot distribution page.

Enrico Zini: "Intervallo RAI" generator

25 December, 2016 - 19:38

During holiday idling, I made a thing to generate picture slideshows similar to RAI's iconic "Intervallo"

You can get it at https://github.com/spanezz/intervallo

Usage:
$ intervallo --help
usage: intervallo [-h] [--font file.ttf] [--audio file.mp3] [--duration sec]
                  imgfile [imgfile ...]

Create an Intervallo RAI out of a collection of images.

positional arguments:
  imgfile           input image files

optional arguments:
  -h, --help        show this help message and exit
  --font file.ttf   Font to use for subtitles
  --audio file.mp3  Audio track
  --duration sec    Time for each image in seconds

For example:

./intervallo --font DejaVuSerif.ttf --audio Paradisi-Toccata.mp3 *.jpg

The images are captioned with their file name, without extension. You may want to rename the image files to have nice descriptive names.

For some audio to use, you can try https://archive.org/details/IntervalloRai-Paradisi

Example

https://www.youtube.com/watch?v=ZCERwjTB4ck

Russ Allbery: Review: A Man Called Ove

25 December, 2016 - 09:58

Review: A Man Called Ove, by Fredrik Backman

Translator: Henning Koch Publisher: Washington Square Copyright: 2012, 2014 Printing: May 2015 ISBN: 1-4767-3802-5 Format: Trade paperback Pages: 337

Ove is 59 years old and drives a Saab. He's grumpy, often taciturn, very particular in how things should be done, and extremely judgmental about how other people do them. He is the sort of person who regularly rants about how poorly things are done these days and how much better they used to be. Ove does not like change.

A Man Called Ove opens with him terrorizing the employees of an Apple Store, trying to buy a computer, but this incident is actually foreshadowing, and will only make sense at the very end of the book. The story actually begins in the second chapter, with Ove making his morning rounds of the neighborhood in which he lives, discovering an out-of-place bicycle and a mangy cat, and then starting to put a hook in his ceiling. But just as he's getting started, he's interrupted by new neighbors, who are incapable of backing up a trailer properly without scraping it against his house. Not that motor vehicles are allowed in the area anyway.

That inauspicious beginning changes Ove's life, mostly through the sheer persistence of other people's disasters. It's not obvious at first that it will, and at the start A Man Called Ove could be a funny collection of stories about a curmudgeon. But as Backman shows more of Ove's life and tells more of his background and situation, it becomes something so much more, something satisfying and heart-breaking and deeply human.

I've been struggling to review this book because I find it hard to capture what makes it so wonderful. Making that even harder, several key plot elements are introduced gradually in the story in ways that add a lot to the rhythm of the plot, and I don't want to spoil them. I think the closest I can get in a spoiler-free review is that A Man Called Ove is about empathy. It's about human connection, even when people seem unlikable, unreachable, or angrily off-putting. And it's a book about seeing the best inside other people, and about finding ways to be persistently oneself while still changing enough to find new connections, and about recognizing those moments when someone is showing you their best without getting caught up on the surface presentation.

The man Ove is the center of this story, the subject of tight third person perspective for nearly all of the book. He's 59 when the story opens, but by the end of the book, mostly through flashback chapters, the reader knows his childhood and early adulthood and much of the story of his marriage. At first, he seems to be an obnoxious, surly, angry curmudgeon, the sort of old man who yells at clouds. But the joy of this book is how the reader's perception changes, how one gains sympathy, and then respect, first for Ove's unshakable inner sense of morality that he got from his father and then for his rule-based approach to how the world should work. One never entirely agrees with him, but Backman demystifies and explains Ove's thought process and ties it into a different generation and a different way of interacting with work (although Ove was still uncommon even in his youth, just not as unique).

As I write this review, news and opinion in the United States are very focused on the plight of the white working class and how that does or does not explain recent election results. Backman is Swedish (I read this book in translation), so it's not coming from US culture and the cultural fault lines are not quite the same. But I think this book says something deeply valuable and fascinating about the working-class culture of Ove's youth, something that's much less about specific politics and much more about how it feels to make things with one's hands, to build or rebuild one's own house, or to work for thirty years at the same job and not be interested in a promotion to management. Backman does a truly spectacular job conveying the sense of angry frustration at the changes in work and life, the difficulty communicating one's internal feelings meaningfully, and the quiet joy of finding those places in life where one can do things properly.

Ove is, of course, not the only character in this book, and every character here is a delight in their own idiosyncratic ways. The main story arc involves the various people in his neighborhood, particularly his new next-door neighbors: a pregnant Iranian woman and her very laid-back husband who is incapable of doing things around the house but keeps trying. I think Parvaneh, the woman, is my favorite character of the story except for Ove, and it's fitting that she's the first to work out the broad outlines of what's happening in Ove's life and the tricky path to effectively helping him. In a way, she's Ove's opposite: fiery, mercurial, talkative, and meddling. But she sees things in Ove that no one else seems to notice. (And the scene between her and Ove when she's learning to drive is a thing of beauty.)

This is a book that could have been extremely sad, and yet isn't. It's a book about somber, depressing topics that somehow manages to be delightfully funny. And it's about a curmudgeon who persistently fails to have any sort of stereotyped heart of gold, but is nonetheless one of the most satisfying, fascinating, ethical, and good-willed characters I've ever read about. It manages to treat a collection of very different characters with individualized deep empathy and appreciation, while never pushing them all into the same mold. And the ending is wonderful.

I rarely read slice of life stories, but this one is worth making an exception for. It's one of the best books I've ever read. Highly, highly recommended.

Rating: 10 out of 10

Russ Allbery: Review: A Man Called Ove

25 December, 2016 - 09:58

Review: A Man Called Ove, by Fredrik Backman

Translator: Henning Koch Publisher: Washington Square Copyright: 2012, 2014 Printing: May 2015 ISBN: 1-4767-3802-5 Format: Trade paperback Pages: 337

Ove is 59 years old and drives a Saab. He's grumpy, often taciturn, very particular in how things should be done, and extremely judgmental about how other people do them. He is the sort of person who regularly rants about how poorly things are done these days and how much better they used to be. Ove does not like change.

A Man Called Ove opens with him terrorizing the employees of an Apple Store, trying to buy a computer, but this incident is actually foreshadowing, and will only make sense at the very end of the book. The story actually begins in the second chapter, with Ove making his morning rounds of the neighborhood in which he lives, discovering an out-of-place bicycle and a mangy cat, and then starting to put a hook in his ceiling. But just as he's getting started, he's interrupted by new neighbors, who are incapable of backing up a trailer properly without scraping it against his house. Not that motor vehicles are allowed in the area anyway.

That inauspicious beginning changes Ove's life, mostly through the sheer persistence of other people's disasters. It's not obvious at first that it will, and at the start A Man Called Ove could be a funny collection of stories about a curmudgeon. But as Backman shows more of Ove's life and tells more of his background and situation, it becomes something so much more, something satisfying and heart-breaking and deeply human.

I've been struggling to review this book because I find it hard to capture what makes it so wonderful. Making that even harder, several key plot elements are introduced gradually in the story in ways that add a lot to the rhythm of the plot, and I don't want to spoil them. I think the closest I can get in a spoiler-free review is that A Man Called Ove is about empathy. It's about human connection, even when people seem unlikable, unreachable, or angrily off-putting. And it's a book about seeing the best inside other people, and about finding ways to be persistently oneself while still changing enough to find new connections, and about recognizing those moments when someone is showing you their best without getting caught up on the surface presentation.

The man Ove is the center of this story, the subject of tight third person perspective for nearly all of the book. He's 59 when the story opens, but by the end of the book, mostly through flashback chapters, the reader knows his childhood and early adulthood and much of the story of his marriage. At first, he seems to be an obnoxious, surly, angry curmudgeon, the sort of old man who yells at clouds. But the joy of this book is how the reader's perception changes, how one gains sympathy, and then respect, first for Ove's unshakable inner sense of morality that he got from his father and then for his rule-based approach to how the world should work. One never entirely agrees with him, but Backman demystifies and explains Ove's thought process and ties it into a different generation and a different way of interacting with work (although Ove was still uncommon even in his youth, just not as unique).

As I write this review, news and opinion in the United States are very focused on the plight of the white working class and how that does or does not explain recent election results. Backman is Swedish (I read this book in translation), so it's not coming from US culture and the cultural fault lines are not quite the same. But I think this book says something deeply valuable and fascinating about the working-class culture of Ove's youth, something that's much less about specific politics and much more about how it feels to make things with one's hands, to build or rebuild one's own house, or to work for thirty years at the same job and not be interested in a promotion to management. Backman does a truly spectacular job conveying the sense of angry frustration at the changes in work and life, the difficulty communicating one's internal feelings meaningfully, and the quiet joy of finding those places in life where one can do things properly.

Ove is, of course, not the only character in this book, and every character here is a delight in their own idiosyncratic ways. The main story arc involves the various people in his neighborhood, particularly his new next-door neighbors: a pregnant Iranian woman and her very laid-back husband who is incapable of doing things around the house but keeps trying. I think Parvaneh, the woman, is my favorite character of the story except for Ove, and it's fitting that she's the first to work out the broad outlines of what's happening in Ove's life and the tricky path to effectively helping him. In a way, she's Ove's opposite: fiery, mercurial, talkative, and meddling. But she sees things in Ove that no one else seems to notice. (And the scene between her and Ove when she's learning to drive is a thing of beauty.)

This is a book that could have been extremely sad, and yet isn't. It's a book about somber, depressing topics that somehow manages to be delightfully funny. And it's about a curmudgeon who persistently fails to have any sort of stereotyped heart of gold, but is nonetheless one of the most satisfying, fascinating, ethical, and good-willed characters I've ever read about. It manages to treat a collection of very different characters with individualized deep empathy and appreciation, while never pushing them all into the same mold. And the ending is wonderful.

I rarely read slice of life stories, but this one is worth making an exception for. It's one of the best books I've ever read. Highly, highly recommended.

Rating: 10 out of 10

Pages

Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้