March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11923) Elytron JDBC Realm hex encoding and modular crypt support.

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-11923?page=com.atlassian.jira.plugin... ] Darran Lofthouse moved EAP7-1234 to WFLY-11923: ----------------------------------------------- Project: WildFly (was: EAP 7 Planning Pilot) Key: WFLY-11923 (was: EAP7-1234) Issue Type: Feature Request (was: Requirement) Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 2.0) Component/s: Security (was: Security) EAP PT Pre-Checked (PC): (was: TODO) Target Release: (was: 7.3.0.GA) EAP PT Community Docs (CD): (was: TODO) EAP PT Product Docs (PD): (was: New) EAP PT Test Dev (TD): (was: TODO) EAP PT Docs Analysis (DA): (was: TODO) EAP PT Test Plan (TP): (was: TODO) EAP PT Analysis Document (AD): (was: TODO) Writer: (was: Chuck Copello) > Elytron JDBC Realm hex encoding and modular crypt support. > ---------------------------------------------------------- > > Key: WFLY-11923 > URL: https://issues.jboss.org/browse/WFLY-11923 > Project: WildFly > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Labels: EAP-CD17 > > This relates to the following issues: - > https://issues.jboss.org/browse/WFCORE-3542 > https://issues.jboss.org/browse/WFCORE-3832 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4302) SNI wildcard mappings match multiple level of subdomain

by Jan Stourac (Jira)

[ https://issues.jboss.org/browse/WFCORE-4302?page=com.atlassian.jira.plugi... ] Jan Stourac commented on WFCORE-4302: ------------------------------------- [~mmazanek], I understand your point. Although, actually the correct variant is: {code} host-context-map={".*\\..*\\.example\\.com"=defaultSSC, "[^.]*\\.example\\.com"=asteriskSSC} {code} or simply {code} host-context-map={"[^.]*\\.example\\.com"=asteriskSSC} {code} Yeah... so user has to be aware that he has to provide correct regular expression instead of a simple notation. > SNI wildcard mappings match multiple level of subdomain > ------------------------------------------------------- > > Key: WFCORE-4302 > URL: https://issues.jboss.org/browse/WFCORE-4302 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 7.0.0.Final > Environment: Wildfly build with undertow and wildfly-core modules build from following sources: > * https://github.com/stuartwdouglas/undertow/tree/sni > * https://github.com/stuartwdouglas/wildfly-core/tree/sni > Reporter: Pavel Jelinek > Assignee: Martin Mazanek > Priority: Major > Labels: SNI > > Based on the [text from analasys|https://github.com/wildfly/wildfly-proposals/blob/master/securit...]: > {quote} > Wildcard names use * as a wildcard, and can only be used to match a single level of subdomain in much the same way as with wildcard certificates. > {quote} > As such, in case I have configured SNI mapping for: > {code} > .*\\.example\\.com > {code} > I expect that this mapping is selected for any single level of subdomain of example.com although, in case of any extra subdomain, this mapping is not utilized. In other words, following hostnames should match: > {code} > test.example.com > another-test.example.com > {code} > although following should not be matched and default server-ssl-context shall be used instead: > {code} > two-sublevel.one-sublevel.example.com > {code} > Current behaviour also matches also 'two-sublevel.one-sublevel.example.com'. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession

by David White (Jira)

[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ] David White commented on JGRP-2299: ----------------------------------- It appears that the NullPointerException that occurs during the unlock operation and the compareTo method in the Owner class is "benign" and can be recovered from. In my application, if I add a try/catch block around the unlock operation and trap the NullPointerException and try the unlock a second time it succeeds. It truly does succeed because our concurrent processes continue and are able to lock/unlock the resource and complete successfully. > LockService does not work correctly if unlock/lock is called in immediate succession > ------------------------------------------------------------------------------------ > > Key: JGRP-2299 > URL: https://issues.jboss.org/browse/JGRP-2299 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.15 > Environment: Windows 10 Oracle JDK 1.8 131 > AIX IBM Java 8 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.1 > > Attachments: JGroupsExample.java, udp+lock.xml > > > In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected. > This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded. > If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock(). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11818) wildfly-16.0.0.Final: "From address" is no more used as default from in email

by Yeray Borges (Jira)

[ https://issues.jboss.org/browse/WFLY-11818?page=com.atlassian.jira.plugin... ] Yeray Borges resolved WFLY-11818. --------------------------------- Resolution: Cannot Reproduce > wildfly-16.0.0.Final: "From address" is no more used as default from in email > ----------------------------------------------------------------------------- > > Key: WFLY-11818 > URL: https://issues.jboss.org/browse/WFLY-11818 > Project: WildFly > Issue Type: Bug > Components: Mail > Affects Versions: 16.0.0.Final > Environment: mvn -v > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T20:41:47+02:00) > Maven home: /apps/apache-maven-3.6.0 > Java version: 11.0.2, vendor: Oracle Corporation, runtime: /usr/java/jdk-11.0.2 > Default locale: de_DE, platform encoding: UTF-8 > OS name: "linux", version: "4.12.14-lp150.12.48-default", arch: "amd64", family: "unix" > Reporter: Wolfgang Mayer > Assignee: Yeray Borges > Priority: Major > > As mentioned in the Help (description) of 'Mail Session' configuration: > From: *From address that is used as default from, if not set when sending* > Apparently this is not the case anymore in wildfly-16.0.0.Final. > For example I made a test with quickstart-16.0/mail/. > When omitting the line > *message.setFrom(new InternetAddress(from));* > Sending mail fails with: > com.sun.mail.smtp.SMTPSendFailedException: 554-Transaction failed > 554 Unauthorized sender address. > I have the same issue when replacing the line above with > message.setFrom(new InternetAddress()); > I am pretty sure that this is working in wildfly-15 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-102) SNI - hostname notation for sni-mapping element does not conform generic rules

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFWIP-102?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFWIP-102: ---------------------------------------- I suspect further changes would be unlikely as this could already be in use on CD releases. > SNI - hostname notation for sni-mapping element does not conform generic rules > ------------------------------------------------------------------------------ > > Key: WFWIP-102 > URL: https://issues.jboss.org/browse/WFWIP-102 > Project: WildFly WIP > Issue Type: Bug > Environment: Wildfly build with undertow and wildfly-core modules build from following sources: > * https://github.com/stuartwdouglas/undertow/tree/sni > * https://github.com/stuartwdouglas/wildfly-core/tree/sni > Reporter: Jan Stourac > Assignee: Darran Lofthouse > Priority: Major > > Way of configuration of {{sni-mapping}} element in {{server-ssl-sni-context}} is not nice from UX and also does not conform the way it is generally used. > With current implementation administrator has to use following notation: > {code} > .*\.example\.com > {code} > This is standard reg-exp notation and is not for easy reading. I think following notation is much better and also is commonly used for this cases: > {code} > *.example.com > {code} > In other words - simple asterisk is used to match any subdomain and dot in our case does not stand for 'any single character'. Note that is the way it was described in [analysis document|https://github.com/wildfly/wildfly-proposals/pull/67/files#diff-...]. > Truth is that with this change we loose some flexibility, e.g. administrator won't be able to configure following: > {code} > www\.exa.ple\.com > {code} > But I doubt this is a common use case. WDYT? -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-102) SNI - hostname notation for sni-mapping element does not conform generic rules

by Jan Stourac (Jira)

[ https://issues.jboss.org/browse/WFWIP-102?page=com.atlassian.jira.plugin.... ] Jan Stourac commented on WFWIP-102: ----------------------------------- [~dlofthouse], is it still viable to implement this? If implemented this means necessity of change in some customer configurations. Current behavior has been brought into WildFly 15/JBoss EAP CD15. If we want to change it, then we should do so before EAP7.3 release as any such change in the product is even more problematic, I suppose. My personal opinion on this is that current expected format is not very user friendly. > SNI - hostname notation for sni-mapping element does not conform generic rules > ------------------------------------------------------------------------------ > > Key: WFWIP-102 > URL: https://issues.jboss.org/browse/WFWIP-102 > Project: WildFly WIP > Issue Type: Bug > Environment: Wildfly build with undertow and wildfly-core modules build from following sources: > * https://github.com/stuartwdouglas/undertow/tree/sni > * https://github.com/stuartwdouglas/wildfly-core/tree/sni > Reporter: Jan Stourac > Assignee: Darran Lofthouse > Priority: Major > > Way of configuration of {{sni-mapping}} element in {{server-ssl-sni-context}} is not nice from UX and also does not conform the way it is generally used. > With current implementation administrator has to use following notation: > {code} > .*\.example\.com > {code} > This is standard reg-exp notation and is not for easy reading. I think following notation is much better and also is commonly used for this cases: > {code} > *.example.com > {code} > In other words - simple asterisk is used to match any subdomain and dot in our case does not stand for 'any single character'. Note that is the way it was described in [analysis document|https://github.com/wildfly/wildfly-proposals/pull/67/files#diff-...]. > Truth is that with this change we loose some flexibility, e.g. administrator won't be able to configure following: > {code} > www\.exa.ple\.com > {code} > But I doubt this is a common use case. WDYT? -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-678) Review Priority of Jupiter Test Cases

by Hayk Hovsepyan (Jira)

[ https://issues.jboss.org/browse/SWSQE-678?page=com.atlassian.jira.plugin.... ] Hayk Hovsepyan resolved SWSQE-678. ---------------------------------- Resolution: Done > Review Priority of Jupiter Test Cases > ------------------------------------- > > Key: SWSQE-678 > URL: https://issues.jboss.org/browse/SWSQE-678 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Hayk Hovsepyan > Priority: Major > Labels: pqi > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3809) DMN DT Analysis Bound sort for gaps overlaps and normalization

by Matteo Mortari (Jira)

[ https://issues.jboss.org/browse/DROOLS-3809?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-3809: ----------------------------------- Description: Normalization causing ConcurrentModificationException Wrong Bound sorting leads to wrong analysis of Gaps and Overlaps Fixing human friendly representation of single value in discrete domain was: Normalization causing ConcurrentModificationException Wrong bound sorting leads to wrong analysis of Gaps and Overlaps Fixing human friendly representation of single value in discrete domain > DMN DT Analysis Bound sort for gaps overlaps and normalization > -------------------------------------------------------------- > > Key: DROOLS-3809 > URL: https://issues.jboss.org/browse/DROOLS-3809 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > > Normalization causing ConcurrentModificationException > Wrong Bound sorting leads to wrong analysis of Gaps and Overlaps > Fixing human friendly representation of single value in discrete domain -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3809) DMN DT Analysis Bound sort for gaps overlaps and normalization

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-3809: -------------------------------------- Summary: DMN DT Analysis Bound sort for gaps overlaps and normalization Key: DROOLS-3809 URL: https://issues.jboss.org/browse/DROOLS-3809 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari Normalization causing ConcurrentModificationException Wrong bound sorting leads to wrong analysis of Gaps and Overlaps Fixing human friendly representation of single value in discrete domain -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4395) The single mapper validation added via WFCORE-2364 happens at Runtime, this should be a Model time check.

by Darran Lofthouse (Jira)

Darran Lofthouse created WFCORE-4395: ---------------------------------------- Summary: The single mapper validation added via WFCORE-2364 happens at Runtime, this should be a Model time check. Key: WFCORE-4395 URL: https://issues.jboss.org/browse/WFCORE-4395 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Darran Lofthouse Fix For: 9.0.0.Beta2 If possible the mappers should be flagged as being mutually exclusive, however failing that the validation should happen during Stage.MODEL. Presently this leads to an unsatisifed dependency: - {noformat} 14:21:59,055 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "elytron"), ("security-domain" => "demon-domain") ]) - failure description: { "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.demo-realm"], "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.security-domain.demon-domain.initial is missing [org.wildfly.security.security-realm.demo-realm]"] } {noformat} Despite this error the underlying cause is not logged at any level. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
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 March 2019