Asterisk should only be included in Bookworm with a reliable commitment
by the maintainers to backport/test security fixes across the typical
three year life cycle (two years of stable-security and one year of
oldstable-security). (There have been 37 CVEs in 2021/2022)

Cheers,
        Moritz

Hi all,

Is there any news from the asterisk maintainers regarding this?
what are the chances that asterisk 20 will be included in bookworm ?
Thanks,
Bogdan Veringioiu

Quoting Bogdan Veringioiu (2023-05-23 14:59:48)
of Bookworm.

Sorry, requires more man power to maintain than I could muster alone :-(


 - Jonas

I've just discovered this "bug report" and I'm very disappointed by it.

Please can someone tell me:

1. How many people are involved as Asterisk Debian Package Maintainers?

2. Has this number decreased noticeably since the previous Debian release
Bullseye?

3. Has anyone contacted the Asterisk community (for example via
https://community.asterisk.org ) to see whether additional volunteers would be
willing to help with the effort involved in keeping Asterisk in the Debian
project?


Thanks,


Antony.

Hi Antony,

Quoting Antony Stone (2023-05-26 16:58:54)

Asterisk is maintained in the [VoIP team], and in principle anyone in
that team can contribute directly to the git repo of asterisk packaging
(and also most of the approximately 1000 formal Debian Developers has
write access to the git repo as well, but will only do so for simpler
quickfixes - anyone generally interested in Asterisk maintenance is
expected to join the team).

In reality, however, not everyone in our team are familiar with all of
the packages we maintain together.  In recent times, all [releases] of
Asterisk since 16.16.1~dfsg+~2.10-1 in January 2021 was issued by me,
and before that Bernhard Schmidt (almost) solely maintained Asterisk
packaging since 13.20.0~dfsg-1 in April 2018.

Unfortunately [Bernhard cannot grasp] how I embed PJProject, and I
cannot grasp how he did it previously.  Effectively, Asterisk has had a
single maintainer for the past 5 years.

[VoIP team]: https://salsa.debian.org/groups/pkg-voip-team/-/group_members

[releases]: https://tracker.debian.org/pkg/asterisk/news/

[Bernhard cannot handle]: https://bugs.debian.org/1014133#25

Asterisk packaging in Debia has had a low bus factor for quite some
time.

No, I haven't done any recruitment work, and neither has anyone else -
to the best of my knowledge.

If you are volunteering to either help yourself or to try do some
recrutiment, then that's much appreciated.

Unfortunately it is too late now for getting Asterisk part of upcoming
stable Debian - but it is regardless helpful for the maintenance in
*unstable* and *testing* during the lifetime of upcoming stable, which
includes the ability for offering it unofficially for upcoming stable
Debian through https://backports.debian.org/


Kind regards,

 - Jonas

Thanks for the explanation.

I am indeed interested in finding out what would be involved / required /
expected in order to help keep Asterisk as a package in a future release of
Debian Stable - and in the meantime, to ensure that it remains available in
Backports.

I have asked on the Asterisk community list / forum to find out whether anyone
else would be willing to join in, but I think the starting point for anyone
agreeing to this needs to be - what would you want someone to do, if they have
the time and interest to help in keeping Asterisk in Debian?

Thanks,

Antony.

Hi,

I'm ready to help to keep asterisk in the Debian project.

At this time I'm compiling from scratch on each new version (18 as well
as 20), I know nothing about creating packages but able to understand
the mechanism with a little help.

I'm too on community list.

Regards

Hi,

I try to create a deb file using dh_make or cowbuilder and it fail with
the same error:

configure.ac:508: error: possibly undefined macro: AC_MSG_WARN
       If this token and others are legitimate, please use m4_pattern_allow.
       See the Autoconf documentation.
configure.ac:849: error: possibly undefined macro: AC_LANG_PROGRAM
autoreconf: error: /usr/bin/autoconf failed with exit status: 1
dh_autoreconf: error: autoreconf -f -i returned exit code 1
make: *** [debian/rules:19: binary] Error 255
dpkg-buildpackage: error: debian/rules binary subprocess returned exit
status 2
I: copying local configuration
E: Failed autobuilding of package
I: unmounting dev/ptmx filesystem
I: unmounting dev/pts filesystem
I: unmounting dev/shm filesystem
I: unmounting proc filesystem
I: unmounting sys filesystem
I: Cleaning COW directory
I: forking: rm -rf /var/cache/pbuilder/build/cow.76107
root@cherry:/home/dh/packages#

Base package is asterisk-20-current.tar.gz

Any clue?

Hello,

I lately discovered  this thread.
I volunteer to help to package Asterisk either in current official
Debian repo or in an alternative repository.

The perspectives of Asterisk Deb packaging is talked about in [1] (I'm
the original author of this thread).

One thing that comes to mind reading [1] is that several people
recommend packaging from scratch while it seems to me, that
contributing in coordinated activities may lower the amount of work
(no need to build a repo, to configure host to use a custom repo, ...)
and increase the outcome quality as Debian standards are quite high.

If having Asterisk distributed with Bookwom is a lost cause, maybe we
can try to have latest Asterisk 20.3 be packaged "the Debian way" in
unstable repo and self assign the goal that this build would done by
new contributors, under the control of experienced mainteners ?

Then, what could be the best media to read or add doc about Asterisk packaging ?

[1] https://community.asterisk.org/t/status-and-perspectives-of-asterisk-package-on-debian-bookworm/97087/11

Regards

Quoting Antony Stone (2023-05-26 22:09:06)

Backports is an *extension* to core package maintenance in Debian.

First the package needs to be in good shape in "unstable", then it gets
accepted into "testing", and only then can it (when released, every 2
years) enter "stable" and optionally ahead of that also "backports".

The VoIP team currently only have enough man power (me) to roll out
regular releases, and needs more people willing to check for and prepare
and test patches fixing severe bugs reported against any of the official
Debian branches where Asterisk is included - i.e. unstable, testing,
stable, and oldstable.
(Backports is only "officially unofficial" in that it comes without
security support, and oldoldstable only borrows infrastructure from
Debian but is maintained by a commercially driven coop).

Debian work is coordinated through the team mailinglist and in the
Debian bugreports (which act as tiny ad-hoc mailinglists as well), and
optionally the team also socializes and does casual chit-chat on irc
(bridged with Matrix): https://wiki.debian.org/Teams/VoIP/

Hope to welcome a lot of you on our mailinglist :-)


 - Jonas

Hi Daniel (and others following along),

Quoting Devel via Pkg-voip-maintainers (2023-05-26 23:07:04)

I don't see how Debian is helped by your packaging from scratch - but
obviously it can help *help* gain more knowledge on the codebase and
experience with tooling involved in packaging.

What is most urgently needed is someone looking at CVEs and other severe
bugs reported against Asterisk versions now in Debian unstable and
oldstable (and in a bright future also in testing and stable).

I am pretty fluent in packaging new upstream releases of Asterisk, but
do not have time for inspecting, fixing and testing bugs.

Not sure what you mean here.  The mailinglist used for Debian packaging
is pkg-voip-maintainers@lists.alioth.debian.org - as listed here:
https://wiki.debian.org/Teams/VoIP/


Kind regards,

 - Jonas

Hi Daniel,

Quoting Daniel Huhardeaux via Pkg-voip-maintainers (2023-05-29 14:40:09)
[...]
packaging Asterisk officially for Debian.

Official Debian packaging does not need someone starting over from
scratch (and such duplicate work is unlikely to succeed using dh_make
which was intended for small simple packages).

If you are interested in helping out improving the state of official
Debian packaging, then please join the VoIP team mailinglist and let's
discuss there how you can best help out - which (as posted in this
bugreport already) is more likely to be work related to composing and
testing patches for security bugs than it is work related to repackaging
Asterisk from scratch).

The team mailinglist and other related info is here:
https://wiki.debian.org/Teams/VoIP/


Kind regards,

 - Jonas

Hi Olivier,

Quoting Olivier (2023-06-02 11:24:44)

Great!

Please subscribe to our mailinglist and discuss more there.
And please consider joining our IRC/Matrix chat room/channel for more
casual hangout.
Info on both is listed at https://wiki.debian.org/Teams/VoIP/

I see 4 approaches:

1) Use what the Asterisk project officially offers.

2) Use what Debian project officially offers.

3) Use what Debian semi-officially offers as "backports".

4) DIY.

Each of those 4 approaches can be done either with least possible effort
on your own part, or through more active collaboration.

Option 1 is good for some users.  Evidently it isn't for me, or I would
not have spent the past 20 years adding patches and build routines on
top of what upstream projects could offer: I firmly believe that it is
benificial to have a "second stage development" focusing on integration
across upstream projects, and I firmly believe that Debian is the best
for doing that.  For those disagreeing, use option 1 or 4 :-)

Option 2 is currently off the table, because for Debian to be
officially "stable" the work has to be done *before* the distribution is
released as "stable", and not enough work was done for that to happen
for the current stable release.

Option 3 is still valid.  It requires help, not on climbing the whole
mountain of building a package, but on concrete narrow tasks of checking
for security bugs, isolating (or writing from scratch if you are really
cool) patches to fix those bugs, and (when baked into a package) testing
that the bugs are indeed fixed.  Only with *both* packaging *and*
maintenance (which includes security sheparding) of that packaging can
the work become semi-officially available in Debian backport.

Option 4 is always an option.  And for me personally is always a big
waste of time, compared to the more efficient collaboration possible
using Debian as a platform for it.  Feel free to disagree, but then
discuss those non-Debian approaches elsewhere than in Debian :-)


Hope to see a lot of you enthusiasts in the Debian VoIP team mailinglist
soon.  More info at https://wiki.debian.org/Teams/VoIP/


Kind regards,

 - Jonas

Hello Moritz,

I've read your bug report at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031046

I believe it to be unacceptable to exclude Asterisk from Bookworm.
Asterisk is used by a LOT of users worldwide and, as you've noted, is
frequently the subject of security concerns.

The VoIP Team is currently working on a plan to resolve your concerns.

If we don't provide Debian users with secure packages, they will use
packages from less reputable sources and chaos will ensue.

I believe the VoIP team can deliver on the commitments you are asking
for, we are working on raising a bigger team of volunteers so we can
more effectively address CVEs.

Stay tuned.

David

Hello,

I also was caught by surprise that Asterisk isn't included in Bookworm. What's more, this (for servers) important package is not mentioned in the official documentation about caveats!

https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html

Following the discussion, I wonder, why Asterisk wasn't kept under limited security support, like binutils?

Also, other packages provide new upstream versions instead of burdening the maintainers with tedious porting of fixes to keep an earlier release. I know Debian is famous for this mindset, but sometimes pragmatism beats ideology?

:wq! PoC

Hi all,

I was wondering, what is the current maintenance status of Asterisk on
Debian?
I see that there are packages published on unstable, but the current
version has a reported security vulnerability (CVE-2024-42365
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078574>) since
August 12, that was still not addressed.
Is the goal to still maintain Asterisk packages in Debian or there is
lack of man-power for that?
I'm using these packages since 2015 and I need to upgrade some servers
that I support form Asterisk 16 to 20 and I was wondering if could
continue to use Debian packages (even if I need to backport them from
unstable to bookworm) or if I need to go in other direction (find some
alternative Debian packaging, or compile/package it myself).

Best regards,
José Miguel Gonçalves

Hi José,

Quoting José Miguel Gonçalves (2024-09-06 13:14:26)

Nothing has changed since my older responses in this bugreport, so
please read my other posts here and ask more specifically if there is
something you don't find covered there already.

Yes, there are bugs filed against Asterisk.  Please go examine which of
those bugs you consider affecting your use of Asterisk.

As also reflected by my older resonses in this bugreport, the goal is to
maintain Asterisk packages in Debian, but having that goal is not
adequate exactly due to lack of man power: I have enough time to keep
Asterisk afloat for unstable, but lack the time to care for stable
releases of Debian.

Whether you find the current level of care for Asterisk in Debian
superior or inferior to whatever support you can achieve elsewhere is
something I cannot really answer.  You do not *need* to go elsewhere, if
that is really what you are asking here.

Kind regards, and thanks for your interest in Debian and Asterisk,

 - Jonas

Hi Jonas,

Thank you for your quick response.
Please do not consider my questions as I was demanding anything.
I just wanted a confirmation that Asterisk was still going to be
packaged in Debian in the near future (at least, during the life of
Asterisk 20).
I only have appreciations for the Debian project, in the maintenance of
very stable systems that I use in my work and private life.
Going to a more specific question, are you considering packaging
Asterisk 20 for bookworm-backports?

Best regards,
José Miguel Gonçalves

Quoting José Miguel Gonçalves (2024-09-06 15:29:12)

I did not.

In fact, I appreciate knowing that others benefit from my maintenance
work, even if it only reaches unstable Debian.

bookworm-backports accepts only packages that has entered Debian
testing, so releasing to -backports is not possible before this very
bugreport about lack of adequate care also for long-term maintenance is
solved.


 - Jonas

Hi Jonas,

I was thinking that it would be possible to go directly from unstable to
backports. Quoting from https://backports.debian.org/: "(In a few cases,
usually for security updates, backports are also created from the Debian
unstable distribution.)".
If Asterisk does not fit in that category of "few cases", I would be
happy to build my own private backport from unstable.
I prefer that instead of building directly from the sources, because I
value a lot the work done my Debian devs in releasing stable and secure
packages (even if they are only available from the unstable release).

Thank you and best regards,
José Miguel Gonçalves

Quoting José Miguel Gonçalves (2024-09-06 16:37:28)
where the package in unstable is less buggy than the one in testing",
which does not fit here.

What makes sense to me is to pour all possible attention into getting
Asterisk acceptable for testing, and only *then* consider if there is
leftover energy to also offer a backport.

Hint hint: I expect to easily be able to handle the task of backporting
in addition to keeping Asterisk up-to-date in unstable.  What is needed
is someone volunteering the time to look after the Asterisk package that
is boringly sitting in stable or oldstable and occationally needing a
security patch applied.

I can do the task of releasing patches-applied updates, so you need not
be an official Debian developer to help.  All you need is dedication to
keep an eye on stable and oldstable branches of Debian, and the ability
to *try* to apply patches.  If you notice a needed patch, try to apply
it, and that fails, then we are a team, and you can ask me to try as
well - and you can shout out to Debian developers at large on the
debian-devel mailinglist as well.

This bugreport is about the lack of helping hands.

Please consider helping out.

Thanks for nice words about the work already done, but really what is
needed here is help.

Kind regards,

 - Jonas

I could volunteer to help, but I could not give dedicate too much time
to it, because there is not much spare time on my side.

I've no problems in patching, compiling, and making packages for Debian,
but would have problems to find the appropriate patches for old Asterisk
releases and would probably would not have the skills to test if the
patches are really doing what they are supposed to do.

If you are fine with those restrictions, please count with me... just
tell me were to start :-)

Quoting José Miguel Gonçalves (2024-09-06 18:11:57)

Great!

Noone in Debian has promised any specific amount of dedication - time
will tell if the actual time invested is adequate.

Your skill set sounds perfectly helpful!

Please subscribe to our mailinglist and discuss more there, and please
join our Salsa team - see details at https://wiki.debian.org/Teams/VoIP/


 - Jonas

I'm a long time subscriber from your mailinglist... and I've just
applied for a Salsa account.

Quoting José Miguel Gonçalves (2024-09-06 18:38:28)

Nice. Then let's move the conversation to the mailinglist.


 - Jonas

Hi Moritz,

I have joined the pkg-voip-team and I am willing to backport/test security fixes across the three year lifecycle for asterisk.

Is there some action you need us to take to allow this bug to close?

The tracker (https://tracker.debian.org/pkg/asterisk) states that there are three security issues in bookworm, but I have not been able to figure out how to address these. There is no asterisk package in bookworm, there is no branch in asterisk on salsa called bookworm or stable. Jonas Smedegaard (pkg-voip-team maintainer) has suggested this might be a problem in the tracker and that I should file a bug, but that is a side quest I'm not interested in. Maybe those CVEs can be marked resolved since asterisk will never be in bookworm, and we can focus on trixie/testing?

Martin

Quoting Martin Rampersad via Pkg-voip-maintainers (2024-12-12 18:23:50)

Please reconsider your level of enthusiasm towards filing bugreports,
Martin.

Frankly I am not comfortable having Asterisk enter into Debian, with a
team where those to be counted as active has such reluctant interest in
gaining experience with the machinery crucial to the work ahead.

Kind regards,

 - Jonas

Jonas,

Will you close #1031046 if I file a bug with the tracker pseudo-package?
If no, what do you need for this bug to close?

Martin

Quoting Martin Rampersad via Pkg-voip-maintainers (2024-12-12 22:41:16)

First, I am not sure it is for me or for us or for the security team to
close the bugreport.

That detail aside, what I would want - and I guess the security team
as well, is some level of confidence of future reliable teamwork here.

Your seemingly striving towards doing as little as possible does not
provide me confidence, but it is not like I am king of asterisk and
this is a Fight Club style riddle where you have to prove yourself to
me, it is more like "Hey, why are you really joining this team if not to
roll up your sleeves and engage?" - I am confused, and concerned for the
maintenance of asterisk.

 - Jonas

It is my assumption that this bug opened because the security team was left with a stable package that nobody on the pkg-voip-team was maintaining, so I understand why they don't want that to happen again, especially with a package with as many CVEs as asterisk. Please correct me if I'm wrong about this.

I would like to deliver confidence about my ability to backport security patches to asterisk. I fail to see how submitting a rendering or workflow bug to the tracker pseudo-package accomplishes this. You still won't know if I can do a backport.

I'm only trying to do as little work as possible that does not directly benefit my stated goal of getting asterisk back in stable.

I notice that asterisk in oldstable is receiving "non-maintainer" updates. Is the pkg-voip-team allowed to pitch in for this? Is it possible for me to contribute by helping catch up on the backlog of CVEs there? This seems like work I could do right now that directly benefits asterisk, takes work off the security team, and also shows I can do the main thing I will be spending the next three years doing.

As for "why are you really joining this team", I am a long time user of asterisk in Debian for my business. I noticed, like many others, that it fell off bookworm. I initially messaged the mailing list with a request to make private builds of the software easier, but your insistence on only doing work that would benefit the official Debian build convinced me to join and fix asterisk the right way.

I have no plans to discontinue use of asterisk in my business, so I felt it would be reasonable to commit to the lifecycle of the next release at least.

Martin

Quoting Martin Rampersad via Pkg-voip-maintainers (2024-12-13 02:17:00)

I am not the security team, but the above loosely matches my
understanding as well.

Yes. I understand, but...

Seen from the Debian side of this, your approach of "as little work as
possible" kinda sticks out, when you are new around here and it is the
only thing you can say.

Security team says "show us the money", and this team waits until all
the money has bled dry and then instead of saying "probably a waste of
your time, but here are the pennies left", you say "waste of my time, so
I pass on that".

Thing is, when the security team filed this bugreport, severe issues
were pending for asterisk officially in Debian. Time went by with noone
ut me (not only showing an interest verbally, but also) doing tasks
relevant asterisk officially in Debian.  Now close to the freeze several
people show up - which is great, that is always great, don't get me
wrong - and that is a) most likely too late to demonstrate real effects
on the team having grown bigger, before the freeze kicks in, also
because b) it is several months after the largest chunk of work needing
tending to is no longer in the hands of Debian but has been handed over
to the LTS team.

You are right, that you don't prove ble to tackle security bugs in
asterisk code by reporting a bug in a web app.  But you do demonstrate
a relevant skill of interacting with the Debian bugtracker, and you do
demonstrate slightly more commitment than by not doing it. I don't say
that you must jump through hoops and do "meaningless idiotic work", and
I don't know if you are super skilled in Debbugs already. What I react
on is that when the *sum* of what we as a team can show in this
bugreport is promise of future commitment + explicit statement of
non-commitment to things slightly off of our narrowly defined duties,
then that is disturbing to me.

The package in oldstable is no longer the responsibility of Debian.
This team (is just a bunch of volunteers that can decide that its
purpose is to go skateboarding on Tuesdays and not care at all about
asterisk, but since you ask me for my opinion) is about maintenance of
official Debian released packages (until we get that ball rolling - I am
open to then expand our activities to do backports, sideports and booths
at venues - but first things first).

Personally you are more than welcome to join the LTS team, and reeive
paiment for helping out with their responsibilities.  And yes, your
paid work there is a strong argument here that you are actively working
on things related to the asteisk packaging officially in Debian, because
LTS work is very similar to Debian work, so confidence is so much higher
that you growing experience there is helpful when a complex situation
occurs here.  So please go ahead and join the LTS team!

Your volunteering here is genuinely much appreciated.

I sure hope you will stick around even if it turns out that now is too
late for reintroducing asterisk in next stable release, and we will
have to "sit it out" until the next release.


Kind regards,

 - Jonas

Jonas,

Regarding how to resolve this bug, see #1030669 which has the same demand
and was closed by a promise from Marco d'Itri. If you don't look him up or
already know who he is, he says "I manage about 150 instances of Varnish,
so let's just assume that I have the experience needed and some motivation."
Moritz replies "Noted, thanks".

It's only when you research the individual that you find he has been a
Debian Developer for 27 years, so perhaps Marco's casual attitude
is an inside joke.

If you follow the work done, you will see that the result is 3 commits
over the last 18 months (varnish:debian/7.1.1-1.1) and two CVEs marked as
"ignored, too minor" in the varnish package tracker.

I accept that I'm not yet qualified to make this promise for asterisk. I'll
level up my Debian participation and try again later.

Thanks for your attention,
Martin

Quoting Martin Rampersad via Pkg-voip-maintainers (2024-12-13 22:30:43)

Yes, I know Marco.  I think I haven't met him in person, but not sure -
but he is has a strongly opinionated and confident voice on mailing
lists.

The concern raised by the security team is real: Marco may easily be
able to manage the level of security bugs expected for the 150 packages
that he maintains, and I will also argue generally that I am relatively
fine handling the 700+ packages I am involved in.  But among those,
asterisk is one of very few packages that stick out as a) having a large
amount of CVEs, and b) more likely than not deviating upstream so much
over the course of its lifetime in Debian, that patches cherry-picked
upstream do not apply.

In short, I genuinely cannot handle security issues on my own.

Other similarly CVE-ridden packages, like Ghostscript, have been a
deep dependency, so that even if others in Debian did not care much
for the package itself, when I gave up on fixing CVEs others chimed in
and helped out anyway, but asterisk is a fringe package so it is easier
for those not caring about the functionality of the package to back out
and let it rot.

Asterisk needs more maintainers, or it will not survive in Debian.

Why later? Whay not now?

You are aware that there might not be a later, right?

You are aware, that if you reappear close to the next freeze, it may
again be too close to a deadline?

Regardless, thanks for your interest in asterisk - however it
materialises,

 - Jonas

I have already said the same thing as Marco: That I would do it, and stated my
use case as he did. I can only assume his offer was deemed reliable because he
has a proven track record within the Debian community, which I don't have.
That is reasonable.

His timing was better too, somehow. From what I can tell, he was not part of
the varnish team before it was at risk of removal. He joined because he has
150 varnish deployments. My timing seems to be very common for people who just
want to get their package in the door. You have commented negatively on this. I
get that.

From what I can tell, refusing to file a bug with the tracker pseudo-package
inadvertently caused some offence.

To carefully file this bug requires me to first believe that the 161 existing
bug reports are not relevant. Once I find my bug is unique, I need to follow a
fairly lengthy guide for filing a bug report the right way. As someone "new
around here" I am extremely reluctant to file a bug in a way that deviates
from this guide.

I called it a side quest. You said I lacked "enthusiasm".
I asked you to confirm if it was necessary, and this is "disturbing" to you.

The "narrowly defined duties" I wish to stick to consist of learning the salsa
platform, gbp, the debian build recipe, and how to backport patches
specifically for asterisk and other vendored dependencies. To me this is
already a considerable courseload for someone who was previously just a user.

I think you are looking for a specific type of person for this task, someone
who is willing to go above and beyond for all things Debian or perhaps around
here it is the minimum.

You are a 20+ year veteran and although you cannot close this bug, your words
carry a lot of weight. Moritz may read your opinions and, I think, wait for
another candidate.

I truly appreciate all the time you've taken to speak with me.

Martin

Quoting Martin Rampersad via Pkg-voip-maintainers (2024-12-14 04:19:03)

The goal of this bug is not to have it closed, but to establish routines
that makes it unlikely for this bug to need reopening.

So you do experience this as a Fight Club entrance door situation.
Sorry for creating that atmosphere!

Any of us, you included, can close this bugreport, but if done through
empty words, someone else (Moritz or others) may very well reopen it.
I don't know the best way forward from here. Possibly the best way
forward is to try let asterisk into stable and see if this new team we
have now can muster it.

Perhaps asking the question in debian-devel@l.d.o is sensible? Or
perhaps asking leader@d.o for advice? I don't know, and any of us in
this team are in principle equally welcome to try out options.

Your approach seems to be to do as little as possible, and that, only
that, is what I argued against - not your "candidacy" for team
membership: You *are* a member of the team, by stepping up and wanting
to be.

Sure, my 20+ years of experience almost by definition means that I am
more suited to talk to the security team or to handle bugreports or to
raise issues in debian-devel or with the leader of Debian, due to my
experience. But should I? How does collaboration work in this team?
What do others in this team want to work together? Do we just commit
patches to git "together", and I do the rest?
because as I see it - or "in my experience", to put weight on it -
interaction with the bug tracker is central to dealing with patches in
Debian, especially for newcomers that may not be used to email-based bug
handling and may not be used to the Debian way of packaging - despite
(in my own case) years of building *from* Debian packages.

I consider sloppy interaction with Debbugs better than avoidance.

I don't think it is fair to frame that as "going above and beyond for
all things Debian". I would agree to frame it as going above and beyond
just fixing bugs.

That is one way this team could work, though: You new folks just
narrowly fix bugs, and I do whatever else tasks involved in maintenance
of an official Debian package. Is that the level of engagement for you
new folks in this team?

What this bugreport is asking for is not *closing* bugs, but *dealing*
with them, which involves interaction with the Debian bug tracker.  And
the concern I raised was that I am not sure that I can muster the tasks
besides narrowly patching, on my own.

In other words: I need you, even if your commitment is narrowly on only
patching, but then I think (I am not sure, so feel free to convince me
differently), that I then need more than you.

 - Jonas

I think I understand now. I would like do what is needed for asterisk. My
current focus is the asterisk bug tracker, as you have mentioned.

Thanks again,
Martin

Quoting Martin Rampersad via Pkg-voip-maintainers (2024-12-14 22:51:05)

And again: Sorry if I come across as brutal and/or stubborn - I am not
super great at collaboration, but I want to.

 - Jonas

Jonas,

My expectations and understanding of how things work in Debian were way off.

My frustration and entitlement were loud and misdirected and I apologize for
that, you've been extremely patient.

It is very easy for a person to use Debian software for years without
understanding anything that happens inside this community. One can visit the
home page, click download, and you are off to the races. apt-get install
asterisk just works and you can get things done.

Then one day apt-get install asterisk doesn't work anymore, and that only
happens when things are dire. The road to getting it back is not anything
like the ISO click or apt-get.

Because I put it in my business, I was looking for a quick fix. But there
isn't a quick fix here. It needs serious help from multiple DMs.

Thank you for keeping it going.

Martin

Quoting Martin Rampersad via Pkg-voip-maintainers (2024-12-15 14:23:25)

Just multiple persons - requires only one "Debian insider".

The only thing that requires a DD or DM is the final handover of the
source package to Debian. Anyone with an email account can help track
issues, anyone with a Debian system can help build and test packages,
and anyone can team up and create a salsa project with git access and
create a draft source package.

This is is one such group, consisting of volunteers interested in
maintaining realtime multimedia software in Debian. Some of us are
Debian "insiders", and some are not. Frankly I don't know how many we
are in the team currently or whom of us are Debian developers - I just
know that I have for some time been the only one actively working on the
asterisk package, and investing too little time in that for it to be in
shape for stable release.

So please, any and all help towards getting asterisk in shape for stable
release is helpful - including (after genuine investigation) posting to
that blocking bugreport that seemingly there is nothing more that can be
done - the package is as fit as is reasonably possible, and is expected
to stay that way for years ahead.

 - Jonas

Hi xuser,

Asterisk is not likeley to be in trixie because of a lack of resources for
handling the large amount of security response work it seems to generate
(or has generated in the past anyway).

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031046 for details.

Nobody has yet committed to doing that work and that's why it's not in
trixie.

Howdy!

We missed Bookworm, but Asterisk is ready for Trixie!

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.

Some references:

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

https://alioth-lists.debian.net/pipermail/pkg-voip-maintainers/2024-December/039033.html

Please close this bug.

Kind regards,

Hi Chris,

Quoting Chris Maj via Pkg-voip-maintainers (2025-04-14 10:01:29)

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

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. :-)

I am still running one bullseye machine here for asterisk, having
upgraded everything else to bookworm. I was hoping there would only be
one release missing the package. With trixie on the horizon expected to
still not have asterisk packaged, what are my options going forward once
bullseye runs out of LTS?

Quoting Kevin Otte via Pkg-voip-maintainers (2025-06-03 22:10:18)

For user support, please see https://www.debian.org/support

Kind regards,

 - Jonas

Hi,

@Chris, do you think you could make the necessary arrangements to have
your version of Asterisk for Trixie pushed into Debian Testing? You are
certainly in the best position, with the help of your team at Sangoma
and other volunteers who have offered their assistance here and
elsewhere, to make this a reality. This step would not only benefit the
current user base but also demonstrate the commitment and capability of
the community to maintain and promptly update the package, particularly
in response to CVEs.

By including the Asterisk in Debian testing, we can showcase the active
engagement of the user community, potentially facilitating its inclusion
in trixie-backports initially, and finally in the next stable release of
Debian. This would ensure that Debian users have access to up-to-date
and secure Asterisk packages.

I fear that without progress on this matter, we may find with numerous
Asterisk instances stuck on Debian Bullseye, which will no longer be
maintained after August 2026 with the end of LTS. Additionally, there
could be a proliferation of individual solutions to migrate to Trixie,
involving local builds that are difficult to keep secure. Having
up-to-date packages maintained in testing (and ideally in
trixie-backports) would provide an "official" solution, demonstrating
the desire to see the inclusion of Asterisk return to Debian Forky.

Thank you all!

Best regards,

Thanks y'all for the excellent ideas, kind words and generous support --
looking forward to helping steward the Asterisk package along with you on
the journey in to backports soon after trixie is released :-)

[image: Sangoma]
[image: LinkedIn] <https://www.linkedin.com/company/sangoma> [image: X]
<https://x.com/sangoma> [image: Facebook]
<https://www.facebook.com/Sangoma/> [image: YouTube]
<https://www.youtube.com/user/SangomaTechnologies/>
Chris Maj Open Source Solutions Advocate

P: +1.920.574.9568

E: cmaj@sangoma.com

W: www.sangoma.com <https://sangoma.com/>
[image: Sangoma]

Hi,

Following the publication of the security bulletins on August 28th ([1]
[2]), I wanted to know if we have made any progress on integrating the
Asterisk package into testing and trixie-backports.

Thank you in advance.

[1]
https://github.com/asterisk/asterisk/security/advisories/GHSA-557q-795j-wfx2

[2]
https://github.com/asterisk/asterisk/security/advisories/GHSA-64qc-9x89-rx5j

Quoting Benjamin Renard via Pkg-voip-maintainers (2025-09-22 18:27:41)

No, not that I know of.

 - Jonas

I have recently rebuilt the current unstable package for
trixie-backports. It built without changes, and the resulting
package was verified to work in a production Asterisk setup.

The tests were made and Sponsored by Linuxhotel.

Quoting Dominik George (2025-10-08 20:34:11)

Sorry, what tests, and in what way has linuxhotel sponsored here?

If you mean to say that linuxhotel has paid for getting asterisk
backported, while the *only* reason for it needing such backporting is
lack of volunteers to help look after asterisk maintenance, then it
seems rather counterproductive to me - but oh well, congratulations
with your payment, I guess.

 - Jonas

Jonas,

You are an incredible PITA to work with. The main reason why I haven't offered contributions here earlier is that you are involved, and thanks for the confirmation.

I hope others here are able to simply acknowledge a success report of using the current package to upgrade a production system to trixie.

Quoting Dominik George (2025-10-08 22:25:22)

Full disclosure: Here are the previous collaborations of ours that I
were able to locate - feel free to point to others, if I missed some:

* https://alioth-lists.debian.net/pipermail/pkg-voip-maintainers/2018-April/032232.html
* lists.debian.org/20200603113952.pn2hrubln5uqcjpa@fjordbox.naturalnet.de
* https://bugs.debian.org/972409
* http://bugs.debian.org/1029076

My recollection of those encounters is that you have had difficulties
understanding my arguments - or conversely, that I have failed at
getting my arguments across. I invite others to judge for themselves
whether those are cases of me being a PITA or not.

 - Jonas

Quoting Moritz Muehlenhoff (2023-02-10 20:49:27)

As Moritz has pointed out privately as part of his great work tracking
CVEs, Asterisk now has no open CVEs.

There has been interest in stable releases from several people, and
Chris has stepped up as maintainer, so this issue is now considered
solved.

We can still use more people to care for backporting security fixes for
stable releases once those emerge again, so please, anyone interested
in helping out with that please add yourselves to the (misleadingly
named) "Uploaders" field in the control file for the package. You need
not be an official Debian developer to do so, you just need the skills
of patching, building and testing the Debian package and an interest in
helping out.

Kind regards,

 - Jonas

Who specifically has stepped up to backport asterisk security fixes for
three years?

Quoting Moritz Mühlenhoff (2026-06-27 13:37:08)

Chris May.

 - Jonas