Bug#1124117: Seeking advice on fixing openconnect despite multi-developer dispute
Hi,
Sticking just to the technical aspects as much as I can here.
Firstly: this is just my opinion, and I'm afraid it's unlikely the TC
will be able to produce a formal resolution in time for the 10th January
stable update. I can try and push one through if really necessary, but
it'll be tight.
I note that upstream's most recent release is 9.12 (from May 2023) and
has, as far as I can see, bugfixes applied since then rather than any
major refactoring. I don't know why upstream hasn't cut a new release in
the mean time. 9.12 is the version in trixie, which pushes me in the
direction of thinking that PRs merged upstream are plausible to consider
for applying to trixie (and indeed later).
I think absent any rationale from Luca beyond "I didn't like the 0-day
NMU despite what the tracker page says", I don't see any reason to delay
#1119300 going into the next trixie update.
In the case of #1099497, it's less obvious. I agree that willy-nilly
changes to security-sensitive code is not ideal, but contra that, this
is a PR that was accepted upstream, and its targeting the version of
gnutls.c that trixie shipped with (by inspection of [0]), and subsequent
changes to that file don't raise any red flags to me. Pace Luca, I think
this is a reasonably impactful bug, and waiting indefinitely for
upstream to cut a new release and expecting our users to roll their own
in the meantime is not cost-free.
If we'd had substantive input from Luca as to the problems with the code
(or that upstream were preparing a bugfix release RSN), or feedback from
upstream that there's some problem with this patch, I'd feel
differently. But given what I'd looked at above about this patch and the
lack of a more particular objection from the maintainer, I do think it's
in our users' interests to ship this change in the next trixie update.
Regards,
Matthew
[0]
https://gitlab.com/openconnect/openconnect/-/commits/master/gnutls.c?ref_type=heads
Reply to: