[
https://issues.apache.org/jira/browse/OFBIZ-9628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Balkir updated OFBIZ-9628:
---------------------------------
Attachment: OFBIZ-No_org.apache.ofbiz.common.email_bugfixes.patch
- Diamond Operators fixed
- Line 547: added another catch for {{RuntimeException}}
- Line 594: changed the if phrase with {{hideInLog}} to prevent the
unboxing-reboxing issue
- Line 664: deleted the declaration of the second {{bodyParts}}, because this
{{bodyParts}} and it’s value is never used
- Line 717: changed the storage of {{content}} into {{this.contentArray}} to a
copy of content to reduce vulnerability
> [FB] Package org.apache.ofbiz.common.email
> ------------------------------------------
>
> Key: OFBIZ-9628
> URL: https://issues.apache.org/jira/browse/OFBIZ-9628
> Project: OFBiz
> Issue Type: Sub-task
> Components: framework
> Affects Versions: Trunk
> Reporter: Dennis Balkir
> Priority: Minor
> Attachments: OFBIZ-No_org.apache.ofbiz.common.email_bugfixes.patch
>
>
> - EmailServices.java:547, REC_CATCH_EXCEPTION
> REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.common.email.EmailServices.sendMailFromScreen(DispatchContext,
> Map)
> This method uses a try-catch block that catches Exception objects, but
> Exception is not thrown within the try block, and RuntimeException is not
> explicitly caught. It is a common bug pattern to say try { ... } catch
> (Exception e) { something } as a shorthand for catching a number of types of
> exception each of whose catch blocks is identical, but this construct also
> accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that
> are thrown, or to explicitly catch RuntimeException exception, rethrow it,
> and then catch all non-Runtime Exceptions, as shown below:
> try {
> ...
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> ... deal with all non-runtime exceptions ...
> }
> - EmailServices.java:592, BX_UNBOXING_IMMEDIATELY_REBOXED
> Bx: Boxed value is unboxed and then immediately reboxed in
> org.apache.ofbiz.common.email.EmailServices.sendMailFromScreen(DispatchContext,
> Map)
> A boxed value is unboxed and then immediately reboxed.
> - EmailServices.java:662, UC_USELESS_OBJECT
> Useless object created
> Our analysis shows that this object is useless. It's created and modified,
> but its value never go outside of the method or produce any side-effect.
> Either there is a mistake and object was intended to be used or it can be
> removed.
> This analysis rarely produces false-positives. Common false-positive cases
> include:
> - This object used to implicitly throw some obscure exception.
> - This object used as a stub to generalize the code.
> - This object used to hold strong references to weak/soft-referenced objects.
> - EmailServices.java:715, EI_EXPOSE_REP2
> EI2: new
> org.apache.ofbiz.common.email.EmailServices$ByteArrayDataSource(byte[],
> String) may expose internal representation by storing an externally mutable
> object into EmailServices$ByteArrayDataSource.contentArray
> This code stores a reference to an externally mutable object into the
> internal representation of the object. If instances are accessed by
> untrusted code, and unchecked changes to the mutable object would compromise
> security or other important properties, you will need to do something
> different. Storing a copy of the object is better approach in many situations.
> - NotificationServices.java:270, REC_CATCH_EXCEPTION
> REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.common.email.NotificationServices.setBaseUrl(Delegator,
> String, Map)
> This method uses a try-catch block that catches Exception objects, but
> Exception is not thrown within the try block, and RuntimeException is not
> explicitly caught. It is a common bug pattern to say try { ... } catch
> (Exception e) { something } as a shorthand for catching a number of types of
> exception each of whose catch blocks is identical, but this construct also
> accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that
> are thrown, or to explicitly catch RuntimeException exception, rethrow it,
> and then catch all non-Runtime Exceptions, as shown below:
> try {
> ...
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> ... deal with all non-runtime exceptions ...
> }
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
