Yes. Additionally we will be particularly keen on enforcing secure coding practices such as variable initialization, use of unsafe functions, memory management, indexing overruns, input validation, etc.
Best Regards, John L. Whiteman -----Original Message----- From: Dev [mailto:dev-boun...@lists.tizen.org] On Behalf Of Dominig ar Foll Sent: Monday, January 19, 2015 2:38 AM To: Tomasz Swierczek; suchang....@samsung.com Cc: dev@lists.tizen.org Subject: Re: [Dev] 2.3 API integration in Common (review model) Hello, in order to be sure that we integrate new code which is not breaking the model, I would propose that we at least ask the reviewer AppFW and Security reviewer to check a few things before sending a +1: - the code does not break basis multi user model * no hard wired path * no hard wire ID * calling uid can be identified. - the code does not break security model * uid and AppID callin gthe API are known in a secured way * privilege associated with the API can be enforced in a secured manner * delay for privilege acceptance is supported (for privilege which can be declared as "user on demand"). - the code does not break User data privacy. * data are not mixed between user and/or Apps * pre set shared directory only are able to * attempt to violate data privacy will result to App rejection. Regards -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
