[Vtigercrm-developers] Roadmap and safety Vtiger & forks

Fri May 13 15:06:54 GMT 2016

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> 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 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:
>
>    - 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 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
>
>
>
>
>
> 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 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
>
>
>
>
> _______________________________________________http://www.vtiger.com/
>
>
>
> _______________________________________________
> http://www.vtiger.com/
>
>
> _______________________________________________
> http://www.vtiger.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20160513/284701dd/attachment-0001.html>