[JBoss JIRA] Created: (SECURITY-344) Error decrypting datasource password with SecureIdentityLoginModule
by Marcus Moyses (JIRA)
Error decrypting datasource password with SecureIdentityLoginModule
-------------------------------------------------------------------
Key: SECURITY-344
URL: https://jira.jboss.org/jira/browse/SECURITY-344
Project: JBoss Security and Identity Management
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JBossSX
Affects Versions: 2.0.2.SP3
Reporter: Marcus Moyses
Assignee: Marcus Moyses
Fix For: 2.0.2.SP5
During password decryption using SecureIdentityLoginModule there could be an error due to missing leading zeros for certain passwords.
This error might appear in the log:
[SecureIdentityLoginModule] Failed to decode password
javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.BlowfishCipher.engineDoFinal(DashoA12275)
at javax.crypto.Cipher.doFinal(DashoA12275)
at org.jboss.resource.security.SecureIdentityLoginModule.decode(SecureIdentityLoginModule.java:173)
at org.jboss.resource.security.SecureIdentityLoginModule.commit(SecureIdentityLoginModule.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (JBAS-4078) DeploymentManager.getAvailableModules() returns null
by Libor Kotouc (JIRA)
DeploymentManager.getAvailableModules() returns null
----------------------------------------------------
Key: JBAS-4078
URL: http://jira.jboss.com/jira/browse/JBAS-4078
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services
Affects Versions: JBossAS-5.0.0.Beta2
Environment: JBoss 5.0.0.beta2 trunk build 20070206, JDK 1.5.0_08
Reporter: Libor Kotouc
Assigned To: Dimitris Andreadis
Priority: Critical
This issue blocks an integration of JBoss AS 5 into NetBeans IDE.
Steps to reproduce the behavior:
1. create a simple web application and copy the .war file into the deploy directory (I used the 'default' server)
2. start JBoss server (./run.sh)
3. run the following code from a J2SE application (I added JBoss jars to the classpath):
public class Main {
public static void main(String[] args) {
try {
javax.enterprise.deploy.spi.factories.DeploymentFactory df = new org.jboss.deployment.spi.factories.DeploymentFactoryImpl();
javax.enterprise.deploy.spi.DeploymentManager dm;
dm = df.getDeploymentManager("http://org.jboss.deployment/jsr88", null, null);
javax.enterprise.deploy.spi.Target[] targets = dm.getTargets();
javax.enterprise.deploy.spi.TargetModuleID[] modules;
modules = dm.getAvailableModules(javax.enterprise.deploy.shared.ModuleType.WAR, targets);
System.out.println(targets.length + " " + targets[0]);
System.out.println(modules);
} catch (javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException ex) {
} catch (javax.enterprise.deploy.spi.exceptions.TargetException ex) {
}
}
}
The output of System.out.println statements is:
1 org.jboss.deployment.spi.JMXTarget@161d36b
null
I expect the module representing the web application, but null is returned.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (JGRP-1279) ENCRYPT: algorithm provider only half implemented
by Bela Ban (JIRA)
ENCRYPT: algorithm provider only half implemented
-------------------------------------------------
Key: JGRP-1279
URL: https://issues.jboss.org/browse/JGRP-1279
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.6.19, 2.12
[Dennis Reed]
ENCRYPT allows the asym_provider to be specified.
But it only uses it for the KeyGenerator lookup, not the Cipher lookup.
And the sym_provider is hard-coded to null.
Is there a reason the sym_provider isn't configurable, and that the providers aren't used for the Cipher lookups?
This is causing issues for a customer, because they have an application that inserts a security provider at the beginning of the list.
When JGroups first starts, it uses the default provider (BouncyCastle), but if there's a shun/reconnect after the application
has inserted its provider, JGroups switches to the application's provider. And since some members are now using a different provider,
they can't communicate.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (JGRP-1205) Retransmitter reset does not prevent new task addition after chanel close
by Vladimir Blagojevic (JIRA)
Retransmitter reset does not prevent new task addition after chanel close
-------------------------------------------------------------------------
Key: JGRP-1205
URL: https://jira.jboss.org/browse/JGRP-1205
Project: JGroups
Issue Type: Bug
Affects Versions: 2.9, 2.8, 2.7, 2.6.15
Reporter: Vladimir Blagojevic
Assignee: Bela Ban
Fix For: 2.10
Sometimes, messages are being added to the Retransmitter *after* a channel has been . This can happen if OOB messages are being passed around at the time a channel leaving a group. The problem occurs in that messages are added after Retransmitter.reset(). Normally, the timer is also stopped when the channel is disconnected, but since the Timer is shared amongst all channels, any messages added to Retransmitter after reset() just continue to be requested because the timer that those tasks were scheduled on did not die.
This can be solved by either specifically stopping the Retransmitter or giving each ProtocolAdapter their own Timer which is then shutdown on channel disconnect.
Michael
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months