[jira] [Updated] (OFBIZ-9820) [FB] Package org.apache.ofbiz.shipment.thirdparty.usps

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Updated] (OFBIZ-9820) [FB] Package org.apache.ofbiz.shipment.thirdparty.usps

Nicolas Malin (Jira)

     [ https://issues.apache.org/jira/browse/OFBIZ-9820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Balkir updated OFBIZ-9820:
---------------------------------
    Attachment: OFBIZ-9820_org.apache.ofbiz.shipment.thirdparty.usps_bugfixes.patch

class UspsMockApiServlet:
- Line 47: it’s not necessary for the class to implement serialVerisonUID
- Line 55: deleted the {{init}} method, since it is just calling its super method
- Line 119: changed the type of {{os}} from a normal {{OutputStream}} to a {{ByteArrayOutputStream}} since it is is declared a a new {{ByteArrayOutputTream}} anyways and with this there is an easy fix for the encoding problem
- Line 129: put the default charset in {{toString}}
- Line 135: deleted the method {{destroy}} since it is just calling its super method

class UspsServices:
- Line 153: added a default Locale to {{toUpperCase}}
- Line 167: removed the declaration of {{maxWeight}} since it is declared again before it is used
- Line 198: added a default Locale to {{toUpperCase}}
- Line 301: removed {{shipToAddress != null &&}} since if {{shipToAddress}} would be null at this point, it would have thrown a Nullpointer before since it was dereferenced
- Line 332: removed the declaration of {{maxWeight}} since it is declared again before it is used
- Line 362: added a default Locale to {{toUpperCase}}
- Line 1058: removed the declaration of {{result}} since it is declared again later before it is used and in the other path where it isn’t declared the method returns
- Line 1408: added a standard charset via {{UtilIO}} to {{getBytes}}
- Line 1449: added another try block inside the existing one to make sure, that the stream is closed
- Line 1549: removed the declaration of {{fromCustomsReference}} since it is declared with another value in the next line
- Line 1617: this is a possible Nullpointer, there should be something done at this point
- Line 1626: this is a possible Nullpointer, there should be something done at this point
- Line 1649: added a standard charset via {{UtilIO}} to {{getBytes}}
- Line 1692: changed the type of {{os}} to {{ByteArrayOutputStream}} since it is already declared as a new {{ByteArrayOutputStream}}
- Line 1703: changed the declaration of {{xmlString}} so it has a proper encoding
- Line 1757: this is intended this way

class UspsServicesTests:
- Line 39: made the field {{module}} final to avoid vulnerability

> [FB] Package org.apache.ofbiz.shipment.thirdparty.usps
> ------------------------------------------------------
>
>                 Key: OFBIZ-9820
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-9820
>             Project: OFBiz
>          Issue Type: Sub-task
>          Components: framework
>    Affects Versions: Trunk
>            Reporter: Dennis Balkir
>            Priority: Minor
>         Attachments: OFBIZ-9820_org.apache.ofbiz.shipment.thirdparty.usps_bugfixes.patch
>
>
> --- UspsMockApiServlet.java:47, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.shipment.thirdparty.usps.UspsMockApiServlet is Serializable; consider declaring a serialVersionUID
> This class implements the Serializable interface, but does not define a serialVersionUID field.  A change as simple as adding a reference to a .class object will add synthetic fields to the class, which will unfortunately change the implicit serialVersionUID (e.g., adding a reference to String.class will generate a static field class$java$lang$String). Also, different source code to bytecode compilers may use different naming conventions for synthetic variables generated for references to class objects or inner classes. To ensure interoperability of Serializable across versions, consider adding an explicit serialVersionUID.
> --- UspsMockApiServlet.java:129, DM_DEFAULT_ENCODING
> Dm: Found reliance on default encoding in org.apache.ofbiz.shipment.thirdparty.usps.UspsMockApiServlet.doGet(HttpServletRequest, HttpServletResponse): java.io.ByteArrayOutputStream.toString()
> Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable. This will cause the application behaviour to vary between platforms. Use an alternative API and specify a charset name or Charset object explicitly.
> --- UspsServices.java:152, DM_CONVERT_CASE
> Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.shipment.thirdparty.usps.UspsServices.uspsRateInquire(DispatchContext, Map)
> A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the
> String.toUpperCase( Locale l )
> String.toLowerCase( Locale l )
> versions instead.
> --- UspsServices.java:166, DLS_DEAD_LOCAL_STORE
> DLS: Dead store to maxWeight in org.apache.ofbiz.shipment.thirdparty.usps.UspsServices.uspsRateInquire(DispatchContext, Map)
> This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.
> Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
> --- UspsServices.java:296, RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE
> RCN: Nullcheck of shipToAddress at line 296 of value previously dereferenced in org.apache.ofbiz.shipment.thirdparty.usps.UspsServices.uspsInternationalRateInquire(DispatchContext, Map)
> A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
> --- UspsServices.java:331, DLS_DEAD_LOCAL_STORE
> DLS: Dead store to maxWeight in org.apache.ofbiz.shipment.thirdparty.usps.UspsServices.uspsInternationalRateInquire(DispatchContext, Map)
> This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.
> Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
> --- UspsServices.java:361, DM_CONVERT_CASE
> Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in org.apache.ofbiz.shipment.thirdparty.usps.UspsServices.uspsInternationalRateInquire(DispatchContext, Map)
> A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the
> String.toUpperCase( Locale l )
> String.toLowerCase( Locale l )
> versions instead.
> --- UspsServices.java:1057, DLS_DEAD_LOCAL_STORE
> DLS: Dead store to result in org.apache.ofbiz.shipment.thirdparty.usps.UspsServices.uspsUpdateShipmentRateInfo(DispatchContext, Map)
> This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.
> Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
> --- UspsServices.java:1406, DM_DEFAULT_ENCODING
> Dm: Found reliance on default encoding in org.apache.ofbiz.shipment.thirdparty.usps.UspsServices.uspsDeliveryConfirmation(DispatchContext, Map): String.getBytes()
> Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable. This will cause the application behaviour to vary between platforms. Use an alternative API and specify a charset name or Charset object explicitly.
> --- UspsServices.java:1447, OS_OPEN_STREAM_EXCEPTION_PATH
> OS: org.apache.ofbiz.shipment.thirdparty.usps.UspsServices.uspsDumpShipmentLabelImages(DispatchContext, Map) may fail to close stream on exception
> The method creates an IO stream object, does not assign it to any fields, pass it to other methods, or return it, and does not appear to close it on all possible exception paths out of the method.  This may result in a file descriptor leak.  It is generally a good idea to use a finally block to ensure that streams are closed.
> --- UspsServices.java:1447, OBL_UNSATISFIED_OBLIGATION_EXCEPTION_EDGE
> OBL: org.apache.ofbiz.shipment.thirdparty.usps.UspsServices.uspsDumpShipmentLabelImages(DispatchContext, Map) may fail to clean up java.io.OutputStream on checked exception
> This method may fail to clean up (close, dispose of) a stream, database object, or other resource requiring an explicit cleanup operation.
> In general, if a method opens a stream or other resource, the method should use a try/finally block to ensure that the stream or resource is cleaned up before the method returns.
> This bug pattern is essentially the same as the OS_OPEN_STREAM and ODR_OPEN_DATABASE_RESOURCE bug patterns, but is based on a different (and hopefully better) static analysis technique. We are interested is getting feedback about the usefulness of this bug pattern. To send feedback, either:
> send email to [hidden email]
> file a bug report: http://findbugs.sourceforge.net/reportingBugs.html
> In particular, the false-positive suppression heuristics for this bug pattern have not been extensively tuned, so reports about false positives are helpful to us.
> See Weimer and Necula, Finding and Preventing Run-Time Error Handling Mistakes, for a description of the analysis technique.
> --- UspsServices.java:1547, DLS_DEAD_LOCAL_STORE
> DLS: Dead store to fromCustomsReference in org.apache.ofbiz.shipment.thirdparty.usps.UspsServices.uspsPriorityMailInternationalLabel(DispatchContext, Map)
> This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.
> Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
> --- UspsServices.java:1615, NP_NULL_ON_SOME_PATH_EXCEPTION
> NP: Possible null pointer dereference of product in org.apache.ofbiz.shipment.thirdparty.usps.UspsServices.uspsPriorityMailInternationalLabel(DispatchContext, Map) on exception path
> A reference value which is null on some exception control path is dereferenced here.  This may lead to a NullPointerException when the code is executed.  Note that because FindBugs currently does not prune infeasible exception paths, this may be a false warning.
> Also note that FindBugs considers the default case of a switch statement to be an exception path, since the default case is often infeasible.
> --- UspsServices.java:1624, NP_NULL_ON_SOME_PATH_EXCEPTION
> NP: Possible null pointer dereference of originGeo in org.apache.ofbiz.shipment.thirdparty.usps.UspsServices.uspsPriorityMailInternationalLabel(DispatchContext, Map) on exception path
> A reference value which is null on some exception control path is dereferenced here.  This may lead to a NullPointerException when the code is executed.  Note that because FindBugs currently does not prune infeasible exception paths, this may be a false warning.
> Also note that FindBugs considers the default case of a switch statement to be an exception path, since the default case is often infeasible.
> --- UspsServices.java:1647, DM_DEFAULT_ENCODING
> Dm: Found reliance on default encoding in org.apache.ofbiz.shipment.thirdparty.usps.UspsServices.uspsPriorityMailInternationalLabel(DispatchContext, Map): String.getBytes()
> Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable. This will cause the application behaviour to vary between platforms. Use an alternative API and specify a charset name or Charset object explicitly.
> --- UspsServices.java:1701, DM_DEFAULT_ENCODING
> Dm: Found reliance on default encoding in org.apache.ofbiz.shipment.thirdparty.usps.UspsServices.sendUspsRequest(String, Document, Delegator, String, String, Locale): java.io.ByteArrayOutputStream.toString()
> Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable. This will cause the application behaviour to vary between platforms. Use an alternative API and specify a charset name or Charset object explicitly.
> --- UspsServices.java:1755, PZLA_PREFER_ZERO_LENGTH_ARRAYS
> PZLA: Should org.apache.ofbiz.shipment.thirdparty.usps.UspsServices.convertPoundsToPoundsOunces(BigDecimal) return a zero length array rather than null?
> It is often a better design to return a length zero array rather than a null reference to indicate that there are no results (i.e., an empty list of results). This way, no explicit check for null is needed by clients of the method.
> On the other hand, using null to indicate "there is no answer to this question" is probably appropriate. For example, File.listFiles() returns an empty list if given a directory containing no files, and returns null if the file is not a directory.
> --- UspsServicesTests.java:39, MS_SHOULD_BE_FINAL
> MS: org.apache.ofbiz.shipment.thirdparty.usps.UspsServicesTests.module isn't final but should be
> This static field public but not final, and could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)