Any way to disable module signature checking for an individual module?

Well, yes, I guess I may have been too glib there.

We’ve gone over this a couple of times in various other threads, but this is the problem:

If your machine has been hacked then YES, they have access to your system. That’s what this entire thing is about. It’s successfully detected and alerted people about security vulnerabilities in their systems, and their machine being attacked and tampered with, without their knowledge.

So all I can suggest is get in touch with the person who wrote the module, and get them to sign it.

Unfortunately I have no idea how to get in touch with the original author of the module. I think someone said once that his name was Naftali something or other, and I don’t know if I am spelling that right. But the impression I got was that he long ago abandoned his modules and that along the way someone, I have no idea who, updated the module I am using (Dialplan Injection) to make it work with newer versions of FreePBX. I wish someone could find the author and convince him to update it because it could stand a bit of additional work - for one thing it plants itself in the top menu bar rather than in the Applications sub-menu where it should be. But I have no idea how to get in touch with him, nor whether he would even have any interest.

I guess I will just have to leave the module signature checking disabled globally then, if there’s no other way to avoid it. I could tolerate the blaring warning notices when I log into FreePBX but it’s the daily e-mails when there is nothing else wrong that are the problem - pretty soon I would just start ignoring them altogether and would never know when something actually needs attention.

Your machine will re-enable signature checking by itself.

Module signing is a SECURITY thing. There’s no reason why you, as a standard user, would want to leave module signing turned off. If the owner of the module refuses to sign their module, then that module shouldn’t be trusted. It’s pretty much that simple.

We don’t make it hard - in fact, we go out of our way to make it EASY for people to sign their own modules with their own key.

So, perhaps I’m asking the wrong question. What does this dialplan injection module do that you can’t do any other way?

–Rob

Well, Rob, on the other hand, there’s no reason that I, as a standard user, should not have the right to decide how much or how little security I need on my system. Module signing is something new; at some point prior to FreePBX 12 nobody had it and most of us never had any problem. Now it is introduced as something new and you just assume that forcing it on everyone won’t cause problems for anyone. Yet I am showing you a specific usage case - where I want to use a third party module that has been around for years, from a source I trust, and yet FreePBX raises constant complaints about it. If FreePBX insists on turning module signing back on, then I will simply remove my e-mail address from FreePBX so that I never receive its nagging.

You may not want to trust the module, but I do. Shouldn’t I have that right? Whose PBX is it, anyway?

I don’t disagree that you make it easy for people to sign their own modules. The problem is that there are a few very good modules that have been around for a very long time, that have not harmed anyone’s system, but which are unsigned because the original author is no longer around to maintain them. Now, if you had a path where I could get a user key for a module, where I could apply it to a module I don’t own and assume the risk for using that module, and the process for getting such a key wasn’t too onerous, I’d be happy to get one. Assuming you don’t ask for too much personal information, that is - remember, I only want a key to run this module on one system, my own, and therefore shouldn’t have to go through the same process a corporation would. And keep in mind that I can’t guarantee anything about the module - I don’t know if it’s open source, closed source, or lost source. The agreement an author might happily sign has terms that I, as a mere user, cannot in good conscience agree with. Sure, I could speculate or lie and tell you whatever you need to hear to get a key, but would you really want that?

So may I suggest you give serious consideration to giving people who want to use a third party module on their system an easy way to get a single-use key that is only good for use on one specific FreePBX installation.

By the way, the question that forms in the back of my mind is this: Suppose a hacker has penetrated your system and wants to install his own module that will act in some malicious manner. What is to stop him from using the method for getting a key and simply applying it to his rogue module? Sure, you’ve delayed him a little bit, but would you really know if he gave you totally bogus information? My point is that although you are seriously annoying users that want to use unsigned third-party modules, maybe you’re not providing as much real security as you think.

This is getting way too long so I will answer your question in another reply.

1 Like

Dialplan Injection gives you an easy way to add a few lines of custom dialplan into the call flow. So for example, once a call arrives via an inbound route, if you wanted to perform some specific task before sending the call on to its destination, you can add the dialplan in a Dialplan Injection. Then you make the destination of the Inbound route the Dialplan Injection, and the destination of the Dialplan Injection the extension, ring group, announcement, or whatever that you want the call to go to.

Maybe you’re wondering what the big advantage is of doing it this way as opposed to dropping the added dialplan into extensions-custom.conf, and using a custom destination. There are three advantages I can think of offhand. For one thing, you don’t have to worry about getting the syntax right in the custom destination. And your added code is more integrated into FreePBX; you don’t have to deal with extensions-custom.conf at all. But the real advantage is that the Dialplan Injections module offers a standard Destinations dropdown menu, so that after your lines of dialplan have executed you can send the call on to wherever it needs to go. Without that dropdown it is VERY difficult to determine what the last line of your custom dialplan should be, and also you have no control over a destination that may change.

For example, say you have an extension 2345 but you decide you want to change 2345 to a ring group, so you delete and recreate the extension with a different extension number (I have never understood why you can’t easily renumber an extension) and then create your ring group. But your custom context still points to the extension, maybe in the correct way and maybe in whatever way the person creating the custom context found would work. When using a module such as this you would get a warning that you have a bad destination. But if you are just adding dialplan in a custom context you are flying blind, and it’s very difficult to determine where your re-entry points should be, and you get no warning that anything is amiss if you delete or in some other way modify the entry point of a destination.

Actually, speaking of which, it would be great if each module page would show a “custom context entry point” for that module. For example in the case of the aforementioned ring group 2345, somewhere on the page for that ring group it could show the context and entry point for that ring group. I am just using a ring group as an example, but basically for anything that can be specified as a destination in the dropdowns, there should be an easy way to see the entry point, especially if for some reason you are really against the idea of people using something like the Dialplan Injection module to make their lives a bit easier and reduce the chance of errors.

EDIT: I just found the page on the POSSA site that gives a full description of Dialplan Injection, if you are really interested. It is at Home · POSSA/freepbx-dialplan-injection Wiki · GitHub

And it gives the author credit as “naftali5”, but no email address or contact information.

1 Like

At some point, someone would go ‘Well, I installed XYZ module that I got from ABC, and suddenly my machine has been hacked’. At which point we revoke the key that signed module XYZ and it is immediately blocked.

But THAT reason is the exact reason why we CAN’T…

Because nothing is stopping the baddies from doing exactly that.

The whole ‘signing’ thing is you generating a key, saying ‘I accept responsibility for this key’, and signing a form.

In fact, there’s nothing stopping, as far as I can see, you signing the module yourself and distributing the signed module. You’re releasing it under the GPL, so you’re not in violation of any licence agreement. As long as you don’t claim it as your own, or remove any copyright notices from it, I can’t see anyone having any issues with it (This is not an official statement, I am not a lawyer, blah blah).

So, lets say you wanted to do that.

You’d generate a key: Sangoma Documentation

You’d then fill in the form here http://literature.schmoozecom.com/EUA/GPG-KEY-SIGNING-r1.pdf and email it back with the key fingerprint you gerneated in the first part.

Then we sign it and send it back off into the cloud. While that’s happening, you download the devtools repo with this command:

git clone Browse FreePBX / devtools - FreePBX GIT

And you’re ready to go (more in-depth instructions are at Sangoma Documentation if you are interested).

All I’m trying to say - it’s not hard. Anyone can do it. Lots of people have. You could volunteer to be the person who signs modules that no-one else cares about any more :sunglasses:

–Rob

I’m willing to do that for modules I run on my system. I am not prepared to take on that responsibility for the rest of the world.

I live in the United States. Lawyers here live and breathe technicalities.

Have you actually READ that form? I understand you’re trying to be helpful, but what you’re telling me and what that form actually says are two very different things:

Please allow me to quote:

  1. USE RESTRICTIONS
    2.1. You are prohibited from using your Key:
    2.1.1. to sign a module that is not Open Source and GPL Compatible as defined by the FSF at Main Page - GPLv3 Wiki index.php/Compatible_licenses
    2.1.2. for or on behalf of any other organization or person,;
    2.1.3. to distribute malicious or harmful content of any kind including, but not limited to, content that would otherwise have the effect of inconveniencing the recipient of such content;
    2.1.4. in a manner that transfers control or permits access
    2.1.5. in any way that could decrease the security of the FreePBX Module signing process.

Regarding 2.1.1, I have no idea whether the module is GPL compatible. And I only could assume it’s open source because it’s hosted at POSSA.

It seems that doing what you suggest would be a direct violation of 2.1.2 since it is not my code.

Regarding 2.1.3, how do I know that this code is not going to do something that will inconvenience the recipient? That’s a ridiculous clause because anyone could claim they are inconvenienced by anything. I say receiving a daily email nagging me about an unsigned module is an inconvenience!

Regarding 2.1.4, isn’t the whole point of doing this to permit access to the module?

I won’t even get into that whole indemnification section in section 7. My point is that there is no way that I, in good conscience OR from a standpoint of not wanting to expose myself to legal liability, could ever sign such a document. The very first line on the form asks for a “Business Name” and I am not a business. If I were, and I were incorporated, then I suspect my lawyers would tell me that I’d be an idiot to sign this (like you, I am not a lawyer, but I’m only willing to assume the risk of running this module on my system, not on every other system in the world).

I have to tell you, this whole thing is starting to smell to me like a scheme to discourage anyone from writing third-party modules for FreePBX. Let me ask you this: Have you actually read that agreement, all the way through? And if you had been forced to sign such an agreement in order to release your first FreePBX module or code, would you have done so? It just seems to me like all the “freedom” to distribute third-party modules for FreePBX is being sucked out of existence by this agreement.

If you can’t change the module signing process, maybe you could at least come up with a user version of that agreement for use by individuals that are only willing to sign a module for use on their own systems, and are not willing to indemnify anyone else against anything (that entire section 7 is just SO WRONG, especially in the lawsuit-happy USA).

Anyway, I don’t know if you are considered to be a representative or employee of Sangoma, but if you are you probably ought not to advise users to execute a fraudulent document. I don’t know if “But Rob said it was okay to do that” would be any kind of legal defense, but I certainly don’t want to be the one to test that theory.

2 Likes

You don’t have to put your signed module back on the internet. There is no requirement for that. You can sign them for your own systems and the only people that would know are Sangoma and yourself.

We’ve had many big companies sign this. Their lawyers don’t have an issue with it. But again, you aren’t a lawyer.

That’s sad that you think that. Please take a step back and look at who runs and maintains POSSA. There are two people involved there. Lorne and Myself. I work for Sangoma and I manage POSSA. If this were written to discourage third-party modules then don’t you think I’d have an issue with it. In fact it was written by Rob as a security prevention method. He came up with the idea and he designed it. Then he and I both pushed to be able to get third party signing. Unfortunately when we “sign” a module, we are saying we support it. This opens up the flood gates for lawsuits against us.

Take for example if you created a visual voicemail module. Then you got it signed by us. Then the company who owns the patent noticed it was in 5 freepbx boxes (of the thousands out there). They then noticed that it’s “signed by Sangoma”. So now they start to file a formal lawsuit because we “officially” support it. This is why the legal mumbo jumbo exists in it’s present form.

Maybe it’s just me, but I think this thread is like a political debate. We are providing our view and you are providing yours. But neither side is compromising or budging. We could go back and forth for days. We have no intention to add a user agreement. How are we suppose to know you ARE a user and NOT a company. Just because you said it on the internet doesnt mean it’ll hold up in court (see your section on “But Rob said it was ok to do that”… “but editor SAID he was an end user”).

You obviously don’t like what we’ve done there/here. I’m not judging but I also don’t feel like we are convincing you of anything (same as you aren’t convincing us). If you really think there’s an active community of third party module developers out there that are discouraged by this agreement I think you are highly mistaken. Before this agreement there were all of two third party module developers. Many have already came and went.

Hold on a second here…

There is a very obvious question that immediately springs to mind. If you and Lorne are the two people involved in POSSA, then why don’t the two of you sign the modules you carry in your repository? This whole situation just gets more and more nonsensical from my point of view. You’d ask me to complete a legal document, in which I’d need to fraudulently agree to certain things, in order to get this module signed, when you as the maintainers of the repository aren’t willing to take this step for the modules you distribute?

I think my mind has just been blown.

I’m not judging anyone either and I certainly didn’t intend for this to turn political. All I am saying is that you’ve created an untenable situation for FreePBX users who wish to use modules created by third parties that for whatever reason are unsigned. As you’ve noted, you aren’t going to budge, and I certainly have no intention of fraudulently attesting to things I have no knowledge of or agreeing to terms I have no legal right to agree with. In the end, my position is that it’s my PBX, and I should have the right to run whatever software I want on it without getting nagged because a module isn’t signed. So until and unless this situation is resolved in a better way, I’ll just leave module signing disabled, and if it insists on turning itself back on (I actually think Rob is wrong about that), I’ll just remove my email from the system. One way or another, I WILL stop this system from nagging me about that module.

But now I am really confused, because it would seem to me that the maintainers of the POSSA repository would be the logical persons to sign the modules in their repository. If this is such an easy and painless process, why not simply get one key for all the modules you offer, and that solves the problem for everyone. On the other hand, if you are unwilling to do that because of some legal considerations or for whatever reason, then why should I as a mere user take that risk, especially knowing full well that I’d be committing an act of fraud by completing that document for someone else’s software? In short, why are you encouraging me to take an action that you, yourselves, apparently seem reluctant to take, when in this case you are the most logical parties to do so (assuming that the original author is unable or unwilling to get his modules signed)?

EDIT: And if there is something in that document that gives you pause in completing it, you COULD always change the language in the agreement. Just saying.

As for your last point, I have no idea how many third party developers there have been, and neither of us know if there might have been more if the barrier to releasing a third-party module was lower. There is no part in arguing that; it’s like debating how many angels can dance on the head of a pin, so whatever point you were attempting to make there, I’ll concede it for the sake of trying to address the real issues here.

I am not able to sign that agreement because Lorne would also need to sign the agreement. I can’t sign it on his behalf. He has chosen to not sign it (some do some don’t) I don’t want to go into details on that as it’s his decision not mine. Now you may ask “well why do you host it”. That is a question I can’t answer. Lorne is the one who uploaded it.

Comments like this make me wonder if you are taking this thread seriously.

Right. And because it’s GPL you can edit framework and remove the nagging code yourself. Signature signing is all in the open and not obfuscated, anyone could remove it and run a modified version of FreePBX.

Rob is right. It will turn itself on when you check online for updates.

I am not reluctant. I can not sign it. I have already “signed” it. I sign the keys. I’m the guy that makes this work. So me signing it doesn’t work when there are multiple people involved in POSSA, I have to get the other party to sign it as well.

I just wanted to provided some insight. I did not mean for this to get out of hand, nor to be called out.

Okay, but can you put yourself in my shoes for a moment and ask yourself how you would feel if you were asked to fraudulently sign a document with regard to someone else’s software, but the maintainers of the repository holding the software were not willing to do it?

Take a song for example. There are several people who might have a right to complete a legal document that eases restrictions on how it can be distributed and used. The author, publisher, and probably a few other corporate entities might have such a right. The individual user would have no such right and would be understandably perplexed if asked to complete such a document, while at the same time being told that the publisher or distributor was unwilling to do it.

Two things wrong with that, first of all I am not a programmer so I’d have no idea how to do that, but second is, supposing I could do that, wouldn’t a software update that includes the framework module just remove the modified code? So I would be right back where I started.

As for the other comments, you have explained why the modules aren’t signed by anyone at POSSA, and it’s not my place to pass judgment on that. All I ask is that you don’t expect a user such as myself to do something that is not something that should rightfully be done by a user, if the software author or a maintainer of the repository is unwilling to do it. Especially not when I would be in violation of the agreement the moment I signed it.

An honest question: If you were in my shoes, and were not connected with the FreePBX project in any way, can you honestly say that you would complete and sign that document for a module you had not created?

A general comment. In all this I think we have gotten sidetracked from the original problem. The reason I want to use the Dialplan Injection module is because it gives me the destination dropdown that lets me select where the call flow will go after it executes my few lines of custom dialplan.

So may I offer a suggestion, but in doing this I must state up front that someone else would need to write the code because I’m not a programmer. So please don’t say “send code” because I can’t do that. I’m just offering this as a suggestion; if no one cares to do it that’s fine.

My suggestion is simple: In the Custom Destinations module, you have a way to send a call out to custom dialplan, which I suppose typically resides in extensions-custom.conf. What you don’t have is an easy way to proceed from your code to wherever you want to go next, after your bit of custom code has run.

So why not add a destination dropdown to the custom destination module, that would suggest what the final line of your custom code needs to be. So if, for example, you wanted to go to ring a particular extension, it would give you the CORRECT goto link for that extension. This would not prevent the problem of no notification if the extension is deleted, but at least it would assist users in jumping to the proper place in the FreePBX context.

Or alternately, maybe there could be a separate information page that lists all the entry points for the various extensions, ring groups, announcements, etc. so that those that need to use a few lines of custom dialplan can find the correct re-entry points back into FreePBX.

This is just a suggestion and I won’t be surprised if it’s ignored but at least it would give people in my situation enough information to avoid the use of the Dialplan Injection module, since it seems that there isn’t going to be any resolution on that issue.

Sigh Honestly, I’m quite disheartened by this. The document says, in essence:

‘Don’t do anything bad with your key. Don’t pretend to be someone else. Don’t let someone else pressure you into signing their modules, they should sign it themselves. REALLY don’t do anything bad with your key’. We had a lawyer look over it, and they changed the wording slightly, but that’s the essence.

The indemnification clause is boilerplate. If we get sued because of something you did, it’s your fault, so you have to make it good.

I’m actually having difficulty trying to figure out another way to interpret it,

It’s just us covering our arses. You’ve agreed to the same or similar terms in the last 10 licence agreements you’ve happily clicked ‘agree’ to.

Anyway, I’m happy to start a new thread if you really want to go through the agreement line by line. I wrote the first few drafts of it before it was handed off to the lawyers, so I know why every line is there, and I honestly don’t think there’s anything wrong with it. Anyway, on to the other question…

1 Like

That would be something like (in the custom dialplan)

exten => s,n,Goto(ivr-2,s,1)

I’m disheartened by the fact that the people who maintain the repository seem to think it would be more appropriate for me to sign their modules than they. Rather than wondering why I don’t want to do it, shouldn’t you be wondering why they won’t? Like I say, I’m not here to judge, I just hate being asked to do something that someone else is not willing to do even though by all rights it would seem that logically they would be the most appropriate person(s) to do it.

Well, it’s a bit different when it’s a document where you are asked to identify yourself using personal information, as opposed to some anonymous click-through agreement (and by the way, I am never “happy” about those things).

I really don’t, because I can already see how it would go, and I don’t think either of us would be happy with the outcome. I actually think you’re one of the good guys, and I’m sure you had the best of intentions, but I don’t know if people in your part of the world are as lawsuit-happy as some people and companies in the USA. I just want to give myself as close to zero legal exposure as I can possibly achieve. Please consider that just as you guys want to cover your arses, I’d like to keep mine covered too!

Right, so to use that example, let’s say I have three IVR’s. How do I know which one is ivr-2, or whether any of them are? If I could go to my IVR pages and each one had a line that showed what its destination would be if you wanted to access it directly, then I would know. And how do I know the proper syntax if it’s a ring group or an extension or an announcement?

I agree that it’s very easy to do it that way IF you know the proper syntax for the destination. If there were a page that listed all the possible destinations on the system, I could use that as a reference, but there isn’t. If the destination were shown on each individual configuration page, I could go there and look it up. If there were a page were you could pick a destination from the standard destination dropdown and it would show you the equivalent destination written out, that would be a huge help. But none of those aids exist, and that’s why I am using Dialplan Injection.

Put it this way, suppose I said to you, after my bit of dialplan is finished, I want to go to the “Friends” IVR. Would you be able to tell me how to write that? I’m guessing not, because neither you nor I would know the number associated with that IVR. But if somewhere in the “Friends” IVR page it said “Custom Context Destination: ivr-2,s,1”, then I would know and could use that at the end of my bit of added dialplan.

Dialplan Injection really is a great little module for adding small bits of dialplan, and I’m just really sorry to hear that it’s apparently been abandoned.

It’s actually the ID of the IVR in the url - For example, your link will look like this
http://192.168.15.5/admin/config.php?type=&display=ivr&id=2

That id is the number you’d use.

That’s a good idea!

I’m flying to Sydney this weekend (Easter with the Family), but remind me about that next weekend, and I’ll see if I can spend an hour or so knocking that up. It wouldn’t be hard at all.

–Rob

Ah, I never realized that. So for an extension with the url http://192.168.1.80/admin/config.php?type=&display=extensions&extdisplay=1025 it would be extensions-1025,s,1 or if the url were http://192.168.1.80/admin/config.php?display=ringgroups&extdisplay=GRP-1101 it would be GRP-1101,s,1 ?

Thank you, I very much appreciate that. I hope you and your family have a great Easter holiday!

Not quite. An extension would be Goto(from-internal,1234,1), and you could do the same thing with a ring group - the ‘from-internal’ context is where phones send their requests to.

This gets slightly more complex if you’re using Class of Service of Extension Routes, but that’s the idea. Actually, ring groups have their own context ‘ext-group’, so you could bypass the from internal context if you DID have CoS or ER, and Goto(ext-group,600,1) … but I’m probably over-complicating things :sunglasses:

So lets say you wanted to run an AGI before every call that every extension dials.

You set their context to be ‘custom-extdial’ or something, and then in extensions_custom.conf add this:

[custom-extdial]
exten => _X.,1,NoOp(Entered extdial with ${EXTEN})
exten => _X.,n,AGI(/your/agi/script.agi)
exten => _X.,n,Goto(from-internal, ${EXTEN}, 1)

That’s just it, I want to go to the correct entry point for a destination, so everything works as it should. Also, this is used for calls coming from the outside, so I would hope that sending a call to from-internal at that point would not be any kind of security risk. Right now the destination of the inbound route is the Dialplan Injection, so I just wonder if by that point the system has done all the security checking it needs to do, in order to make sure an incoming caller can’t hop onto an outgoing trunk and make calls. Assuming that I don’t do something really stupid that gives them such access, that is.

For now I’ll wait until you get back and we can talk more about this. Thank you very much for your help.

Then I’d set the incoming context to something different - ‘from-pstn-prehack’ or something. Do your stuff in that context, and then send it to from-pstn. Then you don’t need to even care about destinations, you just do it through the GUI.

I do stuff like this all the time… For example, a common thing is that I want people to be able to push ‘redial’ to call back an external number that called them. But the caller ID needs to have an extra zero added to it, so they go out the right route.

So in the Dadhi incoming trunk, rather than ‘from-pstn’ I set the context to ‘change-callerid’ and do this:

[change-callerid] exten => _.,1,Set(CALLERID(num)=0${CALLERID(num)}) exten => _.,n,Goto(from-pstn,${EXTEN},1)

Then I don’t need to -ever- care about module changes, as that will always work forever. And it’ll upgrade painlessly for the foreseeable future.