[
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734957#action_12734957
]
Ivan commented on GERONIMO-3003:
--------------------------------
The patch looks good to me, if no objection, I will first try to apply it to
2.1 branch.
> Encrypt password strings in deployment plans
> --------------------------------------------
>
> Key: GERONIMO-3003
> URL: https://issues.apache.org/jira/browse/GERONIMO-3003
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: deployment
> Affects Versions: Wish List
> Reporter: Aman Nanner
> Assignee: Jack Cai
> Priority: Minor
> Fix For: Wish List
>
> Attachments: GERONIMO-3003.patch, GERONIMO-3003_21.patch
>
>
> Geronimo currently has a feature where password strings in the config.xml get
> encrypted using the {{org.apache.geronimo.util.EncryptionManager}}. This
> encryption is performed in the
> {{org.apache.geronimo.system.configuration.GBeanOverride}} class.
> It would be desirable to have the same encryption applied to the password
> strings in deployment plans (e.g. datasource or JMS deployment plans within
> an EAR). Even though the plans are only used during the deployment process,
> and not at runtime, the plans are left with plaintext password strings
> sitting in them. It would be nice if the deployment process could internally
> encrypt the strings and then write back out the deployment plan to the file
> system. Also, this means that the deployment process will require the
> ability to decrypt strings that are already in encrypted format in the plan
> (in the case of redeployment, for example).
> More discussion of this feature can be found in the following mailing list
> thread:
> http://www.mail-archive.com/u...@geronimo.apache.org/msg05859.html
> I would suggest that an appropriate spot to perform the encryption is in the
> {{org.apache.geronimo.j2ee.deployment.EARConfigBuilder}} class, perhaps in
> the following code just before the file is written to a temporary file:
> ----
> if (gerModule.isSetAltDd()) {
> // the the url of the alt dd
> try {
> altVendorDDs.put(path,
> DeploymentUtil.toTempFile(earFile, gerModule.getAltDd().getStringValue()));
> } catch (IOException e) {
> throw new DeploymentException("Invalid alt vendor
> dd url: " + gerModule.getAltDd().getStringValue(), e);
> }
> ----
> However, somebody more familiar with the design might be able to suggest a
> better solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
