[JBoss JIRA] (ELY-183) Protocols for password changing
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-183?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-183:
--------------------------------------
The problem with that is that the password change may be happening due to the existing password being compromised.
> Protocols for password changing
> -------------------------------
>
> Key: ELY-183
> URL: https://issues.jboss.org/browse/ELY-183
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI
> Reporter: Darran Lofthouse
> Fix For: 1.0.0.Final
>
>
> Potentially this is a bit of a research task, as I have mentioned in a couple of places I don't like relying on SSL exclusively for confidentiality - my reasons being it is perfect until their is a compromise and then it is as useful as a chocolate tea pot ;-)
> A lot of the emphasis in the Elytron development so far has been implementation of the more secure SASL mechanisms to eliminate weak password exchanges between a client and the server - however we still have the need for password to be set remotely, this task is to explore some of those options.
> Are there any existing protocols to remotely set a password securely?
> Is there anything specific to our current password types we can take advantage of?
> Are there features of any of our SASL mechanisms to apply a second layer of confidentiality?
> Any other options?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ELY-183) Protocols for password changing
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-183?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-183:
--------------------------------
Only idea: send new password encrypted with old password (or its hash)
> Protocols for password changing
> -------------------------------
>
> Key: ELY-183
> URL: https://issues.jboss.org/browse/ELY-183
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI
> Reporter: Darran Lofthouse
> Fix For: 1.0.0.Final
>
>
> Potentially this is a bit of a research task, as I have mentioned in a couple of places I don't like relying on SSL exclusively for confidentiality - my reasons being it is perfect until their is a compromise and then it is as useful as a chocolate tea pot ;-)
> A lot of the emphasis in the Elytron development so far has been implementation of the more secure SASL mechanisms to eliminate weak password exchanges between a client and the server - however we still have the need for password to be set remotely, this task is to explore some of those options.
> Are there any existing protocols to remotely set a password securely?
> Is there anything specific to our current password types we can take advantage of?
> Are there features of any of our SASL mechanisms to apply a second layer of confidentiality?
> Any other options?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFCORE-841) Patching module testsuite failure
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-841?page=com.atlassian.jira.plugin... ]
Alexey Loubyansky commented on WFCORE-841:
------------------------------------------
Given the async nature of the new Aesh, your guess of the output being late is worth investigating. That would mean other tests could be affected too. [~brian.stansberry] have you seen this failure only in this test? And on this line?
> Patching module testsuite failure
> ---------------------------------
>
> Key: WFCORE-841
> URL: https://issues.jboss.org/browse/WFCORE-841
> Project: WildFly Core
> Issue Type: Bug
> Components: Patching
> Environment: $ java -version
> java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
> OS X Yosemite 10.10.4
> Reporter: Brian Stansberry
> Assignee: Alexey Loubyansky
> Fix For: 2.0.0.Alpha12
>
>
> When running the core build locally , the 'patching' module testsuite fails:
> {code}
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> objc[58076]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/bin/java and /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined.
> Running org.jboss.as.patching.cli.ContentConflictsUnitTestCase
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.892 sec - in org.jboss.as.patching.cli.ContentConflictsUnitTestCase
> Running org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.269 sec - in org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase
> Running org.jboss.as.patching.cli.PatchInspectUnitTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec <<< FAILURE! - in org.jboss.as.patching.cli.PatchInspectUnitTestCase
> testMain(org.jboss.as.patching.cli.PatchInspectUnitTestCase) Time elapsed: 0.044 sec <<< FAILURE!
> java.lang.AssertionError: expected:<{Type=one-off, Description=this is one-off patch 1, Identity name=product, Identity version=version, Patch ID=e7221af6-a05f-49f9-bf24-e40501b54db6, Link=http://test.one}> but was:<{}>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:76)
> at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:57)
> at org.jboss.as.patching.cli.PatchInspectUnitTestCase.testMain(PatchInspectUnitTestCase.java:180)
> {code}
> If I clean and run the test by itself, it passes. It also passes on the CI jobs on brontes, but the log shows the tests excecute in a different order.
> Given all that, my expectation is that one of the two tests that run locally before the failing one is leaving some sort of mess behind. I've found that @Ignoring org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase solves the problem, so I will send up a PR that does that as a workaround.
> The problem does not occur with 2.0.0.Alpha11, and there are only two commits in master since then. One is an undertow upgrade, so it's almost certain the problem was introduced with the other: https://github.com/wildfly/wildfly-core/pull/904
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFCORE-774) Memory leak in JBoss CLI
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-774?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-774:
------------------------------------------------
Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1232736|https://bugzilla.redhat.com/show_bug.cgi?id=1232736] from ON_QA to VERIFIED
> Memory leak in JBoss CLI
> ------------------------
>
> Key: WFCORE-774
> URL: https://issues.jboss.org/browse/WFCORE-774
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 1.0.0.CR6, 2.0.0.Alpha4
> Reporter: Josef Cacek
> Assignee: Tomas Hofman
>
> The JBoss CLI contains a memory leak related to CLI Kerberos authentication.
> The {{org.jboss.as.cli.impl.CommandContextImpl}} class calls the {{initJaasConfig()}} in its constructor,
> which adds a new {{JaasConfigurationWrapper}} instance to {{javax.security.auth.login.Configuration}}.
> It's done for every new {{CommandContext}} instance, so it consumes more and more memory. There is no cleanup for the registered
> configurations.
> Moreover, the searches for appropriate
> login config take more and more time because they have to go through all the wrapped objects.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (JGRP-1946) Auth succeeds when the node without auth starts first
by fatih fatih (JIRA)
[ https://issues.jboss.org/browse/JGRP-1946?page=com.atlassian.jira.plugin.... ]
fatih fatih updated JGRP-1946:
------------------------------
Description:
Node starts without auth it becomes coordinator of its cluster
In the same cluster another node starts with X509 Auth
The node starting with auth succeeds to join to the cluster that is started by the first node instead of creating its own cluster.
The purpose is not to allow the nodes that is with auth and the nodes that is without auth to join with each other.
was:
Node starts without auth it becomes coordinator of its cluster
In the same cluster another node starts with X509 Auth
The node starting with auth succeeds to join to the cluster that is started by the first node instead of creating its own cluster.
> Auth succeeds when the node without auth starts first
> -----------------------------------------------------
>
> Key: JGRP-1946
> URL: https://issues.jboss.org/browse/JGRP-1946
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.6.4
> Environment: jdk 1.7
> Reporter: fatih fatih
> Assignee: Bela Ban
> Attachments: HAController2.java, udp.xml, udp.xml
>
>
> Node starts without auth it becomes coordinator of its cluster
> In the same cluster another node starts with X509 Auth
> The node starting with auth succeeds to join to the cluster that is started by the first node instead of creating its own cluster.
> The purpose is not to allow the nodes that is with auth and the nodes that is without auth to join with each other.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (JGRP-1946) Auth succeeds when the node without auth starts first
by fatih fatih (JIRA)
[ https://issues.jboss.org/browse/JGRP-1946?page=com.atlassian.jira.plugin.... ]
fatih fatih updated JGRP-1946:
------------------------------
Attachment: udp.xml
HAController2.java
udp.xml
one of the udp.xml does not include AUTH property
> Auth succeeds when the node without auth starts first
> -----------------------------------------------------
>
> Key: JGRP-1946
> URL: https://issues.jboss.org/browse/JGRP-1946
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.6.4
> Environment: jdk 1.7
> Reporter: fatih fatih
> Assignee: Bela Ban
> Attachments: HAController2.java, udp.xml, udp.xml
>
>
> Node starts without auth it becomes coordinator of its cluster
> In the same cluster another node starts with X509 Auth
> The node starting with auth succeeds to join to the cluster that is started by the first node instead of creating its own cluster.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (JGRP-1946) Auth succeeds when the node without auth starts first
by fatih fatih (JIRA)
fatih fatih created JGRP-1946:
---------------------------------
Summary: Auth succeeds when the node without auth starts first
Key: JGRP-1946
URL: https://issues.jboss.org/browse/JGRP-1946
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.6.4
Environment: jdk 1.7
Reporter: fatih fatih
Assignee: Bela Ban
Node starts without auth it becomes coordinator of its cluster
In the same cluster another node starts with X509 Auth
The node starting with auth succeeds to join to the cluster that is started by the first node instead of creating its own cluster.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (DROOLS-795) Timers are reset during the serialization process
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-795?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-795:
------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1248429|https://bugzilla.redhat.com/show_bug.cgi?id=1248429] from NEW to ASSIGNED
> Timers are reset during the serialization process
> -------------------------------------------------
>
> Key: DROOLS-795
> URL: https://issues.jboss.org/browse/DROOLS-795
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.3.0.CR1
>
>
> When the marshall serializes a timer it doesn't take count of how much time it is already passed, so when the timer is deserialized it restart from it start time. The following failing test case reproduces the problem.
> {code}
> @Test
> public void testMarshallWithTimedRule() {
> String drl = "rule \"Rule A Timeout\"\n" +
> "when\n" +
> " String( this == \"ATrigger\" )\n" +
> "then\n" +
> " insert (new String( \"A-Timer\") );\n" +
> "System.out.println(\"+++++++Got ATrigger, started A-Timer with 5s timeout\");\n" +
> "end\n" +
> "\n" +
> "rule \"Timer For rule A Timeout\"\n" +
> " timer ( int: 5s )\n" +
> "when\n" +
> " String( this == \"A-Timer\")\n" +
> "then\n" +
> " delete ( \"A-Timer\" );\n" +
> " delete ( \"ATrigger\" );\n" +
> "System.out.println(\"******* reset rule A based on timer\");\n" +
> "end\n";
> KieBase kbase = new KieHelper().addContent( drl, ResourceType.DRL )
> .build( EqualityBehaviorOption.EQUALITY,
> DeclarativeAgendaOption.ENABLED,
> EventProcessingOption.STREAM );
> KieSessionConfiguration sessionConfig = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
> sessionConfig.setOption( ClockTypeOption.get( "pseudo" ) );
> KieSession ksession = kbase.newKieSession(sessionConfig, null);
> ksession.insert( new String( "ATrigger" ) );
> assertEquals( 1, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 2, ksession.getFactCount() );
> SessionPseudoClock clock = ksession.getSessionClock();
> clock.advanceTime( 4, TimeUnit.SECONDS );
> assertEquals( 2, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 2, ksession.getFactCount() );
> ksession = marshallAndUnmarshall( kbase, ksession, sessionConfig);
> clock = ksession.getSessionClock();
> clock.advanceTime( 4, TimeUnit.SECONDS );
> assertEquals( 2, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 0, ksession.getFactCount() );
> }
> public static KieSession marshallAndUnmarshall(KieBase kbase, KieSession ksession, KieSessionConfiguration sessionConfig) {
> // Serialize and Deserialize
> try {
> Marshaller marshaller = KieServices.Factory.get().getMarshallers().newMarshaller(kbase);
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> marshaller.marshall(baos, ksession);
> marshaller = MarshallerFactory.newMarshaller( kbase );
> ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
> baos.close();
> ksession = marshaller.unmarshall(bais, sessionConfig, null);
> bais.close();
> } catch (Exception e) {
> e.printStackTrace();
> fail("unexpected exception :" + e.getMessage());
> }
> return ksession;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (AS7-6911) jconsole fails if trying to connect to a standalone EAP instance running with offset ports
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6911?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6911:
----------------------------------------------
Marek Kopecky <mkopecky(a)redhat.com> changed the Status of [bug 1215278|https://bugzilla.redhat.com/show_bug.cgi?id=1215278] from ON_QA to ASSIGNED
> jconsole fails if trying to connect to a standalone EAP instance running with offset ports
> ------------------------------------------------------------------------------------------
>
> Key: AS7-6911
> URL: https://issues.jboss.org/browse/AS7-6911
> Project: Application Server 7
> Issue Type: Bug
> Components: CLI
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Environment: All
> Reporter: Jay Kumar SenSharma
> Assignee: Stan Silvert
> Labels: cli
>
> If JBoss AS7/8 is started using port-offset as following:
> ie. with -Djboss.socket.binding.port-offset=100
> Then While connecting to it using "jconsole.sh" as a Local Process it throws the following Exception:
> +++++++++++++++++++++++++++++
> Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Error connecting to JBoss AS.
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:80)
> at sun.tools.jconsole.VMPanel.createPluginTabs(VMPanel.java:641)
> at sun.tools.jconsole.VMPanel.propertyChange(VMPanel.java:315)
> at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
> at javax.swing.event.SwingPropertyChangeSupport.firePropertyChange(SwingPropertyChangeSupport.java:75)
> at javax.swing.event.SwingPropertyChangeSupport$1.run(SwingPropertyChangeSupport.java:80)
> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:646)
> at java.awt.EventQueue.access$000(EventQueue.java:84)
> at java.awt.EventQueue$1.run(EventQueue.java:607)
> at java.awt.EventQueue$1.run(EventQueue.java:605)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:616)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.connectCommandContext(JConsoleCLIPlugin.java:109)
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:77)
> +++++++++++++++++++++++
> And the Code "org.jboss.as.cli.gui.JConsoleCLIPlugin" classes Line 109 throws NullPointerException, Because "cliGuiCtx" object is null and not initialized earlier:
> 109 JOptionPane.showMessageDialog(cliGuiCtx.getMainWindow(), message);
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months