[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1877.
----------------------------
Resolution: Done
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1877:
---------------------------
Fix Version/s: (was: 3.5.1)
Removed 3.5.1 fro fix set as this issue is not critical anymore
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (SECURITY-851) Base64Utils class cuts leading zeroes from encoded bytes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-851?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-851:
--------------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1125004|https://bugzilla.redhat.com/show_bug.cgi?id=1125004] from ASSIGNED to MODIFIED
> Base64Utils class cuts leading zeroes from encoded bytes
> --------------------------------------------------------
>
> Key: SECURITY-851
> URL: https://issues.jboss.org/browse/SECURITY-851
> Project: PicketBox
> Issue Type: Bug
> Affects Versions: PicketBox_4_0_21.Beta2
> Reporter: Josef Cacek
> Assignee: Josef Cacek
> Priority: Blocker
> Fix For: PicketBox_4_0_21.Beta4
>
>
> Vault util is failing for some password/salt/iteration combinations because Base64Utils class strips zeroes from provided byte array.
> So if a user encodes a key with length 8 and the leading byte of the key is zero, then after decoding he only gets 7 (or less) bytes.
> For instance:
> {code}
> encode ( { 0, 81, 121, -37, 46, -64, 20, 114 } ) -> "1HUTikm1Ho"
> decode ("1HUTikm1Ho") -> { 81, 121, -37, 46, -64, 20, 114 }
> {code}
> As a result the PBEUtil will fail with javax.crypto.IllegalBlockSizeException.
> IMHO the same problem can occur on other places where the Base64Utils class is used (not only the Vault).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (DROOLS-601) Using queries in combination with agenda-groups leads to wrong firings
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-601:
----------------------------------
Summary: Using queries in combination with agenda-groups leads to wrong firings
Key: DROOLS-601
URL: https://issues.jboss.org/browse/DROOLS-601
Project: Drools
Issue Type: Bug
Affects Versions: 6.2.0.Beta1, 6.1.0.Final
Reporter: Mario Fusco
Assignee: Mark Proctor
When running the following test case:
{code}
@Test
public void testQueryWithAgendaGroup() {
String drl =
"package org.drools.test; " +
"global java.util.List list; " +
"query foo( Integer $i ) " +
" $i := Integer() " +
"end " +
"rule Detect " +
"agenda-group 'one' " +
"when " +
" foo( $i ; ) " +
"then " +
" list.add( $i ); " +
"end " +
"rule OnceMore " +
"agenda-group 'two' " +
"no-loop " +
"when " +
" $i : Integer() " +
"then " +
" update( $i );" +
"end " +
"";
KieHelper helper = new KieHelper();
helper.addContent( drl, ResourceType.DRL );
KieSession kieSession = helper.build().newKieSession();
List<Integer> list = new ArrayList<Integer>();
kieSession.setGlobal( "list", list );
FactHandle handle = kieSession.insert( 42 );
Agenda agenda = kieSession.getAgenda();
agenda.getAgendaGroup("two").setFocus();
agenda.getAgendaGroup("one").setFocus();
kieSession.fireAllRules();
assertEquals( Arrays.asList( 42 ), list );
kieSession.delete( handle );
kieSession.insert( -99 );
agenda.getAgendaGroup("two").setFocus();
agenda.getAgendaGroup("one").setFocus();
kieSession.fireAllRules();
assertEquals( Arrays.asList( 42, -99 ), list );
}
{code}
The "Detect" rule, the one containing the query, fires twice with 42 even if the second time that fact shold be already been deleted. In particular the sequence of relevant events when running this test is the following:
1. 1st fire, 42 updated
1.1. process update in PhreakRuleTerminalNode of OnceMore
1.1.1. blocked by no-loop
1.2. process update in PhreakQueryTerminalNode
1.2.1. update added to leftTupleSets of queryResult
1.2.2. rule Detect doesn't fire again because it is in an inactive agenda-group
2. 42 deleted
2.1. the deleted factHandle refers to the RTNLeftTuple that is then added to the deleted leftTupleSets of the LIANode having as sink the RTN of rule OnceMore. Unfortunately there's no relationship between the deleted factHandle and the query activated by that fact.
3. 2nd fire
3.1. now AG "one" has focus so evaluates PhreakRuleTerminalNode of Detect using the updated leftTuple of point 1.2.1. - ERROR!!!
3.2. process deleted 42 and inserted -99 in PhreakRuleTerminalNode of OnceMore
3.3. process deleted 42 and inserted -99 in PhreakQueryTerminalNode, doesn't fire it because AG "one" is not active
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3850) NPE Deploying EJB @WebService without Security Domain
by Seth Miller (JIRA)
[ https://issues.jboss.org/browse/WFLY-3850?page=com.atlassian.jira.plugin.... ]
Seth Miller commented on WFLY-3850:
-----------------------------------
Fixed with merge in 9.0.0.Alpha.
> NPE Deploying EJB @WebService without Security Domain
> -----------------------------------------------------
>
> Key: WFLY-3850
> URL: https://issues.jboss.org/browse/WFLY-3850
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Web (JBoss Web)
> Affects Versions: 8.1.0.Final
> Reporter: Seth Miller
> Assignee: David Lloyd
>
> Disable EJB security interceptors by altering the standalone.xml ejb subsystem to remove the security domain, then deploy an .ear file with a @WebService within an EJB. The EAR will fail to deploy with the following:
> {code}
> Caused by: java.lang.NullPointerException
> at org.jboss.as.webservices.tomcat.AbstractSecurityMetaDataAccessorEJB.getSecurityDomain(AbstractSecurityMetaDataAccessorEJB.java:63)
> at org.jboss.as.webservices.tomcat.WebMetaDataCreator.createJBossWebAppDescriptor(WebMetaDataCreator.java:120)
> at org.jboss.as.webservices.tomcat.WebMetaDataCreator.create(WebMetaDataCreator.java:80)
> at org.jboss.as.webservices.tomcat.WebMetaDataCreatingDeploymentAspect.start(WebMetaDataCreatingDeploymentAspect.java:41)
> at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
> ... 5 more
> {code}
> Workaround:
> To keep security interceptors disabled on all other EJBs, annotate @WebService classes with a security domain: @SecurityDomain("other") via the pom.xml dependency:
> {code}
> <dependency>
> <groupId>org.jboss.ejb3</groupId>
> <artifactId>jboss-ejb3-ext-api</artifactId>
> <version>${version.org.jboss.ejb3.ext-api}</version>
> <scope>provided</scope>
> </dependency>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-84) Jasper using wrong ProtectionDomain for compiled JSP
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-84?page=com.atlassian.jira.plugin.sy... ]
Jason Greene updated WFLY-84:
-----------------------------
Fix Version/s: 9.0.0.Beta1
(was: 9.0.0.Alpha1)
> Jasper using wrong ProtectionDomain for compiled JSP
> ----------------------------------------------------
>
> Key: WFLY-84
> URL: https://issues.jboss.org/browse/WFLY-84
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: David Lloyd
> Assignee: Remy Maucherat
> Fix For: 9.0.0.Beta1
>
>
> Compiled JSPs loaded via JasperLoader appear to be using a different ProtectionDomain than the rest of the WAR deployment. I think it should probably be using a PD which contains the permissions from the deployment's ClassLoader, and probably the CodeSource from the deployment unit from which the JSP file originated. This will ensure that permissions set via deployment descriptor and/or the management model will take proper effect.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-466) Detect JBossWS Configuration for @PermitAll endpoints within Undertow subsystem.
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-466?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-466:
------------------------------
Fix Version/s: 9.0.0.Beta1
(was: 9.0.0.Alpha1)
> Detect JBossWS Configuration for @PermitAll endpoints within Undertow subsystem.
> --------------------------------------------------------------------------------
>
> Key: WFLY-466
> URL: https://issues.jboss.org/browse/WFLY-466
> Project: WildFly
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.Beta1
>
>
> UNDERTOW-38 has added the possibility of deploying web applications where authentication is mandated but no authorization checks are performed - this is required for integration use cases such as EJB endpoints where authorization checks are being left to the EJB container.
> This task is to update the Undertow susbsystem to detect this scenario and enable the new mode for UNDERTOW-38.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years