< July 2010 | Russ Allbery > Eagle's Path | September 2010 > |
This release fixes an embarassing bug in option parsing in wa_keyring
introduced in 3.7.0 that caused the utility to become basically unusable.
It also fixes the option parsing so that negative values (for gc
for example) don't require --
to disambiguate from options, at
least on platforms that support +
in the getopt() string.
Also fixed is an uninitialized variable in wa_keyring that caused wa_keyring to randomly default to verbose mode, portability to old MIT Kerberos and Heimdal libraries without krb5_get_init_creds_opt_free, and build problems with the Perl module on platforms where shared libraries need to be linked with explicitly.
This release also returns a user rejected error from the WebKDC if the account is disabled or expired in Kerberos, rather than a generic Kerberos error, which will allow WebLogin to return a better error message.
You can get the latest version from the official WebAuth distribution page or from my unofficial distribution page.
This supporting script for using cowbuilder with git-buildpackage came up at DebConf, which also meant more attention on the bug requesting that it be included in git-buildpackage. I've therefore done a few new releases over the last few days including additional features that the example script in git-buildpackage supported that my version of the script hadn't.
Changes since 1.10 include adding support for update, create, and login options, which call cowbuilder with the corresponding flag instead of doing a build, and support for taking the distribution on which to act from the name of the script in case anyone wants to create symlinks to the script as supported by the git-buildpackage example script. I also switched the license to an MIT license instead of the same terms as Perl (which didn't make much sense, since it's not written in Perl).
You can get the latest version of the script from my scripts page, and will also be included in the git-buildpackage package directly down the road.
Thank you very much to Guido Günther for his discussion, willingness to include the script, and bug fixes.
After reading Do It Tomorrow, I was inspired to try some of the techniques that Mark Forster proposes. I commented in the review about the closed list system, which I'm still mostly using with some success. But I also started playing with the initiative slot. In his system, the initiative slot is first thing in the morning each (eligible) morning, which is used for a special project that you want to make forward progress on.
There are several criteria for choosing a task for the initiative slot. One of the strongest is dealing with a backlog. Since I'd been feeling guilty about the backlog of Debian Policy work that had built up, that seemed like a good choice. I picked up Debian Policy backlog clearing as my initiative starting at the beginning of June after the AFS and Kerberos Best Practices Workshop, with a goal of getting the open bug count below 100.
This has been very instructive, both from a time management perspective and from a Debian Policy perspective. Here are a few things that I learned on the Policy side:
The open bugs against Debian Policy by and large represent real work that we should tackle in the Policy document. They're not all fully thought-out proposals, but I didn't find much that I could simply close (apart from a set of bugs requesting additional common-licenses, once I had an analysis tool). From time to time, we've thought about timing out old bugs that have not made any forward progress, but this experience leads me to think that would serve us poorly.
It takes me about an hour on average to resolve a Policy bug. That includes all the fast five-minute typo bugs (well, ten minutes; I need to improve my Policy workflow to be a bit more efficient in the commit process). Some bugs take easily ten hours or more, such as #504880. I think this is on par with or a bit slower than resolving typical bugs in compiled software I package, and much slower than Lintian, where bugs take about a half-hour on average to resolve, I think.
Most Policy bugs are making no forward progress because no one has written wording and started iterating on that wording. There are some exceptions, and this process seems to go better for me than it has for some other contributors, but if I pick up a bug and start drafting wording changes, I can usually bring the bug to resolution in about a week, often less. This implies to me that our process for making Policy changes is reasonable but we need more targetted help. This was discussed at the BoF at DebConf and on the list afterwards and I now have three people who have volunteered to supply some of that targetted help and need to get more organized to make use of that offer.
The normative (rule-affecting) versus informative (informational and documentary) distinction in Policy is tricky and unclear, and most bugs end up becoming normative. While I think our system for dealing with normative bugs is reasonable, this does slow down fixes. I can commit informative changes without review and then tweak them if people object, and it would be nice to fix more wording issues that way, but it's hard to avoid getting tangled up in normative issues.
Things I learned on the time management side:
I didn't work from a closed list, which is frowned on for dealing with backlogs. I'm not sure if this ended up being a problem or not. The correct approach, in theory, is to work out a system for dealing with new incoming work, make sure that system is in place, and then process backlog independently of all new work. I never did that. I never separated out the backlog into a closed list that would get smaller. I suspect I should have, although I'm not sure of a good way to do that in the BTS in an area where we're already using usertags for another purpose.
The point of the initiative slot is to unblock something or to clear a backlog, but the initiative slot is supposed to rotate. It's not a good way to deal with something that's going to take a long time to resolve. In retrospect, I was excessively ambitious with my goal. Even apart from not working from a closed list, I can average about a half-hour a day on the initiative slot, which at an hour a bug and a starting point of 160 bugs would mean 120 days to reach my goal. That's too long for one task to dominate the initiative slot.
The initiative slot really works. We brought the bug count on Policy down from about 160 to 126 over the course of those two months, and I don't think much changed other than my level of activity and of course the normal effect of other people getting more involved when someone is visibly doing work. The bug graph is impressive. It's very obvious when I started working, and also very obvious when the ramp-up to DebConf started and I stopped having time to have a daily initiative slot.
Doing something that's unrelated to my day job in the initiative slot creates an odd tension, and I'm not sure how to deal with that. On one hand, one of my standard time management failure modes is to spend too much time on work and not enough time on non-work tasks. On the other hand, that's partly because I'm hypersensitive to not focusing enough on work and overcompensate, and taking time each morning to do non-work things doesn't help that. I'm not yet sure what to do about this.
One of the failure modes of initiative slots that I'm already noticing is that when I move something out of that slot, rather than continuing to work on it at a normal pace, I have a tendency to stop working on it altogether. This doesn't work, particularly if it was used for backlog clearing. I just build up another backlog and then have to use the slot to clear it again. This means I need to give more attention to my time management outside of that slot.
I stopped using the initiative slot while travelling and haven't gotten back into the hang of regular time management since I've gotten back. I haven't yet decided whether to leave Policy work in the initiative slot for right now but change the goal, or whether to swap it out for something else. I'd like to keep momentum, but I'd also like to start using that slot for other things. Still pondering.
This is a relatively minor release with a couple of bug fixes to bring this package in sync with other work.
The ok_program function in the shell TAP library now only removes bits from error messages after the second colon instead of the first. This feature allows easier testing of programs whose error messages include the system error, but the previous version was cutting off too much since the program name followed by a colon generally starts error messages.
I've also now added several new GCC warning options and runtests.c will now compile without warnings with -Wswitch-enum.
You can get the latest version from the C TAP Harness distribution page.
This release rolls up various fixes from different projects. It adds Kerberos portability code for old MIT Kerberos and Heimdal releases without krb5_get_init_creds_opt_free, adds apr-config --includes to the Apache module build flags for Red Hat Enterprise Linux, and fixes probes for UNIX domain sockets on OpenBSD.
Also in this release is a new test function for listing the contents of a keytab and fixes to the test principal determination in the Kerberos and remctl test libraries.
Finally, the last few releases didn't properly update the contents of the distribution to include all the new M4 macro files in the release tarball. This has now been fixed.
You can get the latest version from the rra-c-util distribution page.
I was hoping that this release would be the long-awaited 1.0 release, but I want to ensure that the server has database upgrade handling before I declare a 1.0 release. I ran out of time to finish that, so this is another beta release, although it's in production at Stanford.
The main change in this release is the addition of the wallet-rekey client program, which takes a keytab and retrieves new keys for every principal listed in that keytab that's in the local realm. The new keys are then merged back into the keytab. This is designed to make it easier to do periodic rekeying of service keytabs.
Thanks to Ian Durkacz, this version includes a new ACL type, krb5-regex, which is similar to krb5 but takes a Perl regular expression matching the authenticated principal instead of a simple string match.
There are two new reports in this version: objects unused, which returns all objects that have never been downloaded; and acls duplicate, which returns all sets of ACLs that have exactly the same entries. The wallet-report backend also now supports a help command which provides a summary of commands.
You can get the latest release from the wallet distribution page. I've uploaded new Debian packages to my personal Debian repository, although they're nearly ready to make it into Debian.
Sam Hartman ported the kadmin patch included in this package to MIT Kerberos 1.8.3, so that seemed like a good excuse for a new release. The patch is not yet heavily tested.
Also in this version are a few bug fixes from the previous release around use with Heimdal. Heimdal 1.3.2 will return an error about a missing service location plugin instead of the last error from Active Directory when changing passwords, which caused the plugin to fail the password change if Active Directory wasn't available. This release now correctly queues the change (and does so for any password change error, to work around problems like this).
Finally, there are some fixes for routine error suppression in
krb5-sync-backend with the -s
flag, and the Active Directory status
manipulation code no longer uses deprecated OpenLDAP library functions.
You can get the latest version from the krb5-sync distribution page.
< July 2010 | Russ Allbery > Eagle's Path | September 2010 > |