[
https://issues.apache.org/jira/browse/OFBIZ-10837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097922#comment-17097922 ]
ASF subversion and git services commented on OFBIZ-10837:
---------------------------------------------------------
Commit 3f60efb343a11723aa56c1bc1f5afac3a2f26e9f in ofbiz-framework's branch refs/heads/trunk from Jacques Le Roux
[
https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=3f60efb ]
Improved: Improve ObjectInputStream class
(OFBIZ-10837)
While working on OFBIZ-11633 I crossed an issue in R18 (not in trunk) where
objects from org.apache.commons.fileupload (namely DiskFileItem and
FileItemHeadersImpl) are not serializable.
While at it I decided to handle at the SafeObjectInputStream level
the "fileItems" case I already crossed with, OFBIZ-11534, in RequestHandler
It has an inconvenient in R18 (not in trunk) where ObjectInputStream can't
handle a null class (of course) and so return a benign exception in log (only).
I believe it's better to handle these specific cases at the lower possible
level in all supported branches.
> Improve ObjectInputStream class (CVE-2019-0189)
> -----------------------------------------------
>
> Key: OFBIZ-10837
> URL:
https://issues.apache.org/jira/browse/OFBIZ-10837> Project: OFBiz
> Issue Type: Sub-task
> Components: framework
> Affects Versions: Release Branch 16.11, Release Branch 18.12, Release Branch 17.12
> Reporter: Jacques Le Roux
> Assignee: Jacques Le Roux
> Priority: Major
> Fix For: 16.11.06, 18.12.01, 17.12.01
>
>
> As reported by FindBugs and Sonar, it's troubling (a Bad practice in Sonar[1], a code smell in Findbugs[2]) when extending to use the same name than the extended Object.[3]
> [1] [
https://sbforge.org/sonar/rules/show/findbugs:NM_SAME_SIMPLE_NAME_AS_SUPERCLASS?layout=false]
> [2] [
https://logging.apache.org/log4j/log4j-2.2/log4j-jul/findbugs.html]
> [3] Bug: The class name org.apache.ofbiz.base.util.ObjectInputStream shadows the simple name of the superclass java.io.ObjectInputStream
> This class has a simple name that is identical to that of its superclass, except that its superclass is in a different package (e.g., alpha.Foo extends beta.Foo). This can be exceptionally confusing, create lots of situations in which you have to look at import statements to resolve references and creates many opportunities to accidentally define methods that do not override methods in their superclasses.
> Rank: Troubling (14), confidence: High
> Pattern: NM_SAME_SIMPLE_NAME_AS_SUPERCLASS
> Type: Nm, Category: BAD_PRACTICE (Bad practice)
> {color:#de350b}2019/09/12: Initiallty this description was intentionnaly done to somehow hide a security issue (CVE-2019-0189) while allowing to fix the bug.{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Locked
