Package: tech-ctte X-Debbugs-CC: Salvatore Bonaccorso <carnil@debian.org>, community@debian.org Control: block 1099497 by -1 Control: block 1119239 by -1 Control: block 1119300 by -1 Hi Debian Technical Comittee, Community Team (CT) has been advising two DDs regarding disagreements with Luca Boccassi over the openconnect package over the last two months. One of the developers involved, Salvatore, would like to get tech-ctte's advise on how to proceed; Luca has not been collaborating and so Salvatore asked CT to act as mediator to keep the discussion focused and constructive. For context the dispute on openconnect extends over three bugs: - Bug#1119239 - Lee's bug - Bug#1119300 - Lee's trixie p-u - Bug#1099497 - Salvatore's bug (and NMUdiff) From CT's perspective the dispute history can be summarized like this: - Lee files bug+p-u and makes 0-day NMU in good faith assuming LowNMU declaration applies (Maintainer: Mike Miller's) - Luca responds with inappropriate angry NACK citing himself actually being maintainer (see extensive upload history) - CT issues a conduct warning and asks Luca to cooperate on a fix - Release Team puts Lee's p-u on hold - No response from Luca. - Lee's NMU fixed his bug in unstable as Luca has not reverted it (yet?), but stable is still affected. - Salvatore triages a distinct Bug#1099497 and pushes a cherry-picked fix (MR !8) - Luca rejects MR as "not safe to do" citing concerns over "another OpenSSL random() debacle" - Salvatore later cites (msg#88) user impact and urgency, care in considering upstream context and (unsuccessful) attempt at reaching upstream for clarification - Salvatore sends intent to NMU (+diff) per CT advise to move things forward - Luca requests cancellation privately with a short message but does not address any of the concerns raised previously - Salvatore has cancelled the NMU and informed Luca So it would appear things are stuck and we need a way forward. What does tech-ctte make of the situation? Please note Salvatore has expressed a desire not to miss the window for the Jan 10th Trixie stable update (13.3). Please let us know if this is not enough time for tech-ctte to gague the situation. Since Luca cites avoiding another instance of the well-known Debian OpenSSL bug as a reason for rejecting Salvatore's changes I would also like to bring Russ Cox's "Lessons from the Debian/OpenSSL Fiasco" post to everyone's attention before we start the discussion: https://research.swtch.com/openssl I found the "Cascade of Failures" section especially enlightening: https://research.swtch.com/openssl#:~#text=Cascade%20of%20Failures > Like any true fiasco, a cascade of bad decisions and mistakes all lined up to make this happen: > [...] > Reading various blogs you find various involved party's intelligence being insulted, but this is really a failure of process, not of intelligence. The maintainer knew he wasn't an expert on the code in question, asked the experts for help, and was given bad information. Below you will find Salvatore's request for help/advice (only sent to CT so far) on Luca's NMU cancellation request as further input for the discussion. --Daniel for the Debian Community Team -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, On Sat, Dec 27, 2025 at 11:59:47AM +0000, Luca Boccassi wrote: > On Wed, 24 Dec 2025 06:57:40 +0100 Salvatore Bonaccorso <carnil@debian.org> wrote: > > I've prepared an NMU for openconnect (versioned as 9.12-3.2) and > > uploaded it to DELAYED/5. Please feel free to tell me if I > > should cancel it. > > Hi, please cancel this. Thank you, and merry christmas Okay I will cancel the upload. Though I have some questions or concerns, and I seek input on how we should handle this properly within Debian. I'm seeking advice from the technical committee, as they according to 6.1.5 can offer advice, and this is my aim here getting some additional input on the techical front/weight for the problems. I try to summarize the problem to the best of my knowledge. We have reports of users in Debian affected by the Debian bug #1099497. After updates of Cisco ASA gateways users reported not to be able to connect anymore to the coorproate an universities VPNs with openconnect. The issue does not affect all installations using Cisco ASA gateways but a set of reports exists. The issue is known upstream as well as https://gitlab.com/openconnect/openconnect/-/issues/659 An initial merge request for unstable was proposed via https://salsa.debian.org/debian/openconnect/-/merge_requests/8 One of the maintainers of openconnect (the currently main active one) Luca Boccassi declined back one month ago the update wtih the reply in https://salsa.debian.org/debian/openconnect/-/merge_requests/8#note_693990 . I'm not completely agreeing with this assessment, because it does not balance in the problems reported by users and the both upstream reports acknowledging that the applied fix upstream fixes the problem and as well those for Debian users. I do agree that one needs to carefully handle openconnect as it is used in security-critical context. Upstream has not cut yet another release and the questions to this in the upstream issue remained unanswered. This might indicate to either upstream does not consider the issue improtant enough, they have concerns yet about the stability, or something else. Unfortunately even a private reachout to clarify this to the main author of openconnect remained unanswered so far. The suggestion that affected users can compile the upstream branch from source or use the upstream provided packages might is personally for me not a friendly option if we include openconnect in a Debian stable release. On the fix side, the patch is targetting specifically the upstream issue https://gitlab.com/openconnect/openconnect/-/issues/659 . The additional commit picked for the MR is to make the commit apply cleanly (and if desired can be skipped, as the hunk which otherwise would not apply cleanly is not compiled in Debian, the openssl.c code). Can someone help weigth in here and advise how we can balance bringing the fixes needed to users vs. handling the security-critical context use of openconnect and avoiding introducing potential Debian specific issues? The goal would be to see both #1099497 and #1119239 (cf. #1119300) be fixed in Debian trixie. Regards, Salvatore -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmlP+h1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2 NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQACgkQBUy48xND z0Sg1Q/+NiyKdJE/05P2QVZyPuQPbFJs8J66puIUGQ6KlLO254SR2f702xsoRqVM ieDD6X/RQu5hazBoL7e97oGkLf/63CV2DUj32XqYabrPimXHBwNMU4NZKWRRUVty 7gHVoW5DIMY6zRsS1Gg9e8/3wO0rrxczMnK8dR/hMT8d9c4MFKw2BSLU1fbE6DGQ ig8MfW8SZMnhcYr//ZiDK6jiXYKaLZLMVkz3luOnFF7mcc6sgB+ye0RAfR45QErz wUq7HW2FZ49xCIrt95995a72xAUAJQ1wfVkOOdF6JiLaJjKlhC0RyOESuZvJI49u HZKLBQjr/xFB3g1AOYhh5iOaw0Q+oUvFeeiflWHuyM7boliKNzpkVDsvXL3UCMOx ljl1iez0ZrK5DQKHdu5e8c5YbBm6LNS/0H+cUU2wnd6kKffufthomKr4SSlpe3Xb a7u7jMDg5IPyumJy+a2vDF4ItiO6Ux9lkCpEVWpEyvEjFh1/DgHQUjBAE+1Swanf 7tXD3HKWdgRqkiFALCwnNvlYiBUGI135odt67NBUv134fE2dpQTwXxpcDrWSC+OT LJAiCsoccjC38zDNV4yq8I/qL3ViivDV6XHQLfbtnEGXrJ9Es+AIC6nyJqc7FUZS mQZf7ZXXI5vrPpAgGwifDCexLggVK8nELycuHMNDnbhhBDf+xXg= =n8ec -----END PGP SIGNATURE-----
Attachment:
signature.asc
Description: PGP signature