fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Reynolds <markr...@bu.edu>
Subject Re: [GSOC2017] Fixing security vulnerabilities reported by sonar scan
Date Sun, 25 Jun 2017 21:58:54 GMT
I have reviewed your PR and it looks good.

On Sunday, June 25, 2017, Thisura Philips <ttcphilips@gmail.com> wrote:
> Hi Mark,
> I sent the PR-375 fixing a part of 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