[VOTE] jUDDI v3.3.8

[Alex O'Ree]

Dear jUDDI enthusiasts,

The new release is here! This release resolves 4 JIRAs, 2 bugs and 2 minor
enhancements. I did miss updating the release notes within the distro but

The release distribution is temporarily available here
https://www.dropbox.com/sh/mknyo1s4g7er3wl/AAAGJf9LuCDRt1et4tqlKa8ua?dl=0

The release artifacts are staged in nexus:
https://repository.apache.org/content/repositories/orgapachejuddi-1018

and we have a tag at:
https://git-wip-us.apache.org/repos/asf/juddi.git/?p=juddi.git;a=tag;h=refs/tags/juddi-3.3.8

Please give it a spin and cast your vote. This vote will be open for
the next 72 hours per the release policy, which is:
- the vote will be closed as soon as 6 hours have past and  >7 +1
votes are received with no -1 vote being cast, or
 - if after 12h >5 +1 votes have been cast with no -1 vote, or
 - if after 24h if 3 +1 votes have been cast with no -1 vote, or failing
that
 - after 72h provided at least 3 +1 votes have been cast and there is
a majority of +1 votes from the cast votes.

+1 for me


Bug

   - [JUDDI-937 ] -
   PolicyRoundRobin not working without service cache
   - [JUDDI-1003 ] -
   spring-web jar supplied with latest JUDDI distribution has security
   vulnerability

Improvement

   - [JUDDI-993 ] - InVm
   transport for embedded juddi needs to handle authentication and a sample
   for usage
   - [JUDDI-1002 ] -
   tModelInstanceInfo value does not check for maximum length

[jira] [Commented] (JUDDI-1003) spring-web jar supplied with latest JUDDI distribution has security vulnerability

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/JUDDI-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17054191#comment-17054191
 ] 

ASF subversion and git services commented on JUDDI-1003:


Commit a28db0a7a6f30a15bcdd588057a1cfb410a9ff28 in juddi's branch 
refs/heads/master from Alex O'Ree
[ https://gitbox.apache.org/repos/asf?p=juddi.git;h=a28db0a ]

JUDDI-1003 updates spring web dependency
JUDDI-1005 related, fixes the distrubtion so that the executable jar for the 
migration tool is included
NOJIRA minor jsp code cleanup


> spring-web jar supplied with latest JUDDI distribution has security 
> vulnerability
> -
>
> Key: JUDDI-1003
> URL: https://issues.apache.org/jira/browse/JUDDI-1003
> Project: jUDDI
>  Issue Type: Bug
>  Components: juddi-tomcat
>Affects Versions: 3.3.6, 3.3.7
>Reporter: Amol Bhonsle
>Assignee: Alex O'Ree
>Priority: Major
> Fix For: 3.3.8
>
>
> The jar for spring-web (JUDDI 3.3.7 comes with spring-web-3.2.18.RELEASE) 
> which is provided in distribution has following Security Vulnerability.
>  
> The {{org.springframework:spring-web}} package is vulnerable to 
> deserialization of untrusted data leading to Remote Code Execution (RCE).
> The {{readRemoteInvocation}} method in {{HttpInvokerServiceExporter.class}} 
> does not properly verify or restrict untrusted objects prior to deserializing 
> them. An attacker can exploit this vulnerability by sending malicious 
> requests containing crafted objects, which when deserialized, execute 
> arbitrary code on the vulnerable system.
>  
> The {{spring-core}} and {{spring-web}} modules of Spring Framework are 
> vulnerable to a multipart content pollution vulnerability. The 
> {{generateMultipartBoundary()}} method in the {{MimeTypeUtils}} class uses a 
> predictable method of generating random values to use as boundary values for 
> multipart requests to other servers. This means that an attacker may be able 
> to predict the boundary values and inject them into requests at unexpected 
> locations, causing the recipient server to incorrectly interpret the 
> multipart request. This will result in unexpected behavior depending on the 
> requests being processed, including privilege escalation if authorization 
> data is sent in the multipart request.
> Note:
> {quote}In order for the attacker to succeed, they would have to be able to 
> guess the multipart boundary value chosen by server A for the multipart 
> request to server B, which requires the attacker to also have control of the 
> server or the ability to see the HTTP log of server A through a separate 
> attack vector.
> {quote}
>  
> Spring Framework is vulnerable to Cross-Site Tracing (XST) attacks. The 
> {{HiddenHttpMethodFilter}} class lets an attacker change the HTTP request 
> method to {{TRACE}}. An attacker can exploit this behavior with an Cross-Site 
> Scripting (XSS) attack by sending a TRACE request and recovering information 
> that would not normally be accessible, such as Cookies with the HTTPOnly flag.
>  
> Please check and provide fix for this.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JUDDI-1005) Need To have correct options to upgrade JUDDI DB Schema

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/JUDDI-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17054192#comment-17054192
 ] 

ASF subversion and git services commented on JUDDI-1005:


Commit a28db0a7a6f30a15bcdd588057a1cfb410a9ff28 in juddi's branch 
refs/heads/master from Alex O'Ree
[ https://gitbox.apache.org/repos/asf?p=juddi.git;h=a28db0a ]

JUDDI-1003 updates spring web dependency
JUDDI-1005 related, fixes the distrubtion so that the executable jar for the 
migration tool is included
NOJIRA minor jsp code cleanup


> Need To have correct options to upgrade JUDDI DB Schema
> ---
>
> Key: JUDDI-1005
> URL: https://issues.apache.org/jira/browse/JUDDI-1005
> Project: jUDDI
>  Issue Type: Bug
>  Components: juddi-tomcat
>Affects Versions: 3.3.6, 3.3.7
>Reporter: Amol Bhonsle
>Priority: Major
> Attachments: 
> uddi-migration-tool-3.3.8-SNAPSHOT-jar-with-dependencies.jar
>
>
> We are trying to update JUDDI DB from JUDDI-3.0.4 to JUDDI-3.3.7. JUDDI DB is 
> hosted on SQL Server. We use openjpa-2.3.0 which is provided by juddi-3.3.7 
> distribution.
>  
> As per openjpa-2.3.0 documentation:
> {{drop option of SchemaTool should do following:}}
> {{drop}}: Drop all schema components in the schema XML. Tables will only be 
> dropped if they would have 0 columns after dropping all columns listed in the 
> XML.
> and add option should do following:
> {{add}}: This is the default action if you do not specify one. It brings the 
> schema up-to-date with the given XML document by adding tables, columns, 
> indexes, etc. This action never drops any schema components.
> Also it is allowed in persistence.xml to use options as comma separated, so 
> we tried following option in persistence.xml to drop old tables and create 
> new tables as per juddi-3.3.7 schema but it did not work:
>  value="buildSchema(SchemaAction='drop,add')"/>
>  
> This gives following Exception when JUDDI is deployed by tomcat :
>  
> {code:java}
> SEVERE: Exception sending context initialized event to listener instance of 
> class org.springframework.web.context.ContextLoaderListenerSEVERE: Exception 
> sending context initialized event to listener instance of class 
> org.springframework.web.context.ContextLoaderListenerorg.springframework.beans.factory.BeanCreationException:
>  Error creating bean with name 'inquiry': Cannot create inner bean '(inner 
> bean)#fa6535a' of type [org.apache.juddi.api.impl.UDDIInquiryImpl] while 
> setting constructor argument; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name '(inner bean)#fa6535a': Instantiation of bean failed; nested 
> exception is org.springframework.beans.BeanInstantiationException: Failed to 
> instantiate [org.apache.juddi.api.impl.UDDIInquiryImpl]: Constructor threw 
> exception; nested exception is  general error> org.apache.openjpa.persistence.PersistenceException: The 
> object 'PK__j3_clerk__5609ADDDCF01D08E' is dependent on column 'clerk_name'. 
> \{stmnt 1807668378 ALTER TABLE j3_clerk DROP COLUMN clerk_name} [code=5074, 
> state=S0001] at 
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:389)
>  at 
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:134)
>  at 
> org.springframework.beans.factory.support.ConstructorResolver.resolveConstructorArguments(ConstructorResolver.java:691)
>  at 
> org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:196)
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1358)
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1204)
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:557)
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:517)
>  at 
> org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:323)
>  at 
> org.springframework.beans.factory.support.AbstractBeanFactory$$Lambda$208/1654431226.getObject(Unknown
>  Source) at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
>  at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:321)
>  at 
> 

[jira] [Resolved] (JUDDI-1003) spring-web jar supplied with latest JUDDI distribution has security vulnerability

[Alex O'Ree (Jira)]

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

Alex O'Ree resolved JUDDI-1003.
---
Resolution: Fixed

> spring-web jar supplied with latest JUDDI distribution has security 
> vulnerability
> -
>
> Key: JUDDI-1003
> URL: https://issues.apache.org/jira/browse/JUDDI-1003
> Project: jUDDI
>  Issue Type: Bug
>  Components: juddi-tomcat
>Affects Versions: 3.3.6, 3.3.7
>Reporter: Amol Bhonsle
>Assignee: Alex O'Ree
>Priority: Major
> Fix For: 3.3.8
>
>
> The jar for spring-web (JUDDI 3.3.7 comes with spring-web-3.2.18.RELEASE) 
> which is provided in distribution has following Security Vulnerability.
>  
> The {{org.springframework:spring-web}} package is vulnerable to 
> deserialization of untrusted data leading to Remote Code Execution (RCE).
> The {{readRemoteInvocation}} method in {{HttpInvokerServiceExporter.class}} 
> does not properly verify or restrict untrusted objects prior to deserializing 
> them. An attacker can exploit this vulnerability by sending malicious 
> requests containing crafted objects, which when deserialized, execute 
> arbitrary code on the vulnerable system.
>  
> The {{spring-core}} and {{spring-web}} modules of Spring Framework are 
> vulnerable to a multipart content pollution vulnerability. The 
> {{generateMultipartBoundary()}} method in the {{MimeTypeUtils}} class uses a 
> predictable method of generating random values to use as boundary values for 
> multipart requests to other servers. This means that an attacker may be able 
> to predict the boundary values and inject them into requests at unexpected 
> locations, causing the recipient server to incorrectly interpret the 
> multipart request. This will result in unexpected behavior depending on the 
> requests being processed, including privilege escalation if authorization 
> data is sent in the multipart request.
> Note:
> {quote}In order for the attacker to succeed, they would have to be able to 
> guess the multipart boundary value chosen by server A for the multipart 
> request to server B, which requires the attacker to also have control of the 
> server or the ability to see the HTTP log of server A through a separate 
> attack vector.
> {quote}
>  
> Spring Framework is vulnerable to Cross-Site Tracing (XST) attacks. The 
> {{HiddenHttpMethodFilter}} class lets an attacker change the HTTP request 
> method to {{TRACE}}. An attacker can exploit this behavior with an Cross-Site 
> Scripting (XSS) attack by sending a TRACE request and recovering information 
> that would not normally be accessible, such as Cookies with the HTTPOnly flag.
>  
> Please check and provide fix for this.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)