Bug#1031046: Request to close

[Chris Maj]

First, I want to loop-in by reference the link to my "asterisk" fork and
"trixie" branch that demonstrates the following praxis:
* builds clean on current Trixie
* outputs signed debs using my GPG key in Salsa
* relies heavily on new gbp setup (thank you Jonas!)
* updates included documentation with links that don't 404
* adds appropriate comments to changelog
* lists me as an uploader
* and removes build dependency on uw-imap/libc-client2007e-dev to address
(now-non-blocking) Bug #1103048:

https://salsa.debian.org/cmaj/asterisk/-/tree/trixie?ref_type=heads

This fork was first mentioned in my post yesterday to Pkg-voip-maintainers:

https://alioth-lists.debian.net/pipermail/pkg-voip-maintainers/2025-April/039600.html

Then, Jonas, to clarify, a quick search reveals that there were 12 *total*
CVEs in the past two years that mention "asterisk" - 6 CVEs in 2024 and 6
CVEs in 2023:

https://www.cve.org/CVERecord/SearchResults?query=asterisk

1. https://www.cve.org/CVERecord?id=CVE-2024-57520
2. https://www.cve.org/CVERecord?id=CVE-2024-53566
3. https://www.cve.org/CVERecord?id=CVE-2024-42491
4. https://www.cve.org/CVERecord?id=CVE-2024-42365
5. https://www.cve.org/CVERecord?id=CVE-2024-35190
6. https://www.cve.org/CVERecord?id=CVE-2024-0986

7. https://www.cve.org/CVERecord?id=CVE-2023-49786
8. https://www.cve.org/CVERecord?id=CVE-2023-49294
9. https://www.cve.org/CVERecord?id=CVE-2023-37457
10. https://www.cve.org/CVERecord?id=CVE-2023-27585
11. https://www.cve.org/CVERecord?id=CVE-2023-26567
12. https://www.cve.org/CVERecord?id=CVE-2023-26566

Digging deeper, looking at pure CVE count is perhaps not the best gauge of
security issues for an active project like Asterisk, which benefits from
several paid full time engineering staff members at Sangoma, commercial
support teams, long-term stability as a 26 year-old project, etc. Instead,
the focus should be on Security Advisories (SA) published by the Asterisk
project itself:

https://github.com/asterisk/asterisk/security/advisories?state=published

There's been 1 SA published so far in 2025 and it included the immediate
release of the updated Asterisk version. There were 3 SAs in 2024 -- only
one was marked "high".  And of the 6 SAs in 2023, one was "critical" and
one was "high".

That's ten SAs in the past two years!  Not too shabby!

Besides internal management shuffling, one way that upstream took care of
the (perceived) CVE flood several years ago was by moving to GitHub
infrastructure -- see
https://www.asterisk.org/the-great-asterisk-migration-of-2023/ -- and
establishing Security Reporting processes using GitHub tools for this
purpose, including working with security researchers in private
repositories and making timely releases of tarballs with security fixes.
The current Asterisk 22 LTS release should continue to see this effort from
the Asterisk engineers until it reaches EOL on 2029-10-16 -- the date given
in the project's robust documentation website "Asterisk Versions" page at
https://docs.asterisk.org/About-the-Project/Asterisk-Versions/ which puts
Asterisk 22 LTS life-span *well beyond a hypothetical Trixie EOL of
mid-2028.*

Finally, I am in a unique position to contribute/volunteer right now as an
employee of Sangoma, as my ear is slightly closer to the ground than most.
Upstream for me is like a babbling brook in the background of my day-to-day
activities. :-)

On Mon, Apr 14, 2025 at 3:15 AM Jonas Smedegaard <jonas at jones.dk> wrote:

> Hi Chris,
>
> Quoting Chris Maj via Pkg-voip-maintainers (2025-04-14 10:01:29)
> > To address OP's security concerns -- there's been only 12 CVEs upstream
> in
> > 2023/2024, owing to much improved processes, automated tests, etc. These
> > continue to be patched in regular upstream releases once or twice a
> month.
> >
> > To address chief maintainer's concerns -- there's been several volunteers
> > over the past year on the mailing list.
>
> What is needed is not promises but demonstrated praxis.
>
> We need a team that has demonstrated investing the needed skills and
> time to backport *any* CVEs *at all*, before we can commit to handling
> such expected rate of 12 CVEs per year.
>
> To avoid misunderstanding: I am *not* blaming the volunteers that have
> chimed in, specifically.  I really don't know if they are all super
> enthusiastic and super skilled and have all simply waited for me to say
> "go!" in the appropriate way for us to blossom as a functional team.
> Whatever the cause, the team is not yet functional, and what the
> security team requested by filing this bugreport is that we *first*
> demonstrate capability in handling CVEs, and only *then* re-add the
> package to stable Debian.
>
> Also, freeze is tomorrow, and it takes at a minimum 3 days for a package
> to enter testing, so even if we somehow demonstrated capability today,
> we would still be too late to include it.
>
> Thanks for the interest,
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>  * Sponsorship: https://ko-fi.com/drjones
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>


-- 
Chris Maj   cmaj at sangoma.com   +1.920.574.9568 <//+19205749568>
Open Source Solutions Advocate, Sangoma US Inc
Free downloads at Asterisk.org and FreePBX.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-voip-maintainers/attachments/20250414/61663b0a/attachment.htm>