Curious as to what sources were used to build the Asterisk deb packages found at deb.freepbx.org? Any insight in to this?
Well for any deb package that is created by Sangoma that is Open Source they are required to provide the Source deb so anyone can take the source and build the same deb and verify its byte for byte the same as the compiled deb package. I took a look and not seeing any source deb files anywhere. Hopefully this is just an oversight or we are missing where they are being stored @penguinpbx @mwhite.
That points to the package repository, we’re asking where the source that was used to build those packages are at. They must provide the actual source code that was used to create the packages.
The open source DEBs are being generated internally for v17 and should be published publicly the same as SRPMs are for RPMs in v16 (although that’s had hiccups in the past as well.) There are some internal tickets open to address this that are currently undergoing QA testing.
As for reproducible builds, we can try making that happen, but for reference, the current Debian policy manual v4.7.2.0 section 4.15 Reproducibility says “Packages should build reproducibly” – not must – and that’s for their official packages, which OP is not referring to.
Right and the question was, what sources are you using to internally generate the .deb package files? Where are these sources from?
I’m not asking about the final .deb and if it’s public or not. I’m asking about everything that was used to make the .deb package.
Hmm that last reply looks like a bit of a troll.
Icinga pulled some nonsense with their packages a few years ago, taking their previously open-source packaging scripts down so they could sell packages as a “premium” offering separate from the open source stuff. Don’t know about the legality of it, but it sure frustrated a lot of their users.
So your going to take stance that because it says should and not must that you are compliant with the GPL. You might want to read what the GPL has to say. It’s very clear. You have to provide the source. You can’t just say the source is from this other site and not provide the Source RPM or DEB as nobody has the ability to confirm that the compiled version is the same as the source with the source file.
Stop playing your word games with the community and honor the request under the GPL which says on request you have to provide the source. It’s been requested by both Tom and now myself. My next email with be the the Free Software Foundation for your refusal to honor the GPL.
Tony, considering the same organization that is building FreePBX is also the maintainer of Asterisk itself, they ARE following the GPL - if they are using the public github distro of Asterisk to build the FreePBX debs.
Just out of curiosity what happens if you try this under debian?
cd /usr/src
wget https://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-22.3.0.tar.gz
tar xvf asterisk-22.3.0.tar.gz
cd asterisk-22*/
make
sudo apt-get install checkinstall
sudo checkinstall (select build the deb)
then do the bit comparison with the deb.freepbx.org Asterisk deb?
As I see it if they ARE using the public github distro then all they really need to do is provide the exact, reproducible, steps THEY used to build the deb. They don’t need to provide the source because they ALREADY provide the source.
When I was building Asterisk from source, I’m pretty sure that the default build configuration was to optimise for the processor on which it was being built. I would hope that FreePBX is not built that way, as it will cause illegal instruction errors on machines in the same architecture family.
Also, I seem to remember that the build date and build machine name are embedded in the main binary, so I don’t think a binary compare will work. (I have a feeling that this is more generally present in ELF binaries. You would need an intelligent compare, that ignored this. I think it also contains information on the library versions against which it was linked, and you would definitely have to make sure that there were no changes to structures in library header files.)
I just built it a few days ago:
root@phony:/usr/src/asterisk-22.3.0/main# strings /usr/src/asterisk-22.3.0/main/asterisk | grep 2025
Asterisk %s, Copyright (C) 1999 - 2025, Sangoma Technologies Corporation and others.
Asterisk %s, Copyright (C) 1999 - 2025, Sangoma Technologies Corporation and others.
2025-04-24 09:05:13 UTC
COPYRIGHT_TAG “Copyright (C) 1999 - 2025, Sangoma Technologies Corporation and others.”
BUILD_DATE “2025-04-24 09:05:13 UTC”
root@phony:/usr/src/asterisk-22.3.0/main#
Yup, the build date and time appears and the BUILD_HOSTNAME also appears in the resultant Debian 12 binary.
configure does have
checking for -march=native support
in it but all I see in the configure.log is --enable-multiarch in the gcc flags.
Ted I would disagree here as the menu selects are predefined in their package creation so without knowing what they are doing in the make of the DEB package you have no way of verifying the source and if things have been injected. Hence why the Source RPM has always been provided before. Since Sangoma moved from RPM based systems to DEB they have not provided the source package. It’s really sad that weeks later and numerous post they still have not provided the source package. What is Sangoma hiding here @penguinpbx? I am sure this is why Tom has requested the actual Source DEB.
Apologies for the delay – I’ve recently taken ownership of the related GitHub issue and expect a resolution of this oversight soon, hopefully by the end of this week. Currently, it looks like a combination of a (potential) data privacy/leak issue in a non-binary compilation artifact, a repo merge issue between our internal source and binary repos, and a mundane permissions issue.
To deflate some expectations: please do not expect bit-for-bit reproducible builds at this time. While a noble goal, that is beyond the scope of the GPL as well as the current Debian project policy (as was linked previously.) Even one-line changes like automatically updating the timestamp in a file at compile time will result in binaries with different hashes. For some historical context, you might also consider the more common past use of proprietary compilers of GPL’d source code - those binaries were totally unverifiable if you lacked the compiler because you couldn’t even produce them, but that did not mean that there was a violation of the GPL.
FWIW the FreePBX distro’s source RPMs were sometimes a struggle to get right as well – and somewhat ironically were discouraged from use by previous stewards. Below is a trip down memory lane
that was explored as part of this renewed effort for automatically publishing source packages, including associated detours to check in on the history/present state of out-of-upstream-tree patches to Asterisk (it looks like way fewer if any nowadays – wanted to make sure we weren’t missing any ;-), reviewing the validity/accuracy of the byte-for-byte matching binary demands, trying to find links to other tools, etc.:
- 2012 - Source RPMS
- 2014 - Patching Asterisk on FreePBX distro
- 2015 - RESOLVED: How do I apply a patch to Asterisk on FreePBX distro?
- 2017 - Asterisk 13.16 shmz src rpm file
- 2018 - Srpm sources
- 2018 - SRPM availability
- 2019 - Source RPM for Asterisk 16.3?
- 2019 - Missing Source RPM
- 2022 - SOLVED: Sangoma-devel RPM not available?
After reviewing those discussions, what really came through was the positive tone and contribution from many different community members. For example, the users documenting and sharing the build-from-source steps – really nice to see and very helpful to fellow users who came later and wish to extend this amazing product in to the future
Yup and we always fixed the issue and engaged people if we missed making sure to publish the source RPMs versus the current ignore attitude that has happened here until the past few days.