<div dir="ltr"><div>First, I want to loop-in by reference the link to my "asterisk" fork and "trixie" branch that demonstrates the following praxis:</div><div>* builds clean on current Trixie</div><div>* outputs signed debs using my GPG key in Salsa</div><div><div>* relies heavily on new gbp setup (thank you Jonas!)</div></div><div>* updates included documentation with links that don't 404</div><div>* adds appropriate comments to changelog</div><div>* lists me as an uploader</div><div>* and removes build dependency on uw-imap/libc-client2007e-dev to address (now-non-blocking) Bug #1103048:</div><div><br></div><div><a href="https://salsa.debian.org/cmaj/asterisk/-/tree/trixie?ref_type=heads">https://salsa.debian.org/cmaj/asterisk/-/tree/trixie?ref_type=heads</a></div><div><br></div><div>This fork was first mentioned in my post yesterday to Pkg-voip-maintainers:</div><div><br></div><div><a href="https://alioth-lists.debian.net/pipermail/pkg-voip-maintainers/2025-April/039600.html">https://alioth-lists.debian.net/pipermail/pkg-voip-maintainers/2025-April/039600.html</a></div><div><br></div>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:<div><br></div><div><a href="https://www.cve.org/CVERecord/SearchResults?query=asterisk">https://www.cve.org/CVERecord/SearchResults?query=asterisk</a></div><div><br></div><div>1. <a href="https://www.cve.org/CVERecord?id=CVE-2024-57520">https://www.cve.org/CVERecord?id=CVE-2024-57520</a></div><div>2. <a href="https://www.cve.org/CVERecord?id=CVE-2024-53566">https://www.cve.org/CVERecord?id=CVE-2024-53566</a></div><div>3. <a href="https://www.cve.org/CVERecord?id=CVE-2024-42491">https://www.cve.org/CVERecord?id=CVE-2024-42491</a></div><div>4. <a href="https://www.cve.org/CVERecord?id=CVE-2024-42365">https://www.cve.org/CVERecord?id=CVE-2024-42365</a></div><div>5. <a href="https://www.cve.org/CVERecord?id=CVE-2024-35190">https://www.cve.org/CVERecord?id=CVE-2024-35190</a></div><div>6. <a href="https://www.cve.org/CVERecord?id=CVE-2024-0986">https://www.cve.org/CVERecord?id=CVE-2024-0986</a></div><div><br></div><div>7. <a href="https://www.cve.org/CVERecord?id=CVE-2023-49786">https://www.cve.org/CVERecord?id=CVE-2023-49786</a></div><div>8. <a href="https://www.cve.org/CVERecord?id=CVE-2023-49294">https://www.cve.org/CVERecord?id=CVE-2023-49294</a></div><div>9. <a href="https://www.cve.org/CVERecord?id=CVE-2023-37457">https://www.cve.org/CVERecord?id=CVE-2023-37457</a></div><div>10. <a href="https://www.cve.org/CVERecord?id=CVE-2023-27585">https://www.cve.org/CVERecord?id=CVE-2023-27585</a></div><div>11. <a href="https://www.cve.org/CVERecord?id=CVE-2023-26567">https://www.cve.org/CVERecord?id=CVE-2023-26567</a></div><div>12. <a href="https://www.cve.org/CVERecord?id=CVE-2023-26566">https://www.cve.org/CVERecord?id=CVE-2023-26566</a></div><div><br></div><div>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:<div><br></div><div><a href="https://github.com/asterisk/asterisk/security/advisories?state=published">https://github.com/asterisk/asterisk/security/advisories?state=published</a></div><div><br></div><div>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".</div><div><br></div><div>That's ten SAs in the past two years!  Not too shabby!</div><div><br></div><div>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 <a href="https://www.asterisk.org/the-great-asterisk-migration-of-2023/">https://www.asterisk.org/the-great-asterisk-migration-of-2023/</a> -- 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 <a href="https://docs.asterisk.org/About-the-Project/Asterisk-Versions/">https://docs.asterisk.org/About-the-Project/Asterisk-Versions/</a> which puts Asterisk 22 LTS life-span *well beyond a hypothetical Trixie EOL of mid-2028.*<div><br></div></div></div><div>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. :-)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 14, 2025 at 3:15 AM Jonas Smedegaard <<a href="mailto:jonas@jones.dk" target="_blank">jonas@jones.dk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Chris,<br>
<br>
Quoting Chris Maj via Pkg-voip-maintainers (2025-04-14 10:01:29)<br>
> To address OP's security concerns -- there's been only 12 CVEs upstream in<br>
> 2023/2024, owing to much improved processes, automated tests, etc. These<br>
> continue to be patched in regular upstream releases once or twice a month.<br>
> <br>
> To address chief maintainer's concerns -- there's been several volunteers<br>
> over the past year on the mailing list.<br>
<br>
What is needed is not promises but demonstrated praxis.<br>
<br>
We need a team that has demonstrated investing the needed skills and<br>
time to backport *any* CVEs *at all*, before we can commit to handling<br>
such expected rate of 12 CVEs per year.<br>
<br>
To avoid misunderstanding: I am *not* blaming the volunteers that have<br>
chimed in, specifically.  I really don't know if they are all super<br>
enthusiastic and super skilled and have all simply waited for me to say<br>
"go!" in the appropriate way for us to blossom as a functional team.<br>
Whatever the cause, the team is not yet functional, and what the<br>
security team requested by filing this bugreport is that we *first*<br>
demonstrate capability in handling CVEs, and only *then* re-add the<br>
package to stable Debian.<br>
<br>
Also, freeze is tomorrow, and it takes at a minimum 3 days for a package<br>
to enter testing, so even if we somehow demonstrated capability today,<br>
we would still be too late to include it.<br>
<br>
Thanks for the interest,<br>
<br>
<br>
 - Jonas<br>
<br>
-- <br>
 * Jonas Smedegaard - idealist & Internet-arkitekt<br>
 * Tlf.: +45 40843136  Website: <a href="http://dr.jones.dk/" rel="noreferrer" target="_blank">http://dr.jones.dk/</a><br>
 * Sponsorship: <a href="https://ko-fi.com/drjones" rel="noreferrer" target="_blank">https://ko-fi.com/drjones</a><br>
<br>
 [x] quote me freely  [ ] ask before reusing  [ ] keep private<br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><font face="monospace">Chris Maj   <a href="mailto:cmaj@sangoma.com" target="_blank">cmaj@sangoma.com</a>   <a href="tel://+19205749568" target="_blank">+1.920.574.9568</a></font></div><div><font face="monospace">Open Source Solutions Advocate, Sangoma US Inc</font></div><div><font face="monospace">Free downloads at Asterisk.org and FreePBX.org<br></font></div><div><font face="monospace"><br></font></div></div></div>