Hi All,
An example for a secure vault YAML configuration file is as shown below
according to the current implementation.
secretRepository:
type:
org.wso2.carbon.kernel.securevault.repository.DefaultSecretRepository
parameters:
privateKeyAlias: wso2carbon
keystoreLocation: resources/se
[Adding Imesh and Jayanga]
On Fri, Mar 17, 2017 at 9:15 AM, Vidura Nanayakkara
wrote:
> Hi All,
>
> An example for a secure vault YAML configuration file is as shown below
> according to the current implementation.
>
> secretRepository:
> type: org.wso2.carbon.kernel.securevault.repository.
>
Hi Vidura,
On Fri, Mar 17, 2017 at 9:15 AM, Vidura Nanayakkara
wrote:
> Hi All,
>
> An example for a secure vault YAML configuration file is as shown below
> according to the current implementation.
>
> secretRepository:
> type: org.wso2.carbon.kernel.securevault.repository.
> DefaultSecretRep
Hi Vidura,
We can identify whether it is in OSGi mode or non-OSGi mode by checking if
the bundleContext is set. If it is not set, then it is in non-OSGi mode.
This is the way we have done for msf4j. Any reason for this new approach?
Regards,
Nira
On Fri, Mar 17, 2017 at 9:37 AM, Lakshman Udayaka
Hi Niranjan,
You are correct we should follow the same way as msf4j to detect whether it
is OSGi mode or not.
The properties suggested are to avoid the OSGi mode check in several
places. With the suggested properties, secure-vault.yaml will have all the
information it needs for the initialization.
Hi Jayanga,
On Fri, Mar 17, 2017 at 10:09 AM, Jayanga Dissanayake
wrote:
> Hi Niranjan,
>
> You are correct we should follow the same way as msf4j to detect whether
> it is OSGi mode or not.
> The properties suggested are to avoid the OSGi mode check in several
> places. With the suggested prop
Could you explain the advantage of this proposed approach based on OSGi vs
non-OSGi mode of execution?
On Fri, Mar 17, 2017 at 9:15 AM, Vidura Nanayakkara
wrote:
> Hi All,
>
> An example for a secure vault YAML configuration file is as shown below
> according to the current implementation.
>
> s
Hi Niranjan,
Ideally, the OSGi / non-OSGi check should happen at the secure vault
initialization phase. The rest of the execution should happen accordingly
without checking for OSGi / non-OSGi. However, if we delegate providing
other file paths (secret.properties, master-key.yaml) to relevant
impl
Hi Kishanthan,
When we have the master-keys.yaml and secrets.properties yaml file path in
secure-vault.yaml configuration the end user do not need to override a
method to explain how the paths are taken but rather handled within the
secure vauilt implementation itself. So if the paths are specifie
Adding these files to parameter section makes no difference because
parameter section includes implementation specific data. So I think it is
ok to keep them in parameter section as well. It is up to the
implementation.
On Fri, Mar 17, 2017 at 10:42 AM, Vidura Nanayakkara
wrote:
> Hi Kishanthan,
Hi All,
Let me do certain clarifications regarding this email. Apologies since the
actual message is not conveyed.
We need to do the OSGi / non-OSGi check only once. However, if we follow
the previous secure-vault.yaml structure (without the secrets.properties
path and the master-keys.yaml pat
11 matches
Mail list logo