fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thisura Philips <ttcphil...@gmail.com>
Subject Re: [offlist] Re: [GSOC2017] Fixing security vulnerabilities reported by sonar scan
Date Sun, 25 Jun 2017 09:38:01 GMT
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 <ojqjii@gmail.com> 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 <markreyn@bu.edu> wrote:
>
> Yes I will review it in the morning.
>
> On Monday, June 12, 2017, Thisura Philips <ttcphilips@gmail.com> 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 <markreyn@bu.edu> wrote:
> >>
> >> Thisura,
> >> Yes, I will review your PR 357 today.
> >> On Thu, Jun 8, 2017 at 4:22 AM, Thisura Philips <ttcphilips@gmail.com>
> 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 <ttcphilips@gmail.com>
> 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 <markreyn@bu.edu>
> 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 <markreyn@bu.edu>
> 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 <
> ttcphilips@gmail.com> 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/
> 1uLk3YPcjnXk7RqF8etsTzIuN59CDU6sgBxpZul__1V4?usp=gmail
> >>>>>>> [2] https://drive.google.com/open?id=
> 1TdwwHM2K1gMb6qILEX7gmzU8dVXcHGBdh569aFJfB2U&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 <edcable@mifos.org>
> wrote:
> >>>>>>>>
> >>>>>>>> Adding Nazeer too.
> >>>>>>>> Ed
> >>>>>>>> On May 27, 2017 9:43 PM, "Thisura Philips" <ttcphilips@gmail.com>
> 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 <edcable@mifos.org>
> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Thisura, I have cc'd Mark on this email
> >>>>>>>>>>
> >>>>>>>>>> On May 10, 2017 14:07, "Thisura Philips" <ttcphilips@gmail.com>
> 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 <
> ttcphilips@gmail.com>
> >>>>>>>>>> > 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/spreadsheets/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 <
> ttcphilips@gmail.com>
> >>>>>>>>>> > > 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 <
> myrle@apache.org> 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 <
> ttcphilips@gmail.com
> >>>>>>>>>> > >
> >>>>>>>>>> > >>> 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/
> definitions/582.html>
> >>>>>>>>>> > -
> >>>>>>>>>> > >>> >    Array Declared Public,
Final, and Static
> >>>>>>>>>> > >>> >    - MITRE, CWE-607 <http://cwe.mitre.org/data/
> definitions/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 <
> >>>>>>>>>> > ttcphilips@gmail.com
> >>>>>>>>>> > >>> >
> >>>>>>>>>> > >>> > 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 <
> >>>>>>>>>> > >>> ttcphilips@gmail.com>
> >>>>>>>>>> > >>> >> 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)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message