Hi Mark, Kindly ignore the above mail since it was sent by mistake.
I sent the PR-375 <https://github.com/apache/fineract/pull/375/> fixing a part of FINERACT-437 <https://issues.apache.org/jira/browse/FINERACT-437>. This PR fixes the issue with "Generic exceptions should never be thrown MITRE, CWE-397 <http://cwe.mitre.org/data/definitions/397.html> - Declaration of Throws for Generic Exception". Please review and let me know if we need any updates on that. I have updated the document <https://docs.google.com/spreadsheets/d/1uLk3YPcjnXk7RqF8etsTzIuN59CDU6sgBxpZul__1V4?usp=gmail> . Thanks & Regards On Sun, Jun 25, 2017 at 3:08 PM, Thisura Philips <[email protected]> wrote: > Hi Mark, > > I sent the PR-375 <https://github.com/apache/fineract/pull/375/> fixing a > part of FINERACT-437 <https://issues.apache.org/jira/browse/FINERACT-437>. > This PR fix the the issue with > > On Tue, Jun 13, 2017 at 1:07 PM, Myrle Krantz <[email protected]> wrote: > >> Hey Mark, Thisura, >> >> You both may have noticed that your replies tend to arrive on the mailing >> list with delay. This is because they are frequently sent to me for >> moderation first. >> >> I'm not certain why that is. My current theory is that it might be >> because of their length. >> >> As an experiment, could you try quoting less of the conversation history >> the next couple of emails and see if that improves things. If it doesn't, >> then I'll ask infra if they know why. >> >> Greets, >> Myrle >> >> Sent from my iPhone >> >> On 13. Jun 2017, at 03:42, Mark Reynolds <[email protected]> wrote: >> >> Yes I will review it in the morning. >> >> On Monday, June 12, 2017, Thisura Philips <[email protected]> wrote: >> > Hi Mark & Nazeer, >> > There were few merge conflicts due to the latest commit. I have >> resolved them and updated the PR. >> > Could you please review it and merge? >> > Thanks & Regards >> > On Thu, Jun 8, 2017 at 8:36 PM, Mark Reynolds <[email protected]> wrote: >> >> >> >> Thisura, >> >> Yes, I will review your PR 357 today. >> >> On Thu, Jun 8, 2017 at 4:22 AM, Thisura Philips <[email protected]> >> wrote: >> >>> >> >>> Hi Mark, >> >>> I have updated the PR[1] adding new constant classes and making those >> sets protected, to make those sets secure. >> >>> Please review and let me know if we need to update it. >> >>> [1] https://github.com/apache/fineract/pull/357 >> >>> On Thu, Jun 1, 2017 at 6:11 AM, Thisura Philips <[email protected]> >> wrote: >> >>>> >> >>>> Hi Mark, >> >>>> That's great. If I get the consent to create new constant classes I >> will do that since that is the most appropriate solution. And will modify >> the PR and will update the document. >> >>>> Thanks & Regards >> >>>> >> >>>> >> >>>> On Thu, Jun 1, 2017 at 3:08 AM, Mark Reynolds <[email protected]> >> wrote: >> >>>>> >> >>>>> Thisura, >> >>>>> Your second PR is also fine. I am moving forward to write a brief >> document about the security >> >>>>> analysis, which you will get Thursday. >> >>>>> On Wed, May 31, 2017 at 4:08 PM, Mark Reynolds <[email protected]> >> wrote: >> >>>>>> >> >>>>>> Thisura, >> >>>>>> My impression is that you add to the API, but you cannot modify >> the argument list of any existing method. >> >>>>>> Therefore, I think adding constant classes, and also removing >> these constants from the interfaces, is fine. >> >>>>>> I have reviewed your first PR and it looks great. I am working on >> your second PR right now. I will also >> >>>>>> create a brief document that addresses your security analysis. >> >>>>>> - Mark >> >>>>>> On Mon, May 29, 2017 at 10:59 PM, Thisura Philips < >> [email protected]> wrote: >> >>>>>>> >> >>>>>>> Hi all, >> >>>>>>> Please note the that the documents[1][2] are updated with the >> latest findings. There are suggestions to improve the fixes as per my >> understanding. I am under the the impression of not doing API changes. >> There fore didn't create any new classes for constants. I have raised this >> problem above in this thread. AFAIK It would be better if we can create >> constant classes to keep these constant sets rather than trying to keep >> them in interfaces (as it was) or in constant classes in a seperate package >> (where we can't use protected key word) >> >>>>>>> The problem with keeping those in the interfaces is the following >> vulnerabilities. >> >>>>>>> >> >>>>>>> MITRE, CWE-582 - Array Declared Public, Final, and Static >> >>>>>>> MITRE, CWE-607 - Public Static Final Field References Mutable >> Object >> >>>>>>> >> >>>>>>> As per the fix, I have moved most of those sets which were in >> interfaces to the respective classes and made them private. As all of them >> were only used in that class it is not a problem. >> >>>>>>> But if we take a class like DepositApiConstants.java [3], it is >> better if we can create a new consant class in the package >> apache.fineract.portfolio.savings.data package and make them protected. >> Or else we can extend the constant class from the consuming class, if the >> consuming classes don't extend other classes (which is the case at the >> moment). Then we can make those Sets protected easily. >> >>>>>>> But doing so is a API change. However I kept those to discuss, >> since there were major changes. Lets dicuss and decide what to do with >> theose yellow colured issues in the document. >> >>>>>>> [1] https://docs.google.com/spreadsheets/d/1uLk3YPcjnXk7RqF8 >> etsTzIuN59CDU6sgBxpZul__1V4?usp=gmail >> >>>>>>> [2] https://drive.google.com/open?id=1TdwwHM2K1gMb6qILEX7gmz >> U8dVXcHGBdh569aFJfB2U&usp=gmail >> >>>>>>> [3] https://github.com/apache/fineract/blob/develop/fineract >> -provider/src/main/java/org/apache/fineract/portfolio/ >> savings/DepositsApiConstants.java >> >>>>>>> Thanks and Regards. >> >>>>>>> On Tue, May 30, 2017 at 5:13 AM, Ed Cable <[email protected]> >> wrote: >> >>>>>>>> >> >>>>>>>> Adding Nazeer too. >> >>>>>>>> Ed >> >>>>>>>> On May 27, 2017 9:43 PM, "Thisura Philips" <[email protected]> >> wrote: >> >>>>>>>>> >> >>>>>>>>> Hi all, >> >>>>>>>>> I have sent a PR [1] resolving the rest of the issues of >> FINERACT-436 [2]. For tracking purpose I have created a new ticket at >> FINERACT-470. This is the second PR connected with the previously merged >> PR [3]. >> >>>>>>>>> Please review and let me know if any thing is needed to be >> changed. >> >>>>>>>>> I am moving on to fixing the FINERACT-437. >> >>>>>>>>> [1] https://github.com/apache/fineract/pull/357 >> >>>>>>>>> [2] https://issues.apache.org/jira/browse/FINERACT-436 >> >>>>>>>>> [3] https://github.com/apache/fineract/pull/343 >> >>>>>>>>> Thanks & Regard >> >>>>>>>>> On Thu, May 11, 2017 at 1:58 AM, Ed Cable <[email protected]> >> wrote: >> >>>>>>>>>> >> >>>>>>>>>> Thisura, I have cc'd Mark on this email >> >>>>>>>>>> >> >>>>>>>>>> On May 10, 2017 14:07, "Thisura Philips" <[email protected]> >> wrote: >> >>>>>>>>>> >> >>>>>>>>>> > Hi Nikhil, >> >>>>>>>>>> > >> >>>>>>>>>> > I am really glad to get selected to GOSC 2017. I have being >> looking on TOIF >> >>>>>>>>>> > a little bit in the past few days. First I will complete the >> SONAR issues. >> >>>>>>>>>> > >> >>>>>>>>>> > Since Mark Reynolds is the mentor of the project, I would >> like to get him >> >>>>>>>>>> > in this thread too. Couldn't find his email though. Please >> some one provide >> >>>>>>>>>> > me the email of Mark. >> >>>>>>>>>> > >> >>>>>>>>>> > Thanks & Regards >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > On Sun, Apr 30, 2017 at 7:41 AM, Thisura Philips < >> [email protected]> >> >>>>>>>>>> > wrote: >> >>>>>>>>>> > >> >>>>>>>>>> > > Hi all, >> >>>>>>>>>> > > >> >>>>>>>>>> > > I have sent the PR [1] >> >>>>>>>>>> > > <https://github.com/apache/incubator-fineract/pull/343> >> including the >> >>>>>>>>>> > > changes needed to resolve the FINERACT-436 [2] >> >>>>>>>>>> > > <https://issues.apache.org/jira/browse/FINERACT-436> in >> accounting and >> >>>>>>>>>> > > infrastructure packages. Please see the updated scanning >> report [3] >> >>>>>>>>>> > > <https://docs.google.com/sprea >> dsheets/d/1uLk3YPcjnXk7RqF8etsTzIuN59CDU >> >>>>>>>>>> > 6sgBxpZul__1V4/> >> >>>>>>>>>> > > . >> >>>>>>>>>> > > >> >>>>>>>>>> > > It would be great if you can review and give feedback to >> continue fixing >> >>>>>>>>>> > > other vulnerabilities. >> >>>>>>>>>> > > >> >>>>>>>>>> > > I have done the LAPSE scanning for a part of accounting >> package as well. >> >>>>>>>>>> > > Will send the results soon. >> >>>>>>>>>> > > >> >>>>>>>>>> > > [1] https://github.com/apache/incubator-fineract/pull/343 >> >>>>>>>>>> > > [2] https://issues.apache.org/jira/browse/FINERACT-436 >> >>>>>>>>>> > > [3] https://docs.google.com/spreadsheets/d/ >> >>>>>>>>>> > 1uLk3YPcjnXk7RqF8etsTzIuN59CDU >> >>>>>>>>>> > > 6sgBxpZul__1V4/ >> >>>>>>>>>> > > >> >>>>>>>>>> > > Thanks & Regards >> >>>>>>>>>> > > >> >>>>>>>>>> > > On Sat, Apr 29, 2017 at 8:12 AM, Thisura Philips < >> [email protected]> >> >>>>>>>>>> > > wrote: >> >>>>>>>>>> > > >> >>>>>>>>>> > >> Hi Myrle, >> >>>>>>>>>> > >> >> >>>>>>>>>> > >> Agreed with the concern in doing an API change. >> >>>>>>>>>> > >> >> >>>>>>>>>> > >> The problem is any one can change the values in these >> arrays since they >> >>>>>>>>>> > >> are accessible public. It is nice if we can protect these >> arrays, (set) >> >>>>>>>>>> > as >> >>>>>>>>>> > >> they are mutable. >> >>>>>>>>>> > >> But as we know we can't use protected or private access >> modifiers in an >> >>>>>>>>>> > >> interface. It would be perfect if we can move the Sets in >> to the >> >>>>>>>>>> > respective >> >>>>>>>>>> > >> classes where they are used. >> >>>>>>>>>> > >> >> >>>>>>>>>> > >> supportedParameters = > org.apache.fineract.accounting. >> >>>>>>>>>> > >> provisioning.serialization.ProvisioningEntriesDefinitionJ >> >>>>>>>>>> > sonDeserializer >> >>>>>>>>>> > >> (Used only in this class) >> >>>>>>>>>> > >> >> >>>>>>>>>> > >> PROVISIONING_ENTRY_PARAMETERS => >> org.apache.fineract.accounting >> >>>>>>>>>> > >> .provisioning.api.ProvisioningEntriesApiResource (Used >> only in this >> >>>>>>>>>> > >> class) >> >>>>>>>>>> > >> >> >>>>>>>>>> > >> ALL_PROVISIONING_ENTRIES => org.apache.fineract.accounting >> >>>>>>>>>> > >> .provisioning.api.ProvisioningEntriesApiResource (Used >> only in this >> >>>>>>>>>> > >> class) >> >>>>>>>>>> > >> >> >>>>>>>>>> > >> Since all of these sets are used in the mentioned classes >> only, we can >> >>>>>>>>>> > >> make them private. >> >>>>>>>>>> > >> >> >>>>>>>>>> > >> >> >>>>>>>>>> > >> Thanks & Regards >> >>>>>>>>>> > >> >> >>>>>>>>>> > >> >> >>>>>>>>>> > >> On Fri, Apr 28, 2017 at 5:49 PM, Myrle Krantz < >> [email protected]> wrote: >> >>>>>>>>>> > >> >> >>>>>>>>>> > >>> By constant class Thisura, do you mean a final class >> with a private >> >>>>>>>>>> > >>> constructor? >> >>>>>>>>>> > >>> >> >>>>>>>>>> > >>> It would be possible to change >> >>>>>>>>>> > >>> org.apache.fineract.accounting >> .provisioning.constant.Provisi >> >>>>>>>>>> > >>> oningEntriesApiConstants. >> >>>>>>>>>> > >>> This would be a breaking change though. Given that the >> interface has >> >>>>>>>>>> > >>> no methods, and no one is likely to have derived from >> it, there's >> >>>>>>>>>> > >>> probably no code to break by changing it, but you still >> have to answer >> >>>>>>>>>> > >>> the question "Why would I change that?" >> >>>>>>>>>> > >>> >> >>>>>>>>>> > >>> Yes, I know that Bloch ("Effective Java", 2nd Ed., >> Chapter 19) said >> >>>>>>>>>> > >>> it's bad. But his arguments only make sense when >> referring to an >> >>>>>>>>>> > >>> interface which contains methods. This interface >> doesn't. So given >> >>>>>>>>>> > >>> that Apache Fineract is communicated with over a REST >> interface, what >> >>>>>>>>>> > >>> harm does this interface cause that would justify making >> an >> >>>>>>>>>> > >>> API-breaking change (though a minor one) to remediate >> the situation? >> >>>>>>>>>> > >>> >> >>>>>>>>>> > >>> Best Regards, >> >>>>>>>>>> > >>> Myrle >> >>>>>>>>>> > >>> >> >>>>>>>>>> > >>> >> >>>>>>>>>> > >>> On Sun, Apr 23, 2017 at 8:00 PM, Thisura Philips < >> [email protected] >> >>>>>>>>>> > > >> >>>>>>>>>> > >>> wrote: >> >>>>>>>>>> > >>> > Hi all, >> >>>>>>>>>> > >>> > >> >>>>>>>>>> > >>> > I have done some of the fixes for FINERACT-436 >> >>>>>>>>>> > >>> > <https://issues.apache.org/jira/browse/FINERACT-436>. >> Please see the >> >>>>>>>>>> > >>> > updated document >> >>>>>>>>>> > >>> > <https://drive.google.com/open >> ?id=1uLk3YPcjnXk7RqF8etsTzIuN5 >> >>>>>>>>>> > >>> 9CDU6sgBxpZul__1V4> >> >>>>>>>>>> > >>> > . >> >>>>>>>>>> > >>> > >> >>>>>>>>>> > >>> > Is there any particular reason to >> >>>>>>>>>> > >>> > have org.apache.fineract.accounting >> .provisioning.constant.Provisi >> >>>>>>>>>> > >>> oningEntriesApiConstants >> >>>>>>>>>> > >>> > as an interface. It is true that variables in >> interfaces are static, >> >>>>>>>>>> > >>> final >> >>>>>>>>>> > >>> > by default. But yet this can cause the following >> vulnerabilities. >> >>>>>>>>>> > >>> > >> >>>>>>>>>> > >>> > - MITRE, CWE-582 <http://cwe.mitre.org/data/def >> initions/582.html> >> >>>>>>>>>> > - >> >>>>>>>>>> > >>> > Array Declared Public, Final, and Static >> >>>>>>>>>> > >>> > - MITRE, CWE-607 <http://cwe.mitre.org/data/def >> initions/607.html> >> >>>>>>>>>> > - >> >>>>>>>>>> > >>> > Public Static Final Field References Mutable Object >> >>>>>>>>>> > >>> > >> >>>>>>>>>> > >>> > >> >>>>>>>>>> > >>> > Can't we change this to a constant class? ASFAIK this >> is the correct >> >>>>>>>>>> > >>> way to >> >>>>>>>>>> > >>> > maintain a set of constants. >> >>>>>>>>>> > >>> > >> >>>>>>>>>> > >>> > Thanks & Regards >> >>>>>>>>>> > >>> > >> >>>>>>>>>> > >>> > >> >>>>>>>>>> > >>> > On Sun, Apr 23, 2017 at 5:53 PM, Thisura Philips < >> >>>>>>>>>> > [email protected] >> >>>>>>>>>> > >>> > >> >>>>>>>>>> > >>> > wrote: >> >>>>>>>>>> > >>> > >> >>>>>>>>>> > >>> >> Hi all, >> >>>>>>>>>> > >>> >> >> >>>>>>>>>> > >>> >> I have created two tickets [1][2] to track the fixes >> for security >> >>>>>>>>>> > >>> >> vulnerabilities reported by sonar. >> >>>>>>>>>> > >>> >> Thanks & Regards. >> >>>>>>>>>> > >>> >> [1] https://issues.apache.org/jira >> /browse/FINERACT-436 >> >>>>>>>>>> > >>> >> [2] https://issues.apache.org/jira >> /browse/FINERACT-437 >> >>>>>>>>>> > >>> >> >> >>>>>>>>>> > >>> >> On Fri, Apr 21, 2017 at 10:31 AM, Thisura Philips < >> >>>>>>>>>> > >>> [email protected]> >> >>>>>>>>>> > >>> >> wrote: >> >>>>>>>>>> > >>> >> >> >>>>>>>>>> > >>> >>> Hi all, >> >>>>>>>>>> > >>> >>> >> >>>>>>>>>> > >>> >>> As per the long discussion in the thread >> "[Mifos-developer] >> >>>>>>>>>> > >>> Application >> >>>>>>>>>> > >>> >>> for GSOC 2017( Static Analysis of Apache Fineract >> )", I have >> >>>>>>>>>> > >>> >>> >> >>>>>>>>>> > >>> >>> * done the static analysis with SonarQube >> >>>>>>>>>> > >>> >>> * generated the vulnerability report, - sonarlint >> report [1] >> >>>>>>>>>> > >>> >>> <https://drive.google.com/open >> ?id=0B6WV3fK5Tak7Uy1uOWk0SW81Wm8>, >> >>>>>>>>>> > >>> >>> sonarqube <https://drive.google.com/open >> >>>>>>>>>> > >>> ?id=0B6WV3fK5Tak7OHJENF9oZFE2X2c> report >> >>>>>>>>>> > >>> >>> [2] <https://drive.google.com/open >> ?id=0B6WV3fK5Tak7OHJENF9oZFE2X2c >> >>>>>>>>>> > > >> >>>>>>>>>> > >>> >>> * summarized >> >>>>>>>>>> > >>> >>> <https://drive.google.com/open >> ?id=1TdwwHM2K1gMb6qILEX7gmzU8d >> >>>>>>>>>> > >>> VXcHGBdh569aFJfB2U> >> >>>>>>>>>> > >>> >>> [3] the types of vulnerabilities, >> >>>>>>>>>> > >>> >>> * attended each of those vulnerabilities to check >> whether they are >> >>>>>>>>>> > >>> not >> >>>>>>>>>> > >>> >>> false positives and >> >>>>>>>>>> > >>> >>> * prepared the checklist [4] >> >>>>>>>>>> > >>> >>> <https://drive.google.com/open >> ?id=1uLk3YPcjnXk7RqF8etsTzIuN5 >> >>>>>>>>>> > >>> 9CDU6sgBxpZul__1V4> >> >>>>>>>>>> > >>> >>> of vulnerabilities with fixes >> >>>>>>>>>> > >>> >>> >> >>>>>>>>>> > >>> >>> All the reports which are generated using different >> plugins, tools >> >>>>>>>>>> > >>> can be >> >>>>>>>>>> > >>> >>> found here [5] >> >>>>>>>>>> > >>> >>> <https://drive.google.com/open >> ?id=0B6WV3fK5Tak7ZVJkVGV3WVZ3OE0>. >> >>>>>>>>>> > >>> >>> >> >>>>>>>>>> > >>> >>> Now we can go ahead and do the necessary changes to >> fix the >> >>>>>>>>>> > reported >> >>>>>>>>>> > >>> >>> vulnerabilities in the codebase. I am looking >> forward to creating >> >>>>>>>>>> > >>> tickets >> >>>>>>>>>> > >>> >>> for each type of issues reported in summary. >> >>>>>>>>>> > >>> >>> >> >>>>>>>>>> > >>> >>> We need to verify the problems (vulnerabilities[4] >> >>>>>>>>>> > >>> >>> <https://drive.google.com/open >> ?id=1uLk3YPcjnXk7RqF8etsTzIuN5 >> >>>>>>>>>> > >>> 9CDU6sgBxpZul__1V4>) >> >>>>>>>>>> > >>> >>> and solutions that I have suggested in the summary >> [3] >> >>>>>>>>>> > >>> >>> <https://drive.google.com/open >> ?id=1TdwwHM2K1gMb6qILEX7gmzU8d >> >>>>>>>>>> > >>> VXcHGBdh569aFJfB2U> >> >>>>>>>>>> > >>> >>> . >> >>>>>>>>>> > >>> >>> >> >>>>>>>>>> > >>> >>> According to the findings [4] >> >>>>>>>>>> > >>> >>> <https://drive.google.com/open >> ?id=1uLk3YPcjnXk7RqF8etsTzIuN5 >> >>>>>>>>>> > >>> 9CDU6sgBxpZul__1V4>, >> >>>>>>>>>> > >>> >>> I will create two tickets for co-related fixes for >> each topic >> >>>>>>>>>> > (type >> >>>>>>>>>> > >>> of >> >>>>>>>>>> > >>> >>> vulnerability) such as >> >>>>>>>>>> > >>> >>> >> >>>>>>>>>> > >>> >>> * Mutable fields should not be "public static" && >> "enum" fields >> >>>>>>>>>> > >>> should >> >>>>>>>>>> > >>> >>> not be publicly mutable && "public static" fields >> should be >> >>>>>>>>>> > constant >> >>>>>>>>>> > >>> >>> * Generic exceptions should never be thrown && >> Throwable and Error >> >>>>>>>>>> > >>> should >> >>>>>>>>>> > >>> >>> not be caught >> >>>>>>>>>> > >>> >>> >> >>>>>>>>>> > >>> >>> Expect the community ideas regarding this to >> validate the suggested >> >>>>>>>>>> > >>> >>> solutions. >> >>>>>>>>>> > >>> >>> >> >>>>>>>>>> > >>> >>> [1] https://drive.google.com/open? >> id=0B6WV3fK5Tak7Uy1uOWk0SW81Wm8 >> >>>>>>>>>> > >>> >>> [2] https://drive.google.com/open? >> id=0B6WV3fK5Tak7OHJENF9oZFE2X2c >> >>>>>>>>>> > >>> >>> [3] https://drive.google.com/open? >> id=1TdwwHM2K1gMb6qILEX7gmz >> >>>>>>>>>> > >>> >>> U8dVXcHGBdh569aFJfB2U >> >>>>>>>>>> > >>> >>> [4] https://drive.google.com/open? >> id=1uLk3YPcjnXk7RqF8etsTzI >> >>>>>>>>>> > >>> >>> uN59CDU6sgBxpZul__1V4 >> >>>>>>>>>> > >>> >>> [5] https://drive.google.com/open? >> id=0B6WV3fK5Tak7ZVJkVGV3WVZ3OE0 >> >>>>>>>>>> > >>> >>> >> >>>>>>>>>> > >>> >>> Thanks & regards >> >>>>>>>>>> > >>> >>> -- >> >>>>>>>>>> > >>> >>> T.T.C Philips (BSc.Eng (Undergrad)) >> >>>>>>>>>> > >>> >>> Computer Science and Engineering, >> >>>>>>>>>> > >>> >>> Sri Lanka Institute of Information Technology(SLIIT) >> >>>>>>>>>> > >>> >>> >> >>>>>>>>>> > >>> >>> >> >>>>>>>>>> > >>> >>> >> >>>>>>>>>> > >>> >>> >> >>>>>>>>>> > >>> >> >> >>>>>>>>>> > >>> >> >> >>>>>>>>>> > >>> >> -- >> >>>>>>>>>> > >>> >> T.T.C Philips (BSc.Eng (Undergrad)) >> >>>>>>>>>> > >>> >> Computer Science and Engineering, >> >>>>>>>>>> > >>> >> Sri Lanka Institute of Information Technology(SLIIT) >> >>>>>>>>>> > >>> >> >> >>>>>>>>>> > >>> >> >> >>>>>>>>>> > >>> >> >> >>>>>>>>>> > >>> >> >> >>>>>>>>>> > >>> > >> >>>>>>>>>> > >>> > >> >>>>>>>>>> > >>> > -- >> >>>>>>>>>> > >>> > T.T.C Philips (BSc.Eng (Undergrad)) >> >>>>>>>>>> > >>> > Computer Science and Engineering, >> >>>>>>>>>> > >>> > Sri Lanka Institute of Information Technology(SLIIT) >> >>>>>>>>>> > >>> >> >>>>>>>>>> > >> >> >>>>>>>>>> > >> >> >>>>>>>>>> > >> >> >>>>>>>>>> > >> -- >> >>>>>>>>>> > >> T.T.C Philips (BSc.Eng (Undergrad)) >> >>>>>>>>>> > >> Computer Science and Engineering, >> >>>>>>>>>> > >> Sri Lanka Institute of Information Technology(SLIIT) >> >>>>>>>>>> > >> >> >>>>>>>>>> > >> >> >>>>>>>>>> > >> >> >>>>>>>>>> > >> >> >>>>>>>>>> > > >> >>>>>>>>>> > > >> >>>>>>>>>> > > -- >> >>>>>>>>>> > > T.T.C Philips (BSc.Eng (Undergrad)) >> >>>>>>>>>> > > Computer Science and Engineering, >> >>>>>>>>>> > > Sri Lanka Institute of Information Technology(SLIIT) >> >>>>>>>>>> > > >> >>>>>>>>>> > > >> >>>>>>>>>> > > >> >>>>>>>>>> > > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > -- >> >>>>>>>>>> > T.T.C Philips (BSc.Eng (Undergrad)) >> >>>>>>>>>> > Computer Science and Engineering, >> >>>>>>>>>> > Sri Lanka Institute of Information Technology(SLIIT) >> >>>>>>>>>> > >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> -- >> >>>>>>>>> T.T.C Philips (BSc.Eng (Undergrad)) >> >>>>>>>>> Computer Science and Engineering, >> >>>>>>>>> Sri Lanka Institute of Information Technology(SLIIT) >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> -- >> >>>>>>> T.T.C Philips (BSc.Eng (Undergrad)) >> >>>>>>> Computer Science and Engineering, >> >>>>>>> Sri Lanka Institute of Information Technology(SLIIT) >> >>>>>>> >> >>>>>>> >> >>>>>> >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> T.T.C Philips (BSc.Eng (Undergrad)) >> >>>> Computer Science and Engineering, >> >>>> Sri Lanka Institute of Information Technology(SLIIT) >> >>>> >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> T.T.C Philips (BSc.Eng (Undergrad)) >> >>> Computer Science and Engineering, >> >>> Sri Lanka Institute of Information Technology(SLIIT) >> >>> >> >>> >> >> >> > >> > >> > >> > -- >> > T.T.C Philips (BSc.Eng (Undergrad)) >> > Computer Science and Engineering, >> > Sri Lanka Institute of Information Technology(SLIIT) >> > >> > >> > >> >> > > > -- > T.T.C Philips (BSc.Eng (Undergrad)) > Computer Science and Engineering, > Sri Lanka Institute of Information Technology(SLIIT) > > > > -- T.T.C Philips (BSc.Eng (Undergrad)) Computer Science and Engineering, Sri Lanka Institute of Information Technology(SLIIT)
