Don't use wildcard dependencies

[millenium-codebug]

composer.json lists many wildcard dependencies:

        "zendframework/zend-http": "2.2.*",
        "zendframework/zend-mail": "2.2.*",
        "videlalvaro/php-amqplib": "2.*",
        "phpoffice/phpspreadsheet": "1.8.*",
        "ezyang/htmlpurifier": "4.*",
        "smarty/smarty": "3.*",
        "phpmailer/phpmailer": "6.*",
        "league/iso3166": "2.*",
        "guzzlehttp/guzzle": "6.*",
        "stevenmaguire/oauth2-microsoft": "2.*",

Versions should always be pinned to a major version so that they don't break when the interface changes with major updates.

Also the following is abandoned:

• videlalvaro/php-amqplib
• zendframework/zend-http
• zendframework/zend-mail

I would also recommend to insert ALL dependencies (adodb for example) in ONE composer.json and please don't commit the vendor

./gdpr/include/smarty/composer.json
./modules/Settings/ProcessMaker/thirdparty/cron-expression/composer.json
./modules/Settings/ProcessMaker/thirdparty/jqcron/composer.json
./modules/VteSync/composer.json

Maybe you should evaluate violinist.io to automate the dependency update process

[nileio]

@millenium-codebug can't agree more - the dependancies are all over the place. I am actively working on a fork https://github.com/mavenea/mavencrm to fix many issues and provide a single click install - check out the backlog and roadmap and what is being worked on. I will include your suggestions

[davidegiarolo]

@millenium-codebug thank you for the advice, we'll pin the version with the right ones. about the zend libraries using the new ones (laminas for example) is a long time process so right now we prefer to fix bugs and maintain those old libraries by ourselfes, we use them mostly for the messages module. we take a look also to violinist.io in order to see if it can helps us

@nileio nice to see that you like our software! about the forks, personally i have an opinion that i want to share with you. a fork is a nice idea when:

• the vendor don't mantain it anymore and you need to keep project alive
• you add some core functionality to the product (for example we added bpmn engine, messaging, syncs and so on) I can't find your roadmap so may be i miss some of your vision but let me say that we aren't in one of the two scenarios above i should be better to contribute to improve and to fix directly this project. For example we are very interested to see your approach to the single click install! In any case fell free to fork the license permits that, of course, and you are welcome regards

[millenium-codebug]

@millenium-codebug thank you for the advice, we'll pin the version with the right ones. about the zend libraries using the new ones (laminas for example) is a long time process so right now we prefer to fix bugs and maintain those old libraries by ourselfes, we use them mostly for the messages module. we take a look also to violinist.io in order to see if it can helps us

Hi @davidegiarolo, I think that your are lying about the fixes of "those old libraries" in composer.json you should load a VTECRM/zend-http package instead of the official and deprecated one or do something like that

    "autoload": {
        "files": ["zend_http_override.php"]
    },

I would like to show this and this to you. I think that if i check, that CVE would affect this repository (and the business version too) and this mean that the software is insecure.

[davidegiarolo]

hi, no one is lying here. simply as human I also can miss some details and i reported to you the feedback of our developers about that thread. consider that this repo is here to improve the software and the software is open so there is no way to lie... I telled you that we fix the old libraries but of course we fix the bugs we found, and the laminas example in place of the zend-mail was one of that. we'll appreciate if you can help us and check the CVE so we can mitigate the issue, or better if you can pull a fix you're welcome. as far as we know the software is secure and consider that we have third party that made penetration and owasp testing.

[nileio]

@millenium-codebug I appreciate that we having a discussion but I don't think it is at all appropriate to refer to a point or anything as being a "lie" !!

@davidegiarolo thanks for explanation. No dev activity in the repo and the forum response about the dev community was little unclear so it appeared more like a closed source product than anything else, and therefore the decision to make a fork. There is also a number of other design objectives that I listed in the backlog and vision in my repo. In all cases, most probably the module fixes + the new theme "blueberry" can be integrated with the core VTE product. I intend to push all the changes in the coming weeks..