[Vtigercrm-developers] Roadmap and safety Vtiger & forks

IT-Solutions4You info at its4you.sk
Thu May 19 08:27:58 GMT 2016


Maybe this link can help us too: 
https://www.cvedetails.com/vulnerability-list/vendor_id-3505/product_id-6148/Vtiger-Vtiger-Crm.html

Matus
ITS4You

Dňa 17. 5. 2016 o 23:16 Błażej Pabiszczak napísal(a):
> @Prasad
>
> None of my replies aim to attack you. I criticize your approach as a
> producer and evaluate some of your actions but I do it only to motivate
> you because I hope you will do something about it. If you take it
> personally, then I do apologize but it’s not my aim. I know that my
> character is tough and it might be difficult to talk with me but I
> certainly do not want to offend anyone… I often write what I think and
> I’m aware of the fact that it isn’t always good from a marketing or
> personal perspective. If you do not want me to write on the mailing
> list, just let me know and I will stop.
>
> When it comes to our plans regarding Vtiger. We - YetiForce- will not be
> adding any code to Vtiger, we simply don’t have time for that, and we
> don’t see any point in doing so. However, we do see a lot of areas,
> where we could cooperate. The more we get from Vtiger by transferring
> the code, the more compatible our systems will be, and the easier it
> will be for you [or the community] to move functionalities from YF to
> Vtiger. Exchanging error information, mobile apps, or API seem to be a
> good start for the cooperation.
>
> YF doesn’t need Vtiger and neither does Vtiger need YF. If you take a
> look at our GitHub community you will see that we have our own
> community, and we’re not trying to find clients or developers in here.
> Those who wanted already switched, and mailing lists aren’t the best
> marketing tool. If we were looking for clients, we’d start from the
> forum and LinkedIn groups. We’re here because we’re looking for areas
> where we could cooperate. 18 months ago we were still adding changes
> from your SVN once every couple of days [when you published them], now
> we add them really rarely, which means our system develops slower as
> well. In my opinion there’s a place for everyone and we can develop
> together.
>
> We sent links to two huge packages with error fixes that apply to YF,
> Vtiger and CoreBOS. In 2016 we will spend at least 25.000€ on security
> audits, and it would be worth to cooperate on that, instead of getting
> mad at each other. These significant security problems stem from the
> fact that no large company in the world has seriously deployed your
> system. Currently, we have two large deployments to be done and they
> expect protection from such attacks:
> https://www.owasp.org/index.php/Top_10_2013-Top_10and the cooperation is
> different when 3 project [YetiForce, Vtiger, CoreBOS] work together
> towards better security, than when just one company works on it.
>
> In my opinion, you should designate one trusted person who would help
> you coordinate a project [e.g. Alan] because this person might bring a
> lot of energy, and more importantly, he may rebuild the trust of some of
> the community members towards the project and it may move everything
> forward.
>
> Look at other projects, such as SuiteCRM or many other commercial
> projects because they develop much more rapidly than you and, in
> retrospect, it will become more and more noticeable.
>
> ---
> Z poważaniem / Regards
> *Błażej Pabiszczak*
> /Chief Executive Officer/
> M: +48.884999123
> E: b.pabiszczak at yetiforce.com
> <mailto:b.pabiszczak at yetiforce.com>
>
> W dniu 2016-05-13 17:06, Prasad napisał(a):
>
>> Dear Błażej,
>> I dislike to get more personal level feedback on this list.
>> You can email me separately - I would appreciate to learn from it.
>> I'm curious to know if your plan is to continue developing on Vtiger
>> codebase.
>> Regards,
>> Prasad
>>
>> --
>> FB <http://www.facebook.com/vtiger> I Twit
>> <http://twitter.com/vtigercrm> I LIn
>> <https://www.linkedin.com/company/1270573?trk=tyah> I Blog
>> <https://blogs.vtiger.com> I Website <https://www.vtiger.com/>
>>
>> On Fri, May 13, 2016 at 6:23 PM, Błażej Pabiszczak
>> <b.pabiszczak at yetiforce.com
>> <mailto:b.pabiszczak at yetiforce.com>> wrote:
>>
>>     @Prasad:
>>     I don't know what priorities you are talking about, but they for
>>     sure have nothing to do with the open source version. Looking at
>>     code.vtiger.com <http://code.vtiger.com> I feel like you're
>>     pretending that you care, and I don't mean whether or not there's
>>     someone who adds stuff there [because lately something is going on
>>     in there], what I mean is that there's nobody to manage that,
>>     nobody to develop that, and nobody to think how to improve the
>>     open source version. You can write this down on code.vtiger.com
>>     <http://code.vtiger.com>:
>>
>>       * Vtiges is full of holes as a Swiss cheese [so are VTE CRM,
>>         CoreBOS, YetiForce]
>>       * Client Portal [including MYC] is full of holes as a Swiss cheese
>>       * 90% of marketplace modules are full of holes as a Swiss cheese
>>
>>     I get it, you got different priorities [PHP 7] now, but if you
>>     start doing something make sure you're doing it well, because most
>>     of PHP 7 changes are like hiding the problem instead of solving it
>>     comprehensively. If you need an issue on code.vtiger.com
>>     <http://code.vtiger.com> there's nothing stopping you from
>>     analyzing our revisions and all improvements, and transferring
>>     these changes to your system. I'm not gonna do that, I'm just
>>     showing you where the problem is, and that it must be addressed.
>>
>>     Here's another pack of security error fixes:
>>     https://github.com/YetiForceCompany/YetiForcePortal/commit/fe8098b3a1cbaf64c9890f6417ad0ca88021c40b.
>>     It's related to MYC though, but MYC is based on the official
>>     client portal that includes the same errors!
>>
>>
>>     @Alan
>>     It might prove to be a difficult task. At the moment barely any
>>     changes we upload to YetiForce can be directly added to Vtiger.
>>     The difference is that when we change anything in any module, we
>>     optimize it, change the business philosophy, and adjust the engine
>>     right away. What's most important, the majority of these changes
>>     is designed to allow for even more changes in the nearest future.
>>     Additionally, the analysis of what we do might take you a while,
>>     check what the monthly GitHub Pulse shows: "Excluding merges, 10
>>     authors have pushed 251 commits to developer and 253 commits to
>>     all branches. On developer, 1,074 files have changed and there
>>     have been 40,048 additions and 18,621 deletions."
>>
>>     The files we delete are no longer used by Vtiger, they are 4.x/5.x
>>     version leftovers.
>>
>>     ---
>>     Z poważaniem / Regards
>>     *Błażej Pabiszczak*
>>     /Chief Executive Officer/
>>     M: +48.884999123
>>     E: b.pabiszczak at yetiforce.com
>>     <mailto:b.pabiszczak at yetiforce.com>
>>
>>     W dniu 2016-05-13 12:27, Alan Bell napisał(a):
>>
>>         OK, so in the linked commit, there is a new class AppRequest
>>         in include/http/Request.php (it is in "includes" in vtiger at
>>         the moment because yetiforce folded the /includes/ into
>>         /include/ a while back)
>>         This class parses fields out of the $_REQUEST data in a number
>>         of ways, and does it properly and would be a central point to
>>         add extra checks at some point.
>>         The commit also includes rewriting pretty much everywhere that
>>         $_REQUEST is directly used in the codebase to use this new
>>         class. It is a good improvement preventing various potential
>>         attacks (mostly attacks by authenticated users, but probably
>>         some unauthed stuff, particularly around password resetting)
>>
>>         I think it also removes the following files on the basis that
>>         they are no longer used, I am not sure if that is true for vtiger
>>
>>         include/utils/InventoryUtils.php
>>         include/utils/export.php
>>         modules/Calendar/iCalExport.php
>>         modules/Calendar/iCalImport.php
>>         modules/ModComments/ModCommentsWidgetHandler.php
>>         modules/OSSTimeControl/Save.php
>>         modules/Reports/AdvancedFilter.php
>>         modules/Reports/CustomReportUtils.php_deprecated
>>         modules/Reports/ReportChartRun.php_deprecated
>>         modules/Reports/ReportSharing.php
>>         modules/Reports/ReportType.php
>>         modules/Users/Authenticate.php
>>
>>         so the commit clearly won't apply cleanly to vtiger, but it is
>>         good stuff and we should incorporate it.
>>
>>         I actually pulled a copy of yetiforce from github to
>>         code.vtiger.com <http://code.vtiger.com> the other day, in the
>>         hope of being able to figure out how to efficiently move stuff
>>         between the systems, and work out what the differences
>>         actually were at this stage.
>>         http://code.vtiger.com/alanbell/yetiforce
>>
>>         I opened an issue for this topic here
>>         http://code.vtiger.com/vtiger/vtigercrm/issues/203
>>
>>         Alan.
>>
>>         On 13/05/16 10:55, Błażej Pabiszczak wrote:
>>
>>             Every now and then we send information about security
>>             errors, not only to Vtiger, but also to creators of Vtiger
>>             modules. In most of the cases, these changes aren't fixed.
>>             I don't understand why security is a taboo subject, and
>>             why nobody considers our comments [maybe we should report
>>             each of these cases publicly? Or maybe we should record a
>>             video on how to break into the OD version?] Any ideas?
>>
>>             The code that is currently added to Vtiger is of low
>>             quality, and since releasing v6.0 nobody has been really
>>             dealing with the development as far as quality and
>>             security are considered. Unfortunately, we inherited a lot
>>             of code from Vtiger [it also applies to other forks –
>>             CoreBOS, VTE CRM]. The majority of errors we point out are
>>             related to not clearing the variables, and storing useless
>>             old files full of holes. Let's see what the reaction to
>>             this post is, if you ignore it we won't publish info like
>>             that anymore, it's a waste of our time. Take into
>>             consideration that our system doesn't have many of the
>>             modules that are in Vtiger because we wrote them from
>>             scratch, so the link below is not a ready solution, it
>>             only points out part of the found errors. Vtiger
>>
>>             Therefore I suggest making a contest – how long does it
>>             take for serious security errors to be fixed, and an
>>             update package to be released, after publishing the errors
>>             on this mailing list.
>>
>>               * https://github.com/YetiForceCompany/YetiForceCRM/commit/4746cda904c88a26cce22194fb76f64d3df9893d
>>
>>
>>             ---
>>             Z poważaniem / Regards
>>             *Błażej Pabiszczak*
>>             /Chief Executive Officer/
>>             M: +48.884999123
>>             E: b.pabiszczak at yetiforce.com
>>             <mailto:b.pabiszczak at yetiforce.com>
>>
>>
>>
>>             _______________________________________________
>>             http://www.vtiger.com/
>>
>>
>>
>>         _______________________________________________
>>         http://www.vtiger.com/
>>
>>
>>     _______________________________________________
>>     http://www.vtiger.com/
>>
>>
>> _______________________________________________
>> http://www.vtiger.com/
>
>
> _______________________________________________
> http://www.vtiger.com/
>




More information about the vtigercrm-developers mailing list