Re: don't upgrade! libpam problem!
>>>>> "Emmanuel" == Emmanuel Charpentier <charpent@bacbuc.dyndns.org> writes:
Emmanuel> Sam Hartmann uttered :
>> It's libpam-modules. A fixed deb is in incoming now. I'm
>> really
>>
>> sorry about thi; I screwed up between testing the patch and
>> doing the final build and introduced a typo. Yes, I know I
>> suck. I will be more careful in the future.
[The long delay in response is because I was at Usenix last week and
because I wanted to see what would happen with the thread before
responding.]
Emmanuel> Don't you test your "final build" ? Of a *vital* package
Emmanuel>
Normally yes. I am more likely to do so in the future. I am familiar
with testing process and had enough information to conclude had I
actually thought about it that I was taking a needlessly high risk.
I do not have information about the decision tree I used to lead to
the decision if one existed.
Emmanuel> ?? If possible at all, on a separate machine ???
I am unlikely to test changes of the class at hand on multiple
machines for PAM. I don't think it is worth the time in most cases.
For other packages, I am much more likely to test changes on multiple
machines. There are classes of PAM change that I would certainly want
to test on multiple configurations.
Emmanuel> Oh, my
Emmanuel> ...
Emmanuel> This kind of *imbecility* gives some *real* arguments to
Emmanuel> tenants of commercial development. No need to FUD
Emmanuel> anybody here : this is *real* mispractice.
Sloppyness, yes. Mispractice, no. I will agree with others who say
they have seen similarly broken things get checked into companies'
source bases. I've also worked in environments where stated policy
did not actually require changes work before being checked into
source bases. Of course those were special cases like new products.
I've also witnessed process failures that lead to similarly broken
code being put into production that might not have been characterized
as mispractice but rather sloppy communication.
In short, there are many process failures that happen within free
software and proprietary software development.
Emmanuel> Expect a lot
Emmanuel> of flak from the commercial development side, and don't
Emmanuel> fight it : it will have been *well* *earned*.
As I said, I made an error both in actuality (it didn't work) and in
process (it was inadequately tested).
Emmanuel> [ To be fair, the speed with which the bug has been
Emmanuel> fixed and 0.72-27 made available is also charcteristic
Emmanuel> of free software processes. ]
Thanks.
Emmanuel> I wonder how much people have been permanently locked
Emmanuel> out of their *only* machines by this shortsightedness
Emmanuel> ... Has someone an idea on how to count them ?
The only data I can provide is mail I received. I received
approximately 33 bug reports and 20 individual emails. Most people
had clearly already solved the problem although I did end up working
with one or two to back out correctly.
As a side note, if you are dedicated to cleaning up your messes, the
effort required to deal with the bug reports and mail is a
significant incentive not to break things.
>> Today has not been my day
Emmanuel> Of course not. Your day will be the day you'll be hung
Emmanuel> by the thumbs 'til the time_t counter wraps around
Emmanuel> ... ;-].
To clarify I meant that today had not been my day and that influenced
how sloppy I was being, not that I was wining about getting complaints
because I broke PAM.
Emmanuel> -- Emmanuel Charpentier
Reply to: