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

[Fabian Fagerholm]

[Dropping the extra cc's, this discussion is not relevant for the bugs
or the cyrus-imapd list.]

On Wed, 2006-12-06 at 12:08 -0500, Roberto C. Sanchez wrote:
> Just realize that such an approach effectively prevents backporting
> after the release of Etch.  I generally use stable on all my machines,
> so that is how I do much of my development work, on Stable.

How does it prevent backporting? Whoever is doing the backport can
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.

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.

> 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.

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.

Cheers,
-- 
Fabian Fagerholm <fabbe at paniq.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-cyrus-sasl2-debian-devel/attachments/20061206/29a2bf09/attachment.pgp