fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thisura Philips <ttcphil...@gmail.com>
Subject Re: [GSOC2017] Fixing security vulnerabilities reported by sonar scan
Date Wed, 28 Jun 2017 12:26:05 GMT
Hi Mark,
Thanks for that Mark.
As Nazeer has suggested I will do the changes to get the code and message
in the constructor.

Thanks & Regards

On Mon, Jun 26, 2017 at 3:28 AM, Mark Reynolds <markreyn@bu.edu> wrote:

> 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)
> >
> >
> >
>



-- 
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