November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7626) Datasources subsystem - small user experience enhancements

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-7626?page=com.atlassian.jira.plugin.... ] Stefano Maestri moved JBEAP-7407 to WFLY-7626: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7626 (was: JBEAP-7407) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JCA (was: JCA) (was: User Experience) > Datasources subsystem - small user experience enhancements > ---------------------------------------------------------- > > Key: WFLY-7626 > URL: https://issues.jboss.org/browse/WFLY-7626 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Stefano Maestri > Assignee: Stefano Maestri > Priority: Minor > Labels: user_experience > > This jira contains some small typo findings and suggestions for user experience enhancements when working with the {{datasources}} subsystem: > 1, Schema file contains a typo on line 1037: "Thios tag is not used ..." -> "This tag is not used ...". > 2, Description for {{flush-strategy}} attribute on both {{data-source}} and {{xa-data-source}} says there are only three valid values, when in fact there are ten. When setting the attribute value to something invalid, the error message correctly lists all ten, except {{UNKNOWN}} is listed as {{null}}. > 3, Description of {{pool-fair}} attribute on both {{data-source}} and {{xa-data-source}} has, IMHO, weird word order: "Defines if pool should use be fair" -> "Defines if pool use should be fair". > 4, Although the description of the attribute {{transaction-isolation}} lists valid values for the attribute, there is no validation. It is possible to assign any value to the attribute. Could the validation be added in a similar manner like it exists for {{flush-strategy}} attribute? This is the case for the attribute on both {{data-source}} and {{xa-data-source}}. > 5, The description of {{background-validation}} attribute on {{data-source}} and {{xa-data-source}} says server needs restart when the attribute value is changed on an enabled data source. However, it's {{restart-required}} value is {{no-services}} and the CLI does not warn the user that server needs to be restarted once the {{background-validation}} value is actually changed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7625) Documentation enhancements in JCA scheme file

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-7625?page=com.atlassian.jira.plugin.... ] Stefano Maestri moved JBEAP-7406 to WFLY-7625: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7625 (was: JBEAP-7406) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JCA (was: JCA) (was: User Experience) Affects Version/s: (was: 7.1.0.DR7) > Documentation enhancements in JCA scheme file > --------------------------------------------- > > Key: WFLY-7625 > URL: https://issues.jboss.org/browse/WFLY-7625 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Stefano Maestri > Assignee: Stefano Maestri > Priority: Minor > > Some parts of the JCA scheme file ({{docs/schema/wildfly-jca_4_0.xsd}}) could use some improvements. It's nothing critical, the docs inside are already pretty good. > 1, {{short-running-threads}} vs. {{long-running threads}} - no description for these. What's the difference between the two and why would I want to configure them separately? > 2, {{bootstrap-context}} - I wasn't able to infer its function based on the descriptions of its attributes, maybe a better description on the {{bootstrap-contexts}} element would help. > 3, {{cached-connection-managerType}} has no description in its child elements. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7624) Inconsistency between DMR and XSD representation of key-store attribute of Elytron key-managers and trust-managers

by Ondrej Kotek (JIRA)

[ https://issues.jboss.org/browse/WFLY-7624?page=com.atlassian.jira.plugin.... ] Ondrej Kotek updated WFLY-7624: ------------------------------- Summary: Inconsistency between DMR and XSD representation of key-store attribute of Elytron key-managers and trust-managers (was: Inconsistency between DMR and XSD representation of key-store attribute of Elytron key-managers) > Inconsistency between DMR and XSD representation of key-store attribute of Elytron key-managers and trust-managers > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-7624 > URL: https://issues.jboss.org/browse/WFLY-7624 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Kotek > Assignee: Darran Lofthouse > Labels: user_experience > > There are inconsistencies between DMR and XSD representation of {{key-managers}}. According to XSD, {{key-store}} is optional, but according to DMR it is {{"nillable" => false}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7624) Inconsistency between DMR and XSD representation of key-store attribute of Elytron key-managers and trust-managers

by Ondrej Kotek (JIRA)

[ https://issues.jboss.org/browse/WFLY-7624?page=com.atlassian.jira.plugin.... ] Ondrej Kotek updated WFLY-7624: ------------------------------- Description: There are inconsistencies between DMR and XSD representation of {{key-managers}} and {{trust-managers}}. According to XSD, {{key-store}} is optional, but according to DMR it is {{"nillable" => false}}. was: There are inconsistencies between DMR and XSD representation of {{key-managers}}. According to XSD, {{key-store}} is optional, but according to DMR it is {{"nillable" => false}}. > Inconsistency between DMR and XSD representation of key-store attribute of Elytron key-managers and trust-managers > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-7624 > URL: https://issues.jboss.org/browse/WFLY-7624 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Kotek > Assignee: Darran Lofthouse > Labels: user_experience > > There are inconsistencies between DMR and XSD representation of {{key-managers}} and {{trust-managers}}. According to XSD, {{key-store}} is optional, but according to DMR it is {{"nillable" => false}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2133) ASYM_ENCRYPT / AUTH: prevent man-in-the-middle attacks on key exchange

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2133?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2133: --------------------------- Security Sensitive Issue: This issue is security relevant > ASYM_ENCRYPT / AUTH: prevent man-in-the-middle attacks on key exchange > ---------------------------------------------------------------------- > > Key: JGRP-2133 > URL: https://issues.jboss.org/browse/JGRP-2133 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.1 > > > When a new member fetches the shared (secret) key from the keyserver (coordinator), the requester sends ist public key with the key request and the keyserver encrypts the secret key with the requester's public key, so that only the requester can decrypt the message with its private key. > However, this initial exchange of the shared key is prone to MIM attacks [1]. The same applies to AUTH and asymmetric authentication, e.g. challenge-response. > Goal: replace the secret key exchange in ASYM_ENCRYPT and ChallengeResponseToken with code that is not prone to MIM attacks. > Possible solutions: > * Diffie-Hellman-Merkle to establish a secret session key only for the key exchange (not used after that). > * Use of certificates: public keys sent with the initial shared key request are signed by the CA and verified by the keyserver when a shared key request is received > \[1\] https://en.wikipedia.org/wiki/Man-in-the-middle_attack -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2133) ASYM_ENCRYPT / AUTH: prevent man-in-the-middle attacks on key exchange

by Bela Ban (JIRA)

Bela Ban created JGRP-2133: ------------------------------ Summary: ASYM_ENCRYPT / AUTH: prevent man-in-the-middle attacks on key exchange Key: JGRP-2133 URL: https://issues.jboss.org/browse/JGRP-2133 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.1 When a new member fetches the shared (secret) key from the keyserver (coordinator), the requester sends ist public key with the key request and the keyserver encrypts the secret key with the requester's public key, so that only the requester can decrypt the message with its private key. However, this initial exchange of the shared key is prone to MIM attacks [1]. The same applies to AUTH and asymmetric authentication, e.g. challenge-response. Goal: replace the secret key exchange in ASYM_ENCRYPT and ChallengeResponseToken with code that is not prone to MIM attacks. Possible solutions: * Diffie-Hellman-Merkle to establish a secret session key only for the key exchange (not used after that). * Use of certificates: public keys sent with the initial shared key request are signed by the CA and verified by the keyserver when a shared key request is received \[1\] https://en.wikipedia.org/wiki/Man-in-the-middle_attack -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1365) directory of images for drools-docs is not where it should be

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1365?page=com.atlassian.jira.plugi... ] Geoffrey De Smet reassigned DROOLS-1365: ---------------------------------------- Assignee: Michael Biarnes Kiefer (was: Geoffrey De Smet) > directory of images for drools-docs is not where it should be > ------------------------------------------------------------- > > Key: DROOLS-1365 > URL: https://issues.jboss.org/browse/DROOLS-1365 > Project: Drools > Issue Type: Bug > Components: docs > Affects Versions: 6.5.0.Final > Reporter: Michael Biarnes Kiefer > Assignee: Michael Biarnes Kiefer > > I see that the images 1.png, 2.png and 3.png are not anymore available under: > https://docs.jboss.org/drools/release/6.5.0.Final/drools-docs/html/images... (where they normally are supposed to be) > I saw on filemgmt.jboss.org, that these images are now in: > https://docs.jboss.org/drools/release/6.5.0.Final/drools-docs/html/images... > Maybe the URL si not constructed good, so "community/docbook" is missing? > What to do here? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1365) directory of images for drools-docs is not where it should be

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1365?page=com.atlassian.jira.plugi... ] Geoffrey De Smet commented on DROOLS-1365: ------------------------------------------ Looks like normal images are copied fine, but the jdocbook style images aren't. Those "common" images (such as callbacks and jboss logo etc) come from: https://github.com/pressgang/maven-jdocbook-style-plugin They are used by https://github.com/pressgang/pressgang-tools/tree/master/pressgang-xslt-ns which is called by https://github.com/pressgang/maven-jdocbook-plugin Check if it happens on the 6.4.0.final build too (with the same JDK etc). Compare the "mvn help:effective-pom" on version of maven-jdocbook-style-plugin, pressgang-xslt-ns and maven-jdocbook-plugin. > directory of images for drools-docs is not where it should be > ------------------------------------------------------------- > > Key: DROOLS-1365 > URL: https://issues.jboss.org/browse/DROOLS-1365 > Project: Drools > Issue Type: Bug > Components: docs > Affects Versions: 6.5.0.Final > Reporter: Michael Biarnes Kiefer > Assignee: Geoffrey De Smet > > I see that the images 1.png, 2.png and 3.png are not anymore available under: > https://docs.jboss.org/drools/release/6.5.0.Final/drools-docs/html/images... (where they normally are supposed to be) > I saw on filemgmt.jboss.org, that these images are now in: > https://docs.jboss.org/drools/release/6.5.0.Final/drools-docs/html/images... > Maybe the URL si not constructed good, so "community/docbook" is missing? > What to do here? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2015) CLI is unable to connect to EAP with undefined security-realm

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2015?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2015: ------------------------------------- Fix Version/s: 3.0.0.Alpha13 > CLI is unable to connect to EAP with undefined security-realm > ------------------------------------------------------------- > > Key: WFCORE-2015 > URL: https://issues.jboss.org/browse/WFCORE-2015 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 3.0.0.Alpha12 > Reporter: Marek Kopecký > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Alpha13 > > > *Description of problem:* > CLI is unable to connect to EAP with undefined security-realm > This is regression against EAP 7.0.0, 6.4.0 and 7.1.0.DR7. > *How reproducible:* > Always > *Steps to Reproduce:* > # /core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm) > # reload > *Actual results:* > {noformat} > [mkopecky@dhcp-10-40-4-180 bin]$ ./jboss-cli.sh -c > [standalone@localhost:9990 /] /core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone@localhost:9990 /] reload > Interrupted while pausing before reconnecting.: sleep interrupted > [disconnected /] > [mkopecky@dhcp-10-40-4-180 bin]$ ./jboss-cli.sh -c > Failed to connect to the controller: Unable to authenticate against controller at localhost:9990: Authentication failed: none of the mechanisms presented by the server are supported > [mkopecky@dhcp-10-40-4-180 bin]$ > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7624) Inconsistency between DMR and XSD representation of key-store attribute of Elytron key-managers

by Ondrej Kotek (JIRA)

[ https://issues.jboss.org/browse/WFLY-7624?page=com.atlassian.jira.plugin.... ] Ondrej Kotek updated WFLY-7624: ------------------------------- Description: There are inconsistencies between DMR and XSD representation of {{key-managers}}. According to XSD, {{key-store}} is optional, but according to DMR it is {{"nillable" => false}}. was: There are inconsistencies between DMR and XSD representation of {{key-managers}}. According to XSD, {{key-store}} is optional, but according to DMR it is {{"nillable" => false}}. Opposite for {{credential-reference}}, see WFLY-7435. > Inconsistency between DMR and XSD representation of key-store attribute of Elytron key-managers > ----------------------------------------------------------------------------------------------- > > Key: WFLY-7624 > URL: https://issues.jboss.org/browse/WFLY-7624 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Kotek > Assignee: Darran Lofthouse > Labels: user_experience > > There are inconsistencies between DMR and XSD representation of {{key-managers}}. According to XSD, {{key-store}} is optional, but according to DMR it is {{"nillable" => false}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 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 November 2016