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:41:01 GMT
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 <ttcphilips@gmail.com>
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 <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/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 <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/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 <
>> 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/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 <
>> >>>>>>>>>> > 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