[Pkg-gnutls-maint] Bug triage

[Andreas Metzler]

On 2006-06-06 James Westby <jw+debian at jameswestby.net> wrote:
> Hi guys,

> I have had a first go at a bug triage to try and work out which of the
> outstanding bugs should be tackled first. I see Andreas has been busy
> with the uploads that will close many bugs.

> My first priorities were the security bugs, so I'll start with those.

> 352182 - Crash in the ASN.1 DER decoder

>   This is the bug that is fixed in libtasn1-3 in unstable, and has been
>   fixed in sarge. However libtasn1-2 is still vunerable in testing and
>   sid. I'm unsure of what the usual thing to do here is, as the
>   vunerable library will have to hang around until all of the reverse
>   dependencies have transitioned. Andreas you said uploading -3 was the
>   only sane way to fix the bug, can you explain what you meant by that?
>   What is stopping us from using the patch that has been supplied to fix
>   -2 as well? Please forgive me if I have this wrong.

The real *reverse* dependencies of libtasn1 are almost nothing besides
gnutls:
(SID)ametzler at argenau:~$ grep-dctrl -FBuild-Depends libtasn1-2 -sPackage /var/lib/apt/lists/ftp.at.debian.org_debian_dists_sid_main_source_Sources
Package: gnutls11
Package: shishi

There are loads of other packages *linking* against libtasn1 but I
doubt that more than one of these actually use it, they just link
against a bunch of libraries (including the whole gnutls dependency
chain) for no reason at all (pkg-config/libtool breakage). Afaiui
these packages wouldn't inherit the libtasn vulnerability.

Fixed libtasn1-2 and the current libtasn1-2 are not completely API
compatible AFAIUI (older gnutls cannot link against it), so it seems
to be a waste of time to pursue this instead of simply using
libtasn1-3 in the 4 packages that actually matter.

> 352188 - Crash in the ASN.1 DER decoder

>   This is the same bug as above, but cloned to libtasn1-0 which is still
>   in sarge, and is affected. I have been trying to apply the patch for
>   -2 to this version, but it's not that easy. Should we be pursuing this
>   line of attack?

This package should never been released with sarge:
ametzler at argenau:~$ apt-cache rdepends libtasn1-0
libtasn1-0
Reverse Depends:
  libtasn1-dev
ametzler at argenau:~$ apt-cache rdepends libtasn1-dev
libtasn1-dev
Reverse Depends:
  libtasn1-2-dev

we should try to get it removed from there if that is possible.

> 309111 - [GNUTLS-SA-2005-1] DoS security problem in gnutls <=1.0.24 (and
> <=1.2.3)

>   The fix in the bug report appears to have been applied to all versions
>   in the archive. Shall I close this one?

>   The NMU seems to have made it in to sarge after the bug was reopened
>   for sarge but noone closed it when it transitioned (speculation).

If you are positive that is fixed please do so, you are the
maintainer. - Noting done which versions you verified to be fixed in
the bug-report would be helpful.

> There were a few other bugs that caught my eye as candidates for a quick
> fix.

> 355272 - [amd64] "The gcrypt library version is too old"

>   This appears to have been fixed as as libgnutls12 now depends on
>   libgcrypt11 (>= 1.2.2) as required.

The bugreport is closed, too.

> 361874 - libgnutls12: uninstallable due to Conflicts/Depends cycle with
> libtasn1-2

>   I think this one can probably be closed as well, as it has probably
>   been long enough.

The bugreport has been closed by the 1.2.11-1 upload.

> 364287 and 364291 are for upstream. What is the usual way of reporting
> things to the gnutls developers? Does the mailing list suffice? (I think
> these two deserve to be normal rather than wishlist as they are features
> I would expect to be in the program).
[...]

I agree that they should be forwarded, however I still think they are
wishlist requests.

Yes, the mailing list gnutls-dev
http://lists.gnupg.org/mailman/listinfo/gnutls-dev 
is the way to go afaik.

cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde