November 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-4982) add-user.sh script use weakeness hashing algorithm (MD5) that is broken for a long time

by Yannick LE NY (JIRA)

Yannick LE NY created AS7-4982: ---------------------------------- Summary: add-user.sh script use weakeness hashing algorithm (MD5) that is broken for a long time Key: AS7-4982 URL: https://issues.jboss.org/browse/AS7-4982 Project: Application Server 7 Issue Type: Bug Components: Console Affects Versions: 7.1.2.Final (EAP) Environment: Jboss EAP 6.0 Beta2 Jboss AS 7.1.1 Linux RHEL 5.4 JDK 1.6.0_24 Reporter: Yannick LE NY Assignee: Heiko Braun Fix For: 7.1.3.Final (EAP) In Jboss EAP 6.0 Beta2 or Jboss AS 7.1.1, we need to use the bin/add-user.sh script to add user access to the Jboss console. And in the the bin/add-user.sh script, you can find that the org.jboss.as.domain-add-user java class is used to : 1) add the login in the files standalone/configuration/mgmt-users.properties and domain/configuration/mgmt-users.properties 2) first hash the password with MD5 hash algorithm and then copy it hashed in the files standalone/configuration/mgmt-users.properties and domain/configuration/mgmt-users.properties When you search about the org.jboss.as.domain-add-user java class on the Internet, you find this source file http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.as/jboss-as-dom... and this file use an import of the org.jboss.sasl.util.UsernamePasswordHashUtil class that is in the file http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/... In the file UsernamePasswordHashUtil.java, we can see that this is the weakness MD5 hash algorithm that is used and that is broken for a long time : At http://en.wikipedia.org/wiki/MD5, the wikipedia article said : "In 1996, a flaw was found with the design of MD5, and while it was not a clearly fatal weakness, cryptographers began recommending the use of other algorithms, such as SHA-1—which has since been found also to be vulnerable. In 2004, more serious flaws were discovered in MD5, making further use of the algorithm for security purposes questionable...In December 2008, a group of researchers used this technique to fake SSL certificate validity,[7][8] and US-CERT now says that MD5 "should be considered cryptographically broken and unsuitable for further use."[9] and most U.S. government applications now require the SHA-2 family of hash functions." org.jboss.sasl.util.UsernamePasswordHashUtil class use java.security.MessageDigest class. As you can see at : http://docs.oracle.com/javase/6/docs/api/java/security/MessageDigest.html, getAlgorithm function can use several hash or Message Digest Algorithms. The hash or Message Digest Algorithms available are : MD2 (weak), MD5 (weak), SHA-1 (weak), SHA-256, SHA-384, and SHA-512 http://docs.oracle.com/javase/1.5.0/docs/guide/security/CryptoSpec.html#AppA http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/Cry... Then can you replace the weakness MD5 Message Digest Algorithm used by add-user.sh by SHA-256 or AES-256. The security team in my big company want now that all the application servers used in the company use strong cipher algorithm as 3DES used by Oracle Weblogic 10 or as AES-256 used by Oracle Weblogic 11. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
10
0 / 0

[JBoss JIRA] (SASL-39) Support for stronger hashes as alternatives to MD5

by Darran Lofthouse (JIRA)

Darran Lofthouse created SASL-39: ------------------------------------ Summary: Support for stronger hashes as alternatives to MD5 Key: SASL-39 URL: https://issues.jboss.org/browse/SASL-39 Project: JBoss SASL Provider Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Darran Lofthouse Fix For: 1.0.4.CR1 Presently Digest authentication is based on MD5 - however we should either update the mechanism or add new mechanisms to support the use of stronger hashes. As this library is used both client and server side installations that require the stronger hashes can just ensure the client and server have the latest version of this library - installations that still require interaction with MD5 will need to ensure that it is still available as a mechanism. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-3977) Serve gzip encoded console resources

by Heiko Braun (JIRA)

Heiko Braun created AS7-3977: -------------------------------- Summary: Serve gzip encoded console resources Key: AS7-3977 URL: https://issues.jboss.org/browse/AS7-3977 Project: Application Server 7 Issue Type: Feature Request Components: Console, Domain Management Reporter: Heiko Braun Assignee: Heiko Braun Fix For: 7.1.2.Final To decrease network latency when loading the console form a remote host. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

3
6
0 / 0

[JBoss JIRA] (AS7-6041) CDI Decorator for a JAX-RS annotated interface results in WELD-001306

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/AS7-6041?page=com.atlassian.jira.plugin.s... ] Jozef Hartinger commented on AS7-6041: -------------------------------------- The problem here is that both the root resource and its decorator implement a JAX-RS-annotated interface. As a result, RESTEasy registers both the resource class and the decorator as resources. RESTEasy then tries to instantiate the abstract decorator class. A CDI decorator should never be registered as a JAX-RS resource, no matter if it's abstract or not. To reproduce, build the application above and visit http://localhost:8080/restTest/rest/user > CDI Decorator for a JAX-RS annotated interface results in WELD-001306 > --------------------------------------------------------------------- > > Key: AS7-6041 > URL: https://issues.jboss.org/browse/AS7-6041 > Project: Application Server 7 > Issue Type: Bug > Components: REST > Affects Versions: 7.1.1.Final > Reporter: Daniel Sachse > Assignee: Stuart Douglas > Fix For: 7.2.0.Alpha1 > > > I already bugged the Errai and Resteasy guys with my problem, but I was told that you guys are in charge of this ;) > I possibly discovered a bug in the Weld implementation provided with JBoss 7.1.1.Final. > I was playing around with Errai and JAX-RS and I discovered that when I add the JAX-RS annotations to the interface this works as expected. > As soon as I start to use a CDI Decorator with the JAX-RS interface, i start getting the following error: > "org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001306 Attempting to inject an unproxyable normal scoped bean Decorator….." > If I then put the JAX-RS annotations back at the implementation, everything works fine. Unfortunately this behavior is not working for me, because Errai needs the annotations at the interface to create client code. > As I was unsure if this only happened with Errai on the classpath, I created a very little demo project, which exactly shows the bug I mentioned: https://github.com/w0mbat/RESTTest -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6041) CDI Decorator for a JAX-RS annotated interface results in WELD-001306

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/AS7-6041?page=com.atlassian.jira.plugin.s... ] Jozef Hartinger moved WELD-1252 to AS7-6041: -------------------------------------------- Project: Application Server 7 (was: Weld) Key: AS7-6041 (was: WELD-1252) Workflow: GIT Pull Request workflow (was: jira) Affects Version/s: 7.1.1.Final (was: 1.1.5.Final) Fix Version/s: 7.2.0.Alpha1 (was: 2.0.0.CR1) > CDI Decorator for a JAX-RS annotated interface results in WELD-001306 > --------------------------------------------------------------------- > > Key: AS7-6041 > URL: https://issues.jboss.org/browse/AS7-6041 > Project: Application Server 7 > Issue Type: Bug > Affects Versions: 7.1.1.Final > Reporter: Daniel Sachse > Assignee: Jozef Hartinger > Fix For: 7.2.0.Alpha1 > > > I already bugged the Errai and Resteasy guys with my problem, but I was told that you guys are in charge of this ;) > I possibly discovered a bug in the Weld implementation provided with JBoss 7.1.1.Final. > I was playing around with Errai and JAX-RS and I discovered that when I add the JAX-RS annotations to the interface this works as expected. > As soon as I start to use a CDI Decorator with the JAX-RS interface, i start getting the following error: > "org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001306 Attempting to inject an unproxyable normal scoped bean Decorator….." > If I then put the JAX-RS annotations back at the implementation, everything works fine. Unfortunately this behavior is not working for me, because Errai needs the annotations at the interface to create client code. > As I was unsure if this only happened with Errai on the classpath, I created a very little demo project, which exactly shows the bug I mentioned: https://github.com/w0mbat/RESTTest -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6041) CDI Decorator for a JAX-RS annotated interface results in WELD-001306

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/AS7-6041?page=com.atlassian.jira.plugin.s... ] Jozef Hartinger updated AS7-6041: --------------------------------- Assignee: Stuart Douglas (was: Jozef Hartinger) Component/s: REST > CDI Decorator for a JAX-RS annotated interface results in WELD-001306 > --------------------------------------------------------------------- > > Key: AS7-6041 > URL: https://issues.jboss.org/browse/AS7-6041 > Project: Application Server 7 > Issue Type: Bug > Components: REST > Affects Versions: 7.1.1.Final > Reporter: Daniel Sachse > Assignee: Stuart Douglas > Fix For: 7.2.0.Alpha1 > > > I already bugged the Errai and Resteasy guys with my problem, but I was told that you guys are in charge of this ;) > I possibly discovered a bug in the Weld implementation provided with JBoss 7.1.1.Final. > I was playing around with Errai and JAX-RS and I discovered that when I add the JAX-RS annotations to the interface this works as expected. > As soon as I start to use a CDI Decorator with the JAX-RS interface, i start getting the following error: > "org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001306 Attempting to inject an unproxyable normal scoped bean Decorator….." > If I then put the JAX-RS annotations back at the implementation, everything works fine. Unfortunately this behavior is not working for me, because Errai needs the annotations at the interface to create client code. > As I was unsure if this only happened with Errai on the classpath, I created a very little demo project, which exactly shows the bug I mentioned: https://github.com/w0mbat/RESTTest -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-5889) Remote client EJB invocation hangs when a large String is passed as parameter

by Tom Ross (JIRA)

Tom Ross created AS7-5889: ----------------------------- Summary: Remote client EJB invocation hangs when a large String is passed as parameter Key: AS7-5889 URL: https://issues.jboss.org/browse/AS7-5889 Project: Application Server 7 Issue Type: Bug Components: EJB Affects Versions: 7.1.3.Final (EAP) Environment: EAP 6.01 ER3 Reporter: Tom Ross Assignee: jaikiran pai Priority: Critical When making an EJB invocation with a String parameter of length 600000 the invocation hangs and never returns. This seem to happen only with 6.01 code line running the test case against 6.1 does not show the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
5
0 / 0

[JBoss JIRA] (AS7-5794) JMX over remoting pollutes query results with ModelController objects

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/AS7-5794?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant commented on AS7-5794: -------------------------------------- [~kabirkhan] I haven't tested against 7.2.x yet. I will if I find some time > JMX over remoting pollutes query results with ModelController objects > --------------------------------------------------------------------- > > Key: AS7-5794 > URL: https://issues.jboss.org/browse/AS7-5794 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management, JMX > Affects Versions: 7.1.2.Final (EAP) > Reporter: Tristan Tarrant > Assignee: Kabir Khan > Fix For: 7.3.0.Alpha1 > > > When issuing MBean queries over JMX remoting, the AS is returning a list of org.jboss.as.controller.ModelController objects in addition to those matching the query. > This is a transcript of a chat we had about it on IRC: > Oct 15 14:51:46 <ttarrant> darranl, if I issue a jmx query over jmx-remoting I get many more objects than expected > Oct 15 14:51:55 <ttarrant> darranl, i.e. ones that do not match the query > Oct 15 14:52:09 <ttarrant> darranl, this is with 7.1.x > Oct 15 14:52:57 <ttarrant> darranl, this works if I use the standard JMX over RMI > Oct 15 14:53:08 --> fnasser (~fnasser(a)CPE602ad07ab726-CM602ad07ab723.cpe.net.cable.rogers.com) has joined #jboss-as7 > Oct 15 14:53:09 <-- fnasser has quit (Changing host) > Oct 15 14:53:09 --> fnasser (~fnasser@redhat/jboss/fnasser) has joined #jboss-as7 > Oct 15 14:53:09 --- ChanServ gives voice to fnasser > Oct 15 14:53:16 <ttarrant> darranl, do you just pass the query the the mbeanserver ? > Oct 15 14:53:39 <darranl> ttarrant: what kind of objects? within AS7 I think there are two things that could affec > t this 1 - The Remoting JMX protocol, 2 - The domain management representation over JMX > Oct 15 14:53:54 <darranl> For #1 yes we just pass it to the MBEanServer and return whatever it returns > Oct 15 14:54:04 <darranl> if it was a Remoting JMX bug maybe we are messing up the query > Oct 15 14:54:16 <ttarrant> darranl, the query is as follows: *:type=CacheManager,component=Interpreter,name=* > Oct 15 14:54:16 <darranl> But not sure if #2 could be the reason more is getting added > Oct 15 14:54:32 <ttarrant> darranl, wait a sec > Oct 15 14:54:57 <darranl> ttarrant: I would suggest getting a Jira raised and assigned to me, I can verify if it i > s a remoting jmx issue or pass over if it is a domain management integration issue > Oct 15 14:55:20 <darranl> regardless of where it is happenign it sounds like you may have discovered a bug > Oct 15 14:56:23 <ttarrant> darranl, let me get the objects it's returning > Oct 15 14:56:39 <darranl> ttarrant: when you enable the RMI approach you bypass both Remoting JMX AND the domain m > anagement integration > Oct 15 14:56:42 <darranl> ok > Oct 15 15:26:08 <ttarrant> darranl, ok, my query actually returns the object I queried for and a bunch of org.jboss.as.controller.ModelController (one for each subsystem) > Oct 15 15:51:24 <darranl> ttarrant: ok that does then sound like it is the domain management integration that is 'poluting' the query results > Oct 15 15:51:53 <darranl> ttarrant: going RMI was just bypassing that as well > Oct 15 15:52:05 <ttarrant> darranl, shall I open a Jira ? > Oct 15 15:52:34 <ttarrant> darranl, I work around the issue by manually filtering the returned objects based on class name > Oct 15 15:53:23 <darranl> ttarrant: it would probably be one for kkhan to look into, think he is just back today so may be worth the Jira so he can have a look once he has caught back up ;-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-5895) Using an annotation from a private api module does not result in a warning

by Carlo de Wolf (JIRA)

Carlo de Wolf created AS7-5895: ---------------------------------- Summary: Using an annotation from a private api module does not result in a warning Key: AS7-5895 URL: https://issues.jboss.org/browse/AS7-5895 Project: Application Server 7 Issue Type: Bug Reporter: Carlo de Wolf If an user deployment uses an annotation from a module that is marked as private there is no warning being emitted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
3
0 / 0

[JBoss JIRA] (JBJCA-907) Eclipse plugin: Avoid adding config property value for ActivationSpec in resource adapter version 1.5

by Vladimir Rastseluev (JIRA)

Vladimir Rastseluev created JBJCA-907: ----------------------------------------- Summary: Eclipse plugin: Avoid adding config property value for ActivationSpec in resource adapter version 1.5 Key: JBJCA-907 URL: https://issues.jboss.org/browse/JBJCA-907 Project: IronJacamar Issue Type: Bug Components: Eclipse Affects Versions: 1.1.0.Beta2 Reporter: Vladimir Rastseluev Assignee: Jeff Zhang Fix For: 1.1.0.Beta3 Due to 1.5 specification schema, there is no possibility to add configuration property value to ActivationSpec class. Please, avoid it in eclipse plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

3
6
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2012