java-sig-commits December 2014

java-sig-commits@lists.fedoraproject.org

13 participants
408 discussions

[Bug 958727] New: plexus-utils: XMLWriterUtil should guard against problematic comments
by Red Hat Bugzilla 08 May '16

08 May '16

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=958727 Bug ID: 958727 Summary: plexus-utils: XMLWriterUtil should guard against problematic comments Product: Fedora Version: rawhide Component: plexus-utils Severity: unspecified Priority: unspecified Assignee: fnasser(a)redhat.com Reporter: fweimer(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: fnasser(a)redhat.com, java-sig-commits(a)lists.fedoraproject.org, mizdebsk(a)redhat.com Blocks: 958220 Category: --- org.codehaus.plexus.util.xml#writeComment(XMLWriter, String, int, int, int) does not check if the comment includes a "-->" sequence. This means that text contained in the command string could be interpreted as XML, possibly leading to XML injection issues, depending on how this method is being called. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=N5myzkUcYQ&a=cc_unsubscribe

1 6

[Bug 958221] New: plexus-utils: directory traversal in org.codehaus.plexus.util.Expand
by Red Hat Bugzilla 08 May '16

08 May '16

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=958221 Bug ID: 958221 Summary: plexus-utils: directory traversal in org.codehaus.plexus.util.Expand Product: Fedora Version: rawhide Component: plexus-utils Severity: unspecified Priority: unspecified Assignee: fnasser(a)redhat.com Reporter: fweimer(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: fnasser(a)redhat.com, java-sig-commits(a)lists.fedoraproject.org, mizdebsk(a)redhat.com Blocks: 958220 Category: --- org.codehaus.plexus.util.Expand does not guard against directory traversal, but such protection is generally expected from unarchiving tools. I think the class should just be deprecated and removed because there do not appear to be any users left (not even a test case). -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=hp1lhU9LQd&a=cc_unsubscribe

1 5

[Bug 1098412] New: pax-logging: Bundles code from other logging libraries
by Red Hat Bugzilla 06 Feb '16

06 Feb '16

https://bugzilla.redhat.com/show_bug.cgi?id=1098412 Bug ID: 1098412 Summary: pax-logging: Bundles code from other logging libraries Product: Fedora Version: rawhide Component: pax-logging Assignee: puntogil(a)libero.it Reporter: fweimer(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: java-sig-commits(a)lists.fedoraproject.org, puntogil(a)libero.it Blocks: 1098237 pax-logging-1.6.9-8.fc21.noarch bundles class files from other Fedora packages in its JAR files, e.g. org/slf4j/ILoggerFactory (from slf4j-0:1.7.7-1.fc21.noarch), org/apache/log4j/helpers/ThreadLocalMap (from log4j-0:1.2.17-16.fc21.noarch), and some OSGI-related classes like org/osgi/service/log/LogEntry whose main package is a bit unclear. This is against the Fedora packaging guidelines, specifically <http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries>. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1098237 [Bug 1098237] Java "static linking"/class bundling in Fedora -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=DUsKDiC5iv&a=cc_unsubscribe

1 6

[Bug 1140314] New: CVE-2013-4444 tomcat: remote code execution via uploaded JSP
by Red Hat Bugzilla 06 Feb '16

06 Feb '16

https://bugzilla.redhat.com/show_bug.cgi?id=1140314 Bug ID: 1140314 Summary: CVE-2013-4444 tomcat: remote code execution via uploaded JSP Product: Security Response Component: vulnerability Keywords: Security Severity: high Priority: high Assignee: security-response-team(a)redhat.com Reporter: vdanen(a)redhat.com CC: akurtako(a)redhat.com, dknox(a)redhat.com, gmurphy(a)redhat.com, ivan.afonichev(a)gmail.com, java-sig-commits(a)lists.fedoraproject.org, jclere(a)redhat.com, jdoyle(a)redhat.com, krzysztof.daniel(a)gmail.com, lgao(a)redhat.com, myarboro(a)redhat.com, pslavice(a)redhat.com, rsvoboda(a)redhat.com, weli(a)redhat.com As reported fixed in Apache Tomcat 7.0.40 [1]: In very limited circumstances, it was possible for an attacker to upload a malicious JSP to a Tomcat server and then trigger the execution of that JSP. While Remote Code Execution would normally be viewed as a critical vulnerability, the circumstances under which this is possible are, in the view of the Tomcat security team, sufficiently limited that this vulnerability is viewed as important. For this attack to succeed all of the following requirements must be met: 1. Using Oracle Java 1.7.0 update 25 or earlier (or any other Java implementation where java.io.File is vulnerable to null byte injection). 2. A web application must be deployed to a vulnerable version of Tomcat. 3. The web application must use the Servlet 3.0 File Upload feature. 4. A file location within a deployed web application must be writeable by the user the Tomcat process is running as. The Tomcat security documentation recommends against this. 5. A custom listener for JMX connections (e.g. the JmxRemoteListener that is not enabled by default) must be configured and be able to load classes from Tomcat's common class loader (i.e. the custom JMX listener must be placed in Tomcat's lib directory). 6. The custom JMX listener must be bound to an address other than localhost for a remote attack (it is bound to localhost by default). If the custom JMX listener is bound to localhost, a local attack will still be possible. Note that requirements 2 and 3 may be replaced with the following requirement: 7. A web application is deployed that uses Apache Commons File Upload 1.2.1 or earlier. In this case (requirements 1, 4, 5, 6 and 7 met) a similar vulnerability may exist on any Servlet container, not just Apache Tomcat. This was fixed in revision 1470437. [2] (April 22, 2013) This issue was identified by Pierre Ernst of the VMware Security Engineering, Communications and Response group (vSECR) and reported to the Tomcat security team via the Pivotal security team on 5 September 2014. It was made public on 10 September 2014. Affects: 7.0.0 to 7.0.39 [1] http://tomcat.apache.org/security-7.html#Fixed_in_Apache_Tomcat_7.0.40 [2] http://svn.apache.org/viewvc?view=revision&revision=1470437 Statement: This issue did not affect the versions of tomcat as shipped with Red Hat Enterprise Linux 5, 6, or 7 nor the versions of tomcat as shipped with JBoss Enterprise Web Server. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=NIGlAdEiPm&a=cc_unsubscribe

1 9

[Bug 1004916] New: Package doesn't provide a sysvinit script or systemd service unit
by Red Hat Bugzilla 28 Jan '16

28 Jan '16

https://bugzilla.redhat.com/show_bug.cgi?id=1004916 Bug ID: 1004916 Summary: Package doesn't provide a sysvinit script or systemd service unit Product: Fedora Version: 19 Component: activemq Severity: high Assignee: mspaulding06(a)gmail.com Reporter: skottler(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: agrimm(a)redhat.com, java-sig-commits(a)lists.fedoraproject.org, mspaulding06(a)gmail.com, tdawson(a)redhat.com Description of problem: activemq doesn't provide the necessary scripts/config files to start. Version-Release number of selected component (if applicable): 0:5.6.0-5.fc19 How reproducible: Always. Steps to Reproduce: 1. yum install -y activemq activemq-core 2. try starting the service 3. note there is not a service unit This seems like a fairly major thing to be missing in the packages. Is there another package or metapackage that needs to be installed for it to work? -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=IC3tNZ0uDP&a=cc_unsubscribe

1 15

[Bug 1127276] New: CVE-2014-5075 smack: MitM vulnerability
by Red Hat Bugzilla 21 Jan '16

21 Jan '16

https://bugzilla.redhat.com/show_bug.cgi?id=1127276 Bug ID: 1127276 Summary: CVE-2014-5075 smack: MitM vulnerability Product: Security Response Component: vulnerability Keywords: Security Severity: medium Priority: medium Assignee: security-response-team(a)redhat.com Reporter: vkaigoro(a)redhat.com CC: brms-jira(a)redhat.com, java-sig-commits(a)lists.fedoraproject.org, pavelp(a)redhat.com, puntogil(a)libero.it, tkirby(a)redhat.com, weli(a)redhat.com It was reported [1] that Smack (XMPP client library) is vulnerable to MitM attacks with a crafted SSL certificates. Quote from [1]: ... Details ------- Smack is using Java's `SSLSocket`, which checks the peer certificate using an `X509TrustManager`, but does not perform hostname verification. Therefore, it is possible to redirect the traffic between a Smack-using application and a legitimate XMPP server through the attacker's server, merely by providing a valid certificate for a domain under the attacker's control. In Smack versions 2.2.0 to 3.4.1, a custom `ServerTrustManager` implementation was used, which was supplied with the connection's server name, and performed hostname verification. However, it failed to verify the basicConstraints and nameConstraints of the certificate chain (CVE-2014-0363, http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0363) and has been removed in Smack 4.0.0. Applications using Smack 2.2.0 to 3.4.1 with a custom `TrustManager` did not benefit from `ServerTrustManager` and are vulnerable as well, unless their own `TrustManager` implementation explicitly performs hostname verification. ... [1]: http://seclists.org/bugtraq/2014/Aug/29 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=vQuZmnHNAP&a=cc_unsubscribe

1 13

[Bug 1079233] New: mockito: update to 1.9.5
by Red Hat Bugzilla 05 Jan '16

05 Jan '16

https://bugzilla.redhat.com/show_bug.cgi?id=1079233 Bug ID: 1079233 Summary: mockito: update to 1.9.5 Product: Fedora Version: rawhide Component: mockito Assignee: rkennke(a)redhat.com Reporter: msrb(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: akurtako(a)redhat.com, java-sig-commits(a)lists.fedoraproject.org, jerboaa(a)gmail.com, omajid(a)redhat.com, rkennke(a)redhat.com Created attachment 877167 --> https://bugzilla.redhat.com/attachment.cgi?id=877167&action=edit update to 1.9.5 Description of problem: Upstream version 1.9.5 is available. Rawhide currently contains version 1.9.0. Attached patch was created by Michael Simacek (see #1040350). -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=dvsIbd2J0V&a=cc_unsubscribe

1 7

[Bug 1147963] New: JENKINS script for showing failed jobs is not working
by Red Hat Bugzilla 01 Dec '15

01 Dec '15

https://bugzilla.redhat.com/show_bug.cgi?id=1147963 Bug ID: 1147963 Summary: JENKINS script for showing failed jobs is not working Product: Fedora Version: 21 Component: jenkins Severity: medium Assignee: msrb(a)redhat.com Reporter: amsharma(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: java-sig-commits(a)lists.fedoraproject.org, msrb(a)redhat.com Description of problem: JENKINS script for showing failed jobs is not working Version-Release number of selected component (if applicable): [root@dhcp201-185 ~]# rpm -qa | grep jenkins jenkins-icon-shim-1.0.3-1.fc21.noarch js-yui2-jenkins-2.9.0-6.fc21.noarch jenkins-task-reactor-1.4-2.fc21.noarch jenkins-external-monitor-job-plugin-1.2-1.fc21.noarch jenkins-javadoc-plugin-1.2-1.fc21.noarch jenkins-commons-jelly-1.1.20120928-6.fc21.noarch jenkins-instance-identity-1.3-4.fc21.noarch jenkins-sshd-1.6-4.fc21.noarch jenkins-1.581-2.fc21.noarch jenkins-ant-plugin-1.2-1.fc21.noarch jenkins-executable-war-1.29-3.fc21.noarch jenkins-xstream-1.4.7-3.jenkins1.fc21.noarch trilead-ssh2-217-4.jenkins4.fc21.noarch jenkins-ssh-cli-auth-1.2-4.fc21.noarch jenkins-core-1.581-2.fc21.noarch jenkins-remoting-2.43-1.fc21.noarch jenkins-json-lib-2.4-7.fc21.noarch jenkins-junit-plugin-1.1-1.fc21.noarch jenkins-mailer-plugin-1.11-1.fc21.noarch jenkins-extras-memory-monitor-1.8-1.fc21.noarch jenkins-crypto-util-1.4-2.fc21.noarch jenkins-version-number-1.1-4.fc21.noarch jenkins-webapp-1.581-2.fc21.noarch jenkins-winstone-2.3-1.fc21.noarch jenkins-jexl-1.1-3.20111212.fc21.noarch jenkins-cli-1.581-2.fc21.noarch How reproducible: Always Steps to Reproduce: 1.go to https://wiki.jenkins-ci.org/display/JENKINS/Failed+Jobs 2. copy script and paste in localhost:8080/script Actual results: It does not display anything in output. Result Result: [] Expected results: It should display all failed jobs Additional info: I had failed jobs in my jenkins -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=63mWa2HTjL&a=cc_unsubscribe

1 4

[Bug 1147105] New: CATALINA_OPTS are only read when SECURITY_MANAGER is true
by Red Hat Bugzilla 17 Nov '15

17 Nov '15

https://bugzilla.redhat.com/show_bug.cgi?id=1147105 Bug ID: 1147105 Summary: CATALINA_OPTS are only read when SECURITY_MANAGER is true Product: Fedora Version: 20 Component: tomcat Assignee: ivan.afonichev(a)gmail.com Reporter: awood(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: ivan.afonichev(a)gmail.com, java-sig-commits(a)lists.fedoraproject.org, krzysztof.daniel(a)gmail.com Description of problem: The CATALINA_OPTS configuration value is ignored during Tomcat start-up unless the SECURITY_MANAGER configuration value is set to true. By default SECURITY_MANAGER is set to "false" so this issue can be pretty confusing if you're trying to add to CATALINA_OPTS and nothing happens. Version-Release number of selected component (if applicable): tomcat-7.0.52-1.fc20.noarch How reproducible: Always Steps to Reproduce: 1. Edit /etc/tomcat/tomcat.conf 2. Set CATALINA_OPTS to something. "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000" for example. 3. Set SECURITY_MANAGER to "false" 3. Restart tomcat. 4. pgrep -fla tomcat Actual results: The pgrep command reveals that Tomcat is running without the values set in CATALINA_OPTS. Expected results: CATALINA_OPTS are present. Additional info: This bug is actually due to the fix to bug 1051194. In the bugfix, the reading in of CATALINA_OPTS has been moved in /usr/libexec/tomcat/server into a block that requires SECURITY_MANAGER to be true. if [ "$1" = "start" ] ; then if [ "${SECURITY_MANAGER}" = "true" ] ; then FLAGS="${FLAGS} $CATALINA_OPTS" OPTIONS="${OPTIONS} \ -Djava.security.manager \ -Djava.security.policy==${CATALINA_BASE}/conf/catalina.policy" fi run start I propose that the flags be read before looking at the security manager settings. Like if [ "$1" = "start" ] ; then FLAGS="${FLAGS} $CATALINA_OPTS" if [ "${SECURITY_MANAGER}" = "true" ] ; then OPTIONS="${OPTIONS} \ -Djava.security.manager \ -Djava.security.policy==${CATALINA_BASE}/conf/catalina.policy" fi run start Possible OPTIONS should be read outside of the block too? -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=H3lP9UbWQ1&a=cc_unsubscribe

1 6

[Bug 1177153] New: zookeeper-lib-devel is missing
by Red Hat Bugzilla 04 Nov '15

04 Nov '15

https://bugzilla.redhat.com/show_bug.cgi?id=1177153 Bug ID: 1177153 Summary: zookeeper-lib-devel is missing Product: Fedora Version: 21 Component: zookeeper Assignee: tstclair(a)redhat.com Reporter: fedora(a)famillecollet.com QA Contact: extras-qa(a)fedoraproject.org CC: ethan(a)ethantuttle.com, java-sig-commits(a)lists.fedoraproject.org, jeff(a)ocjtech.us, s(a)shk.io, tstclair(a)redhat.com Up to Fedora 20 zookeeper-lib-devel was available. I understand that zookeeper-devel provides the needed stuf. I think zookeeper-devel have to obsoletes and provides zookeeper-lib-devel And zookeeper have to obsoletes and provides zookeeper-lib This will allow smoth update from Fedora < 21 And avoid having to conditionalize the BR in dependent packages (even if I prefer the previous layout, which pull much less dependency) P.S. I use this to build php-pecl-zookeper (but not yet submitted for Fedora repo) -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=6r7IOnjNPg&a=cc_unsubscribe

1 3

← Newer
1
2
3
4
5
6
7
...
41
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

java-sig-commits December 2014