Should use /dev/urandom instead of /dev/random

Here's a patch

This looks fine for an SRU. Please provide a TEST CASE: in the description. Is this already fixed in a later version? If it affects Hardy, we should fix it there, too.

Assigining to me for sponsoring for dapper.

The problem was fixed in 2.1.22-0~pre04 in Debian, and all versions after Dapper are okay.

Thanks, closing main task then.

Sponsored (with some minor changelog tweaks) and accepted into dapper-proposed. Please test the actual .debs from -proposed and let us know whether they work for you.

If possible, provide a TEST CASE: which our verification team can use to verify the updated packages.

I can confirm that the original dapper libsasl2 library, 2.1.19.dfsg1-0.1ubuntu2, used /dev/random, and that the proposed update to libsasl2, 2.1.19.dfsg1-0.1ubuntu3, uses /dev/urandom instead. I confirmed this in two ways: first, by grepping the output of strings on each library as describedin the TESTCASE section, and second, by running the sasltestuite program provided by the related sasl2-bin package (after setting up the sasldb in the way the testsuite wants) under strace and verifying that the updated library does indeed open /dev/urandom.

Unfortunately, the sasltestsuite program in dapper segfaults early on its run in both the original and -proposed versions at the same location (and thus, is not a regression due to the -proposed update), limiting it's usefulness for catching regressions. However, I downloaded the source to the package, recompiled the testsuite program against the system version of libsasl after commenting out the failing testcase, and ran it against both versions (with -a for all tests, otherwise it picks 25 of the corruption ones at random). Both testruns succeeded; the only difference in the output of the testruns was in the corruption tests, where different cases detected corruption but completed successfully. Based on this, I don't believe there to be any regressions from the libsasl2 update in dapper-proposed.

(In fact, running the teststuite against the original library took much longer than against the updated library precisely because /dev/random would block when the kernel's entropy pool was used up.)

Copied to dapper-updates, thank you!