Bug#400955: Time to step up to the plate... Bug 400747

[Roberto C. Sanchez]

On Wed, Dec 06, 2006 at 08:49:11PM +0200, Fabian Fagerholm wrote:
> 
> How does it prevent backporting? Whoever is doing the backport can

If we backport the "fixed" cyrus-sasl2, then broken apps will break.

> either apply the patch as part of the backport, or can try coordinating
> with other backporters to fix the misbehaving programs. This is exactly
> the kind of activity that backporting is about.
> 
Right.  I guess that if we decide to "officially" backport, then we may
need to revert the patch in the backport.  Perhaps this should be
discussed after Etch is released.

> For etch+1, we can start immediately to track down offending packages,
> by disabling the patch. The list of offending packages that this yields
> is going to be helpful for backporters. We could also possibly drop the
> patch in an etch point release through t-p-u. In the worst case, we will
> have eliminated most offending packages by the time etch+1 is released.
> 
> > Anyhow, is there any idea how many packages we are talking about?
> 
> Among the ones we would need to audit are at least the major (mostly
> email-related) ones like postfix, cyrus-imapd, exim4-deamon-heavy,
> openldap, plus the cyrus-imapd-derived kolab. I count around 70 reverse
> deps on libsasl2[-2], so we'd need to look at all those. Plus rdeps of
> higher degrees, in case there are more complex code paths.
> 
OK.  This is more work than I had originally thought.

> > The RC bug count for Etch is still much higher than the RMs wanted
> > (160 in the last mail I saw, IIRC).  So, we may yet have a window in
> > which to work.
> 
> Our package was supposed to have been frozen already. We've been granted
> an exception, but not permission to take risks, and especially not with
> packages that we don't maintain.
> 
Good point.

> But forget that for a moment. Here's what we would need to do: for each
> packaged piece of software that uses the SASL base64 code, locate every
> place in the code that makes calls into the SASL code, and eliminate any
> possibility that otherwise valid base64 data contains non-base64
> characters. If they work already, prove it for the general case (not
> just for a single example). If they don't, write patches, submit them to
> the maintainers, and help the maintainers to integrate them.
> 
> That's a *lot* of work, and the above assumes that we don't miss any
> piece of software that calls the SASL base64 code, that our patches are
> bug-free and don't cause any side-effects, and that we don't make any
> mistakes in proving that the package is ok -- which is impossible for
> the amount of code that we would have to go through, unless we assume
> that etch will not be released in another 6-12 months, and we get all
> maintainers to help us immediately.
> 
> I'm not trying to forbid anyone from doing this, but please be aware of
> how big the task is and what degree of certainty you need to achieve
> before this option is realistic.
> 
Good point.  I'd like to keep my job, so I will only have my spare time
in which to do this :-)

Otherwise, it sounds like a good plan to me.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com