Jump to content
  • 0

Third Party Modules


blesbill

Question

Hi,

I do see a lot of third party modules being developed and made available to the community in general, which is great but, I do have a few queries:

1. Are there any strict guidelines/rules applicable for developers of such modules?
2. Are these modules audited, validated & verified by Blesta before being made available?
3. Is the code within these modules opensource or encoded in some way?
4. Do the modules get re-audited/verified once any new updates are provided?
5. How much control does Blesta have over these modules in general?
6. In case the developer of such modules calls it a day and stops providing any required updates, would Blesta take over and provide updates to these modules.

Looking forward to hear from the Blesta team.

Thanks.
 

Link to comment
Share on other sites

10 answers to this question

Recommended Posts

  • 0
Quote

1. Are there any strict guidelines/rules applicable for developers of such modules?

There are guidelines which are listed here: https://docs.blesta.com/display/dev/Programming+Style+Guide but I'm not sure if Blesta check and force people to change it.

Quote

2. Are these modules audited, validated & verified by Blesta before being made available?

Not that I'm aware of they can be audited if the developer wishes to do so. But if they follow the guidelines on the link above they shouldn't have any issues because the Blesta core is stable.

Quote

3. Is the code within these modules opensource or encoded in some way?

Depends on the developer again, all Blesta modules / plugins / gateways are open.

Quote

4. Do the modules get re-audited/verified once any new updates are provided?

Same as point 2.

Quote

5. How much control does Blesta have over these modules in general?

None.

Quote

6. In case the developer of such modules calls it a day and stops providing any required updates, would Blesta take over and provide updates to these modules.

Nope.

PS these are from my experiences on the forum, the guys can add to the thread when they have time :D

Link to comment
Share on other sites

  • 0

Thanks Mike, I'll just add, re #2. We can audit the code for a module or plugin for a fee, and label it as "Certified by Blesta". We haven't done this yet for any 3rd party extensions, but we're open to the idea. Re #6. Maybe. This would be on a case-by case basis. But, in large, our recommendation is that the developer release the extension as FOSS on Github.

Link to comment
Share on other sites

  • 0
4 hours ago, Paul said:

re #2. We can audit the code for a module or plugin for a fee, and label it as "Certified by Blesta". We haven't done this yet for any 3rd party extensions, but we're open to the idea.

it would be a option for us . we have a large portfolio of plugins/modules that we rewrite them using namespace and Standard PSR .

Link to comment
Share on other sites

  • 0

Hey guys,

Thanks for your responses.

I strongly believe that anything which becomes part of Blesta and made publicly available which includes third party modules should:

1. Follow a set of strict guidelines/terms for developers
2. Should be audited, validated & verified by Blesta before going public
3. Not be encoded in any way - when Blesta is opensource, why should others be encoded?

If Blesta don't have the time for auditing such external modules, then they can form a review team for this process. They can request a couple of trusted developers from the blesta community to be a part of this review team.

Also, I would like to know how much of a threat will be an insecure module for a Blesta environment? What would be the impact?

Looking forward for your replies.

Thanks.

Link to comment
Share on other sites

  • 0
1 hour ago, blesbill said:

Hey guys,

Thanks for your responses.

I strongly believe that anything which becomes part of Blesta and made publicly available which includes third party modules should:

1. Follow a set of strict guidelines/terms for developers
2. Should be audited, validated & verified by Blesta before going public
3. Not be encoded in any way - when Blesta is opensource, why should others be encoded?

If Blesta don't have the time for auditing such external modules, then they can form a review team for this process. They can request a couple of trusted developers from the blesta community to be a part of this review team.

Also, I would like to know how much of a threat will be an insecure module for a Blesta environment? What would be the impact?

Looking forward for your replies.

Thanks.

Blesta is Open Code, not Open Source.

Encrypt the paid modules is necessary to protect the license system. 

Link to comment
Share on other sites

  • 0
4 hours ago, blesbill said:

Hey guys,

Thanks for your responses.

I strongly believe that anything which becomes part of Blesta and made publicly available which includes third party modules should:

1. Follow a set of strict guidelines/terms for developers
2. Should be audited, validated & verified by Blesta before going public
3. Not be encoded in any way - when Blesta is opensource, why should others be encoded?

If Blesta don't have the time for auditing such external modules, then they can form a review team for this process. They can request a couple of trusted developers from the blesta community to be a part of this review team.

Also, I would like to know how much of a threat will be an insecure module for a Blesta environment? What would be the impact?

Looking forward for your replies.

Thanks.

To add to Timothy Even Blesta has 3 files encoded for licensing reasons. It's up to you if you wish to use a third party and if Blesta forced them to be audited and verified that:

1. causes people to complain that it's taking ages to show up on the marketplace.blesta.com (See a competitor is a great example of that, a developer updated his script then had to wait days for it to be updated on the marketplace).

2. more cost for the developers for little costs (monthly prices) which then leads them to go.... Nah F**k it can't be bothered with that => No third party addons.

So you have to do your own research by using trials or asking them, Blesta isn't the php police.

Link to comment
Share on other sites

  • 0

In an ideal world, it would be great if everything was open and audited with our seal of approval. Because Blesta is extensible, 3rd-party developers can create their own extensions. Those extensions are therefor their own intellectual property. So, they can choose to license it how they wish, encode it or not, have it audited or not, etc etc.

If we were to put strict rules on 3rd-party extensions, it would result in fewer such extensions being available and still be no guarantee that the ones available, and audited, with our seal of approval could never be exploited. There is some risk with any software, so it's up to people to assess that risk and make decisions on what to use.

I like the idea of an optional, paid "Certified by Blesta" process for extensions, because it's voluntary and ensures people that the code was reviewed by Blesta developers and meets our standards for security or code styling. This can add value to 3rd-party extensions by creating a level of trust with users, but there would be a cost associated and it wouldn't make sense for obscure or open source extensions. "Certified by Blesta" is not something we would require though, because it would have a negative impact on the availability of extensions. We want to make it as easy as possible for 3rd parties to create more extensions, not less.

Link to comment
Share on other sites

  • 0
1 hour ago, Paul said:

In an ideal world, it would be great if everything was open and audited with our seal of approval. Because Blesta is extensible, 3rd-party developers can create their own extensions. Those extensions are therefor their own intellectual property. So, they can choose to license it how they wish, encode it or not, have it audited or not, etc etc.

If we were to put strict rules on 3rd-party extensions, it would result in fewer such extensions being available and still be no guarantee that the ones available, and audited, with our seal of approval could never be exploited. There is some risk with any software, so it's up to people to assess that risk and make decisions on what to use.

I like the idea of an optional, paid "Certified by Blesta" process for extensions, because it's voluntary and ensures people that the code was reviewed by Blesta developers and meets our standards for security or code styling. This can add value to 3rd-party extensions by creating a level of trust with users, but there would be a cost associated and it wouldn't make sense for obscure or open source extensions. "Certified by Blesta" is not something we would require though, because it would have a negative impact on the availability of extensions. We want to make it as easy as possible for 3rd parties to create more extensions, not less.

I agree with both of you @Licensecart aka Michael Dance & @Paul as the only reason I release more modules for blesta first before I do any other panel is for exactly that fact it is easy to do so there is no requirements and I can do with it as I see fit because if anthonyl and blesbill had their way all of the developers including me would do exactly like Michael Dance said and go far away from blesta as possible and not ever release another module for blesta again after that until it was lifted lol as the whole point is we as the blesta community as a whole are trying to drive people to blesta including developers not in the other direction which would be driving them away from blesta and to competitors as you bet if you start requiring nonsense like that I and every other developer would be running away fast as we can and dropping all support for blesta for development lol. Here me We do not want that! We don't want the other competition to get any bigger than they already are! Look at CrapMCS(WHMCS for people who haven't been watching the forums here for a long time) has way more modules than any other panel combined if we try implementing what blesbill and anthonyl want blesta would be dead in comparison to the competition! which means people will go to the competition instead of blesta! because they cannot get a module/plugin/gateway that they need because no developer would even touch blesta after that! I have an idea let's tell anthonyl and blesbill to do a social experiment build a panel and put these nonsense restrictions and requirements and see how many developers even bother with their panel because we all know besides them that no developer would ever even bother touching that panel and then take those restrictions & requirements away and then see if the developers even come back they might or they might not because to be honest in my opinion if you put those rules & requirements & restrictions on developers for a panel you have already burned your chances of me ever considering that panel for developement ever.  

Link to comment
Share on other sites

  • 0
2 hours ago, timnboys said:

Lots of blah blah 

Look, I get you're a college kid, but stop acting like a child. I'm not going to entrust my billing system data and its integration with critical service providers to plugins that could be easily exploited because of cowboy coding practices. I don't trust your coding. I don't know it. There's no history there. Even your "fix" of the Digital Ocean module was a half-fix with problems. 

So yes, until that trust and history is built, there's absolutely no way I'll use plugins made by your or others that encode their files with no way to get a good look at their security. That's my choice. 

It's up to you to figure out if you want to spend that extra money to do that or not. No one's forcing you or anyone else to do it

Link to comment
Share on other sites

  • 0
36 minutes ago, AnthonyL said:

Look, I get you're a college kid, but stop acting like a child. I'm not going to entrust my billing system data and its integration with critical service providers to plugins that could be easily exploited because of cowboy coding practices. I don't trust your coding. I don't know it. There's no history there. Even your "fix" of the Digital Ocean module was a half-fix with problems. 

So yes, until that trust and history is built, there's absolutely no way I'll use plugins made by your or others that encode their files with no way to get a good look at their security. That's my choice. 

It's up to you to figure out if you want to spend that extra money to do that or not. No one's forcing you or anyone else to do it

let me give you a pm on this because I don't want this thread to be another "firestorm" over something that can be handed privately.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...