Hello,
Today, I built a new Debian Bookworm VM.
When trying to install asterisk package I was surprised to learn it’s not available anymore in Bookworm repo while it was available a couple of months ago.
How should you understand data from [1] ?
Will asterisk become available a couple of days after bookworm release or should it take much longer than that ?
[1] Information on source package asterisk
Best regards
This is a question for the Debian Project, not Asterisk.
Antony.
Will never be in bookworm
I find that somewhat disturbing.
Could the Asterisk developers please comment on the discussions with the
Debian Project regarding their request for “a reliable commitment by the
maintainers to backport/test security fixes across the typical three year life
cycle”?
It’s clearly too late to do anything about Debian 12 Bookworm now, but I would
like to know whether it’s reasonable to expect it to reappear in Trixie in 2
years’ time.
The two specific questions I’m interested in are:
Was this requirement from Debian present for previous releases, or is this
something new they have introduced?
What additional effort would it mean for the Asterisk project to comply with
this request, given that Debian only seems to use LTS versions of Asterisk
now?
Thanks,
Antony.
The Asterisk project doesn’t maintain any distro packages. We never have. When they say “maintainers” they are referring to anyone within the Debian project who maintains packages.
If you want to use quite the latest software, in general, Debian is not the right thing for you. Unless you compile asterisk on your own. What I’d recommend by the way and always did for 15 years.
I never used asterisk out of a package manager.
Ah, I see. I had interpreted “maintainers” to mean the maintainers
(developers) of Asterisk itself, but re-reading that “bug report” I can see
how it refers to internal Debian people instead.
Thanks for the clarification.
Antony.
Aye, it’s a bit overloaded. “package maintainers” would be better and give more context, otherwise many people assume “software maintainers”.
If you want to use quite the latest software, in general, Debian is not the
right thing for you.
I completely agree.
Unless you compile asterisk on your own. What I’d recommend by the way and
always did for 15 years. I never used asterisk out of a package manager.
I have customers who do not want to commit resources to updating individual
applications on their systems - it’s the reason they use packaged
distributions - so that someone else takes on the responsibility of updating
packages as and when required, and internal staff only need to do “apt-get
upgrade” or whatever the appropriate equivalent is.
These are generally people who want stability (both in terms of tried-and-
tested software, and systems which do not change frequently) more than they
want the latest version of things.
Antony.
Hello, if you need Debian packaging you could just maintain your own. I think it’s probably better for an asterisk environnement. Debian is a really nice distro, but for some packages, i think, it’s not a good idea to use their packages. For Asterisk, waiting 3 years to have a new version it’s not ideal way. We maintain our own since 20 years now and this is a perfect compromise to have Debian support with always the latest version, security fixes and your own patches if you needed. Big thank you for all people who maintain Asterisk in Debian this last years.
@tootai
Thanks for adding this link to Debian Bug 1031046: this is exactly what I was after.
On a general point of view, for many end users, current Asterisk feature set perfectly match their needs and this has been the case for several years. These users don’t mind to be several Asterisk versions behind at the moment their system remains secure.
For them, the question is: what is the cheapest way to keep a system secure ? Compiling from source doesn’t help unless the source code (and various tools to built the binaries) is also kept up to date.
From Debian package maintainers point of view, the question is:
“How many CVE impacting Asterisk 20.2 will be discovered within the next 3 years ?
Who will check corresponding patches cleanly apply to Debian’s( lightly-adapted ?) Asterisk 20.2 and if necessary will modify these patches so that the can apply afterwards to Debian’s Asterisk 20.2 ?”
In 1031046 bug report, reporter mentioned 37 CVE during 2021-2022. During this period, Debian repo provided Asterisk 16.
So if I had to keep up, compiling from source for instance, I should have updated my Asterisk 16 source code at least 30 times (if case one new Asterisk 16.X.Y version corrects several CVE).
That is certainly not a light task or a light commitment.
I found it rather disappointing news, that Asterisk will not be in the Debian
stable version which is due to be released on 10th June, so I replied to the
“bug report” asking for some more information about the decision:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031046#20
I’m going to follow up with Jonas Smedegaard to find out what sort of
assistance he would require, but I’m reporting the dialogue here to ask
whether anyone else on this list is interested in helping to keep Asterisk in
Debian (as his reply says, in backports, if nothing else, for the time being).
I personally am far happier to install packages from backports than I am from
unstable on a Debian machine.
Feel free to reply to me off-list if you’d like to find out more, since this is
far more of a Debian thing than it is an Asterisk project thing.
Thanks,
Antony.
I wouldn’t hesitate to volunteer to help to have an Asterisk deb packages available.
I also wonder if selecting a dedicated repository would help to reconcile current Asterisk development practices with Debian rules.
More specifically, would you say porting every CVE patches to a fixed Asterisk 20.2 (as done in the past with Asterisk 16), requires more or less effort than applying a fixed set of Debian-originated patches (I think there are about 10 of them) to current Asterisk 20.X ?
Is publishing a different Asterisk 20.X version anytime a CVE is patched, something currently acceptable by Debian repo management rules even if the feature set slightly changes over time ?
Would Sangoma/Digium accept to host a community managed deb repo ?
Define “host a community managed deb repo”.
@jcolp:
Yes, of course 
I think the main question is the one about the most efficient way to write and publish patches in a deb package.
If upstream (Asterisk) write patches at only applies to lastest version of Asterisk 20, then is it simpler to repackage this very last Asterisk version or is it simpler to port the original patch so that is also applies to a different Asterisk version than the it was originally written for ?
It seems to me repacking requires sysadmin skills while porting a patch requires C programming skills and familiarity with Asterisk source code.
Is current Debian practice to port upstream patches ?
What do other distros ?
I can only speak from a project perspective, we don’t backport patches to old versions and they may or may not apply depending on what exactly was touched. It depends.
From a Debian sysadmin perspective, you should be able to update your asterisk package anytime you wish without fearing regression.
If changing from 20.2 to 20.8 removes one feature (because of a CVE), then sysadmin should be warned about that and have the possibility to cancel the upgrade.
I’ve never written such notices but I think I can learn to do so.
Similarly, with proper guidance, I think can follow a recipe which transforms an Asterisk 20.X version into a genuine asterisk deb package.
Alternatively, learning Asterisk C code would be much harder for me and out of reach, presently.
Same here. We use our own package for several years. Whenever a new Asterisk version comes out we update accordingly. This way it is also easier to get past “bigger changes” as it is pretty clear what happened and why (e.g. recently with the first github release).
@flofloi, @quintana
How do you build your own package ?
Do you include Debian’s patches (for instance the one that locate Asterisk sound files in /usr/share/asterisk) ?
We do, but we haven’t included the latest changes upstream (which unfortunately didn’t make it into bookworm anyway). E.g. we do not separate jansson and pjsip and instead do it the Asterisk way by building it with bundled jansson and pjsip.