Asterisk sources for FreePBX v17

FreePBX Development
1

Curious as to what sources were used to build the Asterisk deb packages found at deb.freepbx.org? Any insight in to this?

3

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.

1 Like
4
1 Like
5

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.

2 Likes
6

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.

7

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.

8
9

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.

10

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.

2 Likes
11

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.

12

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

13

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.

14

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.

1 Like
15

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 :thinking: :car: 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.:

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 :slight_smile:

16

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.

1 Like
17

Hmm, you didn’t say anything about verifying the source, you had mentioned
“the compiled version”

The thing I don’t quite understand is this sort of myopic view from the Linux userbase about binaries. I cut my teeth on Tektronix Unix and not only did you have to compile every interesting program you wanted to use from source - you had to compile gcc and the build toolchain using the crappy native Tek compiler before you could even start doing that…

Under FreeBSD, I always compiled all packages from source mainly because I had run into a number of times that favorite applications were abandoned, or their source disappeared. There were a few times I went to prior installs to obtain source…

It’s very unfortunate that Linux never put the effort into developing something like FreeBSD’s Ports system.

18

There is a difference between me compiling a .deb or .rpm for use and maybe passing it around for funsies or whatever and me doing the same thing under an open source license.

In this case, just linking to the Asterisk source isn’t enough for this. Part of the source is providing all the configuration options and other data as well. For example, we should be provided with the exact menuselect options used by the FreePBX .deb to configure Asterisk. We should know each flag, setting option, etc that was used to produce the final package.

You just can’t say “We compiled it with Asterisk, Postfix, Apache, etc” you need to provide the exact ways you build Asterisk, Postifx, Apache, etc. so any one else working with this package can verify and validate it’s working as expected.

19

I’m not arguing that. I’m saying 99% of the Linux userbase has their heads up their asses with this incessant demand for compiled binaries.

“When I was a Boy” us REAL men downloaded the SOURCE baby and COMPILED IT uh uh uh uh! We KNEW it was clean because we could run md5 against the entire source tarfile before we started!!!

By depending on precompiled binaries, it totally creates this problem of verification. How many times do you have to say “your creating your own problem and screwing yourself” before get it?

The GPL license was created to make copyrights “free” for SOURCE. Why would an end-user think it was even OK to run a compiled FOSS binary on FOSS in the first place? Oh yeah, because Linus told 'em that’s OK and none of them have ever done the equivalent of a “pacbuilder -world” on their distro.

It’s the entire package ecosystem that is screwed, here.

20

What is any of this supposed to mean?

The original question was about the source used to create the distributed packages.

Feels like there is some other conversation happening somewhere that you are answering to.

21

I’m wondering that myself since this is open source not sure what privacy leak can happen. All the code / pieces is open source, it can’t be private. It makes one wonder if this is fancyspeak for closed source code / pieces got put into an open source package.