Your message dated Sun, 17 Jun 2018 20:20:52 +0100
with message-id <1529263252.2082.40.ca...@adam-barratt.org.uk>
and subject line Re: Bug#834854: jessie-pu: package charybdis/3.4.2-5~deb8u1
has caused the Debian Bug report #834854,
regarding jessie-pu: package charybdis/3.4.2-5~deb8u1
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
834854: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834854
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian....@packages.debian.org
Usertags: pu
TL;DR: Charybdis 3.4 (Jessie) introduces a regression (CertFP broken)
from Charybdis 3.3 (Wheezy). 7-line patch (attached) fixes the issue.
Charybdis 3.4 suffers from a regression which breaks authentication in
certain scenarios. The bug is now documented upstream here:
https://github.com/charybdis-ircd/charybdis/pull/211
To provide some context, IRC servers support authentication through
two main mechanisms: passwords and X509 certificates (or CertFP). The
latter works fine in 3.3, but has been broken by a code refactoring in
3.4. Since upstream does not test our code path often (GnuTLS, used
primarly to avoid OpenSSL licensing issues), this bug has been
overlooked for a while.
I have produced a simple patch which fixes the issue for Charybdis 3.5
here:
https://github.com/charybdis-ircd/charybdis/pull/211/commits/0ff0a0592de84dec2a2f46d9f8d6e22f6c1ee467
The patch can be trivially ported to Charybdis 3.4. Such a patch is
attached to this bug report.
Upstream made its own version of the patch, but I do not recommend
using it as it is harder to review and more difficult to backport to
3.4:
https://github.com/charybdis-ircd/charybdis/commit/3288fc46483db508acf2dcdd546a5aea54401de5
If this update isn't possible, I will have to go through backports to
ship 3.5 in Jessie, but that would be unfortunate because I believe
that backports are more for new functionalities than fixing such
regressions.
Another option would be to ship 3.5 directly in Jessie, as it is now
considered to be the "stable" upstream version. However, that diff is
actually much larger:
299 files changed, 20157 insertions(+), 14302 deletions(-)
I'd be happy to provide a debdiff if that is necessary, but that would
be actually harder to use than the provided patch, which is just put
in debian/patches with a proper changelog mention.
Thanks for your consideration and hard work!
-- System Information:
Debian Release: 8.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'stable'), (1, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Bug: https://github.com/charybdis-ircd/charybdis/pull/211
will be factored into 3.5.3, so hold on before merging...
>From 0ff0a0592de84dec2a2f46d9f8d6e22f6c1ee467 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= <anar...@debian.org>
Date: Fri, 19 Aug 2016 11:53:59 -0400
Subject: [PATCH] fix error handling in gnutls certfp support
---
libratbox/src/gnutls.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/libratbox/src/gnutls.c b/libratbox/src/gnutls.c
index f51211f..9bb69bb 100644
--- a/libratbox/src/gnutls.c
+++ b/libratbox/src/gnutls.c
@@ -608,18 +608,17 @@ rb_get_ssl_certfp(rb_fde_t *F, uint8_t certfp[RB_SSL_CERTFP_LEN], int method)
if (gnutls_certificate_type_get(SSL_P(F)) != GNUTLS_CRT_X509)
return 0;
- if (gnutls_x509_crt_init(&cert) < 0)
- return 0;
-
cert_list_size = 0;
cert_list = gnutls_certificate_get_peers(SSL_P(F), &cert_list_size);
- if (cert_list == NULL)
+ if (cert_list_size <= 0)
{
- gnutls_x509_crt_deinit(cert);
return 0;
}
- if (gnutls_x509_crt_import(cert, &cert_list[0], GNUTLS_X509_FMT_DER) < 0)
+ if (gnutls_x509_crt_init(&cert) != GNUTLS_E_SUCCESS)
+ return 0;
+
+ if (gnutls_x509_crt_import(cert, &cert_list[0], GNUTLS_X509_FMT_DER) != GNUTLS_E_SUCCESS)
{
gnutls_x509_crt_deinit(cert);
return 0;
--- End Message ---
--- Begin Message ---
Control: tags -1 + wontfix
On Wed, 2018-06-13 at 17:37 -0400, Antoine Beaupré wrote:
> On 2018-06-13 16:00:41, Adam D. Barratt wrote:
> > On Tue, 2016-09-13 at 12:04 +0200, Julien Cristau wrote:
> > > On Sun, Sep 11, 2016 at 16:58:34 -0400, Antoine Beaupré wrote:
> > >
> > > > 1. ignore the above two extra issues and simply add the patch
> > > > for
> > > > #215
> > > > to the pile of patches in jessie
> > > > 2. import the new gnutls.c module from an eventual new 3.5
> > > > release
> > > > upstream directly in jessie - this may be difficult because of
> > > > internal
> > > > API changes
> > > > 3. import 3.5.x directly in jessie
> > > >
> > > > I would like to have feedback from the release team as to which
> > > > approach
> > > > to take forward.
> > > >
> > >
> > > I don't think 3 is a reasonable option. The rest will depend on
> > > specifics.
> >
> > There's been no further activity on this bug since the above, so I
> > think it's reasonable to say it's unlikely to be getting fixed in
> > jessie at this point?
>
> Hmm... I am not sure what to do with this... 3.4 is pretty much dead
> at
> this point, and I suspect most people will have migrated to 3.5. the
> complete fix is pretty invasive so I guess we can just punt this away
> for ever and assume people will upgrade to stretch already... :/
Unfortunately the window for getting fixes into the final jessie point
release has now closed.
I'm not sure whether a suitable update could be put together for
jessie-lts, but that might be worth investigating?
Regards,
Adam
--- End Message ---
